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

[Ryan Sleevi]

I'm not sure how you got that from my message, but no, I'm not saying that.

I'm saying revalidation is required for *any* reason (including 'unused' or
not specified) _except_ keyCompromise, superseded, or cessationOfOperation.

On Wed, Feb 1, 2017 at 11:41 AM, Jeremy Rowley <jeremy.rowley at digicert.com>
wrote:

> Yes…. Nevermind.
>
>
>
> Basically, you’re saying revalidation is required for keyCompromise or
> cACompromise only?
>
>
>
> *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> 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] *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>
> *Cc:* Peter Bowen <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>
> wrote:
>
>
>
>
>
>
>
> On Wed, Feb 1, 2017 at 10:49 AM, Ryan Sleevi <sleevi at google.com> wrote:
>
> Reposing on behalf of Jürgen Brauckmann <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
> https://cabforum.org/mailman/listinfo/public
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170201/1d11d37c/attachment-0003.html>