[cabfpub] Assuring trust in website identities

Sat Feb 25 15:32:08 UTC 2017

Kirk,

I’m glad to hear you support my proposal.  I did realize, after reading Ryan’s email, the sunset probably needs to be a rolling date to handle the BR “phase in” period.  So the rule needs to effectively be:

* Effective July 1, 2017,  unexpired OV/IV SSL certificates must be revoked within 24 hours of the fifth anniversary of their issuance

The details need to get ironed out (define fifth anniversary, etc), but I think that this ensure that, by mid-2018, all SSL certs that have organization or individual identity used at least baseline vetting requirements.

Thanks,
Peter

> On Feb 24, 2017, at 10:06 PM, Kirk Hall <Kirk.Hall at entrustdatacard.com> wrote:
> 
> +1 Peter.  Well said.  

> All the CA Security Council (CASC) members have endorsed the following Five Principles of TLS Certificate Identity 
>  
> 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.
>  
> We had not planned to bring this up in the Forum (and there is no need to discuss further on this list), 
>  
> 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 <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 <mailto:public at cabforum.org>>
> Cc: Peter Bowen <pzb at amzn.com <mailto: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/ <https://casecurity.org/identity/>) announced at RSAC last week (https://www.rsaconference.com/videos/100-encrypted-web-new-challenges-for-tls <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 <https://cabforum.org/mailman/listinfo/public><RSAC 2017 PDAC W10 Hall presentation (2-10-2017).pdf>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170225/594b1027/attachment-0003.html>