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

[Ryan Sleevi]

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/20190308/8404314c/attachment.html>