Subject: Re: draft minutes for comment

From: "Denis Pinkas" <[email-masked]>
Date: Mon, 8 Aug 2005 17:39:40 +0100

Steve,

A few coments.

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

Add:

"Denis proposed to use the subject directory attributes extension" 
which is well suited to carry this kind of 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, 
>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)

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.

>3280bis Open Issues - Denis Pinkas (Bull)

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, 

Please delete: "although this seems to yield a minor space/complexity saving", 
since the topic is much more important than space saving. 

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

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.

> 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)

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
>align out text with the latest X.509 technical corrigendum, with 

Replace with : 
"find a better compromise with the latest X.509 technical corrigendum, "

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

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.

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

Delete the remaining of the sentence which is:
 
>, 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.

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

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

End of revised comments,

Denis

---

From: Stephen Kent <[email-masked]>
Date: Mon, 8 Aug 2005 16:15:46 -0400

Denis,

>...

I'll add the first line.

>...

I added ytext re Russ's comments on the IPR issue.

>...

I deleted the text representing my value judgement on space/complexity savings.

>...

I will not make this requested change as I do not believe that it 
accurately reflects the resolution of the discussion.

>...
>"find a better compromise with the latest X.509 technical corrigendum, "]

done

>or to delete annex D.1. (and thus annex D) which is the only section that

done.

>  >be agreement to soften the prohibition against private key usage.

done.

>of long term signatures in informative annexes. So the informative 
I reworded this slightly and added it to the XAdES section.

Steve