[cabfpub] CA/Browser Forum ASN.1 module

Ryan Sleevi sleevi at google.com
Mon Feb 27 17:29:52 MST 2017


On Mon, Feb 27, 2017 at 4:22 PM, Peter Bowen <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)


> 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170227/f762a069/attachment.html>


More information about the Public mailing list