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

From: "Matt Cooper" <[email-masked]>
Date: Thu, 4 Sep 2003 13:22:13 -0400

Hi Denis,

We have decided to keep basic information on retrieval in the draft. We look
forward to any additional commentary you may have when we submit the next
version.

-Matt

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Wednesday, August 27, 2003 9:34 AM
> To: Matt Cooper
> Cc: 'PKIX List'
> Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
> 
> 
> Matt,
> 
> > 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.
> 
> 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
> > 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!?)
> 
> Yes, indeed. :-)
> 
>  > 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.
> 
> Certificate retrieval cannot be fully separated from path 
> construction.
> 
>  > (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?
> 
> 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
> 
> >>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
> >>
> > 
> > 
> > 
> 
>