1. CDB-040224-1 Chris Bonatti (IECA, Inc.) Tel: (+1) 301-548-9569 Proposed PKI4IPSEC Certificate Management Requirements Document IETF #59 – PKI4IPSEC Working Group 1 March 2004 – Seoul, Republic of Korea

2. CDB-040224-2 Status of Draft Publication history: –draft-dploy-requirements-002002-MAR –draft-bonatti-pki4ipsec-profile-reqts-00 2004-JAN-30 Requirements are based upon the existing Project DPLOY work, but have been extensively tailored to the PKI4IPSEC charter and assumed scenario. Currently published as a personal draft pending acceptance into the WG.

3. CDB-040224-3 Document Structure 1.Introduction 2.Architecture –VPN System (VPN Peers & VPN Admin) –PKI System (CA, RA, Repository) –VPN-PKI interaction (steps in certificate life cycle) 3.Requirements –Subsections address different requirement areas 4.Security Considerations Annexes A. References B. Acknowledgements C. Editor's Address D. Summary of Requirements Plan to include a summary table similar to those in RFCs 1122, 1123, and 2975. E. Change History

4. CDB-040224-4 Changes to Draft Rewrote and trimmed to fit proposed scope of deliverable (2) from IETF PKI4IPSEC charter, and remove references to Project Dploy objectives. Added definitions of Community Realm, CRL Distribution Points (CDP), and Authority Info Access (AIA) Restructured the "Architecture" section to bring the presentation of Figure 1 to the front to go along with the overview of the section, and to add a new step diagram showing the certificate life cycle to the "VPN-PKI Interaction" subsection.

5. CDB-040224-5 Changes to Draft (2) Added a new subsection 2.1.2 to describe the VPN peer. Subsection 3.2 was deleted to maintain the focus on generic requirements agreed in Minneapolis. Selection of specific protocols will be done in the deliverable (3) profile. Deleted the requirement from 3.2.3.1 to include the maximum CRL size in the certificate template. This may need to be specified in the profile, but not be in the certificate itself. Revised 3.3.3 to to clarify that key escrow requirements and any key transport between the VPN admin and the peer are beyond scope.

6. CDB-040224-6 Changes to Draft (3) Added AIA extension as a MAY requirement in 3.5.2. Removed the requirement for HTTP support in favor of a requirement for a single mandatory protocol to be specified in the profile. Removed subsection on "Intra-IKE Considerations" as these should be dealt with in the existing deliverable (1) PKI profiles. Considerable editorial revision was also done. See Annex E for a complete list of changes.

7. CDB-040224-7 “Big” Issues Expansion of scope to include case where VPN admin does not exist. –Expands from “80% solution” to 90%, by picking up the lower tail. –Requirements and solution need little change as scenario is the same as a community of one with the Peer and Admin collocated. –Pre-authorization is obviously not necessary. Reconsider the adequacy of Figure 2 to elaborate the complexity of the certificate life cycle. Should it, perhaps, be split into multiple figures?

8. CDB-040224-8 “Big” Issues (2) Section 3.3.4 needs to be generated pending WG approval of additional use case for PKI generation of keys. Need to determine the relationship between IKE certificates, and certificates for ongoing cert management use. Closure on MUST ID fields in IKE certificates: –Certificates MUST contain at least one of Subject or the SubjectAltName iPAddress, dNSName, or rfc822Name. –Some question of whether or how Key_ID will be supported. Perhaps SubjectAltName otherName can support.

9. CDB-040224-9 “Big” Issues (3) Section 4 (Security Considerations) needs to be generated. Annex D needs to be generated.

10. CDB-040224-10 Way Forward Propose that this draft be adopted by the WG as a first cut at the Informational RFC described in charter deliverable (2). Continue to address issues and massage requirements.

11. CDB-040224-11 Questions?