1. Certificate Path Building draft-ietf-pkix-certpathbuild-01.txt Peter Hesse Matt Cooper Yuriy Dzambasow Susan Joseph Richard Nicholas

2. Why This Document? Certificate path building is relatively easy to do, but difficult to do well Implementations are frequently over simplified or vendor specific in nature –Leads to interoperability problems where one vendor’s solution frequently may not work with another vendor’s PKI This paper seeks to provide generic path building guidance that should work with any vendor’s PKI –The intent is to promote both efficiency and interoperability

3. Why This Document? There is currently a lack of guidance relating to the certificate path building This leaves the software developers, who may lack extensive experience in PKI, on their own to determine how to go about building paths –Naturally, this can lead to less than comprehensive path building solutions The intent of this document is to provide guidance to software developers in the hope that it will help improve certificate path building modules in general –Nothing in the document is intended to be prescriptive

4. What’s Inside In addition to providing an overview of path building and PKI structures, this document seeks to address four areas of path building considerations: –Help in making the decision of building from the trusted root (reverse) or the end entity (forward) –Methods that may make certificate path building more efficient (Finding the “best path first”) –Common flaws in path building modules –Simplifying the decision tree

5. Changes from -00 to -01 (General) made certain terminology more consistent ("certification path" throughout the document instead of "certificate path", "cert path", etc.) softened the tone; made it clear that the document provides informational recommendations and does not prescribe a particular method for certification path building removed statements on the document providing guidance based on "best practices" but instead explicitly defined the motivation and purpose behind the document, as well as the criteria that led to the guidance provided. removed some non-ascii characters that had snuck in

6. Changes from -00 to -01 (Specific) Thoroughly updated section 1.1 (Motivation) and 1.2 (Purpose) updated terminology section to include a few additional terms updated mesh PKI figure to better differentiate it from other structures included a section (2.2) that clearly identifies the authors‘ criteria for a path building implementation broke up section 2.4 (How to Build a Certification Path) with some subsections added section 3.3 (Representing the Decision Tree Programmatically) updated section 3.5 to include additional information about the sorting methods that follow. Sorting methods are no longer called "rules". added section 5.4 (Distinguished Name Encoding) added section 6.3 (Subject Information Access)

7. Current comments The document has a section on certificate and CRL retrieval (Section 6, Retrieval Methods) which discusses some mechanisms that may be used by implementations when attempting to retrieve certificates It has been requested that we add information on what extensions can be used to pass retrieval location information –We feel this is accomplished in sections 6.2, 6.3, 6.4 (Perhaps with a few new words) –Since this document is informational, we do not intend to add SHOULDs and MUSTs

8. Current comments The current draft uses the words “building”, “discovery”, and “obtaining” to mean basically the same thing. –Our next draft will address this issue. –We will clearly define the terms that are used, and use them consistently through the draft “Subscriber”, “User”, and “End Entity” –Since path building is not always done for a user or subscriber certificate (i.e. Indirect CRL Issuer) we will attempt to normalize this toward “End Entity”

9. Current comments The term “Trust” is used without a clear definition –I don’t think we want to wrestle that monster; however, I think we will identify that “Trust” in this document means “public key can be trusted subject to the validation procedure in RFC 3280” Section 1.4.4 (Bridge Structures) refers to Bridges as non-hierarchical –We will repeat the comment from 2.3 that no matter the structure, it always simplifies to a (series of) hierarchical structure(s).

10. Current comments Section 1.5 provides two reasons why Bridge CA support should be included –The second reason is the only important one; the first reason (“Because they exist”) will be minimized Why is building from the EE called “Forward” and building from the Root called “Reverse”? –The reason (crossCertificate naming) will be identified in the document

11. Current comments The document identifies a number of ways that paths may be built and considered “less trustworthy” than other alternatives Section 2.4.2 has a confusing example There are some missing references, and the differences between normative and informative references need to be made. Section 8 – Security considerations mentions protection of root key and root cert—needs a slight rewording since root certs are not required –We’ll make the required changes for all these

12. Document Status As of this date, we have received and integrated comments from a number of people, resulting in the changes from (-00) to (-01). You can also see the open comments we plan to address in the document The next draft of this document will be released in November and is aimed at WG Last Call –we are still hoping for more comments before we release the next draft!

13. Questions? Contact Info –Peter Hesse pmhesse@geminisecurity.com +1.703.934.2031 –Matt Cooper mcooper@orionsec.com +1.703.917.0060 –Yuriy Dzambasow yuriy@anassoc.com +1.410.859.5449 x107 –Susan Joseph susan.joseph@digitalnet.com +1.301.939.2705 –Richard Nicholas richard.nicholas@digitalnet.com +1.301.939.2722

14. Thank You