Subject: PKIX meeting minutes, final

From: Stephen Kent <[email-masked]>
Date: Fri, 12 Aug 2005 11:46:05 -0400

PKIX WG Meeting 8/2/05

Edited by Steve Kent

Chairs: Stephen Kent <[email-masked]> & Tim Polk <[email-masked]>

The PKIX WG met once during the 63nd IETF. A total of approximately 
53 individuals participated in the meeting.

Document status - Tim Polk (NIST)

	Two new RFCs (PK Algorithms and Permanent Identifier) have 
been issued since the last meeting. Four additional documents have 
been approved by the IESG and are in the RFC editor's queue 
(Certificate path building, warranty extension, 2510bis and 2511bis). 
Three documents are being reviewed by the ADs (AC policies, CertStire 
HTTP, and 3770bis). CRL AIA is in IESG last call. WG last call for 
SIM will be initiated after this IETF meeting. More detailed 
discussions of 3280bis and SCVP will follow. (see slides)

PKIX WG Document Presentations

SRV RR otherName - Stefan Santesson (Microsoft)
	This individual submission is being adopted by PKIX. The 
proposal specifies a way to embed a service name in a certificate, 
employing the syntax used to identify a service in DNS SRV records. 
The intent is to securely bind the DNS-specified service to a named 
entity, using the otherName type of GeneralName to carry the 
specified SRV RR query string. Denis noted that this proposal is a 
somewhat odd use of the subject alt name, in that the string is not 
the name of the certificate subject, but the name of a service 
provided by this subject. Instead he proposed use of the subject 
directory attributes extension. Others objected to this specific way 
of binding service authorization info to a certificate, vs. other 
approaches, e.g., EKU, or other subject alt name forms. There was 
general agreement that the proposal needs to be carefully vetted by 
DNS experts. (see slides)

Simple Certificate Validation Protocol (SCVP) - Tim Polk (NIST)
	IPR issues have been resolved since the last IETF meeting. 
Russ Housely said that CoreStreet indicated that compliant SCVP 
implementations could be developed that would not infringe their 
patents. However, Russ also reminded attendees that ultimately each 
vendor needs to evaluate the formal, legal statements from 
CoreStreet. The base specification has not changed significantly 
since the -18 draft. The draft meets most of the requirements 
specified in RFC 3379, but return of (relayed) SCVP responses was not 
included. This will be fixed in the next draft. Also, the conformance 
requirements seem to impose undue burdens on all clients, contrary to 
the goal of supporting thin clients. Remaining open issues will be 
discussed on the list, e.g., syntax details. (see slides)

SCVP Open Issues - Denis Pinkas (Bull)
	Denis emphasizes the need for thin clients, e.g., on cell 
phones, to be supported. Denis suggested that several OPTIONAL fields 
should be omitted to facilitate thin client support. However, because 
these are optional, it appears that the document can be worded to 
ensure that they impose no burden on a client that does not wish to 
invoke them. Denis would like to see a facility to allow per-trust 
anchor validation parameters, obviously not for thin clients, since 
only a sophisticated client would be able to take advantage of this 
facility. Denis also would like to represent both the validation 
policy and validation algorithm into a single OID. It was agreed that 
the URI pointer to a policy will be deleted. Is also was agreed that 
the terms "validation policy" and "validation algorithm" need to be 
better defined in the document. (see slides)

3280bis - Tim Polk (NIST)
	A new draft has been submitted with relatively minor 
enhancements. Several open issues remain to be resolved. In 
particular, questions involving name ambiguity have been raised, 
particularly as they impact CRL validation. We may deal with this 
issue by adding text in the security considerations section that 
discusses this issue. The text has been changed to clarify what 
conforming CAs MUST do in issuing a certificate, vs. what conforming 
RPs MUST do re certificate path processing. The path validation 
algorithm notes that it accepts paths that are X.509 compliant, but 
not PKIX compliant, in support of interoperability. Peter Sylvester 
asked whether there would be support to help him write a defect 
report against x.509 concerning the change of the name of the 
non-repudiation bit, since this change breaks applications that are 
based on standard ASN.1 compiler outputs (and it changes the XER 
encoding on the wire). (see slides)

3280bis Open Issues - Denis Pinkas (Bull)
	Denis reviewed seven topics that he considers open issues. He 
suggests that text on TA key update should be explicitly covered 
here, not just a reference to RFC 2510. He also suggests that we find 
a better compromise with the latest X.509 technical corrigendum, with 
respect to key usage. Denis reviewed the name ambiguity debate that 
has taken place on the list. He suggested that the private key usage 
extension not be deprecated universally, but rather be allowed in 
certain contexts, e.g., time stamp crypto modules. He proposed to 
soften the prohibition against private key usage or to delete annex 
D.1. (and thus annex D) which is the only section that
addresses this topic. Denis asked for a simplified revocation status 
checking algorithm description, that addresses only the PKIX-mandated 
certificate extensions. He also suggests clarification of the text 
that says what CRLs are "available" in the local cache. Finally, 
Denis discussed several subtle issues associated with indirect CRLs. 
At the microphone a series of individuals responded to Denis's 
suggestions, most disagreed with one of more of his points. (see 
slides)

Related Specifications & Liaison Presentations

CMS Advanced Electronic Signatures (CAdES) - Denis Pinkas (on behalf 
of ETSI TC ESI)
	This document is based on RFC 3126 and is aligned with a 
re-issue of ETSI TS 101 733. CAdES is a new name, intended to 
distinguish it from the XML-based version spec. Denis said that the 
document now presents the basic electronic signature formats in the 
main body of the document while placing features to achieve the 
maintenance of long term signatures in informative annexes, thus the 
informative annexes may equally be interesting. (see slides)

XKMS - Stephen Farrell (on behalf of W3C)
	This presentation noted that the XKMS specification in W3C 
was completed and multiple interoperable implementations have been 
tested. Interested PKIX members are encouraged to visit the W3C web 
site and review the spec. (no slides)