[cabfpub] Ballot 92 reviewed

Steve Roylance steve.roylance at globalsign.com
Mon Oct 29 14:18:34 UTC 2012


Melih.

Agreed, hence the use of "owner" (in quotes) in my reply below. In
hindsight, with this subject, it pays to be careful on the use of "owner".

A Domain Validation test implies potential "ownership" of a domain but
does not identify the "owner" so I agree "access" is a better term.

Steve



On 29/10/2012 12:37, "Melih Abdulhayoglu" <melih at comodo.com> wrote:

>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: 5001 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121029/945d11c1/attachment-0002.p7s>


More information about the Public mailing list