[cabf_validation] Clarification of BRs to address "default deny" implications

Wed Feb 26 00:22:45 MST 2020

Here's another one in 7.1.4.2.2 i.

"i. Certificate Field: subject:organizationalUnitName (OID: 2.5.4.11) 
Optional. The CA SHALL implement a process that prevents an OU attribute 
from including a name, DBA, tradename, trademark, address, location, or 
other text that refers to a specific natural person or Legal Entity 
unless the CA has verified this information in accordance with Section 
3.2 *and the Certificate also contains subject:organizationName, 
subject:givenName, subject:surname, subject:localityName, and 
subject:countryName* attributes, also verified in accordance with 
Section 3.2.2.1."

With a "default deny" interpretation, perhaps this means that OUs cannot 
be included unless the Certificate includes ALL of these fields. I think 
this is a poorly worded section anyway, regardless of the default 
allow/deny issue :-)

Dimitris.

On 2020-02-19 9:49 π.μ., Doug Beattie via Validation wrote:
> This is my attempt to list the important sections of the BRs and get comments on where "default deny" is not clear or will break things.  This is one way to review the BRs, perhaps not the best, but this will get the discussions moving to address sections of the BRs which are not 100% clear:
>
> https://docs.google.com/document/d/1i3CvNbd6mHI9KYYith94C7RQ-ny6ibuo7x7j7m9hSM4/edit
>
>
>
> Here is one obvious example, 4.9.10:
>
>       OCSP responders operated by the CA SHALL support the HTTP GET method, as described in RFC 6960 and/or RFC 5019.
>
> If we were to take a "default deny" view of this, then POST is prohibited.  If "default deny is the only reasonable way to interpret the BRs", then we need to fix this statement and others like it.
>
> During the VWG meeting yesterday there was a suggestion to review the lists to be sure that they are clearly either "the" list, or if it's a sample of the list (others permitted).  If anyone wants to review this and supply their comments, then that would be great.  We can collect up the recommended changes from this document into a clarification ballot, or ballots.
>
> Doug
>
>
>
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20200226/031302c6/attachment.html>