[Servercert-wg] Ballot SC17: Alternative registration numbers for EU certificates

[Tim Hollebeek]

1) That is a reasonable concern, and I think it would be great to clarify the proper encoding.  I’ll see what I can do.

 

2) Do you have any proposed improvements?

 

3) I actually proposed something similar.  There were several threads in this Forum about how to achieve that goal, and they did not reach consensus.  Those discussions highlight the additional complexity of various alternatives, and there’s also the downside of having to iterate with ETSI.

 

-Tim

 

From: Ryan Sleevi <sleevi at google.com> 
Sent: Friday, March 8, 2019 3:30 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Ballot SC17: Alternative registration numbers for EU certificates

 

Tim,

 

There are many great things about the approach being used, although there still remain concerns.

 

Is this perfunctory discussion - e.g. no changes will be accepted or considered - or is this to allow meaningful feedback to be incorporated? It might be useful to know the extent to which the ballot authors are willing to consider. The reference to 'iii' in your list of reasons leave it ambiguous as to whether this was an element considered from that design, or that any ballot is presumed to need to be compatible with that design.

 

Examples include:

1) X.520 defines organizationIdentifier as an unbounded DirectoryString. Is the intent that the semantics espoused in RFC 5280, Section 4.1.2.6 apply? Can and should stronger guidance be given as to the selection of the underlying string type, given that this attribute shares none of the backwards compatibility concerns that were needed when RFC 5280 was published? I think a particular area of concern to highlight is whether the expected selection MUST be PrintableString or UTF8String. If UTF8String, it seems we will still encounter ambiguous representations for a given identifier.

2) The proposal still leaves a number of "or any other method" type concerns. I'm hugely appreciative of the explicit registration within the BRs of the accepted schemes and their expected semantics, but I'm concerned about the 'or equivalent' and 'or approved', as they both seem to allow the introduction of ambiguous constructions.

3) On a technical level, the approach diverges from the purpose of a Subject attribute in helping to determine hierarchically the relevance of the information, in that it attempts to flatten multiple levels of hierarchy to a single attribute. Such a design decision is odd, even for ETSI. For example, consider 319 412-5 4.3.2, which structures monetary value into an individualized sequence, and then further segments the currency code itself into a set of registrations. It seems that the choice to flatten to a string is odd, especially considering that the whole value proposition of ASN.1 is the ability to express structured data, and seems to be largely (solely?) motivated by the desire to use the organizationIdentifier OID, rather than any other OID, and as a consequence, needs to make the thing that walks like a duck, talks like a duck, and quacks like a duck be declared a cat.

 

Seeing such concerns addressed would give me great hope that there is opportunity for productive and thoughtful engagement. Ignoring these give me concern that this is an attempt to bypass the otherwise productive discussion and improvements that the Forum or open-access SDOs such as the IETF can provide.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190314/62a12fe6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20190314/62a12fe6/attachment.p7s>