[cabfpub] Short Lived Certificates

[kirk_hall at trendmicro.com]

Jeremy, even if an attacker could cache and supply a previously good response (clearly a problem) – wouldn’t that be the rare case?

More likely a short lived cert might be revoked soon after issuance because of a key compromise, etc. – in those cases, quick revocation with required OCSP responses would, in fact, deliver correct revocation information (“revoked”)  to the vast majority of relying parties (as no attacker would be devilishly supplying cached but incorrect good responses to relying parties in those cases).

In other words, I don’t think we should drop the normal procedure of supplying revocation information to relying parties simply because in the rare case an attacker can get around it – revocation is still useful to relying parties in the “normal” case where no attack is occurring.  We can’t get to 100% security, but 99% security is still worth going for.

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Friday, July 27, 2012 11:29 AM
To: public at cabforum.org
Subject: Re: [cabfpub] Short Lived Certificates


To follow up on the initial post, some members have disagreed about the value of the short-lived certificates.  This is a response to that disagreement and an attempt to move the discussion to the public mailing list:



I think this discussion is straying from the point that several of us are trying to make-- that revocation time-tables are effectively the same as short-lived certificates, regardless of the mechanism selected.  In a secure-site environment, a short-lived certificate has the same practical effect as current revocation mechanisms because with the caching of CRLs and certificate status responses there will always create a window where revocation can't happen.  Even if a CA revokes a certificate using OCSP, the CA can't prevent an attacker from supplying a previously good response for a given TTL.  There isn't a benefit to OCPS or CRL over short-lived certs.



All we should be asking at this point is whether a short-lived certificate should be acceptable under the baseline requirements (a minimum standard).  Remember, we are only establishing a floor for certificate practices, not building walls to restrict practices we don't implement, stifle new ideas, or prevent every conceivable attack.  Therefore, the burden is on those opposed to short-lived certificates to provide clear and convincing reasons why they should not be allowed.  From a practical standpoint, a short-lived certificate has a benefit for those companies who don't want to rely on OCSP or CRL certificate revocation and would like a performance gain by eliminating revocation look-ups.  The whole point of a short-lived certificate is that its short life IS the revocation information.



As far as intermediate certificates are concerned, we can get a significant performance gain if we limit the revocation information in intermediates used to issue short lived certificates to CRLs instead of mandating OCSP.  This way intermediates still have revocation information included but short-lived certificates continue to provide a significant benefit.  Unless someone has a good security reason against it, the baseline requirements should permit short-lived certificates issued from an Intermediate that contain CRLs but not require OCSP.



Jeremy


From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Friday, July 27, 2012 12:26 PM
To: public at cabforum.org
Subject: [cabfpub] Short Lived Certificates

Hi everyone,

One of the current discussions in the CAB Forum is the issuance of short-lived certificates.  I thought I’d move the discussion over this public list for additional input. This is the proposal (which has been updated from its original post based on the comments received so far):

While reviewing the baseline requirements, we noticed an odd situation where the baseline requirements permit a CA to omit any revocation information in a certificate.  We also noticed that the baseline requirements don't permit the use of short-lived certificates.  As discussed previously, short-lived certificates have a lifecycle of about seven days.  Because the lifecycle is short, the risks associated with a compromised certificate are minimized, making revocation information in the certificate unnecessary.  Because short-lived certificates are highly sensitive to the accuracy of a relying party's system time, for fault-tolerance purposes, it is best if short-lived certificates have a “valid from” date/time that pre-dates the actual date/time of issuance.  Having the certificate be valid for a period of 14 days (seven on either side of the issuance date) helps eliminate the accuracy concerns.

Appendix B of the baseline requirements state:

B. cRLDistributionPoints

This extension MAY be present.  If present, it MUST NOT be marked critical, and it MUST contain the  HTTP URL of the CA’s CRL service.  See Section 13.2.1 for details.

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].

This results in an odd situation where a CA can issue a certificate without either a CRL or AIA if the customer promises to use OCSP stapling. A customer won’t serve a revoked certificate through its server, meaning the certificate can never be effectively revoked. Compare this to Appendix B of the EV Guidelines.

(B) cRLDistributionPoint

This extension SHOULD be present and MUST NOT be marked critical.  If present, it MUST contain the HTTP URL of the CA‟s CRL service.  This extension MUST be present if the certificate does not specify OCSP responder locations in an authorityInformationAccess extension.  See Section  11 for details.

(C) authorityInformationAccess

This extension SHOULD be present and MUST NOT be marked critical.  If present, it MUST contain  the HTTP URL of the CA‟s OCSP responder (accessMethod = 1.3.6.1.5.5.7.48.1).

An HTTP URL MAY be included for the Subordinate CA‟s certificate (accessMethod = 1.3.6.1.5.5.7.48.2)

This extension MUST be present if the certificate does not contain a cRLDistributionPoint extension.  See Section 11 for details.

To accommodate short-lived certificates and remedy this loophole, I propose we modify the baseline requirements as follows:

(new definition) Short Lived Certificates: A Certificate with an “Valid To” date that is seven or less days from the date of issuance and a “Valid From” date that is no more than seven days prior to the date of issuance.

13.1.5 Reasons for Revocation

If one or more of the following reasons for revocation occurs, a CA SHALL, within 24 hours, (i) revoke all affected Certificates that contain a cRLDistributionPoint or an authorityInformationAccess extension and (ii) cease issuing Short Lived Certificates to the Subscriber until none of the reasons for revocation apply.

13.2.2 Repository

The CA SHALL maintain an online 24x7 Repository that application software can use to automatically check the current status of all unexpired Certificates (except Short Lived Certificates) issued by the CA.  The CA MAY include certificate status information for Short Lived Certificates in its Repository.

Appendix B – Certificate Extensions (Normative)

Subordinate CA Certificates

B. cRLDistributionPoint

This extension MUST be present and MUST NOT be marked critical.  This extension MUST contain the  HTTP URL of the CA’s CRL service.

C. authorityInformationAccess

With the exception of stapling, which is noted below, this extension MAY be present.  If present, this extension 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.

Subscriber Certificates

B. cRLDistributionPoint

This extension MAY be present.  If present, it MUST NOT be marked critical, and it MUST contain the  HTTP URL of the CA’s CRL service.  This extension MUST be present if the certificate does not specify OCSP responder locations in an authorityInformationAccess extension and the certificate is not a Short Lived Certificate.

C. authorityInformationAccess

With the exception of stapling, which is noted below, Short Lived Certificates, this extension MUST be present.  This extension MAY be present in Short Lived Certificates. 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.

Jeremy


TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://cabforum.org/pipermail/public/attachments/20120727/fc53c955/attachment-0001.html