[cabfpub] Ballot 92 - Certificate examples to aid discussions.

[kirk_hall at trendmicro.com]

I'm not sure what your message below and attachments are meant to demonstrate - but it appears to be more of a browser problem than a CA problem.  I'll let the browsers respond to that.

I asked the sponsors to respond to the question below, and Jeremy deferred to you as the author of this part of Ballot 92.  I don't think your message below is responsive.  Can you tell us if you see a security difference, and if so, why?

Here is the basic question which needs answering:


What is the difference between 10 DV certs (each for a single domain) where domain control was proved for each with a single customer (either someone who owned all 10 domains, or an ISP/hosting company who controlled all 10 domains), versus a DV SANs cert with the same 10 domains inside (owned by one party or controlled by an ISP or hosting company), 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.


From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Steve Roylance
Sent: Friday, November 02, 2012 9:05 AM
To: CABFPub (public at cabforum.org)
Subject: [cabfpub] Ballot 92 - Certificate examples to aid discussions.

Dear all.

It seems that many people were confused about the Intent of Ballot 92.

Even though Jeremy illustrated some examples during the discussions (thanks!) and even though the ballot itself features examples, I felt that it would be beneficial to all parties to come to an agreement on the scope of the problem and therefore to provide an illustration of the alternative mix of domains/IPs/Shortnames that we are trying to encompass.

Please see the attached XLS (and PDF version).

I've illustrated several different combinations of public/non public domains.  In order to allow everyone to visualise (in their favourite certificate viewer) just how things stand I've also provided certificates, PKCS12's keys and requests.  These are in the ZIP file and are labelled as per the XLS sheet so you should be able to quickly and easily identify a specific combination of components you may be concerned about and obtain an example.  i.e. DV 1-13, OV 1-10 and Controversial 1-4.

I've also provided a few screen shots in a 2nd PDF to highlight how the Windows Certificate Viewer makes a 'best attempt' to display information to relying parties.  i.e. When there is no CN it reverts to the next OU.    My intention here is not to ballot how the browsers show certificates but to indicate that both the browsers and CAs need to work together to improve the situation for relying parties and I'm happy to try to move the CAs forward first.  After all, it's the CAs who attest to the combination of the various component parts of the certificate by signing it, so Browsers will never be able to move forward whilst CAs don't have a solid baseline of when and when not to include additional Subject DN Information.

The majority of the feedback I received last week seems to highlight that mixed 'DV' domains are contentious hence the 1-4 in the sheet.  Some think that it's fine to allow multiple owners to be bundled in to a single certificate.  I do not think this is acceptable.   I'm sure that some of the supporters of this motion will be able to add additional weight to the argument in terms of private key control, however as I have always stated, my focus is on what replying parties are able to see today and CAs can certainly improve this.

Kind Regards

Steve

P.S. If you want a particular combination of components adding them please let me know.  Additional SAN entries beyond 2 only complicate things further and are effectively subsets of the examples created.  I didn't have the chance to make CRLs etc so some browsers balk - We can address this over the coming days/weeks prior to a resubmission of the ballot.



<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>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121104/f3aecf10/attachment-0004.html>