[cabfpub] [cabfman] Ballot 92 - Implications of RFC 6125 and Subject Alternative Names

[Geoff Keating]

I understand this ballot has been withdrawn.  I would have voted NO.

I have some policy objections and there are a variety of technical problems.  In the order presented, here are my concerns:

• The proposal limits the use of DV certificates.  The stated justification is to ensure that it's possible to identify a 'responsible party'.  This assumes that there is a single 'responsible party', that the responsible party needs to be identified, that it is useful to identify that entity, and that it is possible to identify that entity.   None of these seem likely to apply in every case.

• It's not clear why, if you're going to allow internal server names at all, that it's necessary to prohibit the case of a certificate issued only to an internal server name.  I'm also hesitant to mess with the agreed-to phase out of these names.  If I was going to mess with the phase out, I'd prefer to make it shorter than anything else!

• The proposal refers to 'confusable bidirectional text' without defining it.  The phrase doesn't appear in the references.  I've spent some time thinking about it and I can't tell what exactly was intended here.  Possibly this is simply a drafting error, this is intended as a heading, so the 'SHALL NOT' should be in lowercase, and the 'must' in item 'c' should be in uppercase?

• Section 11.1.3 makes special rules for wildcard labels in top-level domains, but these appear to be a special case of the rule "The CA MUST confirm that the Applicant controls the Fully-Qualified Domain Name".  It was asserted that the proposal requires wildcard characters to be in only the left-most label, but I don't see any wording to that effect.  I would support such a restriction if it was actually in the proposal.

• Speaking of things that are not in the proposal, the current baseline requirements already require a subjectAltName field, and that the commonName field's value (if any) must be in it.

There are many parts of the proposal that make useful improvements, and so I'd really like to see them split out separately.  I think that would also help avoid some of the technical problems by allowing better review before a ballot.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4316 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121025/506a30c7/attachment-0002.p7s>