[cabfpub] Assuring trust in website identities

Sat Feb 25 06:06:53 UTC 2017

+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:public-bounces at cabforum.org] On Behalf Of Peter Bowen via Public
Sent: Friday, February 24, 2017 8:40 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Peter Bowen <pzb at amzn.com>
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

Public at cabforum.org<mailto:Public at cabforum.org>

https://cabforum.org/mailman/listinfo/public
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170225/204d2afa/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: RSAC 2017 PDAC W10 Hall presentation (2-10-2017).pdf
Type: application/pdf
Size: 4147365 bytes
Desc: RSAC 2017 PDAC W10 Hall presentation (2-10-2017).pdf
URL: <http://cabforum.org/pipermail/public/attachments/20170225/204d2afa/attachment-0001.pdf>