[cabfpub] Ballot 92 reviewed

[Steve Roylance]

Hi Gerv,


I was out last week, hence the delay in responding to posts on this
ballot. (Bad timing I know, but in a few years, you too will come to
appreciate the fun around being shackled to school half terms ;-) )

Answers in line:-

On 26/10/2012 09:21, "Gervase Markham" <gerv at mozilla.org> wrote:

>On 25/10/12 22:07, Jeremy Rowley wrote:
>> A certificate with a non-FQDN or private IP address is essentially
>> non-verified if the certificate lacks organization details.
>
>I disagree with that statement; I would say that it has been linked to
>an owner if it contains at least one SAN (or CN) value which is fully
>qualified. Which I believe is the intent of the changes to section 9.2.2.

The intention behind the wording in the proposed revision of 9.2.1 that
Jeremy was referring to was to constrain the issuance of certificates with
non verifiable domain names/IP addresses/host names etc (deemed
dangerous/toxic by many CABForum and non CABForum members including
yourself).  Merely having one FQDN present does not identify the owner. It
identifies that the CA has performed some level of challenge response on
an FQDN only and not necessarily validated identity.  It's the identity
that becomes useful in any forensic examination of data packets following
a successful attack.   We've all discussed the suitability of DV in the
past in various scenarios and there's clearly a definite need for DV in
the market where owners of domains simply want a credential to prove
ownership, but what we are saying here is that we should not rely on the
DV only mechanisms to highlight the "owner" of non-verifiable items
because it doesn't.   My feeling was that we could look to keep the
current phase out deadline of shortnames by strengthening the
authentication associated with that type of certificate.


The intent of 9.2.2 was to ensure that if you were going to use the CN
then popular certificate viewers would present either an FQDN or Public IP
allowing 'slightly' easier differentiation of certificates.  Allowing
shortnames in the CN simply labels one certificate the same as another
when all of the rest of the certificate could be different.  i.e. If you
are going to use the CN then make it unique and relevant.

>
>> *Section 10.3 ­ Information Requirements*
>>
>> This change is to clarify that at least one subjectAltName extension
>>  entry is required.  CN was deprecated in v1.0.  This change furthers
>> the deprecation by shifting domain name entries into the
>> subjectAltName extension.
>
>I am definitely in favour of this.
>
>> By requiring wildcard characters in only the complete left-most
>> label, the forum¹s practices will conform to the various RFCs already
>> created and prevent a possible attack.
>
>I think it also corresponds to what modern browsers allow.
>
>Gerv
>_______________________________________________
>Public mailing list
>Public at cabforum.org
>https://cabforum.org/mailman/listinfo/public