Subject: RE: draft-ietf-pkix-certpathbuild-00.txt

From: "Matt Cooper" <[email-masked]>
Date: Thu, 14 Aug 2003 15:32:23 -0400

Hi Denis,

First, apologies for taking so long to get you a reply.

You're right, the topic of retrieval (where to find certificates,
discussions of various sources, how to obtain revocation information, and
what CAs should put in certs to facilitate all of this) is a very important
topic that is intimately related to path building. However, I think that
they are separable topics. Our document shies away from retrieval topics and
focuses on ideas for how to go about navigating the decision tree once you
have the certificates. (Perhaps we have put the cart before horse!?) On the
other hand, we didn't feel that we could address the topic of building
without some limited discussion on retrieval. (Hence the rather short
sections you referred to.)

I agree with you 110% that additional guidance for both PKI consumers and
CAs in this area would be very helpful. BUT, in the interest of keeping the
document from growing out of control, I submit that retrieval would be an
ideal topic for a new document. (In fact, this idea was brought up at the
meeting in Vienna.) Items A-C in your message would be ideal content for
such a document. What do you (and others) think of this idea?

> From: Denis Pinkas
> 1. The difference between a CA-certificate and a cross-certificate is 
> still very hazy since what means a "realm" is either left undefined or 
> is said to be "dependant upon local policy". It is thus impossible to 
> have standard rules with such an approach.

I assume you referring to the sorting method that suggests you traverse
certs from cACertificate prior to crossCertificatePair? This is based solely
on what we've seen in the field as common practice. So, although realm is a
fuzzy notion, more often than not (from what I've seen at least) it seems
that if both cACertificate and crossCertificatePair are populated, that
cACertificate is the "local realm" and usually confines searches to the
local network. But, like all the other sorting methods, it won't work all
the time for every scenario. I personally like this sorting method, but
there are other dissenters. I certainly wouldn't oppose removal if that
seems to be the consensus or the group feels it won't contribute to
optimizing the path building.

> From: Denis Pinkas
> Is it really important to make the difference if both:
> 
>   - the pointers to CA repositories are present, and
>   - these repositories entries are correctly filled-in ?

I think so. Retrieving the certs is only half the problem - these pointers
help you find certs, but they don't necessarily help you decide what to do
with them once you have them. If we can use some information to guess at
whether the CA is local to the PKI consumer vs. remote, we can use this to
try to consume paths from the local (and presumably faster) network first.
Were you looking for a statement that says use of these sources should
over-ride other available sources?

> From: Denis Pinkas
> Figure 3 does not make sense unless the trust points
> are indicated.

Is it necessary for the diagram to indicate which CA (if any of them) is the
trust point? On the other hand, to make it consistent with the other
examples, I agree there should be one designated. The other thing I don't
like about this diagram is that it needs to be 4 or 5 CAs instead of three -
3 CAs looks just like a ring topology. I  will change this in the next
version.

> From: Denis Pinkas
> 3. The case of validating a certificate in the past after a CA key 
> rollover (using the new root key) should be addressed.

Do you mean validating an old certificate at some past T where T precedes
the notBefore in the cert issued from the new CA key to the old CA key? I
don't think this should validate. Then on the other side of the notBefore,
no additional discussion should be necessary, or am I missing what you are
telling me? I think the current sorting methods will handle key-rollover for
a T post the notBefore time without a problem.

> From: Denis Pinkas
> 4. An interesting case to discuss would be the encoding of the issuer 
> name before and after December 31, 2003 since all certificates issued 
> after December 31, 2003 MUST use the UTF8String encoding of 
> DirectoryString (except as noted). The case of "name rollover" 
> certificates to support an orderly migration to UTF8String encoding 
> should be explained.

Excellent idea and thanks for pointing it out. Although, I think we should
not use  MUST here since this is informational only.

> From: Denis Pinkas
> 5. The document is far too long.

Denis, you told me this immediately following a bunch of suggestions on how
to make it longer! To tell you the truth, I agree, it is rather lengthy. On
the other hand, I would be reticent to remove any of the sorting discussion.
And, I think absent a retrieval doc, there needs to be at least some limited
discussion of retrieval. I'm not certain how to shorten it without removing
something that others may well find to be of value. Perhaps the sorting
methods could be moved to an appendix?

-Matt

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Tuesday, July 15, 2003 5:23 AM
> To: Peter Hesse; 'Matt Cooper'; 'Yuriy Dzambasow'; 'Susan 
> Joseph'; Richard E. Nicholas (Nicholas, Richard)
> Cc: Steve Hanna; 'PKIX List'
> Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
> 
> 
> Comments on certpathbuild-00.txt
> 
> The title of the document was promising, but the content is 
> not exactly what 
> would have been expected.
> 
> The topic should be how to allow interoperability to find out 
> the elements 
> (i.e. both the certificates and the associated revocation status 
> information) needed for to build a certification path either walking 
> downwards or upwards the certification tree.
> 
> The document should explain how inserting some of the 
> extensions defined in 
> RFC 3280 will allow to build the certification path, 
> irrespective of local 
> conditions (e.g. the user does not have a XX-xxxxxxDirectory where 
> everything needed is stored. :-)  )
> 
> Some interesting elements are provided starting page 54, in 
> sections 6.2 and 
> 6.3. but this is far from sufficient.
> 
> There are two solutions to this problem, either walking 
> downwards or upwards 
> the certification tree.
> 
> 
> A. Walking downwards the certification tree.
> 
> Each trust point SHOULD include in the self-signed 
> certificate the way to 
> find out where the CA has placed the CA certificates that it 
> issues. This 
> SHALL be done using the Subject Information Access extension 
> defined in 
> section 4.2.2.2 from RFC 3280.
> 
> The id-ad-caRepository OID SHALL be used to indicate in which 
> repository the 
> CA publishes its certificates and CRLs (if issued).
> 
> Each CA certificate SHOULD also include the Subject 
> Information Access 
> extension defined in section 4.2.2.2. from RFC 3280.
> 
> This is the preferred method, since anyway trust points MUST be known.
> 
> 
> B. Walking upwards the certification tree.
> 
> Each end-entity certificate and each CA certificate SHOULD 
> include the way 
> to find out where the CA is placing the other certificates. 
> This SHALL be 
> done using the Authority Information Access extension defined 
> in section 
> 4.2.2.1 from RFC 3280 :
> 
> The id-ad-caIssuers OID SHALL be used to list where the CA 
> that has issued 
> the certificate lists CA certificates issued to the CA.
> 
> This extension SHOULD be included in end-entity certificates and CA 
> certificates.
> 
> This can only be a complement to the previous method, since 
> anyway trust 
> points MUST be known. When the downwards approach does not 
> succeed (explain 
> in which cases, it may not succeed), then a combination of 
> both methods may 
> succeed.
> 
> Note: The location of CRLs is not specified in this extension. That 
> information is provided by the cRLDistributionPoints extension.
> 
> 
> C. Revocation checking
> 
> For revocation checking each end-entity and CA certificate 
> SHALL either 
> include :
> 
>     a) a cRLDistributionPoints extension, or
>     b) Subject Information access extension that includes the 
> id-ad-ocsp OID
>        to indicate the location of servers using the Online 
> Certificate
>        Status Protocol (OCSP) [RFC 2560].
> 
> 
> Other comments.
> 
> 1. The difference between a CA-certificate and a 
> cross-certificate is still 
> very hazy since what means a "realm" is either left undefined 
> or is said to 
> be "dependant upon local policy". It is thus impossible to 
> have standard 
> rules with such an approach.
> 
> Introducing naming constraints between subject and issuer 
> names might be 
> more appropriate; however, the real question is the following:
> 
> Is it really important to make the difference if both:
> 
>   - the pointers to CA repositories are present, and
>   - these repositories entries are correctly filled-in ?
> 
> 
> 2. There is, as usual, some confusion between cross 
> certification (which is, 
> by definition, unilateral) and mutual cross certification 
> (see section 
> 13.2). Figure 3 does not make sense unless the trust points 
> are indicated.
> 
> 
> 3. The case of validating a certificate in the past after a 
> CA key rollover 
> (using the new root key) should be addressed.
> 
> 
> 4. An interesting case to discuss would be the encoding of 
> the issuer name 
> before and after December 31, 2003 since all certificates 
> issued after 
> December 31, 2003 MUST use the UTF8String encoding of DirectoryString 
> (except as noted). The case of "name rollover" certificates 
> to support an 
> orderly migration to UTF8String encoding should be explained .
> 
> 
> 5. The document is far too long.
> 
> 
> Denis
>

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 27 Aug 2003 15:33:35 +0200

Matt,

> they are separable topics. 

I do not think so.

The story starts with a target certificate and a candidate trust point.
The question is then using information that may be found both in the 
certificate and in the trust point, how can we find CA certificates and 
certificate revocation information related to a candidate path bewteen the 
target certificate and the candidate trust point.

The "navigation" is subject to which CA certificates can be obtained.

 > Our document shies away from retrieval topics and
> have the certificates. (Perhaps we have put the cart before horse!?) 

Yes, indeed. :-)

 > On the

> ideal topic for a new document. 

Certificate retrieval cannot be fully separated from path construction.

 > (In fact, this idea was brought up at the

I could suggest deletions in your document, but it appears that you think 
that nothing should be suppressed. :-)

In fact, a restructuring of the document would be necessary to mix for each 
step the story of path building and of CA certificate fetching.

Denis