+100 WoSign like to endorse this.
I always think the true identity is more important than encryption. A fake site using DV SSL is more dangerous that no SSL. For example, this site is a fade Office 365 site: https://www.microsoftonline.us.com/ that I am sure this by checking the certificate is a free DV SSL that Microsoft never use this type certificate for its site, but the normal Internet user don't know this, then entered his/her Office 365 username and password to fraud. Good news for CAs is, as I know, 360 Browser will have different UI for EV/OV/IV/DV, the OV UI will like EV to display organization name in the address bar but use white color, to make difference from EV green bar, but let site visitor know this website true identity that no need to click the certificate subject for details. Best Regards, Richard From: Public [mailto:[email protected]] On Behalf Of Kirk Hall via Public Sent: Saturday, February 25, 2017 2:07 PM To: CA/Browser Forum Public Discussion List <[email protected]> Cc: Kirk Hall <[email protected]> Subject: Re: [cabfpub] Assuring trust in website identities +1 Peter. Well said. Wow, I didn't expect it, but thanks for posting the links to my RSA Security Conference presentation last week on the importance of website identity for user security. All the CA Security Council (CASC) members have endorsed the following Five Principles of TLS Certificate Identity - see page 33 of the following White Paper, if you are interested: https://casecurity.org/wp-content/uploads/2017/02/Use-of-Identity-in-SSL-TLS-Certs-for-User-Safety-Final-2017-02-17.pdf 1. Identity in TLS server certs should be used by browsers as a proxy for greater user safety 2. CAs should vet their customers to the highest identity level possible 3. OV certs should receive their own browser UI different from DV certs to show user safety 4. EV certs should continue to receive a separate browser UI from OV and DV certs to show greater user safety 5. Browsers should agree on common UI security indicators, avoid changes to UI, and work with others to educate users about the meaning of the common UI security indicators for greater user safety. These principles have been endorsed by Comodo, DigiCert, Entrust Datacard, GlobalSign, GoDaddy, Symantec, Trustwave. If any other members of the Forum (CA or browser) want to add their endorsement, please let me know. Here is an executive summary of the same White Paper: https://casecurity.org/wp-content/uploads/2017/02/Executive-Summary-Use-of-Identity-in-SSL-TLS-Certs-for-User-Safety-Final-2017-02-17.pdf In addition, there is a long list of major enterprise website owners who have also endorsed the use (and display) of website identity for user security. See Slide 49 of the attached pdf, which I presented at the RSA Security Conference last week. Oddly enough, no one has ever asked enterprise website owners what they would like to see in the browser UI to protect their brands and their customers - but when asked, they have indicated they would like to see confirmed identity data displayed to users. Peter posted the link to the audio of my presentation, but here it is again: https://www.rsaconference.com/videos/100-encrypted-web-new-challenges-for-tls The presentation was well attended, and appeared to be well received. We had not planned to bring this up in the Forum (and there is no need to discuss further on this list), but if anyone is interested in promoting website identity, please let me and the CASC members know. As to the main suggestion in Peter's email - we support this. If there are pre-BR certs still out there that are not in compliance with the BRs (after five years), let's get them revoked. It will be easy to do, and good for user security. -----Original Message----- From: Public [mailto:[email protected]] On Behalf Of Peter Bowen via Public Sent: Friday, February 24, 2017 8:40 PM To: CA/Browser Forum Public Discussion List <[email protected]> Cc: Peter Bowen <[email protected]> Subject: [cabfpub] Assuring trust in website identities The BRs came into effect on July 1, 2012. This year we have the fifth anniversary of the BRs, and we have an opportunity to help provide high assurance of website identities using certificates. Given the new Website Identity initiative (https://casecurity.org/identity/) announced at RSAC last week (https://www.rsaconference.com/videos/100-encrypted-web-new-challenges-for-tls), it is clear others are thinking similarily. In a discussion with Kirk today, I mentioned that one of the challenges with recognition of OV certificates is the existence of certificates with OV/IV info which are not covered by the BRs, either due to issuance date or missing data in the certificate. It is very hard for browsers to detect whether a certificate is a legitimate OV/IV certificate or not given the existence of these certificates. In order to help assure trust in website identity, Kirk suggested that we set a sunset date for certificates with identity that are not clearly covered in the BRs. I think the sunset date should be July 1, 2017, which is five years from the BR effective date. On this date, all CAs much revoke unexpired certificates that meet the following criteria: - Contain at least one attribute of type organizationName {2 5 4 10}, givenName {2 5 4 42}, or surName {2 5 4 4} in the Subject Name, and - Is not self-signed certificate, as defined in X.509, and does not have cA set to true in the basic constraints extension (this avoids revoking CA certificates), and - Any of the following are true: - Is not a valid Certificate as defined by X.509 - Was issued before 2012-07-01T00:00:00Z and includes an extended key usage extension that contains the id-kp-serverAuth {1 3 6 1 5 5 7 3 1} or anyExtendedKeyUsage {2 5 29 37 0} key purpose - Does not include an extended key usage extension but does include a key usage extension with digitalSignature - Does not include an extended key usage extension but does include a key usage extension with keyEncipherment and has a RSA subject public key By revoking these certificates, we can assure that all un-revoked certificates used for website identity authentication that have identity information were vetted according to the BRs. I want to thank Kirk for suggesting revocation of these as the solution to help assure relying parties of website identities. Do others agree that this path makes sense in order to provide high assurance of website identity? Thanks, Peter _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
