[cabf_validation] Agenda

[Ryan Sleevi]

Unfortunately, we had a bunch of people making unattributed edits.

These edits attempted to introduce requirements that aren't already part of
the BRs, and because they were unattributed (the user was not signed in),
it's not possible for our IP policy to determine who made that suggestion.

I've restricted the document to comment-only, to avoid that risk, and ask
that folks suggesting edits identify themselves, and I'll be happy to make
those edits.

However, there's also an important question, which Doug raised several
times with suggestions, which is whether or not we should introduce new
normative requirements at this time. In what may come as a surprise to some
people, I'm not supportive of that, at least not at this stage.

I think it's important that we try to capture and document what our
existing requirements are (i.e. what's already part of the BRs), as well as
areas that might logically be interpreted even when not explicitly stated.
For example, what the value of the "localityName" for a CA certificate
"should" be, and what validation rules, if any, apply.

By focusing on this, we can make sure that whatever is presently allowed is
clear.

I'm very much supportive of tightening the normative requirements, and
reducing the flexibility being inferred with our current structure.
Concretely, my objective here is to get to very tight profiles, especially
with respect to standard (RFC 5280) fields. But I think that's the last
step, and I worry that doing so now will only distract from the evaluation
about whether our current requirements are accurately reflected (i.e. is
there a default-deny type of disagreement)

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200410/40bec6af/attachment.html>