Subject: Objections Raised by the IESG on the Roadmap document

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Thu, 08 Aug 2002 13:27:57 -0400

This is my fault, as I should have caught this before it got to the
IESG.

The document contains a lot of status information on the various
Internet Drafts and RFCs that make up the PKIX Document set.

Well, it is considered inappropriate for information that is as
dynamic as document status to be enshrined in an RFC.

I suggest that we remove the status text from the document and
resubmit. The IESG recommends that the status information be placed on
a webpage, which can be linked from the IESG Charter Page. Of course
we would need someone to volunteer to keep that information up to
date.

			-Jeff

---

From: "Sean P. Turner" <[email-masked]>
Date: Thu, 08 Aug 2002 13:40:02 -0400

Jeff,

Just to make sure - it's just the "STATUS: *" lines in section 4?

spt

---

From: "Enrique Velasco" <[email-masked]>
Date: Fri, 9 Aug 2002 11:16:08 -0400

Should an Intermediate CA Certificate include the CRL Distribution Point
Extension?

One might want to revoke an Intermediate CA Certificate if there's a key
compromise, therefore publishing a CRL, but that would be completely useless
if no one's checking it, so my first answer to my own question would be YES.

Then I wonder how can this be done, as the Root CA key should be off-line,
as recommended.

I've noticed that only a few Intermediate CA Certificates include a CRL
Distribution point, and those CRL are valid for several months. So I Imagine
that issuing such CRL must be a manual (i.e.. not automated) process, done
only when there is the urge to revoke the Intermediate CA Certificate.

Any thoughts?

again,

Should an Intermediate CA Certificate include the CRL Distribution Point
Extension?
and how can this be done?

	Enrique Velasco
	Acepta.com

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 12 Aug 2002 12:27:01 +0200

Enrique,

> Then I wonder how can this be done, as the Root CA key should be off-line,

RFC 3280 states: The CRL is signed using the CRL issuer's private key;

   The cRLDistributionPoints extension is a SEQUENCE of
   DistributionPoint.  A DistributionPoint consists of three fields,
   each of which is optional: distributionPoint, reasons, and cRLIssuer.
   While each of these fields is optional, a DistributionPoint MUST NOT
   consist of only the reasons field; either distributionPoint or
   cRLIssuer MUST be present.  If the certificate issuer is not the CRL
   issuer, then the cRLIssuer field MUST be present and contain the Name
   of the CRL issuer.  

This means that CRLs can be signed by a key different from the CA key.
To achieve that goal, the CA needs to issue a certificate to the CRL Issuer.
 
> only when there is the urge to revoke the Intermediate CA Certificate.

Some products do not support CRL issuers with a key different from the CA
key, but if you want to keep the CA key as "off-line" as possible, RFC 3280
provides you with a solution.

> and how can this be done?

It is highly advisable to include in every certificate either a CDP
extension or an AIA extension, so that in an "Open PKI" any relying party
may know where to fetch the revocation status information (CRLs or OCSP
responses).

Denis

---

From: "Jeffrey I. Schiller" <[email-masked]>
Date: Thu, 15 Aug 2002 11:09:41 -0400

I believe it goes beyond that. In general RFC level documents may not 
make references to any Internet Draft. So the whole discussion of which 
Internet Draft is at what status is out of line.

			-Jeff