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

Steve Roylance steve.roylance at globalsign.com
Mon Oct 29 12:35:52 UTC 2012


Hi Geoff.


Answers in line.

On 26/10/2012 00:02, "Geoff Keating" <geoffk at apple.com> wrote:

>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.

As I mentioned in my reply to Gerv and as Eddy pointed out in his reply
this this mail you can't solve all problems but I hope you can agree that
solving some moves the bar upward and that's always been the intention of
the BRs - Set a Baseline and move it upwards ver time.

>
>€ 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!

Talking to customers then a shorter phase out would be far harder to work
with for all parties.  All we are saying here is that yes, you can still
have your request, just prove who you are as you are in a club where
someone else might also request exactly the same credential so we'll
ensure we identify them too.

>
>€ 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?

I'll have to ask Brad to come back to you on that one.

>
>€ 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.

Can you suggest wording that you would support as this would nod out help
others too?

>
>€ 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.

I've answered part of this in the reply to Gerv.

>
>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.

Maybe that's possible.  Shall we se how it goes with the next suggestion
and if splitting works then I'm fine with that.

>
>_______________________________________________
>Management mailing list
>Management at cabforum.org
>https://cabforum.org/mailman/listinfo/management





More information about the Public mailing list