[cabfpub] Pre-Ballot - Short-Life Certificates

Tue Nov 18 17:22:18 UTC 2014

On Mon Nov 10 2014 at 3:03:04 PM Sigbjørn Vik <sigbjorn at opera.com> wrote:

> Hi,
>
> Some more thoughts, since that is what you wanted :)
>
> It seems that in general, we have an issue, where we cannot upgrade
> certificate specifications and usage, because it will break older
> clients. When legacy usage is a problem like this, it would be good to
> fix it. Most likely the problem will become worse over time, and it will
> take time to get the fix out to all clients, so we should start right away.
>
> TLS SNI ensured that one server could serve different certificates
> depending on which domain the client wants to connect to. If we made a
> similar extension for the client to state what it supports, then the
> server could serve different certificates depending on what the client
> understands. In practice such an extension might say e.g. "Client
> support version 1.0; Opera version 25.0.1614.68", that is sufficient for
> the server to know what the client supports, and to work around any
> client specific bugs. Privacy minded users/vendors can fall back to not
> specifying the extension, and get old style certificates.
>
> If we had such a specification, then the discussion around short-lived
> certificates would be quite different, as we don't need to worry about
> legacy clients, servers just keep serving them the old certificates. So
> assume this exists, then read on :)
>
> One of the issues I have with not specifying revocation pointers is that
> it is then possible to bulk pre-issue certificates for a year, with no
> way to revoke them. When things are possible to do, sooner or later
> someone will want to do them, e.g. due to some old legacy system which
> nobody dares change. Having rules which can be checked programmatically
> is much preferable.
>
> So here is another suggestion:
> Create a special breed of short-lived certificates. They have no 'valid
> from' or 'valid to' fields, nor revocation pointers. Instead they carry
> a proof of the time they were issued, e.g. the latest hash from a CT
> log. The certificate is valid 3 days from that timestamp. Backdating is
> possible (and legal, but more than 3 days is pointless), pre-issuing is
> impossible. Clients have CT log data anyhow, and can compare their local
> time to the log time, and automatically account for any clock skew.
> Since clock skew is handled, expired certs can be treated just as
> harshly as revoked certs. Total data size on the wire should be smaller
> than the original proposal.
>

I would certainly be pushing for CT to be used for short-lived
certificates, just like any other, so that part I'm fine with.

However, if we're going to introduce logs as a trusted source of time, then
we would need to think about how logs can prove that their time is honest.
This strikes me as potentially quite tricky.

>
>
> On 10-Nov-14 15:18, Rob Stradling wrote:
> > Hi Gerv.  Some thoughts...
> >
> > 1. BRs 13.2.6 says that OCSP responders MUST NOT respond with a "good"
> > status for "a certificate that has not been issued" and that "The CA
> > SHOULD monitor the responder for such requests as part of its security
> > response procedures".
> > If OCSP is never used (which would be the case if AIA->OCSP is omitted),
> > then "monitoring the responder" in this way cannot happen.  This could
> > mean that future CA compromises aren't spotted as early as they
> > otherwise might be.
> >
> > 2. When revocation is effective (e.g. Firefox with OCSP hard-fail
> > enabled by the user), the user is prevented from accessing the HTTPS
> > site.  However, certificate expiration is treated less harshly - the
> > user can still access the site.
> > For short-lived certs to be an effective revocation mechanism (for all
> > certs ideally, but definitely for short-lived certs), expiration needs
> > to be treated as harshly as revocation IMHO.
> > The idea of your proposed ballot is that existing browsers will benefit
> > from omitting all revocation pointers.  But it's the existing browsers
> > that, by definition, cannot be updated to treat expiration as harshly as
> > revocation.
> >
> > 3. You propose that "CAs are still required to provide revocation
> > information for such certificates (during their life)", and I agree with
> > that.
> > For Google's CRLSets, Mozilla's OneCRL (I presume), and certainly
> > Phill's/my Compressed CRLSet proposal, the generator needs to be able to
> > determine the current status of every certificate that's in scope.  To
> > do this, a revocation pointer for each certificate is required.  If
> > there's no revocation pointer in a cert, what do we do?
> > Phill's already expressed our hope that "If however we combine short
> > lived certs with compressed CRLs we can reduce the vulnerability window
> > from days to hours".
> >
> > 4. What is preventing you from experimenting with short-lived certs that
> > _do_ contain revocation pointers?
> > You could change Firefox so that it avoids doing revocation checks for
> > short-lived certs.  You could gather statistics on how much of a problem
> > clock-skew is for the use of short-lived certs in practice.  You could
> > gather user reports on how much of a pain it is to install a new cert on
> > a daily basis.
> >
> >
> > But if we must omit revocation pointers, then...
> >
> > 5. Possible compromise: Make AIA->OCSP optional, but require CDP.
> > Firefox doesn't check CDP, AIUI Windows intends to stop checking CDP,
> > AIUI many mobile devices have never checked CDP.
> > But including CDP helps the production of CRLSets.
> >
> > 6. Possible compromise 2: Specify a new mechanism for obtaining
> > revocation status, which no existing browser will use, but which CRLSet
> > generators could use.
> > Perhaps use the same syntax as the CDP extension, but just change the
> > extension's OID.  Or maybe put an OCSP responder URL in the issuing CA
> > cert's Subject Information Access extension (instead of the end-entity
> > cert's Authority Information Access extension).
> >
> >
> > On 23/10/14 13:13, Gervase Markham wrote:
> >> Following on from discussions at the last face-to-face and in the
> >> Mozilla forum, this is a pre-ballot for discussion. Comments are very
> >> welcome.
> >>
> >> Gerv
> >>
> >>
> >> Pre-Ballot XXX - Short-Life Certificates
> >>
> >> Gervase Markham of Mozilla made the following motion and XXX of XXX and
> >> YYY of YYY have endorsed it:
> >>
> >> The CA Browser Forum believes that short-life certificates are one
> >> possible option for addressing the issue of timely revocation, and so
> >> wishes to remove barriers preventing CAs and browsers deploying and
> >> gaining experience with them. Having a short life on a certificate is an
> >> alternative method of limiting the fallout from mis-issuance while also
> >> providing good performance.
> >>
> >> The ability to omit revocation pointers from a short-life certificate is
> >> important if they are to have any benefit in clients which do not handle
> >> them in a special way (that is, at the moment, all clients). So this
> >> ballot permits that as an exception to the rule requiring OCSP
> >> information to always be present.
> >>
> >> The definition of "short life" as 73 hours is intended such that sites
> >> can roll over their certs every 24 hours, and for all periods of
> >> operation, the cert is valid for 24.5 hours before and 24.5 hours after
> >> - thus to some degree mitigating the effects of clock skew and timezone
> >> issues. To prevent CAs pre-issuing a pile of sequential certificates
> >> which could then potentially be stolen in one big chunk, we forbid them
> >> from creating short-life certs in advance.
> >>
> >> For the avoidance of doubt: CAs are still required to provide revocation
> >> information for such certificates (during their life), which may be
> >> checked by a client which has an out-of-band method of obtaining the
> >> necessary endpoint information and wishes to make the necessary
> >> performance tradeoff. [Comments particularly welcome here; I wrote it in
> >> part because otherwise the surgery to the BRs is rather more extensive.]
> >>
> >> ---MOTION BEGINS---
> >>
> >> Update Appendix B of the CAB Forum Baseline Requirements, part (3),
> >> section C, to say:
> >>
> >> C. authorityInformationAccess
> >>
> >> Other than the exceptions noted below, this extension MUST be present.
> >> It MUST NOT be marked critical, and it MUST contain the HTTP URL of the
> >> Issuing CA’s OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1). It
> >> SHOULD also contain the HTTP URL of the Issuing CA’s certificate
> >> (accessMethod = 1.3.6.1.5.5.7.48.2). See Section 13.2.1 for details.
> >>
> >> The HTTP URL of the Issuing CA’s OCSP responder MAY be omitted in either
> >> of the following two cases:
> >>
> >> * the Subscriber “staples” OCSP responses for the Certificate in its TLS
> >> handshakes [RFC4366]; or
> >>
> >> * the time period between the notBefore and notAfter fields is less than
> >> or equal to 73 hours. To take advantage of this exception, the CA must
> >> create the certificate at a time within 1 hour of that encoded in
> notBefore.
> >>
> >> ---MOTION ENDS---
> >>
> >> For your information, the current text of B (3) C is:
> >>
> >> C. authorityInformationAccess
> >>
> >> With the exception of stapling, which is noted below, this extension
> >> MUST be present. It MUST NOT be marked critical, and it MUST contain the
> >> HTTP URL of the Issuing CA’s OCSP responder (accessMethod =
> >> 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the Issuing
> >> CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2). See Section 13.2.1
> >> for details.
> >>
> >> The HTTP URL of the Issuing CA’s OCSP responder MAY be omitted provided
> >> that the Subscriber “staples” OCSP responses for the Certificate in its
> >> TLS handshakes [RFC4366].
> >>
> >> _______________________________________________
> >> Public mailing list
> >> Public at cabforum.org
> >> https://cabforum.org/mailman/listinfo/public
> >>
> >
>
>
> --
> Sigbjørn Vik
> Opera Software
> _______________________________________________
> 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/20141118/b56c9b10/attachment-0003.html>