[cabf_validation] Agenda

[Tim Hollebeek]

I agree with this.  As we’ve all agreed on the call, not only is the current structure a mess, the structure leaves a lot of ambiguity around what is actually allowed, and in many cases doesn’t match what was actually intended.  I think fixing up the existing requirements to have fewer ambiguities and errors is an necessary step before tightening the profiles up (which is also a useful goal).

 

-Tim

 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Validation
Sent: Friday, April 10, 2020 10:40 AM
To: Doug Beattie <doug.beattie at globalsign.com>
Cc: CABforum3 <validation at cabforum.org>
Subject: Re: [cabf_validation] Agenda

 

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/20200416/dc0aa3d5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20200416/dc0aa3d5/attachment.p7s>