[cabfpub] Ballot 92 reviewed

Tue Oct 30 18:48:24 UTC 2012

My other question was, what is the difference between 10 DV certs (each for a single domain) where domain control was proved for each with a single customer, versus a DV SANs cert with the same 10 domains inside, where domain control was proved for each with a single customer?  

It appears to me they are equivalent from a security standpoint.

If we force customers to buy OV certs if they want multiple domains inside, we will be adding cost and delay for no added security.

-----Original Message-----
From: Steve Roylance [mailto:steve.roylance at globalsign.com] 
Sent: Tuesday, October 30, 2012 1:25 PM
To: Kirk Hall (RD-US)
Cc: public at cabforum.org; Gervase Markham
Subject: Re: [cabfpub] Ballot 92 reviewed

Hi Kirk,

I'm slowly working my way through all the e-mails and feedback over this last week on Ballot 92 and will be addressing concerns and thinking about how language could be adjusted to allow us all to move forward.

However here's some quick feedback on your statement below.

Nothing here is misleading as it's reality.  A relying party would not be tricked into anything.  When they looked at the certificate, they would see they had a session with an entity that had control over the domain they were communicating with and therefore have a choice to continue or
not.   The reverse is actually true in that if there is no information
within the certificate they will be unable to determine who it is that has the private key.  It may be none of the domain owners if a third party is controlling the domains.

Please also note that it's not possible to have different levels of domain vetting within the current BRs. As they stand it's just positive verification of domain control that is confirmed. i.e. An FQDN must be
verified if it is to be included in a certificate.   OV and DV are classes
of certificate which are based on the inclusion/or not of other verified information.

I hope that helps.

Steve   

On 29/10/2012 17:08, "kirk_hall at trendmicro.com" <kirk_hall at trendmicro.com>
wrote:

>Under the proposal, only one domain in the SANs cert would be OV vetted.
>Then other DV domains owned by others can be inserted as well.  So a 
>relying party would be tricked into thinking that all domains in the 
>SANs cert were OV vetted to that one owner (whose identity would appear 
>for all the DV domains).  That's misleading.
>
>-----Original Message-----
>From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] 
>On Behalf Of Steve Roylance
>Sent: Monday, October 29, 2012 10:37 AM
>To: Gervase Markham
>Cc: public at cabforum.org
>Subject: Re: [cabfpub] Ballot 92 reviewed
>
>Hi Gerv.
>
>
>On 29/10/2012 13:33, "Gervase Markham" <gerv at mozilla.org> wrote:
>
>>On 29/10/12 12:15, Steve Roylance wrote:
>>> 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 them just as much as the owner of a single-FQDN DV cert 
>>is identified.
>
>We are not debating the use of DV here.  We are saying that a 
>non-unique component added to a DV based certificate or one used alone 
>makes it a different animal with different rules.
>
>>
>>> 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.
>>
>>This seems to be "OV vs DV" in disguise. :-)
>
>Nope :-)...I believe that DV is great for SSL when the owner does not 
>need to be authenticated.  There are lots of uses and clearly SSL is 
>better than no SSL, but where non uniqueness creeps in it's different.
>
>
>>
>>If a DV cert for www.foo.com is OK in a certain scenario, why is a DV 
>>cert for www.foo.com, foo.mail and foopymachine not OK? Both certs 
>>contain exactly the same amount of information regarding who 'owns'
>>them
>>- it's the person who owns www.foo.com.
>
>See Melih's post and my reply and you'll see these are different cases.
>Currently anyone can have access to foopymachine or foo.mail so make 
>sure the person/organisation requesting this is identified.
>
>>
>>> 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.
>>
>>This is begging the question of whether you need to know the 'owner' 
>>in this sense in the first place. Or, to put it another way: why is 
>>this argument not an argument against all DV certs?
>
>It's the non-unique element that makes them different and dangerous if 
>given out freely.  You can't use a DV cert to attack another FQDN, but 
>you can use a non unique to attack another same name non unique.
>
>This trying to do the right thing is hard workŠ :-(
>
>>
>>Gerv
>
>
>_______________________________________________
>Public mailing list
>Public at cabforum.org
>https://cabforum.org/mailman/listinfo/public
><table class="TM_EMAIL_NOTICE"><tr><td><pre>
>TREND MICRO EMAIL NOTICE
>The information contained in this email and any attachments is 
>confidential and may be subject to copyright or other intellectual 
>property protection.
>If you are not the intended recipient, you are not authorized to use or 
>disclose this information, and we request that you notify us by reply 
>mail or telephone and delete the original message from your mail 
>system.
></pre></td></tr></table>

<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>