<br><br><div class="gmail_quote">On Mon Nov 10 2014 at 3:03:04 PM Sigbjørn Vik <<a href="mailto:sigbjorn@opera.com">sigbjorn@opera.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
Some more thoughts, since that is what you wanted :)<br>
<br>
It seems that in general, we have an issue, where we cannot upgrade<br>
certificate specifications and usage, because it will break older<br>
clients. When legacy usage is a problem like this, it would be good to<br>
fix it. Most likely the problem will become worse over time, and it will<br>
take time to get the fix out to all clients, so we should start right away.<br>
<br>
TLS SNI ensured that one server could serve different certificates<br>
depending on which domain the client wants to connect to. If we made a<br>
similar extension for the client to state what it supports, then the<br>
server could serve different certificates depending on what the client<br>
understands. In practice such an extension might say e.g. "Client<br>
support version 1.0; Opera version 25.0.1614.68", that is sufficient for<br>
the server to know what the client supports, and to work around any<br>
client specific bugs. Privacy minded users/vendors can fall back to not<br>
specifying the extension, and get old style certificates.<br>
<br>
If we had such a specification, then the discussion around short-lived<br>
certificates would be quite different, as we don't need to worry about<br>
legacy clients, servers just keep serving them the old certificates. So<br>
assume this exists, then read on :)<br>
<br>
One of the issues I have with not specifying revocation pointers is that<br>
it is then possible to bulk pre-issue certificates for a year, with no<br>
way to revoke them. When things are possible to do, sooner or later<br>
someone will want to do them, e.g. due to some old legacy system which<br>
nobody dares change. Having rules which can be checked programmatically<br>
is much preferable.<br>
<br>
So here is another suggestion:<br>
Create a special breed of short-lived certificates. They have no 'valid<br>
from' or 'valid to' fields, nor revocation pointers. Instead they carry<br>
a proof of the time they were issued, e.g. the latest hash from a CT<br>
log. The certificate is valid 3 days from that timestamp. Backdating is<br>
possible (and legal, but more than 3 days is pointless), pre-issuing is<br>
impossible. Clients have CT log data anyhow, and can compare their local<br>
time to the log time, and automatically account for any clock skew.<br>
Since clock skew is handled, expired certs can be treated just as<br>
harshly as revoked certs. Total data size on the wire should be smaller<br>
than the original proposal.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On 10-Nov-14 15:18, Rob Stradling wrote:<br>
> Hi Gerv.  Some thoughts...<br>
><br>
> 1. BRs 13.2.6 says that OCSP responders MUST NOT respond with a "good"<br>
> status for "a certificate that has not been issued" and that "The CA<br>
> SHOULD monitor the responder for such requests as part of its security<br>
> response procedures".<br>
> If OCSP is never used (which would be the case if AIA->OCSP is omitted),<br>
> then "monitoring the responder" in this way cannot happen.  This could<br>
> mean that future CA compromises aren't spotted as early as they<br>
> otherwise might be.<br>
><br>
> 2. When revocation is effective (e.g. Firefox with OCSP hard-fail<br>
> enabled by the user), the user is prevented from accessing the HTTPS<br>
> site.  However, certificate expiration is treated less harshly - the<br>
> user can still access the site.<br>
> For short-lived certs to be an effective revocation mechanism (for all<br>
> certs ideally, but definitely for short-lived certs), expiration needs<br>
> to be treated as harshly as revocation IMHO.<br>
> The idea of your proposed ballot is that existing browsers will benefit<br>
> from omitting all revocation pointers.  But it's the existing browsers<br>
> that, by definition, cannot be updated to treat expiration as harshly as<br>
> revocation.<br>
><br>
> 3. You propose that "CAs are still required to provide revocation<br>
> information for such certificates (during their life)", and I agree with<br>
> that.<br>
> For Google's CRLSets, Mozilla's OneCRL (I presume), and certainly<br>
> Phill's/my Compressed CRLSet proposal, the generator needs to be able to<br>
> determine the current status of every certificate that's in scope.  To<br>
> do this, a revocation pointer for each certificate is required.  If<br>
> there's no revocation pointer in a cert, what do we do?<br>
> Phill's already expressed our hope that "If however we combine short<br>
> lived certs with compressed CRLs we can reduce the vulnerability window<br>
> from days to hours".<br>
><br>
> 4. What is preventing you from experimenting with short-lived certs that<br>
> _do_ contain revocation pointers?<br>
> You could change Firefox so that it avoids doing revocation checks for<br>
> short-lived certs.  You could gather statistics on how much of a problem<br>
> clock-skew is for the use of short-lived certs in practice.  You could<br>
> gather user reports on how much of a pain it is to install a new cert on<br>
> a daily basis.<br>
><br>
><br>
> But if we must omit revocation pointers, then...<br>
><br>
> 5. Possible compromise: Make AIA->OCSP optional, but require CDP.<br>
> Firefox doesn't check CDP, AIUI Windows intends to stop checking CDP,<br>
> AIUI many mobile devices have never checked CDP.<br>
> But including CDP helps the production of CRLSets.<br>
><br>
> 6. Possible compromise 2: Specify a new mechanism for obtaining<br>
> revocation status, which no existing browser will use, but which CRLSet<br>
> generators could use.<br>
> Perhaps use the same syntax as the CDP extension, but just change the<br>
> extension's OID.  Or maybe put an OCSP responder URL in the issuing CA<br>
> cert's Subject Information Access extension (instead of the end-entity<br>
> cert's Authority Information Access extension).<br>
><br>
><br>
> On 23/10/14 13:13, Gervase Markham wrote:<br>
>> Following on from discussions at the last face-to-face and in the<br>
>> Mozilla forum, this is a pre-ballot for discussion. Comments are very<br>
>> welcome.<br>
>><br>
>> Gerv<br>
>><br>
>><br>
>> Pre-Ballot XXX - Short-Life Certificates<br>
>><br>
>> Gervase Markham of Mozilla made the following motion and XXX of XXX and<br>
>> YYY of YYY have endorsed it:<br>
>><br>
>> The CA Browser Forum believes that short-life certificates are one<br>
>> possible option for addressing the issue of timely revocation, and so<br>
>> wishes to remove barriers preventing CAs and browsers deploying and<br>
>> gaining experience with them. Having a short life on a certificate is an<br>
>> alternative method of limiting the fallout from mis-issuance while also<br>
>> providing good performance.<br>
>><br>
>> The ability to omit revocation pointers from a short-life certificate is<br>
>> important if they are to have any benefit in clients which do not handle<br>
>> them in a special way (that is, at the moment, all clients). So this<br>
>> ballot permits that as an exception to the rule requiring OCSP<br>
>> information to always be present.<br>
>><br>
>> The definition of "short life" as 73 hours is intended such that sites<br>
>> can roll over their certs every 24 hours, and for all periods of<br>
>> operation, the cert is valid for 24.5 hours before and 24.5 hours after<br>
>> - thus to some degree mitigating the effects of clock skew and timezone<br>
>> issues. To prevent CAs pre-issuing a pile of sequential certificates<br>
>> which could then potentially be stolen in one big chunk, we forbid them<br>
>> from creating short-life certs in advance.<br>
>><br>
>> For the avoidance of doubt: CAs are still required to provide revocation<br>
>> information for such certificates (during their life), which may be<br>
>> checked by a client which has an out-of-band method of obtaining the<br>
>> necessary endpoint information and wishes to make the necessary<br>
>> performance tradeoff. [Comments particularly welcome here; I wrote it in<br>
>> part because otherwise the surgery to the BRs is rather more extensive.]<br>
>><br>
>> ---MOTION BEGINS---<br>
>><br>
>> Update Appendix B of the CAB Forum Baseline Requirements, part (3),<br>
>> section C, to say:<br>
>><br>
>> C. authorityInformationAccess<br>
>><br>
>> Other than the exceptions noted below, this extension MUST be present.<br>
>> It MUST NOT be marked critical, and it MUST contain the HTTP URL of the<br>
>> Issuing CA’s OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1). It<br>
>> SHOULD also contain the HTTP URL of the Issuing CA’s certificate<br>
>> (accessMethod = 1.3.6.1.5.5.7.48.2). See Section 13.2.1 for details.<br>
>><br>
>> The HTTP URL of the Issuing CA’s OCSP responder MAY be omitted in either<br>
>> of the following two cases:<br>
>><br>
>> * the Subscriber “staples” OCSP responses for the Certificate in its TLS<br>
>> handshakes [RFC4366]; or<br>
>><br>
>> * the time period between the notBefore and notAfter fields is less than<br>
>> or equal to 73 hours. To take advantage of this exception, the CA must<br>
>> create the certificate at a time within 1 hour of that encoded in notBefore.<br>
>><br>
>> ---MOTION ENDS---<br>
>><br>
>> For your information, the current text of B (3) C is:<br>
>><br>
>> C. authorityInformationAccess<br>
>><br>
>> With the exception of stapling, which is noted below, this extension<br>
>> MUST be present. It MUST NOT be marked critical, and it MUST contain the<br>
>> HTTP URL of the Issuing CA’s OCSP responder (accessMethod =<br>
>> 1.3.6.1.5.5.7.48.1). It SHOULD also contain the HTTP URL of the Issuing<br>
>> CA’s certificate (accessMethod = 1.3.6.1.5.5.7.48.2). See Section 13.2.1<br>
>> for details.<br>
>><br>
>> The HTTP URL of the Issuing CA’s OCSP responder MAY be omitted provided<br>
>> that the Subscriber “staples” OCSP responses for the Certificate in its<br>
>> TLS handshakes [RFC4366].<br>
>><br>
>> ______________________________<u></u>_________________<br>
>> Public mailing list<br>
>> <a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
>> <a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/<u></u>listinfo/public</a><br>
>><br>
><br>
<br>
<br>
--<br>
Sigbjørn Vik<br>
Opera Software<br>
______________________________<u></u>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/<u></u>listinfo/public</a><br>
</blockquote></div>