Subject: Proposal on use of CRL issuer in section 3 of RFC3280

From: "David A. Cooper" <[email-masked]>
Date: Thu, 18 Nov 2004 11:10:36 -0500

All,

It is clear that the use of the term "CRL issuer" in section 3 of RFC
3280 has been causing a lot of confusion, since some people have
interpreted this section as providing a definition of "CRL issuer"
rather than just providing a description of the corresponding diagram.

I believe that this section should be changed in 3280bis.  Below is a
proposal (with changes in blue) for a
revision to this section.

Dave

----------------------------------------------------------------------------

3  Overview of Approach

Following is a simplified view of the architectural model
assumed by

the PKIX specifications.

The components in this model are:

end entity: user of PKI certificates and/or end user system
that is

the subject of a certificate;

CA:         certification authority;

RA:         registration authority, i.e., an optional system
to which

a CA delegates certain management functions;

CRL issuer: a system which publishes certificate revocation lists;

repository: a system or collection of distributed systems that
stores

certificates and CRLs and serves as a means of

distributing these certificates and CRLs to end
entities.

CAs are responsible for indicating the
status of the certificates that

they issue.  Status information may be provided using the Online

Certificate Status Protocol (OCSP) [RFC 2560], certificate revocation

lists (CRLs), or some other mechanism.  In general, when status
information

is provided using CRLs, the CA is also the CRL issuer.  However, a CA

may delegate the responsibility for issuing CRLs to a different
entity.

Note that an Attribute Authority (AA) might also
choose to delegate

the publication of CRLs.

+---+

| C |                       +------------+

| e | <-------------------->| End entity |

| r |       Operational     +------------+

| t |       transactions          ^

| i |      and management         |  Management

| f |       transactions          |  transactions        PKI

| i |                             |                     users

| c |                             v

| a | =======================  +--+------------+
==============

| t |                          ^               ^

| e |                          |               |         PKI

|   |                          v               |
management

| & |                       +------+           |
entities

|   | <---------------------|  RA  |<----+     |

| C |  Publish certificate  +------+     |     |

| R |                                    |     |

| L |                                    |     |

|   |                                    v     v

| R |                                +------------+

| e | <------------------------------|     CA     |

| p |   Publish certificate          +------------+

| o |   Publish CRL                     ^      ^

| s |                                   |      |  Management

| i |                +------------+     |      |  transactions

| t | <--------------| CRL Issuer |<----+      |

| o |   Publish CRL  +------------+            v

| r |                                      +------+

| y |                                      |  CA  |

+---+                                      +------+

Figure 1 - PKI Entities

---

From: Stephen Kent <[email-masked]>
Date: Thu, 18 Nov 2004 13:40:27 -0500

David,

A few comments on your proposed 3280bis, section 3 text:

the term "publishes" in the definition of CRL issuer seems to 
emphasize promulgation vs. signing or CRLs.

I suggest using the phrase "revocation status" vs. status here.

Also, I'm not sure why we should include the phrase "or some other 
mechanism" in the description of how a CA provides revocation status 
info.  the more options we allow for this (and especially the vague 
sort of phrase cited above), the greater the likelihood that a client 
and CA have not chosen common means of acquiring/publishing this 
critical info. if this was an indirect way to alluding to SCVP, let's 
me more direct.

Steve

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 18 Nov 2004 15:16:32 -0500

> emphasize promulgation vs. signing or CRLs. 

RFC 3280 states:  "CRL issuer: an optional system to which a CA 
delegates the publication of certificate revocation lists;"

I was just trying to minimize the changes.  I could always change this 
to sign, generate, create, whatever.

> I suggest using the phrase "revocation status" vs. status here.

OK.

> critical info. if this was an indirect way to alluding to SCVP, let's 

This wasn't meant to allude to SCVP.  There are many mechanisms for 
distributing revocation status other than CRLs and OCSP.  I wouldn't 
want to encourage their use since that would lead to interoperability 
problems, but I didn't think PKIX profiles precluded the use of 
revocation status mechanisms that are not described in PKIX documents.

Section 5 of RFC 3280 states:  "Conforming CAs are not required to issue 
CRLs if other revocation or certificate status mechanisms are provided."

I can certainly remove the phrase "or some other mechanism".  I didn't 
want to leave the impression that revocation status providers MUST use 
either CRLs or OCSP, unless the working group really intends to impose 
such a restriction.

Dave

---

From: Stephen Kent <[email-masked]>
Date: Fri, 19 Nov 2004 13:17:32 -0500

David,

	<SNIP>
>>mechanism" in the description of how a CA provides revocation 
>>status info.  the more options we allow for this (and especially 
>>the vague sort of phrase cited above), the greater the likelihood 
>>that a client and CA have not chosen common means of 
>>acquiring/publishing this critical info. if this was an indirect 
>>way to alluding to SCVP, let's me more direct.
>
>want to encourage their use since that would lead to 
>interoperability problems, but I didn't think PKIX profiles 
>precluded the use of revocation status mechanisms that are not 
>described in PKIX documents.
>
>Section 5 of RFC 3280 states:  "Conforming CAs are not required to 
>issue CRLs if other revocation or certificate status mechanisms are 
>provided."
>
>I can certainly remove the phrase "or some other mechanism".  I 
>didn't want to leave the impression that revocation status providers 
>MUST use either CRLs or OCSP, unless the working group really 
>intends to impose such a restriction.

That's a fair question. At first we insisted on CRLs.  Then we added 
OCSP and my assumption was that we wanted to require either CRLs or 
OCSP. If we impose no requirements on support for ANY standard 
revocation service, then I do worry that we create serious 
interoperability problems between RPs and CAs.

Steve