[cabfpub] CA/Browser Forum ASN.1 module

Peter Bowen pzb at amzn.com
Tue Feb 28 00:37:17 UTC 2017

> On Feb 27, 2017, at 4:29 PM, Ryan Sleevi <sleevi at google.com> wrote:
> On Mon, Feb 27, 2017 at 4:22 PM, Peter Bowen <pzb at amzn.com <mailto:pzb at amzn.com>> wrote:
>> 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.
> I'm a little nervous about duplicating content in a way that could be seen as normative. I think one approach to that would be to set the ASN.1 module (either as an appendix or a dedicated Guideline), refer to the appropriate guideline as to the content, and within the Guideline, describe what is permitted.
> How do you feel about that approach? I think you're right that we've had enough subtle slight divergence between the X.500/X.520 idealized DIT and the real-world of the WebPKI, so this seems much less a case of actively 'forking' a spec so much as recognize it's been 'forked' since 2012 (at a minimum, although in practice, much earlier)

I think pointers to the guideline are perfect.  There have been discussions about making the guideline clearer on content.  Maybe we can have a draft for review in RTP and target a vote shortly after.

> Given that it seems that these were never used (see other thread) should we fix this?
> Yeah, given that, let's fix it and do it right. It does sound like the impact of changing OIDs is so minimal that the ecosystem can handle the divergence, and that lets us get our OID arc clean.
> So it sounds like two, possibly three ballots:
> - X.520 vs RFC5280 vs RFC5912 , aligning both the technical content and the descriptive content and adopting it
>   - Option 1 - By updating the EVGs & BRs with this
>   - Option 2 - By adopting as a separate document
> - .onion & Tor cleanup of OID arcs and ASN.1 module (affects EVGs) 
> Does that sound right?

I like Option 1.  I want to make sure that anything we do matches RFC 5280 syntax and ideally X.520 syntax, so anyone using the grammars defined in either can process the certificates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170227/0e73c151/attachment-0003.html>

More information about the Public mailing list