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 <[email protected]> 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:[email protected] > <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] > <mailto:[email protected]>> > Cc: Peter Bowen <[email protected] <mailto:[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/ > <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 > [email protected] <mailto:[email protected]> > https://cabforum.org/mailman/listinfo/public > <https://cabforum.org/mailman/listinfo/public><RSAC 2017 PDAC W10 Hall > presentation (2-10-2017).pdf>
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
