[cabfpub] CA/Browser Forum ASN.1 module

Peter Bowen pzb at amzn.com
Mon Feb 27 17:22:45 MST 2017


> On Feb 27, 2017, at 1:34 PM, Ryan Sleevi <sleevi at google.com> wrote:
> 
> 
> 
> On Mon, Feb 27, 2017 at 12:35 PM, Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>> wrote:
> First, the modules in the current X.520 SelectedAttributes module all use UnboundedDirectoryString, while we expect upper bounds on some strings. 
> 
> Fair enough, although RFC 5280 defines these upper bounds, and 5280 is normative. I think the subtlety of 5280 vs X.520 may be lost for some members, so I think it's reasonable here, although RFC 5912 may be suitable for incorporation.

I’ll compare RFC 5912 and the ITU-T Ed. 8 ASN.1 and make sure that I’m not conflicting incompatibly.

> Second, the BRs and EVGs have redefined the content of the attributes vis-a-vis X.520, so I think it makes sense to have our own version.
> 
> I think this is a much more compelling argument, since we've certainly seen some confusion from members with respect to the normative constraints of what this content must cover. Despite the Baseline Requirements defining rules for the validation/verification of this information, the question of what this contains (e.g. "country") is surprisingly one that's tripped up more than a few member CAs.

Given this, would it make sense to add comments about what content is allowed for certain attributes?  Right now the syntax is defined but not the permitted content.

> Thanks for pointing out both of these issues.
>  
> > I found a couple of errors in the tor appendix.  I think I got the intent right, but can someone please confirm?
> >
> > Can you clarify the errors you see? A quick visual scan only shows the differences being the introduction of the EXTENSION .. IDENTIFIED BY syntax, is that correct?
> 
> cabf-caSigningNonce OBJECT IDENTIFIER ::= { cabf 41 }
> cabf-applicantSigningNonce OBJECT IDENTIFIER ::= { cabf 42 }
> 
> Both of these use a “cabf” definition, but this is not defined anywhere.  I was guessing it is
> cabf ID ::= { joint‐iso‐itu‐t(2) international‐organizations(23) ca‐browser‐forum(140) }
> 
> However it could mean something under 2.23.140 (eg. 2.23.140.3 or so).
> 
> Ah, good point! I believe the 'intent' was 140.1 (consistent with the .onion extension). Jeremy, given that DigiCert is issuing these certificates, can you clarify what you've done in production? 
> 
> Note, it was a 'bug' that we put the .onion extension on the .1 arc, since .1 is for policies at https://cabforum.org/object-registry/ <https://cabforum.org/object-registry/>
Given that it seems that these were never used (see other thread) should we fix this?

Thanks,
Peter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170227/c37d887f/attachment.html>


More information about the Public mailing list