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