Subject: OCSP revision

From: "Carl Wallace" <[email-masked]>
Date: Tue, 8 Nov 2005 13:52:20 -0500

At the meeting yesterday, OCSP revisions to address algorithm agility were
discussed.  Since the doc is being revised, I suggest an extension or field
be added to enable clients to ask the responder to include the responder's
certificate in the response (similar to the certReq field in RFC3161).

---

From: Dr Stephen Henson <[email-masked]>
Date: Tue, 08 Nov 2005 19:36:41 +0000

> certificate in the response (similar to the certReq field in RFC3161).  

Could other OCSP revisions be incorporated at the same time or just
"algorithm agility"?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Massimiliano Pala <[email-masked]>
Date: Fri, 11 Nov 2005 00:15:53 -0500

Hi all,

Is there a way for a CA to specify its own (not its issuer's) CRL
distribution point in its certificate ?

I am asking this because the only way I found so far is by using
the Subject Information Access with id-ad-caRepository as accessMethod.
The problem is that its definition is too broad, therefore the URI I
can put in there could address a CRL or Certs repository or other
services.

 From the RFC-3280 (pp 47):

<< The id-ad-caRepository OID is used when the subject is a CA, and
    publishes its certificates and CRLs (if issued) in a repository.  The
    accessLocation field is defined as a GeneralName, which can take
    several forms. >>

While the accessLocation is quite simple to deal with, we should have
different accessMethod ids at least for CRLs and Certificates repositories.

In other words, is there a method to access the CRLs of a CA from the CA's
certificate only ?

Am I missing something here ?

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]      [email-masked]
                                                 Tel.:   +39 (0)11  564 7081
http://security.polito.it                       Fax:    +39   178  270 2077
                                                 Mobile: +39 (0)347 7222 365

Politecnico di Torino (EuroPKI)
Certification Authority Informations:

Authority Access Point                                  http://ca.polito.it
Authority's Certificate:          http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------

---

From: "Santosh Chokhani" <[email-masked]>
Date: Fri, 11 Nov 2005 07:29:59 -0500

And why would you want to do that?

Generally, you need revocation information for a certificate and hence CRL
DP in the certificate can and should be used to get the revocation data.

Why would you want a pointer in Issuing CA certificate?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Massimiliano Pala
Sent: Friday, November 11, 2005 12:16 AM
To: [email-masked]
Subject: RFC-3280 [Subject Information Access]

Hi all,

I am asking this because the only way I found so far is by using the Subject
Information Access with id-ad-caRepository as accessMethod. The problem is
that its definition is too broad, therefore the URI I can put in there could
address a CRL or Certs repository or other services.

-- 

Best Regards,

	Massimiliano Pala

---

From: Tom Gindin <[email-masked]>
Date: Sat, 12 Nov 2005 16:04:43 -0500

Santosh, Massimiliano:

        I'm confused by the way in which one would enable "a CA to specify 
its own (not its issuer's) CRL distribution point in its certificate". 
Does this mean the distribution point covering the CA (which should 
already be in the certificate issued to this CA) or a distribution point 
containing a CRL created by the CA (which gets put into the CRL DP of a 
certificate it creates)?  And does it go into a certificate issued to the 
CA by another CA (in which case it can't be specified in this way), a 
certificate issued by the CA to somebody else (the purpose for which CRL 
DP's were designed, unless it's a CRL covering the CA), or a rollover 
self-issued certificate?
        A relying party certainly needs to have revocation information for 
an intermediate CA, and that's normally found in the intermediate CA's 
certificate.  I suppose that if an intermediate CA has a certificate from 
which it's hard to find the CRL (e.g. a certificate with no distribution 
point address or with only a DN as specification) a pointer from each 
certificate it issues could be useful.  However, this would naturally go 
into the AIA extension (since it references information about the issuer 
of the certificate) rather than into SIA, and it would have to be of lower 
precedence than an AIA or DP in the issuer certificate itself since the CA 
MUST not be able to override a revocation of its certificate.  Is 
permitting a CA to do this really a good idea, and if so is it worthwhile?

Tom Gindin

"Santosh Chokhani" <[email-masked]>
Sent by: [email-masked]
11/11/2005 07:29 AM
 
        To:     <[email-masked]>
        cc: 
        Subject:        RE: RFC-3280 [Subject Information Access]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
On
Behalf Of Massimiliano Pala
Sent: Friday, November 11, 2005 12:16 AM
To: [email-masked]
Subject: RFC-3280 [Subject Information Access]

Hi all,

I am asking this because the only way I found so far is by using the 
Subject
Information Access with id-ad-caRepository as accessMethod. The problem is
that its definition is too broad, therefore the URI I can put in there 
could
address a CRL or Certs repository or other services.

While the accessLocation is quite simple to deal with, we should have
different accessMethod ids at least for CRLs and Certificates 
repositories.

-- 

Best Regards,

                 Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] [email-masked]
                                                 Tel.:   +39 (0)11  564 
7081
http://security.polito.it                       Fax:    +39   178  270 
2077
                                                 Mobile: +39 (0)347 7222 
365

Authority Access Point                                  
http://ca.polito.it
Authority's Certificate:          
http://ca.polito.it/ca_cert/en_index.html
Certificate Revocation List:              
http://ca.polito.it/crl02/crl.crl
--o------------------------------------------------------------------------

---

From: Massimiliano Pala <[email-masked]>
Date: Sat, 12 Nov 2005 17:54:04 -0500

> DP's were designed, unless it's a CRL covering the CA), or a rollover 

Now I am confused... sorry I did not get your question. Let me explain by
using an example:

	rootCA -> CA1 -> CA2 -> UserCert

In this case the CRL Distribution Point extension will carry pointers to:
* If in the user cert -> to the CRL issued by CA2
* If in the CA2 cert -> to the CRL issued by CA1
* If in the rootCA cert -> to the CRL issued by the issuer of rootCA, which
   is equivalent to the subject, therefor (this is my guess) you can put there
   the pointer to the CRL issued by rootCA

My problem is: how do I find the CRL issued by CA2 without having to retrieve
a UserCert (or a cert issued by CA2) ? I guess there is no way to do such a
thing at the moment... am I wrong ?

> of the certificate) rather than into SIA, and it would have to be of lower

Indeed, my point was : how to search for a CRL issued by CA1 provided you
only have CA1 cert ? This should go into SIA, not AIA...

> permitting a CA to do this really a good idea, and if so is it worthwhile?

No, probably there is a misunderstanding here. What I was proposing was not
to change AIA or CDP contents, instead to provide a specific extension to
point to CRLs issued by the "current" CA cert (not by its issuer). This
has a different purpose than searching for revocation information for the
"current" certificate; I want a pointer to revocation information provided
by the "current" certificate...

I hope I clarified a bit what I was really asking... :-D

Let me know,

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]            [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 062 (Sudikoff)	    Office Phone: +1 (603) 646-9226
--o------------------------------------------------------------------------

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sat, 12 Nov 2005 20:40:29 -0500

Tom,

See responses in-line under [Santosh:]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tom Gindin
Sent: Saturday, November 12, 2005 4:05 PM
To: Santosh Chokhani
Cc: [email-masked]
Subject: RE: RFC-3280 [Subject Information Access]

        Santosh, Massimiliano:

[Santosh: A CRL DP in a certificate will point to location(s) from which
revocation information for that certificate can be obtained.]

certificate it creates)?

[Santosh: Again, a CRL DP in certificate points to CRL that covers the
status of the certificate.]

  And does it go into a certificate issued to the 
CA by another CA (in which case it can't be specified in this way), a 
certificate issued by the CA to somebody else (the purpose for which CRL 
DP's were designed, unless it's a CRL covering the CA), or a rollover 
self-issued certificate?

[Santosh: I am not sure what you are saying above.  But, a CRL DP in a
certificate will point to location(s) from which revocation information for
that certificate can be obtained.]

certificate.

[Santosh; Amen]

I suppose that if an intermediate CA has a certificate from 

[Santosh: You can always define new extensions or add fields and options to
existing extensions.  But, that is not there.  You should talk with the
3280bis editors if you want to have a capability in SIA or AIA to point to
CRL.]

Tom Gindin

        To:     <[email-masked]>
        cc: 

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

Hi all,

-- 

Best Regards,

                 Massimiliano Pala

Authority Access Point                                  
http://ca.polito.it
Authority's Certificate:

---

From: Russ Housley <[email-masked]>
Date: Sun, 13 Nov 2005 19:05:25 -0500

>         rootCA -> CA1 -> CA2 -> UserCert

Since you do not say anything about indirect CRLs, I'll assume that 
it has nothing to do with your question.  My response ignores indirect CRLs.

If each of these certificates contains a CRL DP, then you do not need 
any further information.

CA2 -> UserCert:  The CRL DP in this certificate will provide a 
pointer to the CRL issued by CA2 that will include an entry for 
UserCert if it is revoked.

CA1 -> CA2:  The CRL DP in this certificate will provide a pointer to 
the CRL issued by CA1 that will include an entry for CA2 if it is revoked.

rootCA -> CA1:  The CRL DP in this certificate will provide a pointer 
to the CRL issued by rootCA that will include an entry for CA1 if it 
is revoked.

Russ

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 14 Nov 2005 13:51:42 -0500

Hi Russ,

thank for the answer, but probably due to my bad english I was not really
clear... my situation is this:

- I have an OCSP server and I want it to be able to "auto" configure the
   downloading of CRLs, provided some pointer is given in the CA cert for
   its own certs, this is:

	* I have only CA2 cert

	* I want to access CRLs issued by CA2

	* No other info is given to the server besides the CA2 cert

The question is if there are extensions/methods to do that without having
to access at least one certificate issued by CA2 (where the CDP will provide
the pointer I need).

My guess is that SubjectInformationAccess could be used, but its definition
is quite broad and I was looking for something more specific... easy for the
developers...

>>         rootCA -> CA1 -> CA2 -> UserCert
[...]
> CA2 -> UserCert:  The CRL DP in this certificate will provide a pointer 
> to the CRL issued by CA2 that will include an entry for UserCert if it 
> is revoked.
> 
> rootCA -> CA1:  The CRL DP in this certificate will provide a pointer to 
> the CRL issued by rootCA that will include an entry for CA1 if it is 
> revoked.

-- 

Best Regards,

	Massimiliano Pala

Dartmouth Computer Science Dept                     Tel.: +1 (603) 397-3883
PKI/Trust
--o------------------------------------------------------------------------

---

From: Russ Housley <[email-masked]>
Date: Mon, 14 Nov 2005 14:16:24 -0500

SIA could be used to provide the pointer that you seek, but I do not 
think that anyone uses it that way.  In fact, I suspect that a 
document would need to be written to tell people how to do it in an 
interoperable way.  If you want to pursue that, you would need to 
write an internet-draft and convince the PKIX WG that it wants to 
adopt it as a work item.

Russ

At 01:51 PM 11/14/2005, Massimiliano Pala wrote:
>>If each of these certificates contains a CRL DP, then you do not 
>>need any further information.
>>CA1 -> CA2:  The CRL DP in this certificate will provide a pointer 
>>to the CRL issued by CA1 that will include an entry for CA2 if it is revoked.
>>rootCA -> CA1:  The CRL DP in this certificate will provide a 
>>pointer to the CRL issued by rootCA that will include an entry for 
>>CA1 if it is revoked.
>
>--
>
>Best Regards,
>
>         Massimiliano Pala
>

---

From: "David A. Cooper" <[email-masked]>
Date: Mon, 14 Nov 2005 15:34:08 -0500

Massimiliano,

At the moment, there is no way to accomplish what you are trying to do 
in general.

I should begin by pointing out that the text that you quoted from RFC 
3280 has been changed in 3280bis so that it no longer mentions CRLs:

   The id-ad-caRepository OID is used when the subject is a CA, and
   publishes certificates it issues in a repository.  The accessLocation
   field is defined as a GeneralName, which can take several forms.

If a CA issues full CRLs then what you are trying to accomplish may be 
possible.  If the CA makes its certificates and CRLs available in a 
directory and you know the directory and the name of the CA, then you 
should be able to obtain the CA's CRL if it issues a full CRL (see RFC 
2587).  If a CA issues full CRLs, but you cannot use this method to find 
the CRL, then you will need to look at the cRLDistributionPoints 
extension in one of the certificates issued by the CA to determine where 
to obtain the CRL.

The biggest problem will be if the CA only issues segmented CRLs.  In 
this case looking at a single certificate issued by the CA will not be 
sufficient, since different certificates will point to different CRL 
segments.  For such a CA it would also not be possible to use some new 
accessMethod in the subjectInfoAccess extension since the CA may create 
new CRL segments as it issues certificates and the SIA extensions of 
certificates could not be updated to add these new segments.

Dave

---

From: "Santosh Chokhani" <[email-masked]>
Date: Mon, 14 Nov 2005 17:20:59 -0500

There are several issues like this for CA -- OCSP Responder communication
that are not covered by 2560 and could stand some guidance or
standardization in a new I-D or revision of 2560.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ Housley
Sent: Monday, November 14, 2005 2:16 PM
To: Massimiliano Pala
Cc: pkix
Subject: Re: RFC-3280 [Subject Information Access]

Russ

At 01:51 PM 11/14/2005, Massimiliano Pala wrote:
>Hi Russ,
>
>thank for the answer, but probably due to my bad english I was not 
>really clear... my situation is this:
>
>The question is if there are extensions/methods to do that without 
>having to access at least one certificate issued by CA2 (where the CDP 
>will provide the pointer I need).
>
>My guess is that SubjectInformationAccess could be used, but its 
>definition is quite broad and I was looking for something more 
>specific... easy for the developers...
>
>Russ Housley wrote:
>>Massimiliano:
>>
>>>Now I am confused... sorry I did not get your question. Let me 
>>>explain by using an example:
>>>

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 14 Nov 2005 19:05:52 -0500

> At the moment, there is no way to accomplish what you are trying to do 

:-(

>   field is defined as a GeneralName, which can take several forms.

So in 3280bis this will not provide a generalized pointer to certs AND
CRLs but only to certs repositories, right ?

[...]
> certificates could not be updated to add these new segments.

Is there any chance we can define a `SubjectRevocationAccess' extension
that will point to revocation informations provided by the Subject of the
certificate it appears in ? Is a bad idea ? Could it be added to the
3280bis ?

Thanks to all for any comment/support!

-- 

Best Regards,

	Massimiliano Pala

Dartmouth Computer Science Dept               Home Phone: +1 (603) 397-3883
PKI/Trust - Office 062                        Work Phone: +1 (603) 646-9226
--o------------------------------------------------------------------------

---

From: Massimiliano Pala <[email-masked]>
Date: Mon, 14 Nov 2005 18:57:55 -0500

Russ Housley wrote:
> think that anyone uses it that way.  In fact, I suspect that a document 

That was my original point, but I do agree no one is actually using it
in this way...

> would need to be written to tell people how to do it in an interoperable 
> way.  If you want to pursue that, you would need to write an 
> internet-draft and convince the PKIX WG that it wants to adopt it as a 
> work item.

Now the next step is to understand if this could be useful in real environments
or not... well, obviously I think so, but I would like to have other opinions
about this.

Thanks for the answer!

-- 

Best Regards,

	Massimiliano Pala