PKIX WG Meeting 12/8/98 & 12/9/98 

Edited by Steve Kent (WG co-chair) 

The PKIX WG met twice during the 43rd 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 Cert/CRL Profile (draft-ietf-pkix-ipki-part1-11.txt) 
Approved for Proposed Standard 

KEA Algorithms for Profile (draft-ietf-pkix-ipki-kea-02.txt) 
In WG Chairs' hands - ready for publication as Informational RFC 

ECDSA Algorithms for Profile (draft-ietf-pkix-ipki-ecdsa-01.txt) 
In Editors' hands. 

HTTP/FTP Operations (draft-ietf-pkix-opp-ftp-http-04.txt) 
In WG Chairs'/Area Director's hands - ready for IESG 

LDAP V2 Operational Protocols (draft-ietf-pkix-ipki2opp-08.txt) 
Awaiting schema document and will be reviewed by IESG together. 

LDAP V2 Schema (draft-ietf-pkix-ldapv2-schema-02.txt) 
In Area Director's hands, will be forwarded to IESG very soon. 

OCSP (draft-ietf-pkix-ocsp-07.txt) 
In Area Director's hands 

CMP (draft-ietf-pkix-ipki3cmp-08.txt) and CRMF (draft-ietf-pkix-crmf-01.txt) 
About to be approved by IESG 

CMC (draft-ietf-pkix-cmc-02.txt) 
Under development. 

CMMF (draft-ietf-pkix-cmmf-02.txt) 
In WG last call, but probably will be deleted, due to subsumption by CMC. 

Certificate Policy/Practices Guideline (draft-ietf-pkix-ipki-part4-03.txt) 
In Area Director's hands - ready for publication as Informational RFC 

Reports on Established Projects: 

OCSP (A. Malpani-ValiCert) 
Announcement of an OCSP server available for interoperability testing. 

CMC (J. Weinstein-Netscape) 
Notable changes from last time, and new text makes explicit what requirements 
are being met. Given the extent of these changes, this I-D is NOT yet in WG 
last call. CMC is primarily based on PKCS 10, and CMRF, and CMS (PKCS 7 

successor developed in S/MIME). Protocol is stateless, to make life easier for 
the server, optional for client. Features supported include client or CA 
generation of key pairs, optional key recovery, POP, realtime and staged 
delivery responses, and (local) RAs. Mandatory algorithms include DSA and D-H, 
with RSA as an option. Steve Kent, WG co-chair, asked that the document be 
revised to make explicit the security requirements imposed on CMC transactions 
and whether these requirements are met by CMC in all cases, or whether CMC 
optionally satisfies these requirements. In the latter case, there are 

security dependencies relative to the underlying protocol employed for 

transport. Such dependencies must be explicitly stated in the document. Jeff 
agreed to make the edits necessary to satisfy these concerns. 

Carlisle Adams raised some concerns about the POP mechanisms contained in the 
protocol and raised issues about the need for more details, and some edits 
(e.g., OID values), to ensure interoperability. Carlislie was asked to send 
these issues to the list so that the CMC authors can address them prior to WG 
last call. 

Diffie-Hellman POP Mechanisms (J. Schaad-Microsoft) 
Jim provided an update on an informational document that will specify a means 
of proof of possession with non-fixed groups, consistent with S/MIME contexts. There was general
agreement that the result of this work will be appropriate as a standards track (vs. informational) RFC. 


PKIX Roadmap (A. Arsenault-NSA) 
Al has received a few comments but is looking for more, and will continue to 
refine the document as the last of the mainline 

X.509 PDAM Update (T. Polk- NIST) 
Tim presented several slides provided by Sharon Boyen (Entrust), describing 
X.509 proposed changes from the September ITU-T meeting. The PDAM describes 
new extensions related to attribute certificate revocation, etc. Comments are 
requested from PKIX WG members. For more details, see the message to the WG 
from Hoyt Kesterson (Hoyt.Kesterson@bull.com), dated 11/23/98. 


Reports on New(er) Topics: 

Qualified Certificates (draft-ietf-santesson-qc-01.txt) (S. Santesson) 
This I-D addresses profiling X.509 certificates for use in a particular 

application context, i.e., for generation of digital signatures that will be 
recognized as legal throughout the EU. These certificates are to be issued to 
individuals who will generate digital signatures that support non-repudiation. 
There is an assumption that these certificates will be used not only with 
custom applications, but also with standard IETF applications such as S/MIME, 
hence the relevance to this WG. Only four certificate fields are addressed by 
this: Issuer, Subject, Policy, and Key usage. Thus a primary focus of this 
document is on naming, both requiring support for specific DN attributes and 
specifying semantics for the names. The slides provide additional details. 

ETSI Report on Electronic Signature Standardization (D. Pinkas) 
Denis provided a brief report on "electronic" signature standardization. This 
is quite analogous to the previous presentation, with the further focus on 
signatures for high value transactions. Again, non-repudiation is essential, 
but here roles, not just individual identities, are relevant, as is the 

context in which the signature is applied, e.g., as indicated by policy. The 
ETSI group has identified a list of issues to be resolved in order to provide 
the necessary framework for such high value signature applications. See the 
slides for additional details. The report is available at: 
http://www.etsi.org/SEC/ESRep042.pdf 


Timestamp (draft-ietf-pkix-time-stamp-00.txt) 
Data Certification Server (draft-ietf-pkix-dcs-00.txt) C. Adams- Entrust 
Carlisle reviewed differences between the current drafts and the drafts 

reviewed at the previous IETF meeting. In particular, the new version of the 
timed stamp I-D offers finer granularity for time stamps and support for time 
stamping of just a nonce. It was suggested that we combine the services of 
time stamping and document "notarization" into a single protocol, where the 
object submitted could be a hash or the object itself. However, there was not 
agreement that such combination was beneficial in all cases, and a single 
server may offer both timestamping and data certification services with only 
slightly greater complexity. The CMP-derived status indications need to be 
"masked" to clarify the fact that some CMP error conditions are not relevant 
to this application. 

The timestamp I-D appears to be ready to move to WG last call with the next 
version, however the data certification I-D needs more work. Also, the WG 
chairs need to co-ordinate with the Security AD to modify the charter to 
encompass both of these I-Ds.