Subject: draft minutes

From: Stephen Kent <[email-masked]>
Date: Mon, 7 Nov 2005 16:03:57 -0500

Please send me a message with any requested corrections before 11/28:

Steve
-----

PKIX WG Meeting 11/7/05

Edited by Steve Kent

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

The PKIX WG met once during the 64th IETF. A total of approximately 
45 individuals participated in the meeting.

Document status - Tim Polk (NIST)
Three RFCs just issued: 4158, 4210, and 4211.
Three documents in the RFC editor's queue: CertStore HTTP, 3770bis, 
and CRL AIA.
Two documents with the ADs: AC Policies & PKIX Repository Locator.
Other documents:
-	SIM is undergoing revisions to address WG co-chair comments 
before being forwarded to the IESG.
-	The authors are being asked to create a matrix
-	A new version of 3280bis will be submitted after this meeting.
-	The WG chairs have requested a new version of the GOST 
algorithms to be posted, before initiating a last call
(Slides)

PKIX WG Document Presentations

RFC 2797bis, CMC transport, and CMC Compliance - Jim Schaad (Soaring Hawk)
Last call will be initiated for all three after this meeting. Updates 
include features to support SIM certificate requests. (Slides)

SCVP rev 21- David Cooper (NIST)
	Text was added to clarify conformance requirements. WantBack 
items were made optional. New, optional items were added to allow an 
SCVP server to relay responses from other SCVP servers, and to label 
responses with an identity specified by a requestor, if the server 
has multiple identities. The reference to validation policies was 
tightened, so that only OIDs, not URIs, are accepted. Policy 
parameters, in addition to validation algorithm parameters, are now 
supported, but the optional validation policy attributes were 
removed, since no examples have been provided and the need for this 
facility was not well established.

The one remaining problem here is how to make this protocol agile 
with regard to the hash algorithm employed for certificate 
references. Today SHA-1 is hardwired. Updating the spec to specify 
another hash function does not satisfy the new algorithm agility 
requirement. Steve Kent suggested that the hash function can be an 
aspect of the server's validation policy, to satisfy the agility 
requirement. Russ Housley suggested that the OID of the hash employed 
be explicitly returned, in case the server's policy changes over time 
(but the policy OID does not). A straw poll was conducted to get a 
sense of the room for the two alternatives described in the last 
slide in this presentation. The first alternative received 12 votes, 
vs. 0 for the second. (Slides)

SHA-1 Collisions & OCSP - Russ Housley (Vigil Security)
	 Based on the recent NIST hash workshop, Russ suggests that 
we begin making plans to move away from  SHA-1, with a 2010 target 
for transition. NIST will begin work on a successor to SHA-256, but a 
new algorithm may be 5 years away. The only good alternative now is 
SHA-256.

	From an algorithm agility perspective, OCSP request/response 
exchange needs to provide a way for the requestor to know which 
algorithms the responder (server) supports. This could be supported 
by adding a new protocol to negotiate the hash algorithm prior to 
entering into the OCSP exchange. Alternatively, the responder's 
certificate could have an extension that specified supported hash 
algorithms. This also might be addressed via configuration at the 
requestor, although this is problematic given the intent of changing 
the algorithm twice over the next 10 years. Russ suggests a request 
extension that allows the requestor to specify which hash functions 
(and signature algorithms) it supports. There is still a need to 
select one of the three approaches cited above, to allow a requestor 
to determine which algorithms are supported by the responder.

	Russ suggests that the WG find volunteers to update OCSP, and 
to examine other PKIX protocols to determine whether they exhibit 
similar problems and, if so, how to fix them. Stephen Farrell asks 
whether there may be a way to solve this problem more generically, 
rather than engineering a solution for each protocol in PKIX, and in 
other WGs.  (Slides)

SHA-2 Support in PKIX - Tim Polk (NIST)
        We currently specify how to use SHA-2 (SHA-256 & SHA-512) for 
RSA (RFC 4055), but not for DSA or EC-DSA. Tim suggests that two new 
drafts be generated, one for DSA and one for ECDSA, because the two 
algorithms are at different stages of NIST publication. NIST has 
volunteered to write these two drafts, but additional co-editors are 
welcome. (Slides)

Service Names as Subject Alt Names - Stefan Santesson (Microsoft)
       The draft has been revised since its initial version. It no 
longer is bound as tightly to the DNS SRV record example. The 
assumption here is that the user (host) knows the service name and 
domain name and determines whether the server to which it connects is 
appropriate, based on the server's certificate. Steve Kent suggests 
that we need to revisit the security implications of use of this 
facility, given the revised definition of the use model. Stefan 
suggests that use of name constraints for this extension may be 
appropriate. Since the string comparison is against the locally 
configured service name, not the DNS SRV string, UTF8 seems to be the 
right encoding choice. (Slides)

Related Specifications & Liaison Presentations

Carl Wallace (Orion Security) - LTANS WG status
	LTANS is meeting the same day (in the same room) at this 
IETF. Carl requests review by PKIX WG members of the evidence record 
I-D and an archive protocol I-D from LTANS. Note potential 
relationships between SCVP and LTNANS work.  (no slides)

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 08 Nov 2005 20:38:44 +0100

Stephen Kent wrote:

> responses with an identity specified by a requestor, if the server has 
> multiple identities. The reference to validation policies was 
> supported, but the optional validation policy attributes were removed, 
> since no examples have been provided and the need for this facility 
> was not well established.

The authors have spend three months to get out an editors after the 
Paris meeting and
after Denis and me spend an hour to explain Tim Polk our issues. During 
the following
months that was no interaction, and  just a week before the submission 
deadline, there
was a editors draft shown to us to comment it within three days. This 
draft showed that
the notes taken by Tim Polk do not reflect the issues, and, not 
surprisong, they were either
ignored or only partially interpreted.

The mentioned 'server has multiple identities' has never been stated as 
such, and the requested
implementation (something which I have been asking for since years) is 
continuously misunderstood,
either refused, then partially implement, and then withdrawn.

Point 1:

What I have been requesting is that the CVrequest, and the CVResponse 
carry two sequences
of identifiers for the requestors and the responders.

For the CVRequest, the requestorName sequence indicates who is acting as 
client or for whom
the client is acting. A server may use the list to determine whether one 
of the authentication
methods matches with one of the entities.

For the CVRequest, the responderName sequence indicates who the client 
believs should participate
in the response. (this seems to be close to the current text). But the 
indication should be
a list, in order to allow for proxies chaining or other. it is up to the 
server to determine
what to do with the field, and how to respond with an appropriate 
authentication method.

For the CVResponse, the the requestorName sequence is essentially a copy 
of the last CVrequest
(e.g. if chaining was used). The server may add an identification, if 
the initial client has not
provide one, and if it can be derived from a networking identification 
or an authentication method,
all this controlled by a policy where a client can be allowed to stay 
anonymous through a proxy.

For the CVResponse, the the responderName sequence (a responder field 
had been introduced in the
past and then removed again), indicates the identities of parties that 
have participated in the
creation of the response. This allows a client to show them immediately 
without the need of
interpreting the details of the result which is difficult if not 
impossible in case of muiltiple
identities of servers.

The various drafts cover all this partially, but each time only a part, 
a different one.

Or,  in

    CVRequest ::= SEQUENCE {
      cvRequestVersion        INTEGER DEFAULT 1,
      query                   Query,
      requestorRef        [0] GeneralNames OPTIONAL,
      requestNonce        [1] OCTET STRING OPTIONAL,
      requestorName       [2] GeneralName OPTIONAL,
      responderName       [3] GeneralName OPTIONAL,
      requestExtensions   [4] Extensions OPTIONAL }

   CVResponse ::= SEQUENCE {
      cvResponseVersion         INTEGER,
      serverConfigurationID     INTEGER,
      producedAt                GeneralizedTime,
      responseStatus            ResponseStatus,
      respValidationPolicy  [0] RespValidationPolicy OPTIONAL,
      requestRef            [1] RequestReference OPTIONAL,
      requestorRef          [2] GeneralNames OPTIONAL,
      requestorName         [3] GeneralNames OPTIONAL,
      replyObjects          [4] ReplyObjects OPTIONAL,
      respNonce             [5] OCTET STRING OPTIONAL,
      serverContextInfo     [6] OCTET STRING OPTIONAL,
      cvResponseExtensions  [7] Extensions OPTIONAL }

there should be

      requestorName         [x] GeneralNames OPTIONAL,
      responderName         [y] GeneralNames OPTIONAL,

(There was once a responder in the response structure.)

Point 2:

I have asked to explain the need for the  MUST concerning

 If the default values for all of the flags are used, then the
  response flags item MUST NOT be included in the request.

    responseFlags           ResponseFlags OPTIONAL,

you can have the same effect using

    responseFlags           ResponseFlags DEFAULT {} ,

(modulo syntax errors introduced by my limited knowledge).

i.e. a MUST important for interop test is replaced by a standard feature 
of ASN.1

My suggestion of  'elegance', i.e. the one that I made a strawman in Paris
was to change the definition of

    ResponseFlags ::= SEQUENCE {
      fullRequestInResponse      [0] BOOLEAN DEFAULT FALSE,
      responseValidationPolByRef [1] BOOLEAN DEFAULT TRUE,
      protectResponse            [2] BOOLEAN DEFAULT TRUE,
      cachedResponse             [3] BOOLEAN DEFAULT TRUE }

to a bitstring with named values, and thus avoiding nested DEFAULT specs.
I can live with that, just write the DEFAULT as indicated above, and you 
have one
test les for interop. On the other hand, there are compilers that may have
problems with nested defaults. so

    ResponseFlags ::= BIT STRING {
      fullRequestInResponse(0),         responseValidationPolByRef(1)
      protectResponse(2)
      cachedResponse (3) }

and an appropriate DEFAULT 
(responseValidationPolByRef,protectResponse,cachedResponse)
or DEFAULT '0111'B

I repeat, the original point is the MUST about the empty sequence 
implying an
unncessary addition explicit test for conformance which you can handle by a
spec of DEFAULT { }.

point 3;

After 2 years or so, none of the authors ever answered why there is:

ReplyWantBacks ::= SEQUENCE OF ReplyWantBack

    ReplyWantBack::= SEQUENCE {
      wb                         OBJECT IDENTIFIER,
      value                      OCTET STRING }

where some of the octet strings contain certificat lists and crls for 
example.
What is the security risk or advantage to force client to invoke a parser
individually each time.

I simply propose:

    ReplyWantBack::= SEQUENCE {
      wbType                       OBJECT IDENTIFIER,
      wbValue                      ANY DEFINED BY wbType }

(or in fact the correct corresponding current ASN.1 which may be a
bit difficult to understand for some people.)

There are minimal changes in the text that follows this definition, i.e.
instead of saying the octet string contains you says the type used is ...

Compare this with a similar construct in the request.

    RevocationInfo ::= CHOICE {
      crl                    [0] CertificateList,
      delta-crl              [1] CertificateList,
      ocsp                   [2] OCSPResponse,
      other                  [3] OtherRevInfo }

    OtherRevInfo ::= SEQUENCE {
      riType                     OBJECT IDENTIFIER,
      riValue                    ANY DEFINED BY riType }

Point 4:

Use current ASN1. Free tools to validate the syntax exist.

Point 5:
Policy issues: I leave this mainly to Denis, but IMO the policy definitions
are intended to be usable for a client to determine *ALL* the required 
or possible
parameters. By no way it is acceptable that a client try be required to 
make
a trial to detrmline whether a something is necessary or required. Otherwise
the whole point of having a protocol for policy discovery is useless.

Point 6:

Since this is ther from the very beginning, some error codes are represented
as integer, although one would rather use an enumeration. Integers are
for values that be be used for counting. But well, I won't die because 
of that.

>
> The one remaining problem here is how to make this protocol agile with 
> regard to the hash algorithm employed for certificate references. 
> Today SHA-1 is hardwired. Updating the spec to specify another hash 
> function does not satisfy the new algorithm agility requirement. Steve 
> Kent suggested that the hash function can be an aspect of the server's 
> validation policy, to satisfy the agility requirement. Russ Housley 
> suggested that the OID of the hash employed be explicitly returned, in 
> case the server's policy changes over time (but the policy OID does 
> not). A straw poll was conducted to get a sense of the room for the 
> two alternatives described in the last slide in this presentation. The 
> first alternative received 12 votes, vs. 0 for the second. (Slides)

Why are these alternatives?

A client should be able to detect CURRENT hash algorithm in a policy 
lookup.

A server response and request are self containing entities. No 
additional information
should be required to interprete the content, in particular, it an octet 
string containing
a hash always needs to be accompanied by an algorithm identifier (unless 
the the protocol
or version specific default is used.

Peter

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 8 Nov 2005 15:32:28 -0500

Peter,

First, I am the editor of the minutes, not Tim.

I'm afraid that your comments are not germane to the meeting minutes, 
the primary goal of which is to accurately represent what was said by 
the presenters and WG attendees in the course of the meeting. 
Objective, factual errors related to what was said are valid a basis 
for comments on meeting minutes. However, a detailed debate about a 
contentious issue like this is not appropriate for meeting minute 
comments & corrections.

Steve

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 09 Nov 2005 12:00:12 +0100

> First, I am the editor of the minutes, not Tim.

Did I say that?

> contentious issue like this is not appropriate for meeting minute 

Indeed, this is not a comment for minutes.

Throw into a black hole, wait until they evaporate as a part of
the detailed discussion. You have asked in a private message
to send a comment, you may thus just consider that I have forgotten
to change the comment into something more appropriate and that
I used the minutes as a starting point.

Do you want me to resend?

---

From: Stephen Kent <[email-masked]>
Date: Wed, 9 Nov 2005 16:28:18 -0500

Peter,

I reread your message and realize that when you used the phrase "... 
the notes taken by Tim Polk ..." you were not referring to the 
meeting minutes. My error. I had assumed you were, because the 
message was sent with a subject line of "draft minutes (SCVP part)."

>...
I would like the material I requested in the private message re SCVP, 
sent a a private response. The 6 points in your message don't follow 
the format of what I requested, i.e., reference to section of 
SCVP-21, explanation of why is is not compliant with 3379 OR with a 
request that you or Denis made in subsequent messages. None of the 
points references a section number in SCVP-21, nor provides cross 
references to 3379, for example.

steve

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 10 Nov 2005 14:45:50 +0100

SCVP-21 was made as a result of a discussion of one hour between Tim, 
Denis and me, where
Tim took notes.

During three months there was no exchange to clarify anything. one week 
before
the deadline of the submission we were informed about an editors draft 
and had three
days to comment, the obvious thing was that several points were 
misunderstood
or that the authors were afraid to change something, or they referred to 
existing
implementations, etc. Nothing, really nothing to explain what is wrong, 
in particular
when some requests have been partially treated and retreated in the past.
I don't think that it is unfair to ask why the authors (who are as I 
understand not implementors)
continue to find arguments other than technical to refuse request which they
technically already admit as useful, ending with a remark

Given the tone and content of your message, I have finally recognized that you 
will never be happy with SCVP (or any document I am involved with.)  You are 
clearly determined to disagree with whatever is in the specification, so I have 
given up on addressing your comments.  There are far too many demands on my time 
for such wasted effort.  I have got to concentrate my efforts where they have 
*some* chance of success.

SCVP 21 finally after years of pointing to the requirement
a server can return another SCVP response. Good.

There is the n-th iterator of changed handling identities in the request 
and
response, resulting this time in a respondername in a request,
the encodings and semantics of the fields were changed
from octet strings to generalname, good, but, I did only see recently
that two drafts ago an already existing responder identity in the request
was removed.

It is not very pleasing to see, first, total rejection, then partial 
support,
then a bit more, then partial removal, etc. It may be that my request
is totally uninterpretable or what?

Peter