[cabfpub] downgrade DV UI RE: OIDs for DV and OV

Wed Nov 5 06:09:42 MST 2014

A few comments.  First, if a bank is using anything other than EV, they shouldn’t be a bank.

You can’t really split out the security provided by identity verification from the security provided by protection against eavesdropping into two separate things.  If you have identity verification without encryption, there can be no private information transmitted (which is usually pretty useless), and if you have encryption without identity verification, things are even worse, since there can be arbitrarily many “men in the middle”.  TLS is an authenticated encryption protocol.

DV has uses beyond just its encryption function.  Remember, DNS is not a trustworthy protocol.  If you are talking to http://something.example.com, you don’t even know the information came from something.example.com, or even any machine owned, authorized, or administered by the owner of example.com.  It could even be coming from 127.0.0.127.

If you are talking to https://something.example.com, you know (with low confidence …) the information is coming from a machine administered by the owner of example.com.  That’s certainly a big improvement over bare http; in fact I’d argue it’s getting close to time for bare http to just go away in many use cases.  It’s perfectly appropriate for, for example, reading articles or information posted by a small organization that owns a domain and little else.  That it actually comes from the domain owner is all I really care about.

In my opinion, EV, OV, and DV all have their uses in certain scenarios.  The fact that some people refuse to acknowledge use cases that are not important for their company or product(s) is not helpful.  And it should be easy to tell the intended use or uses of a certificate just by looking at the certificate.  I support any and all proposals to move things in that direction over time.

-Tim

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Richard Wang
Sent: Tuesday, November 04, 2014 10:54 PM
To: Dean Coclin; Gervase Markham; public at cabforum.org
Subject: Re: [cabfpub] downgrade DV UI RE: OIDs for DV and OV

I withdraw the word "DV should go away" since it has encryption function for those sites that can't provide identity documents. But I still think the browser should identify the difference of DV SSL and OV SSL, tell end user clearly.

I agree Eddy said: it should be clearly "domain control validated" - that's what it is, not more and also not less.

And I agree Dean opinion that " DV is NOT sufficient use case for the majority of Internet e-commerce".

And I still think the website identity is more important than security, if a bank spoof site has a DV SSL that display the same UI with OV SSL, then it is more dangerous than no SSL. This is why so many website identity providers to prove the site true identity than SSL deployment in China.

Welcome other CAs speak out your opinion for this topic, thanks.

Best Regards,

Richard

-----Original Message-----

From: Dean Coclin [mailto:Dean_Coclin at symantec.com]

Sent: Wednesday, November 5, 2014 10:07 AM

To: Gervase Markham; Richard Wang; public at cabforum.org<mailto:public at cabforum.org>

Subject: RE: [cabfpub] downgrade DV UI RE: OIDs for DV and OV

I also disagree with that blanket statement, especially the word "downgrade". There are many legitimate uses for DV certs and that shouldn't be diminished or "downgraded". I agree with Gerv that DV should not "go away"

For the majority of consumers though, do you think it's sufficient to know that they are connected to "match.com"? I would think it would be better for them to know that they are connected to "Match.com, Inc". More specifically, is DV a sufficient use case for the majority of Internet e-commerce?

-----Original Message-----

From: Gervase Markham [mailto:gerv at mozilla.org]

Sent: Tuesday, November 04, 2014 8:39 PM

To: Richard Wang; Dean Coclin; public at cabforum.org<mailto:public at cabforum.org>

Subject: Re: [cabfpub] downgrade DV UI RE: OIDs for DV and OV

On 04/11/14 01:52, Richard Wang wrote:

> I think we not only need to add DV and OV OID to end user certificate,

> but also the browsers *should downgrade the DV UI* to tell users that

> this site true identity is not verified!

I disagree with that as a blanket statement.

There are many Internet businesses which are known simply by their domain name. "match.com", and so on. For them, a DV certificate, which proves that the holder of the certificate owns match.com,<http://scanmail.trustwave.com/?c=4062&d=xJ_Z1H2thi_aV6bTok68LPmE09Nf15ZRM5VL6cBO3Q&s=5&u=http%3a%2f%2fmatch%2ecom> has verified their identity to a degree which is often sufficient.

Clearly, this is not all you need in every case, but it's not true to say that "identity is not verified" for DV certificates. It depends what sort of identity verification an end user needs.

> Chrome display a GREEN padlock like OV and say “Identity verified”, is

> this info correct?

It says that underneath a reprint of the domain name - which is the piece of identity which has been verified.

> All comments are welcome, I wish the DV SSL will die in the future

> since the site identity is more important than encryption, spoof site

> has SSL is no any good meaning and is more dangerous than no SSL.

DV is the only plausible route to the web being secure by default. It is not going to go away.

Gerv

________________________________

This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141105/93afbc0b/attachment-0001.html 