Subject: draft minutes for comment

From: Stephen Kent <[email-masked]>
Date: Wed, 3 Aug 2005 06:07:36 -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)
	An individual submission, now being adopted by PKIX. The 
proposal specifies a way to embed a pointer to a DNS SRV record in a 
certificate, to securely bind the DNS record to a named entity, using 
the otherName type of GeneralName to carry the specific 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. 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, 
but the core 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)

3280bis 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, although this 
seems to yield a minor space/complexity savings. 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.

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.

SCVP 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 
align out text 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. 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, although there appeared to 
be agreement to soften the prohibition against private key usage.

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.

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

---

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 9 Aug 2005 14:22:14 +0100

Steve,

I think the SRV RR text is not entirely correct. The proposal is not to
include a pointer to a SRV record. The proposal is to create a name form
that holds a service name and the domain of that service in a way that
matches the content of a dns SRV resource record (not points to it).

This might be a gradual difference but it is important one since the
name in the cert is not intended to be used to construct a dns query,
only to validate a servers authorization to provide a service.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

> -----Original Message-----
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Stephen Kent
> Sent: den 8 augusti 2005 22:16
> To: Denis Pinkas
> Cc: [email-masked]
> Subject: Re: draft minutes for comment
> 
> 
> Denis,
> 
> >...
> >>subject.
> >Add:
> >"Denis proposed to use the subject directory attributes extension"
> >which is well suited to carry this kind of extension..
> 
> I'll add the first line.
> 
> >...
> >
> >Russ said a few words about the patent issue. I would not dare to say
it,
> >but it would be useful for the WG to know what was said in the room.
> 
> I added ytext re Russ's comments on the IPR issue.
> 
> >...
> >SCVP - Open Issues - Denis Pinkas (Bull)
> >
> >  >policy and validation algorithm into a single OID,
> >
> >Please delete: "although this seems to yield a minor space/complexity
> saving",
> >since the topic is much more important than space saving.
> 
> I deleted the text representing my value judgement on space/complexity
> savings.
> 
> >...
> >>particularly as they impact CRL validation.
> >
> >
> >Please delete:
> >>  We may deal with this issue by adding text in the security
> considerations
> >>  section that discusses this issue.
> >
> >Replace with: "This issue will need to be discused in the security
> >considerations
> >section and it has been proposed to add an informative annex for
> explaining
> >in more depth the issue and the solutions.
> 
> I will not make this requested change as I do not believe that it
> accurately reflects the resolution of the discussion.
> 
> >...
> >
> >3280bis - Open Issues - Denis Pinkas (Bull)
> >
> >Replace with :
> >"find a better compromise with the latest X.509 technical
corrigendum, "]
> done
> >>certain contexts, e.g., time stamp crypto modules.
> >
> >It has been 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
> >adresses this topic.
> done.
> >>  Denis asked for a
> >>disagreed with one of more of his points.
> >
> >Delete the remaining of the sentence which is:
> >
> >>, although there appeared to
> done.
> >Add: XAdES.
> >"Denis said that the document is now presenting the basic electronic
> >signature formats
> >in the main body of the document while placing the features to
> >achieve the maintenance
> >of long term signatures in informative annexes. So the informative
> >annexes may equally be
> >interresting".
> >
> I reworded this slightly and added it to the XAdES section.
> 
> Steve