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

CDB Status of Draft Publication history: –draft-dploy-requirements MAR –draft-bonatti-pki4ipsec-profile-reqts 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.

CDB 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 E. Change History

CDB 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.

CDB Changes to Draft (2) Added a new subsection 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 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 to to clarify that key escrow requirements and any key transport between the VPN admin and the peer are beyond scope.

CDB Changes to Draft (3) Added AIA extension as a MAY requirement in 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.

CDB “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?

CDB “Big” Issues (2) Section 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.

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

CDB 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.

CDB Questions?