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

[Ryan Sleevi]

On Wed, Nov 7, 2012 at 10:37 AM, Ryan Hurst <ryan.hurst at globalsign.com> wrote:
> Ryan (Sleevi),
>
>
>
>> 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.
>
>
>
> The issue is not so much about the UI, the UI (though I am sure we all agree
> it could be improved) but about what the binding in the certificate says.
>
>
>
> Fundamentally a certificate is a binding of a key to an identity, the
> presumption of which is that the holder of the key is the named entity.
> Certificates where there is no discernible binding to the entity that holds
> the key provide relying parties no way to tell who can see the data
> in-flight which is in the case of SSL the reason the certificates are used.
>
>
>
> This is the problem trying to be addressed here.

For domain validation, the named entity is the authorized domain
holder. The guarantees afforded by a DV cert is merely that no other
party than those authorized to act on behalf of the domain holder.

If it is believed that Relying Parties want or expect better
guarantees than that - such as organizationally identifying
information - then we're really talking about removing DV, not about
the distinction between DV and OV for multi-name certs. Which, I've
been assured, is not the topic of discussion.

So the RP still gets some degree of security assurance - the only
parties that can eavesdrop on the communication are the authorized
domain holders. Whether or not that domain holder is authorized for
other domains is inconsequential, nor does it change any RP behaviours
when you talk two certs + SNI or one cert + two names.

If anything, SNI+DV defeats the goal of providing named party
identities, because then it's no longer obvious to the RP all of the
domains that the holder is authorized for.

>
>
>
>> 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.
>
>
>
> True but in this case a relying party knows that this is the case and that
> is an important difference.

Again, I would suggest that the presentation of information to an RP,
beyond the assurance of the security guarantees for that level, is a
UI matter. It'd be no different than proposing some new X.509v3
extension to hold information about the named party - if browsers and
UI elements do not parse and display that extension, then regardless
if what the CA/B Forum mandates that extension, it does nothing for
the RP.

>
>
>
>> 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.
>
>
>
> Of  course, this is not the problem trying to be addressed this is about the
> relying party not the subscriber.
>
>
>
> Ryan (Hurst)