> On Feb 27, 2017, at 11:34 AM, Ryan Sleevi <[email protected]> wrote:
>
>
>
> On Mon, Feb 27, 2017 at 9:25 AM, Peter Bowen via Public <[email protected]>
> wrote:
> There have been some questions about expected ASN.1 grammar for BR & EV
> certificates. I’ve created a module that attempts to collect it all.
>
> Why the duplication of the X.500 attribute definitions, renamed with the
> prefix 'cabf' ? Do the existing set of module definitions not suffice via
> import?
First, the modules in the current X.520 SelectedAttributes module all use
UnboundedDirectoryString, while we expect upper bounds on some strings.
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. For example:
X.520, section 6.5.4: The Business Category attribute type specifies
information concerning the occupation of some common objects, e.g., people. For
example, this attribute provides the facility to interrogate the Directory
about people sharing the same occupation
EVG, section 9.2.4: This field MUST contain one of the following strings:
"Private Organization", "Government Entity", "Business Entity", or
"Non-Commercial Entity" depending upon whether the Subject qualifies under the
terms of Section 8.5.2, 8.5.3, 8.5.4 or 8.5.5 of these Guidelines,
respectively.
To avoid confusion, I suggest we define our own attributes to ensure that CAs
don’t incorrectly assume X.520 is the controlling definition.
> With respect to the EV OIDs, you used the abbreviation joi, which is
> presumably jurisdictionOfIncorporation. However, Ballot 119 was adopted to
> remove the "ofIncorporation" suffix. At the risk of subtle pedantry, I
> suspect this might be better as
>
> id-ev-jursidiction ID ::= {ldap-enterprise microsoft(311) ev(60) 2 1}
> id-ev-jurisdiction-localityName ID ::= {id-ev-jurisdiction 1}
> id-ev-jurisdiction-stateOrProvinceName ID ::= {id-ev-jurisdiction 2}
> id-ev-jurisdiction-countryName ID ::= {id-ev-jurisdiction 3}
>
> I suspect Jody might be able to work with Microsoft's OID maintenance team to
> figure out how Microsoft would prefer 60.2.1 be documented, similar to other
> documents (e.g.
> https://support.microsoft.com/en-us/help/287547/object-ids-associated-with-microsoft-cryptography
> or https://msdn.microsoft.com/en-us/library/ms677614(v=vs.85).aspx )
Happy to make whatever changes are needed here.
> 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).
Thanks,
Peter
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
