[cabfpub] Ballot 92 reviewed

Melih Abdulhayoglu melih at comodo.com
Mon Oct 29 12:37:57 UTC 2012


DV does "NOT" validate  domain "OWNER".
It merely validates that the applicant has "ACCESS" to the "DOMAIN'.

I feel we should use the correct terminology to avoid confusion.

Kind regards

Melih Abdulhayoglu
Comodo

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Steve Roylance
Sent: Monday, October 29, 2012 8:15 AM
To: Gervase Markham
Cc: public at cabforum.org
Subject: Re: [cabfpub] Ballot 92 reviewed

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


_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5257 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121029/f27a9059/attachment-0002.p7s>


More information about the Public mailing list