[cabfpub] [cabfman] Ballot 92 - Certificate examples to aid discussions.
ryan.hurst at globalsign.com
Wed Nov 7 19:08:02 UTC 2012
> 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.
I would say it differently, in domain validation the named entity is one who
can demonstrate they can control content that is served from that domain.
This is because issuers support models such as the certificate requestor
being able to embed a key into a metatag in the content as proof of control
of the content as well as other similar mechanisms.
This is different than being the authorized 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.
Since I have not said it yet let me now, I think DV is good as it allows
increased usage of SSL which is important for the privacy and security of
the internet therefore removing DV would be a mistake.
> 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
The problem is that it's not only the authorized domain owner.
> 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.
I don't think SNI makes this harder, as long as DV certificates only contain
domains for which the domain holder is the same.
> 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.
Using this argument no change should ever be made to until clients have been
updated to present the information, having been on the browser side myself
in the past I know that ones ability to spend engineering resources on
making UI changes dependent on non-existent data is essentially impossible.
When looking at a certificates contents we have to ask the question what
does this data mean independent of UI. The goal here is to simply ensure the
answer to this question is be non-ambiguous.
More information about the Public