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

From: Tomas Gustavsson <[email-masked]>
Date: Fri, 26 Nov 2010 12:59:38 +0100

Hi,

We just implemented RFC4387 in EJBCA (ejbca.org), or at least partly. So
just out of curiosity, has this rfc other implementations?
Is it widely used by any clients (I don't know of any myself)?

We implemented rfc4387 primarily to be able to supply a standard way of
distributing CA certificates and CRLs to relying clients, and not so
much to distribute client certificates (yet).
Since this feature was needed it was nice to be able to implement it
according to a standard, instead of inventing something new as usual.

Cheers,
Tomas

---

From: Ersin Gülaçtı <[email-masked]>
Date: Fri, 26 Nov 2010 15:38:32 +0200

We have implemented a service which has the similar functionality but our
service is not compliant with RFC4387. We are considering to implement an
RFC4387 interface but RFC4387 lacks a very important (at least for us)
capability. 

Our service can respond to queries for CRLs that are created before or after
a given date. This helps our certificate validation algorithm to find the
necessary CRLs long after the expiration date of the certificate. If this
kind of queries can be handled by RFC4387 we will implement it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Tomas Gustavsson
Sent: Friday, November 26, 2010 2:00 PM
To: [email-masked]
Subject: [pkix] RFC4387, cert store access via http implementations?

Hi,

Cheers,
Tomas

_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Tom Gindin <[email-masked]>
Date: Fri, 26 Nov 2010 20:13:42 -0500

It sounds to me as if you need the facilities suggested by 
http://www.ietf.org/mail-archive/web/pkix/current/msg28393.html, in 
particular the lastBefore keyword.  Do you also need a "nextAfter" 
keyword, as your message suggests, or is that just included for 
completeness?

                Tom Gindin

From:
Ersin Gülaçtı <[email-masked]>
To:
"'Tomas Gustavsson'" <[email-masked]>, <[email-masked]>
Date:
11/26/2010 08:34 AM
Subject:
Re: [pkix] RFC4387, cert store access via http implementations?
Sent by:
[email-masked]

Our service can respond to queries for CRLs that are created before or 
after
a given date. This helps our certificate validation algorithm to find the
necessary CRLs long after the expiration date of the certificate. If this
kind of queries can be handled by RFC4387 we will implement it.

-----Original Message-----

Hi,

Cheers,
Tomas

---

From: [email-masked]
Date: Sun, 28 Nov 2010 17:19:15 +0200 (EET)

We need both funtionality. Since there was no explicit definition of lastBefore and nextAfter in the RFC we haven't implemented the RFC. But as Peter and you mentioned it is possible to use these attribute names. How can we assure that these attribute names are compatible among different implementations?

----- Orijinal Mesaj -----
Kimden: "Tom Gindin" <[email-masked]>
Kime: "Ersin Gülaçtı" <[email-masked]>
Kk: [email-masked], [email-masked], "Tomas Gustavsson" <[email-masked]>
Gönderilenler: 27 Kasım Cumartesi 2010 3:13:42
Konu: Re: [pkix] RFC4387, cert store access via http implementations?

                Tom Gindin

From:

-----Original Message-----

Hi,

Cheers,
Tomas

---

From: Yoav Nir <[email-masked]>
Date: Sun, 28 Nov 2010 22:47:57 +0200

The obvious answer would be to write a draft that extends RFC 4387. Then there would be just one right way to do it.

On Nov 28, 2010, at 5:19 PM, <[email-masked]> <[email-masked]> wrote:

> q��y��
> ���"��赩Ry˫�܆jװk

---

From: Tom Gindin <[email-masked]>
Date: Tue, 30 Nov 2010 09:06:21 -0500

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.

                Tom Gindin

From:
Peter Gutmann <[email-masked]>
To:
[email-masked], Tom Gindin/Watson/IBM@IBMUS
Cc:
[email-masked]
Date:
11/29/2010 01:34 AM
Subject:
Re: [pkix] RFC4387, cert store access via http implementations?

[email-masked] writes:

>We need both funtionality. Since there was no explicit definition of
>lastBefore and nextAfter in the RFC we haven't implemented the RFC. But 
as
>Peter and you mentioned it is possible to use these attribute names. How 
can
>we assure that these attribute names are compatible among different
>implementations?

Publish an RFC "additional attribute types for xxx"?  OTOH is there any 
chance
that someone other than you will ever need, or use, these attributes?  The
reason why the extensibility was added was to allow the addition of
custom/proprietory attributes without requiring a new RFC for each one.

Peter.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Tue, 30 Nov 2010 18:22:59 +0100

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.