PKIX WG Meeting Minutes 8/26-27/98 The PKIX WG met twice during the 42nd IETF and a approximately 190 individuals participated in these meetings. The meeting began with a review of the status of all of the WG document, presented by Warwick Ford, WG co-chair. The following text summarizes the status of the documents: PKIX Certificate/CRL Profile (draft-ietf-pkix-ipki-part1-09.txt) IESG Last Call KEA Algorithm Profile (draft-ietf-pkix-ipki-kea-02.txt) Close to completion by Editors HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) Ready for WG last call LDAP V2 Profile (March 98 draft) At IESG, pending WG delivery of V2 Schema LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-01.txt) In WG last call OCSP (draft-ietf-pkix-ocsp-05.txt) In WG last call CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF (draft-ietf-pkix-crmf-01.txt) In hands of IESG; pending IESG last call CMMF (draft-ietf-pkix-cmmf-02.txt) and CMC (draft-ietf-pkix-cmc-01.txt) In WG last call Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt) In SA Director's hands, pending publication as Informational RFC REVIEWS OF ESTABLISHED PROJECTS: PKIX Certificate and CRL Profile (Tim Polk) Ready for IESG ballot, after receipt of minor editorial comments during IETF last call. Straw polls used to resolve last few contentious issues, specifically mandating use of DNs for all Issuers, and mandating use of strict subtrees for the NameConstraints extension. Jeff Schiller noted that the IETF web site has pointers to the Entrust license required for inclusion of CRL distribution point within this document. The license is easy to execute; there is a reciprocity clause that requires licensing to Entrust any intellectual property associated with CRL distribution, as a side effect of - KEA and ECDS Algorithms (Tim Polk) Work on these algorithm ids continues, subject to resolution of some intellectual property issues. - LDAP V2 Schema and Profile (Tim Moses, Dave ???, Santosh Chokani) Most of the schema are not controversial; outstanding issues is whether all CAcertificates should appear in the cross certificate directory attribute, or whether certificates that are internal to a domain should appear in the CA certificate attribute. There is consensus that any self-signed CA certificates belong in the latter attribute. The disagreement here revolves around alternative certificate validation algorithms; both approaches have been implemented and both work, each favoring a different PKI model. The CA certificate attribute has been a feature of X.509 for a long while, so the proposal to move all (non- self-signed) CA certificates to the cross CA certificate attribute represents a non-backward compatible change for systems not making use of cross certificates. Still, this is the direction currently being pursued by the X.509 committee in resolving this ambiguity in the original standard. Performance analysis of 6 different approaches, under varying assumptions of PKI models, shows that.