Subject: 3280bis: certificate revocation status responsibility (1/3)

From: Denis Pinkas <[email-masked]>
Date: Sat, 13 Nov 2004 14:56:49 +0100

3280bis: certificate revocation status responsibility (1/3)

This is an addition proposal related to indirect CRLs.

X.509 states in section 7.3:

"7.3  Certificate validity

The authority that issues certificates (public-key or attribute) also
has the responsibility to indicate the validity of certificates it
issues.  Generally, certificates are subject to possible subsequent
revocation. This revocation, and notification of the revocation may be
done directly by the same authority that issued the certificate, or
indirectly by another authority duly authorized by the authority that
issued the certificate. "

This text from section 7.3 of X.509 should be imported into RFC 3280 and
this will close the issue about which entity MUST nominate the CRL
Issuer. The title of that section should be renamed "certificate
revocation status responsibility" and should be slightly re-arranged.
Hereafter is a proposal:

"X. Certificate revocation status responsibility

The authority that issues certificates (public-key or attribute) has
the responsibility to indicate the revocation status of certificates
it issues. Generally, certificates are subject to possible subsequent
revocation. This revocation, and notification of the revocation may be
done directly by the same authority that issued the certificate, or
indirectly by another authority duly authorized by the authority that
issued the certificate."

RFC 3280 does not provide a formal definition for an indirect CRL, but
it could be inferred from the content of section 5, whenever the CRL
issuer is not the CA that issued the certificates, the CRL is referred
to as an indirect CRL.

Proposed definition:

"indirect CRL: A revocation list that is not issued directly by a CA
but by authority duly authorized by a CA".

Other parts of RFC 3280 explain that an indirect CRL may be understood
as a revocation list that provides revocation information about
certificates either issued by:

    a) a single CA, or
    b) multiple CAs.

In case a), called "indirect CRL of type a)", an indirect CRL provides
revocation information for certificates issued by one CA, and for
which a delegation has been granted by that CA.

In case b), called "indirect CRL of type b)", an indirect CRL still
provides revocation information for certificates issued by one CA, but
also for certificates issued by others CAs.

It should then be explained how a relying party may verify that
delegation has indeed been granted by a CA to a CRL Issuer.

The following text is proposed to be happened after the previous
proposed text:

"Assuming that the relying party has found a candidate CRL, the DN
contained in the issuer field from the CRL SHALL match the subject DN
contained a CRL Issuer certificate (i.e. a certificate which has the
cRLSign bit set in the keyUsage extension) issued to the CRL Issuer by
the CA that has issued the certificate to be tested.

In order to prevent DN ambiguity, the CRL Issuer SHALL not accept to
manage revocation status information for a given CA DN, if it already
manages revocation status information for another CA that has the same
DN."

Denis

---

From: Ed Gerck <[email-masked]>
Date: Sat, 13 Nov 2004 18:39:09 -0800

> indirectly by another authority duly authorized by the authority that

This addition, considering how many questions I received when recently
stating the same in the ID draft-gerck-pkix-revocation-01.txt, seems to
be quite necessary.

Because the revocation status of a certificate refers to conditions that
a conforming issuer CA authoritatively defines for each certificate
(for example, revocation is delegated to X), this addition makes clear
that in PKIX a certificate is either revoked or not revoked. It does not
matter who you ask.

> but by authority duly authorized by a CA".

Again, this clarification seems necessary.

> manages revocation status information for another CA that has the same

However, because multiple mechanisms are available to an issuer CA to
define revocation, CAs with the same DN could use different mechanisms
without ambiguity (even if we just distinguish CAs by their DNs). These
mechanisms include a CDP extension with a URI DistributionPointName, an
AIA extension with an OCSP access descriptor, and an AIA extension with
an HTTP CRL access descriptor.

Could your proposal reflect these possiblitities as well?

Cheers,
Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Sat, 13 Nov 2004 18:39:09 -0800

Cheers,
Ed Gerck