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

[Ryan Sleevi]

While that proposes an alternative, it doesn't provide any explanation
about the security benefits or value to relying parties/ecosystem, so I
don't think it's worth discussing unless you wanted to expand on that.

I think aligning on 13 months, across the board, as an initial step, seems
to be a far more reasonable step. We could then discuss specific cases
where it might be desirable to be more frequent - in particular, domain
validation (and the method used to validate that domain) have much more
nuanced levels of assurance, and we should arguably couple the reuse of
that information to the confidence and signals we have in how that
information was obtained.

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

> 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> 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/5f9313e8/attachment-0003.html>