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

Ryan Sleevi sleevi at google.com
Wed Nov 7 18:09:18 UTC 2012


On Mon, Nov 5, 2012 at 9:41 AM, Steve Roylance <
steve.roylance at globalsign.com> wrote:

> 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.
>

So then the argument here is that this is a UI issue, and has been
mentioned elsewhere by several browsers, I don't believe there is present
interest in discussing mandatory UI behaviours, which this proposal feels
like a direct run-around to. While I'm sure I can speak for all browser
vendors when I say that user security is at the forefront of our concerns,
I don't believe this is the best way to spark those discussions by
proposing to forbid some forms of DV simply because you disagree with the
UI afforded to DV.


>
> 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.
>

As repeatedly mentioned, SNI deployment in practice is such that it's not a
viable option for a variety of sites - particularly those that need to work
for a wide array of devices and platforms, such as Bank of America.


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

Again, and has been repeatedly mentioned, if Mallory, the recipient of such
certificates, possesses three certificates - one for www.bankofamerica.com,
one for www.bobsbits.com, and one for both - then she is fully capable of
decrypting all traffic. Requiring that Mallory be issued two distinct
certificates has no practical or marginal security benefits over issuing
Mallory a single certificate. The only reason to mention that Mallory can
see/decrypt all information is to suggest that with two DV certs she
somehow cannot - eg: that there are security benefits - and it has been
shown that it does not.


>
> So what is placed into the common name? (Nothing is the proposed best
> practice)
> 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.
>

If you believe there are situations where Bank of America (or any other
organization, big or small) may not be aware that certificates have been
issued for domains under their control, please let the browsers know so
that they can respond appropriately.


>
> 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 any CAs are issuing certificates to parties without verifying that the
party requesting (and receiving) the certificate is authorized for all
domains asserted by the CA within the certificate, please let us know so
that we can take action, such as potentially removing the CA from our trust
lists.

While I understand the hypothetical situation being described here, I think
that it's fundamentally no different than misissuance, and thus warrants
the same response as a misissued certificate. I hope that this sort of
understanding is shared and is considered self-evident.


>
> 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.
>
> Steve
>
>
> 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
> discussions.
>
> 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<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.****
>
>  ****
>
> ** **
>
> TREND MICRO EMAIL NOTICE
> The information contained in this email and any attachments is confidentialand 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.
>
> _______________________________________________ Management mailing list
> Management at cabforum.org https://cabforum.org/mailman/listinfo/management
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20121107/a956efb0/attachment-0004.html>


More information about the Public mailing list