[cabfpub] Draft Ballot 186 - Limiting the Reuse of Validation Information

Jeremy Rowley jeremy.rowley at digicert.com
Wed Feb 1 12:59:04 MST 2017


What if we decoupled revalidation of organization information and domain validation? Organization information wouldn’t change if a certificate is revoked for key compromise and tends to change less frequently than domain information. We could keep org information at 39 months and specify domain validation must occur more frequently. 

 

From: Ryan Sleevi [mailto:sleevi at google.com] 
Sent: Wednesday, February 1, 2017 12:24 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com>
Subject: Re: [cabfpub] Draft Ballot 186 - Limiting the Reuse of Validation Information

 

Jeremy,

 

Did you misread superseded as suspended? "Suspension" is indicated by certificateHold, which is different than the ones listed.

 

For sake of completeness, here's the RFC5280 list of revocation reasons:

   ReasonFlags ::= BIT STRING {

        unused                  (0),

        keyCompromise           (1),

        cACompromise            (2),

        affiliationChanged      (3),

        superseded              (4),

        cessationOfOperation    (5),

        certificateHold         (6),

        privilegeWithdrawn      (7),

        aACompromise            (8) }

 

On Wed, Feb 1, 2017 at 11:13 AM, Jeremy Rowley via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:

Suspension is not permitted under 4.9.13 of the BRs. It didn’t work with the way browsers did caching, making it impossible to unrevoked a cert. Plus, it was pretty suspicious when CRL listings disappeared.

 

From: Public [mailto:public-bounces at cabforum.org <mailto:public-bounces at cabforum.org> ] On Behalf Of Peter Bowen via Public
Sent: Wednesday, February 1, 2017 11:58 AM
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: Re: [cabfpub] Draft Ballot 186 - Limiting the Reuse of Validation Information

 

 

On Feb 1, 2017, at 10:51 AM, Ryan Sleevi via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:

 

 

 

On Wed, Feb 1, 2017 at 10:49 AM, Ryan Sleevi <sleevi at google.com <mailto:sleevi at google.com> > wrote:

Reposing on behalf of Jürgen Brauckmann <brauckmann at dfn-cert.de <mailto:brauckmann at dfn-cert.de> >

 

Ryan Sleevi via Public schrieb:
>   4. The CA has not revoked any certificates which contain certificate
> information verified using the document or data.

Your goal is to kill OV?

 

And why does OV require revocation? OV totally remains valid, so long as you're not revoking those certs.

 

As mentioned in my other message just now, beyond keyCompromise, what other reasons would you revoke a cert? Surely if you revoke a cert because of "affiliationChanged", you should very well be revalidating the affiliation before issuing a new cert; otherwise, you could revoke the cert and totally reissue it using the original bogus information.

 

Consider these revocation reasons in the X.509 text:

- superseded indicates that the certificate has been superseded but
there is no cause to suspect that the private key has been compromised

- cessationOfOperation indicates that the certificate is no longer
needed for the purpose for which it was issued but there is no cause
to suspect that the private key has been compromise

If a customer is replacing certificate X with certificate Y (probably
with the same SANs), it is completely reasonable for them to request
revocation of X once Y is fully deployed.  I would use "superseded"
for this case.  It is also possible that a customer ceases to use a
server and wants to revoke using "cessationOfOperation".  Neither of
these cases says anything about the validity of the domain
registration or organization information.

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/20170201/5a528245/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170201/5a528245/attachment-0001.bin>


More information about the Public mailing list