Subject: Re: [pkix] RFC4387, cert store access via http implementations?

From: Tom Gindin <[email-masked]>
Date: Thu, 2 Dec 2010 21:19:04 -0500

The good news is that if you use a dummy implementation of this 
feature both keywords are equally simple to implement.  The arrangement is 
as follows:
        For each supported value of IHash or DPHash (assuming that that is 
standardized), there exists a configuration property whose key name ends 
with that value and whose value is a local directory's path.  The contents 
of that directory are a set of CRL files named YYYYMMDDHHMMSS.crl, where 
the name reflects the date and time when that CRL was issued.
        I hope it's evident how one would implement both lastBefore and 
nextAfter, as well as the basic retrieval, in such a case.

                Tom Gindin

From:
Jean-Marc Desperrier <[email-masked]>
To:
[email-masked], Tom Gindin/Watson/IBM@IBMUS
Cc:
Peter Gutmann <[email-masked]>
Date:
11/30/2010 12:25 PM
Subject:
Re: [pkix] RFC4387, cert store access via http implementations?

Tom Gindin wrote:
>          Others have asked for functionality equivalent to lastBefore, 
such
> as Rafal Siuda in September, although he thought it would be easier to 
get
> CA's to leave expired certificates on fresh CRL's.  I think that's 
needed
> for any post-expiration signature verification that doesn't do the kind 
of
> preservation of results sketched in the old technr draft.  Ersin will 
need
> to explain the use of nextAfter.

The request for lastBefore from Rafa Siuda comes from this statement :
 > Reason:
 > As rfc5280 states on CRL should be certificates which are not expired.

That's not precisely what rfc5280 says. It says instead :
    [...] An entry MUST NOT be removed
    from the CRL until it appears on one regularly scheduled CRL issued
    beyond the revoked certificate's validity period.

So if you want to be sure to get the last CRL in which your certificate 
might be frequent, you need to be able to request the first regularly 
scheduled CRL issued beyond it's validity period.

To do that, you need a nextAfter request containing the expiration date 
of the certificate.

Similarly, if a document has been signed at date X, what you usually 
want to be sure of is that at that date X the signing certificate wasn't 
revoked. So you want to be sure there's no CRL that revokes this 
certificate with a revocation date earlier than X.

RFC5280 says that revocation date "is the date at which the CA processed 
the revocation".
So the next CRL issued after X can revoke the certificate with a 
revocation date earlier than X, but only that next CRL can do that as 
RFC5280 also states that "the revocation date SHOULD NOT precede the 
date of issue of earlier CRLs."

So again the correct request to do is for the nextAfter CRL using date X 
of signature of the document.

So in my opinion, that usually nextAfter that's required, and not 
lastBefore.

---

From: Ersin Gülaçtı <[email-masked]>
Date: Fri, 3 Dec 2010 14:12:22 +0200

Actually what we need is to learn the status of a certificate at a certain
time in the past (at the signature date of a signed document). There is no
explicit way of doing this with current RFCs. Therefore we try to collect
the last CRL before the signature date and the first CRL after the signature
date. (We can use RFC 4387 with lastBefore and nextAfter keywords) 

We need both CRLs to catch a possible certificateHold status. By looking at
the lastBefore CRL we can see whether the certificate was on hold at that
time. By looking at the nextAfter CRL we can see whether the certificate was
valid at signature time. 

I am aware that this is not an accurate solution but it is an estimate
evaluation of the status of the certificate.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jean-Marc Desperrier
Sent: Tuesday, November 30, 2010 7:23 PM
To: [email-masked]; Tom Gindin
Subject: Re: [pkix] RFC4387, cert store access via http implementations?

such
> as Rafal Siuda in September, although he thought it would be easier to get
> CA's to leave expired certificates on fresh CRL's.  I think that's needed
> for any post-expiration signature verification that doesn't do the kind of
> preservation of results sketched in the old technr draft.  Ersin will need

So in my opinion, that usually nextAfter that's required, and not 
lastBefore.
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix