> On Feb 27, 2017, at 4:29 PM, Ryan Sleevi <[email protected]> wrote:
>
>
>
> On Mon, Feb 27, 2017 at 4:22 PM, Peter Bowen <[email protected]
> <mailto:[email protected]>> 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.
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
