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

Steve Roylance steve.roylance at globalsign.com
Mon Nov 5 17:41:40 UTC 2012

Hi Kirk,

What I was attempting to show with the practical (and painstaking) exercise
of making 50+ examples was that certificates are extremely 'flexible' and so
therefore are browsers in how they have evolved to interpret them.  This
means that there's an array of possible moving parts to consider which can
be both included or excluded resulting in the smorgasbord of alternatives we
see today.  

The vast assortment of alternatives is mainly to the detriment of
understanding by relying parties using todays browsers/certificate viewers.
How should we expect the browsers to be able to sift through the information
and all possible combinations, decide which parts are most relevant, and
then finally show these in the most effective manner to relying parties?
CA's need to first establish a constant baseline such that we can then
petition browsers to show relevant information to relying parties.

You keep repeating your security question and I keep repeating my answer.
My concern is not with the security issues here, but with consistency of
practice towards relying parties and subscribers. The EV guidelines AND the
Base Requirements were crafted to address BOTH security and certificate
structure best practice from CAs towards relying parties and subscribers and
not just one element.  If all provisions simply had to pass the litmus test
of security we would not have been able to get to where we are today.

So let me try to answer your security question by taking the example of 2 DV
certs on 2 IPs with two owners (not 10).  Let's assume one is
www.bankofamerica.com (Actually owned by Bank of America) and one is
www.bobsbits.com (Actually owned by Robert Doe).

With two 'separate' DV certificates Robert's customers cannot see/decrypt
any information sent to Bank or America's customers (unless due to bad
security practice keys are replicated)  SNI allows these to exist on the
same IP and the type of service is completely arbitrary to the discussions ­
rather like trying to say a service is e-commerce or not we cannot and
therefore should not try to pin it down.

With a single DV certificate (therefore a shared key) both customers can
see/decrypt all information.

So what is placed into the common name? (Nothing is the proposed best
So what is placed into the initial SAN? www.bobsbits.com?

The elephant in the room here is does Bank of America know that they share
keys with Robert?  (i.e. From a subscriber perspective).  i.e. Has the CA
been diligent enough to say to all parties (When they obtained domain
control proof) did you really know you are sharing keys/services with all
these additional entities/domain owners/people who control a domain.

So either the CA needs to verify that ALL domains are owned by the same
party (EV presents the only method acceptable to date by looking at WHOIS or
contacting the registrar) and choose to leave that information out, or
include the details of the party that controls the domains on behalf of all
the real owners.

If everyone finds it acceptable that positive domain control is completely
independent of all other tests/assurances (i.e. a positive response to any
challenge) then this needs to be reflected into the EV guidelines too.

Please think of the issue we have with our conference calls.  Ben gives out
the details and takes a register of attendees.    Many would object if
suddenly the line was shared with entities we did not recognise/trust.

I'll work with the other endorsers to amend the language to address smaller
concerns raised but in general I want this to proceed along the same lines.


From:  "kirk_hall at trendmicro.com" <kirk_hall at trendmicro.com>
Date:  Sunday, 4 November 2012 16:52
To:  "CABFPub (public at cabforum.org)" <public at cabforum.org>, CABForum
Management <management at cabforum.org>
Subject:  Re: [cabfman] [cabfpub] Ballot 92 - Certificate examples to aid

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




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.

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
telephone and delete the original message from your mail system.
_______________________________________________ Management mailing list
Management at cabforum.org https://cabforum.org/mailman/listinfo/management

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121105/bbee7487/attachment-0004.html>

More information about the Public mailing list