Re: One final week of Last Call for SCVP

[Stephen Kent <[e-mail]>]

Denis,

We are both sensitive to the fact that Tim is a co-editor of the 
document and co-chair.  I believe that is why Tim made the comment 
you quoted in his message, i.e., noting that I will act to determine 
WG consensus for SCVP.

WG chairs consider many factors when trying to evaluate consensus. We 
do no want to merely count the number of messages sent by an 
individual, or their length. We do want to take into account comments 
from a diverse, knowledgeable set of WG participants. In my opinion 
message content is important. However, repetition of the same 
arguments by the same WG member does not violate the notion of rough 
consensus if nobody else supports those arguments. If the same 
arguments are made by multiple WG members, preferably not affiliated 
with the same organization, then there is reason to believe that we 
do not have consensus.

Steve




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SJ7cK7098220; Mon, 28 Feb 2005 11:07:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SJ7cdp098219; Mon, 28 Feb 2005 11:07:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SJ7QbM098197 for <[e-mail]>; Mon, 28 Feb 2005 11:07:29 -0800 (PST) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1SJ6WkL009178; Mon, 28 Feb 2005 14:06:36 -0500 (EST)
Mime-Version: 1.0
Message-Id: <p0621020cbe4909ba365a@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 28 Feb 2005 12:56:23 -0500
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: One final week of Last Call for SCVP
Cc: [e-mail], Sam Hartman <[e-mail]>, russ housley <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

We are both sensitive to the fact that Tim is a co-editor of the 
document and co-chair.  I believe that is why Tim made the comment 
you quoted in his message, i.e., noting that I will act to determine 
WG consensus for SCVP.

WG chairs consider many factors when trying to evaluate consensus. We 
do no want to merely count the number of messages sent by an 
individual, or their length. We do want to take into account comments 
from a diverse, knowledgeable set of WG participants. In my opinion 
message content is important. However, repetition of the same 
arguments by the same WG member does not violate the notion of rough 
consensus if nobody else supports those arguments. If the same 
arguments are made by multiple WG members, preferably not affiliated 
with the same organization, then there is reason to believe that we 
do not have consensus.

Steve



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SICb8W092682; Mon, 28 Feb 2005 10:12:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SICbgL092681; Mon, 28 Feb 2005 10:12:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SICW6p092663 for <[e-mail]>; Mon, 28 Feb 2005 10:12:32 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-47.fastq.com [65.39.92.47]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id j1SICNc62868; Mon, 28 Feb 2005 11:12:23 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: Comments to SCVP ID 17
Date: Mon, 28 Feb 2005 11:09:15 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Reasonable minds may differ on these shades of meaning without
resolution.  The IETF empowers WG chairs as it does in order to resolve
such impasses.  This document has been tied up in WG far too long
debating ethereal issues that have little if any bits-on-the-wire
technical substance.  Time to move it on I think and let "running code"
determine what defects, if any, exist.

Mike




-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Denis Pinkas
Sent: Monday, February 28, 2005 2:24 AM
To: [e-mail]
Cc: [e-mail]; [e-mail]
Subject: Re: Comments to SCVP ID 17




Here are some revised comments, based on the previous e-mail.

1. A new wording introduced in the document which is: “PKI policies”.
This
term is defined nowhere in RFC 3280, nor in this document. When it is
used, it seems to mean “validation policy”. Please delete everywhere
“PKI
policy” and replace it with “validation policy”.


2. On page 7 the new term “basic certification path processing
 algorithm”
is introduced whereas RFC 3280 uses a different wording :

  - “certification path validation” (that is the title of section 6) and
  - “basic path validation” (that is the title of section 6.1).

Please do not introduce a new term.


3. The text refers to section 6.1.1 and it is said that one the input in
section 6.1.1 is a “Set of Trust Anchors”. This is not consistent with
section 6.1.1 from RFC3280 which deals with a *single* trust anchor,
while section 6.2 from RFC 3280 deals with multiple trust anchors.

 From the introduction, “a validation policy contains one or more trust
anchors”. The protocol should allow, with a single request-response, to
check if a certificate is valid against a validation policy which has
more than one trust anchor. These checks should be done in accordance
with section 6.2 from RFC 3280. The current ASN.1 is not conformant with
section 6.1 from RFC 3280.


4. Section 1.4 is about a validation algorithm. Different rules may
apply
to every trust anchor and to the CA certificates from the certification
path under every trust anchor. The ASN.1 description of ValidationPolicy
starting on page 17 does not allow the client to define CA related
different parameters for every trust anchor.

We currently have:

ValidationPolicy ::= SEQUENCE {
        validationPolRef          ValidationPolRef,
        validationAlg         [0] ValidationAlg OPTIONAL,
        userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
        IDENTIFIER OPTIONAL,
        inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
        requireExplicitPolicy [3] BOOLEAN OPTIONAL,
        inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
        trustAnchors          [6] TrustAnchors OPTIONAL,
        keyUsages             [7] KeyUsages OPTIONAL,
        extendedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL}

and

ValidationAlg ::= SEQUENCE {
        valAlgId              OBJECT IDENTIFIER,
        parameters            ANY DEFINED BY valAlgId OPTIONAL }

If:
        trustAnchors          [6] TrustAnchors OPTIONAL,

is changed into:

        trustAnchor          [6] TrustAnchor OPTIONAL,

  ... then this would be conformant with the algorithm from section 6.1
of
RFC 3280, but validation policies with multiple trust anchors and their
own parameters could not be used.

The conditions that apply to CA certificates may be very complicated and
vary from one trust anchor to another. The goal if this document is to
support section 6.2 from FRC 3280.

A validation policy could OPTIONALLY include several “target certificate
specific parameters” as Wen-Cheng proposed, since they usually do not
change from one trust anchor to another.

This would also solve the problem that Wen-Cheng noticed about the “name
validation algorithm”.

Note that, as Wen-Cheng proposed, “target certificate” seems to be a
better term rather than “end certificate”

It is obvious that for each certification path, the algorithm from
section 6.1 of RFC 3280 is being used. The validationAlg parameter is
not
needed. We could then simply have:

ValidationPolicy ::= SEQUENCE {
        validationPolRef          ValidationPolRef,
        keyUsages                [0] KeyUsages OPTIONAL,
        extendedKeyUsages        [1] SEQUENCE OF KeyPurposeId OPTIONAL,
        nameValidationAlgParms   [2] NameValidationAlgParms OPTIONAL,
        otherTests               [3] OtherTests OPTIONAL
    }

additionalTests could be used for example to test QCStatements
extensions
presence and values, which would be very useful for Qualified
Certificates.


5.Section 1.5 states: “However, revocation checking is an optional
feature in [PKIX-1], ... ” This is incorrect.

RFC 3280 does not say that revocation checking is optional. Only CRLs
processing is defined in RFC 3280 but we all know that OCSP is an
alternative method. For DPV, revocation checking MUST be done to
validate
a certification path, but this may be done using different means. This
means may be specified in the validation policy.


6. It should be remembered that RFC 3379 makes the separation between
DPV
and DPD, while this document defines a single protocol for both of them.
At the minimum the document should be profiled so that implementers may
choose to support only DPV and not be forced to support also DPD.


7. “SCVP” is a not a good name when the request is to only build a
certification path - with or without revocation status (i.e. DPD,
leaving
the validation to the client). The certificate is not VALIDATED by the
server, and even if it would, the client would not trust it. If someone
says : “I support SCVP”, how could it make clear that it only supports
the DPV variant of it ?

Better names would be:

  - DPVP: Delegated Path Validation Protocol, and
  - DPDP: Delegated Path Discovery Protocol.


8. The text correctly states on page 6: “An SCVP request needs only to
contain the certificate to be validated, the referenced validation
policy, and any run-time parameters for the request”.

It would be very beneficial to be able to have implementations that only
support the above requirements for DPV, leaving the security protection
(i.e. integrity) to the communication link (i.e. using TLS) and not
supporting other parameters (with the exception of the above optional
“target certificate specific parameters” as Wen-Cheng proposed). It is
currently not straightforward to derive from the current document a
profile for this.

It is suggested to revise the document so that this goal can be achieved
and that conformance clauses are added to be able to say that a given
implementation is conformant to this aspect only.

Additional comments (up to page 8 only) follow.


9. Page 5. Section 1. Second paragraph. The text states:

    The first class of applications wants just two things: confirmation
    that the public key belongs to the identity named in the certificate
    and confirmation that the public key can be used for the intended
    purpose.

This is not the main goal. Rephrase as:

    The first class of applications wants just confirmation
    that the certificate is valid according a given validation policy.


10. Page 5. Section 1. Second paragraph. The text states:

    The second class of applications can perform certification path
    validation, but they lack a reliable or efficient method of
    constructing a valid certification path.

Rephrase as:

    The second class of applications can perform certification path
    validation, but they lack a reliable or efficient method of
    constructing a valid certification path and the associated
    revocation status information.


11. Page 5. Section 1.1. Second paragraph.

    The primary goals of SCVP are to make it easier to deploy
PKI-enabled
    applications and to allow central administration of PKI policies
    within an organization.

Rephrase as:

    The primary goals of SCVP are to make it easier to deploy
PKI-enabled
    applications and to allow a server to support one or more validation
    policies against which certificates can be tested by applications.


12. Page 5. Section 1.1. Second paragraph.

    SCVP can be used by clients that do much of
    the certificate processing themselves but simply want an untrusted
    server to collect information for them.  However, when the client
has
    complete trust in the SCVP server, SCVP can be used to delegate the
    work of certification path construction and validation, and SCVP can
    be used to ensure that policies are consistently enforced throughout
    an organization.

Rephrase as:

    SCVP, used for DPV, can be used by clients that have complete trust
    in a trusted DPV server. In such a case, the protocol can be used to
    delegate the work of certification path construction and validation.

    SCVP, used for DPD, can be used by clients that do much of
    the certificate processing themselves but simply want an untrusted
    DPD server to collect information for them.


Denis






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SGTraS084170; Mon, 28 Feb 2005 08:29:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SGTrFe084169; Mon, 28 Feb 2005 08:29:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SGTqY8084143 for <[e-mail]>; Mon, 28 Feb 2005 08:29:52 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j1SGTen22157; Mon, 28 Feb 2005 17:29:40 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 28 Feb 2005 17:29:40 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j1SGTd305009; Mon, 28 Feb 2005 17:29:39 +0100 (MET)
Date: Mon, 28 Feb 2005 17:29:39 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: About RFC 3280bis
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> This change was not made to accommodate "partial" path validation, so 
> there is no need to change section 6.1.6.  The change was only intended 
> to acknowledge that the final certificate in the certification path may 
> be a CA certificate, although it is being validated for some use other 
> than certificate signing (e.g., CRL signing, OCSP response signing, 
> signing of CMP/CMC transaction messages).

I see.

> In the -01 draft, I will add a note to section 6.1 stating that 
> certificate n is referred to as the "end certificate" (or "target 
> certificate" if WG consensus is that that term should be used instead).

Target seems sufficiently neutral.

What about adding your explanation above or something like:

"The path algorithm can be applied for all certificates which are
 used for purposes other than certificate signing. Such certificates
 can be end entity certificates, or CA certificates when they are used
 for other purposes than certificate signing." 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SGBdlP082913; Mon, 28 Feb 2005 08:11:39 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SGBdXX082912; Mon, 28 Feb 2005 08:11:39 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SGBc4s082904 for <[e-mail]>; Mon, 28 Feb 2005 08:11:38 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1SGAfcN025589; Mon, 28 Feb 2005 11:10:44 -0500
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1SGAUEX029792; Mon, 28 Feb 2005 11:10:32 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 28 Feb 2005 11:11:16 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: About RFC 3280bis
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

This was not intended to be a change at all.  Some clarification will be 
needed in 3280bis-01.

The reason for the change is as follows.  RFC 3280 began section 6.1.5 with

     To complete the processing of the end entity certificate, perform the
     following steps for certificate n:

The problem with this is that "end entity certificate" refers to a 
certificate that is not a CA certificate.  While the final certificate 
in a certification path is usually an end entity certificate, it may be 
a CA certificate.  In X.509, the term "end certificate" is used to refer 
to the final certificate in a certification path, whether that 
certificate is a CA certificate or an end entity certificate.  That is 
why I changed "end entity certificate" to "end certificate".

This change was not made to accommodate "partial" path validation, so 
there is no need to change section 6.1.6.  The change was only intended 
to acknowledge that the final certificate in the certification path may 
be a CA certificate, although it is being validated for some use other 
than certificate signing (e.g., CRL signing, OCSP response signing, 
signing of CMP/CMC transaction messages).

In the -01 draft, I will add a note to section 6.1 stating that 
certificate n is referred to as the "end certificate" (or "target 
certificate" if WG consensus is that that term should be used instead).

Dave

Peter Sylvester wrote:

>6.1.5 has remove the word 'entity', this seems a major change
>because it now also specifies a path validation algorithm for
>CA certs.
>
>But, 6.1.6 has not be updated to also output information that 
>are necessary  to determine later or earlier whether the CA 
>certificate can be used to sign a particular certificate. 
>
>For example, whether it can sign another ca cert or not,
>or the permitted and prohibited subtrees. 
>
>(modulo the option to augment the input parameters)
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SFx5tU082098; Mon, 28 Feb 2005 07:59:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SFx5SB082097; Mon, 28 Feb 2005 07:59:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SFx2pt082072 for <[e-mail]>; Mon, 28 Feb 2005 07:59:04 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA39654; Mon, 28 Feb 2005 17:12:35 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005022816584576:2281 ; Mon, 28 Feb 2005 16:58:45 +0100 
Message-ID: <[e-mail]>
Date: Mon, 28 Feb 2005 16:59:19 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "David A. Cooper" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: About RFC 3280bis
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/02/2005 16:58:45, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/02/2005 16:58:47, Serialize complete at 28/02/2005 16:58:47
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,

No problem. I will wait.

Denis

> Denis,
> 
> Here is what Tim said when he first announced that 3280bis-00 was 
> available:
> 
>  > David has also created an html diff file that shows all changes from 
> 3280 to 3280bis.
>  >
>  > 
> http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html
>  >
>  > He has not had time to pull together a "disposition of comments" 
> email, since I have
>  > him triple booked at the moment.   (In particular, he is working on 
> SCVP as well.)
>  > He will try to get that to the list before the meeting, but the diff 
> file makes it very
>  > easy to identify the changes that have been made.
> 
> I will be creating the "disposition of comments" that you want to see, 
> but I have other projects that are of higher priority that must be 
> completed first.  The disposition of comments will have to wait until I 
> have time.
> 
> For those who want to know how 3280bis-00 differs from 3280, the diff 
> file is the best place to look since it highlights every change, even 
> ones that are too minor to mention in a "disposition of comments" 
> document.  If you don't want to look at the diff file and only want to 
> read the "disposition of comments" document, that's fine.  But, you will 
> have to wait until I have time to write it.
> 
> Dave
> 
> Denis Pinkas wrote:
> 
>> Tim,
>>
>>> I certainly agree that no one has the time to read all of 3280bis 
>>> these days, and that it is important to provide the set of changes in 
>>> a straightforward manner.  However, it was very difficult to convey 
>>> the complete context of the proposed changes without showing how they 
>>> would impact the current text.   Describing the changes out of 
>>> context and rolling them in later would surely result in repetitive 
>>> debates, and I personally don't see the value in arguing every issue 
>>> twice.  To ensure that the complete impact of all changes were 
>>> accurately conveyed, we felt the need to create a 3280bis draft.
>>>
>>> To facilitate an efficient review by WG members that are already 
>>> familiar with 3280, the editor also has provided an html diff file 
>>> that shows all changes from 3280 to 3280bis. As noted earlier on 
>>> list, this file is available at
>>>
>>> http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html 
>>>
>>>
>>> The html diff file clearly identifies every change (deletions are in 
>>> red and strikethrough, insertions are in green) so no one should have 
>>> to read the entire document or spend cycles figuring out which 
>>> sections were, or were not, modified.
>>
>>
>>
>> This still does not solve the concern.
>>
>> We need a short document that we can print to review in the train or 
>> in the plane. I cannot handle a 100 pages document.
>>
>> Please save our trees (since trees are transformed into paper).
>>
>>  .. but more important, what we need is a summary of all the change 
>> requests and, even more important, how they have been addressed.
>>
>> A change document will not mention the comments that have been discarded.
>>
>> Denis
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SFrR98081693; Mon, 28 Feb 2005 07:53:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SFrRiW081692; Mon, 28 Feb 2005 07:53:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SFrQPR081680 for <[e-mail]>; Mon, 28 Feb 2005 07:53:26 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1SFqeDH014506; Mon, 28 Feb 2005 10:52:41 -0500
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1SFphEX020542; Mon, 28 Feb 2005 10:51:43 -0500 (EST)
Message-ID: <[e-mail]>
Date: Mon, 28 Feb 2005 10:52:29 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: About RFC 3280bis
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Here is what Tim said when he first announced that 3280bis-00 was available:

 > David has also created an html diff file that shows all changes from 
3280 to 3280bis.
 >
 > 
http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html
 >
 > He has not had time to pull together a "disposition of comments" 
email, since I have
 > him triple booked at the moment.   (In particular, he is working on 
SCVP as well.)
 > He will try to get that to the list before the meeting, but the diff 
file makes it very
 > easy to identify the changes that have been made.

I will be creating the "disposition of comments" that you want to see, 
but I have other projects that are of higher priority that must be 
completed first.  The disposition of comments will have to wait until I 
have time.

For those who want to know how 3280bis-00 differs from 3280, the diff 
file is the best place to look since it highlights every change, even 
ones that are too minor to mention in a "disposition of comments" 
document.  If you don't want to look at the diff file and only want to 
read the "disposition of comments" document, that's fine.  But, you will 
have to wait until I have time to write it.

Dave

Denis Pinkas wrote:

> Tim,
>
>> I certainly agree that no one has the time to read all of 3280bis 
>> these days, and that it is important to provide the set of changes in 
>> a straightforward manner.  However, it was very difficult to convey 
>> the complete context of the proposed changes without showing how they 
>> would impact the current text.   Describing the changes out of 
>> context and rolling them in later would surely result in repetitive 
>> debates, and I personally don't see the value in arguing every issue 
>> twice.  To ensure that the complete impact of all changes were 
>> accurately conveyed, we felt the need to create a 3280bis draft.
>>
>> To facilitate an efficient review by WG members that are already 
>> familiar with 3280, the editor also has provided an html diff file 
>> that shows all changes from 3280 to 3280bis. As noted earlier on 
>> list, this file is available at
>>
>> http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html 
>>
>>
>> The html diff file clearly identifies every change (deletions are in 
>> red and strikethrough, insertions are in green) so no one should have 
>> to read the entire document or spend cycles figuring out which 
>> sections were, or were not, modified.
>
>
> This still does not solve the concern.
>
> We need a short document that we can print to review in the train or 
> in the plane. I cannot handle a 100 pages document.
>
> Please save our trees (since trees are transformed into paper).
>
>  .. but more important, what we need is a summary of all the change 
> requests and, even more important, how they have been addressed.
>
> A change document will not mention the comments that have been discarded.
>
> Denis



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SEYVGn076045; Mon, 28 Feb 2005 06:34:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SEYVVi076044; Mon, 28 Feb 2005 06:34:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SEYQav076034 for <[e-mail]>; Mon, 28 Feb 2005 06:34:26 -0800 (PST) (envelope-from [e-mail])
Received: from real1.localdomain ([192.168.2.10]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1SEYGD1027716; Mon, 28 Feb 2005 09:34:16 -0500
Received: from real1.localdomain (real1.localdomain [127.0.0.1]) by real1.localdomain (8.12.8/8.12.8) with ESMTP id j1SEYGiq003698; Mon, 28 Feb 2005 09:34:16 -0500
Received: (from apache@localhost) by real1.localdomain (8.12.8/8.12.8/Submit) id j1SEYG57003696; Mon, 28 Feb 2005 09:34:16 -0500
Received: from pool-141-156-40-37.res.east.verizon.net (pool-141-156-40-37.res.east.verizon.net [141.156.40.37])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Mon, 28 Feb 2005 09:34:16 -0500
Message-ID: <[e-mail]>
Date: Mon, 28 Feb 2005 09:34:16 -0500
From: [e-mail]
To: [e-mail]
Cc: [e-mail], [e-mail]
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 141.156.40.37
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please accept the draft agenda below for the PKIX WG at the 62nd IETF meeting.

Thanks,

Tim Polk

---------------------------------------------

Public Key Infrastructure (X.509) WG (pkix)

TUESDAY, March 8, 2005, 1300-1500

===================================

CHAIRS: Stephen Kent <[e-mail]>
        Tim Polk <[e-mail]>

1. WG Status and Direction

1.1 Document Status Review [Tim Polk (NIST)]
       (10 min.)

2. PKIX WG Specifications

2.1 Simple Certificate Validation Protocol (SCVP)
       Trevor Freeman (Microsoft) and David Cooper (NIST
      http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-18.txt

      Significant progress has been made towards rough consensus through
      the two drafts submitted since the last meeting.  These drafts
      represent been submitted with significant enhancements.  This
      presentation will highlight those changes and their rationale, as
      well as the question of rough consensus.
      (20 min.)

2.2 3280bis
        David Cooper (NIST)
      currently available on NIST site
http://csrc.nist.gov/pki/documents/PKIX/draft-ietf-pkix-rfc3280bis-00.txt
      see also
http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html

      A design team met in January to develop a -00 draft from a issues
      list complied from PKIX mail messages and mail to the RFC 3280
      editors.  Draft -00 incorproates a number of clarifications and small
      changes designed to align with ISO and remove ambiguities, and a new
      section on comparing internationalized names.  Draft -00 and a diff
      file highlighting changes are now available from the URLS above.  
      This presentation will focus on the set of changes and in the -00
      draft and the proposed approaches for comparing internationalized names.
      (30 min.)

2.3 UTF8String Deployment and Migration
        Masaki Shimaoka (JNSA PKI Challenge Project)
        (no draft)

      This presentation will provide the feedback recieved fron a questionnaire
      on UTF8String deployment in Asia, and discuss a migration strategy
      that is currently under development. 
      (15 min.)

2.4 Discovering CRL Signer Certificates Using AIA
        Stefan Santesson (Microsoft)
      http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt

      Draft -00 of this new PKIX document was published after the last meeting.
      This presentation will review the comments recieved oin this document to
      date and the plan for progression.
      (15 min.)

2.5 Update on CMC Archive, CMC Transport
        Jim Schaad (Soaring Hawk)
      http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-trans-03.txt
      http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-archive-01.txt

      This presentation will review the state of several related drafts and
      highlight the controversies that remain.  (20 min.)

3. Related Specifications & Liaison Presentations

      Time allowing, liaison presentations will be accommodated to ensure the
      PKIX WG is aware of related specifications currently progressing as
      individual drafts.

3.1 Lightweight Directory Access Protocol (LDAP) schema definitions
      Kent Zeilenga (OpenLDAP)
      http://www.ietf.org/internet-drafts/draft-zeilenga-ldap-x509-01.txt

      The author of this individual submission has requested that the WG review
      and comment upon this draft.  He intends to make a decision by the end of
      IETF#62 whether to recommend this revision for IESG consideration as a
      Proposed Standard. This document is intended to be published at the same
      time as the revised LDAP TS being developed by the LDAPBIS WG. (10 min.)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SCi3ml056038; Mon, 28 Feb 2005 04:44:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SCi348056037; Mon, 28 Feb 2005 04:44:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SCi1qr055879 for <[e-mail]>; Mon, 28 Feb 2005 04:44:02 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j1SChdn18492 for <[e-mail]>; Mon, 28 Feb 2005 13:43:39 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Mon, 28 Feb 2005 13:43:39 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j1SChd904302 for [e-mail]; Mon, 28 Feb 2005 13:43:39 +0100 (MET)
Date: Mon, 28 Feb 2005 13:43:39 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: About RFC 3280bis
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

6.1.5 has remove the word 'entity', this seems a major change
because it now also specifies a path validation algorithm for
CA certs.

But, 6.1.6 has not be updated to also output information that 
are necessary  to determine later or earlier whether the CA 
certificate can be used to sign a particular certificate. 

For example, whether it can sign another ca cert or not,
or the permitted and prohibited subtrees. 

(modulo the option to augment the input parameters)
  




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SBul3B039078; Mon, 28 Feb 2005 03:56:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1SBuldQ039077; Mon, 28 Feb 2005 03:56:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1SBuk9w039034 for <[e-mail]>; Mon, 28 Feb 2005 03:56:46 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Mon, 28 Feb 2005 11:56:36 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Date: Mon, 28 Feb 2005 11:56:39 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
thread-index: AcUagVPSl3l2S6TfRceEOma8qt0L/wDCUl1g
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 28 Feb 2005 11:56:36.0878 (UTC) FILETIME=[8E3AEAE0:01C51D8C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1SBul9w039071
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

No problem, take your time.

My understanding is that you have not requested any technical changes to
the document.

Your comments seems to have in common that you would like the document
to state that AIA in CRLs only applies to indirect CRLs. However, such
limitation was not imposed on the scope of this work when accepted by
PKIX and I personally strongly object to it.

I think it is your job (whenever you have time) to seek consensus for
your opinion to impose such limitation on this draft.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 24 februari 2005 15:59
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> Stefan,
> 
> This is a waiting response. No response from me does not mean that I
agree
> with your arguments.
> 
> Since SCVP-17 was issued, I simply spent the time I had to comment on
> SCVP-17 and thus I have no more time available for this draft for the
> moment.
> 
> In general, I can say that, for the time being, we are still not in
> agreement.
> 
> Denis
> 
> 
> > Comments in-line;
> > (Some stuff deleted to keep volume down)
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >>What about the following sentences picked from the document:
> >>
> >>    Standardized methods of finding the certificate of the CRL
issuer
> >
> > are
> >
> >>    currently available either though an accessible directory
location
> >
> > or
> >
> >>    through use of the Subject Information Access extension in
> >>    intermediary CA certificates.  These methods are however not
> >>    generally applicable, and they do not provide a generic solution
> >
> > to
> >
> >>    the problem.
> >>
> >>This is true only if indirect CRLs are being used, but the wording
> >>"indirect
> >>CRL" is absent from these lines.
> >
> >
> > [Stefan] Even if it was true ONLY for indirect CRL's, text would be
> > correct. But even more, this is NOT ONLY true for indirect CRL's.
For
> > example, it is also true if your current CA infrastructure and its
CA
> > certificates (which may be valid for another 5-20 years), don't
include
> > a SIA extension. AIA in CRL's can be added to the infrastructure
without
> > reissuing CA certificates, SIA can't. This is just 1 example. There
are
> > more.
> >
> >
> >>>It is an optional mechanism to be used
> >>>by those who whish to use it to find the CRL signer cert.
> >>
> >>  ... which is really motivated when indirect CRLs are being used,
but
> >>otherwise is not and the draft does not say it.
> >>
> >
> >
> > [Stefan] Because it is not useful only for indirect CRLs.
> >
> >
> >>>I think the motivation for allowing this extension in CRLs is
> >>>sufficiently stated in the document.
> >>
> >>It is not. In addition, adding an extension does not make sense
unless
> >
> > you
> >
> >>tell how it should be used.
> >>
> >
> >
> > [Stefan] What is unclear for you?
> >
> >
> >>>Nothing you suggest is changing the
> >>>technical outline of the specified solution.
> >>
> >>In this case, the processing of this new extension may be explained
> >
> > and
> >
> >>this
> >>is not the case at this time.
> >>
> >
> >
> > [Stefan] What is missing?
> >
> >
> > <stuff deleted>
> >
> >>>>The problem is that neither the abstract nor the introduction of
> >>>
> > this
> >
> >>>>draft is limiting the scope to indirect CRLs only.
> >>>
> >>>[Stefan] That is because the scope of AIA in CRLs is not limited to
> >>>indirect CRLs.
> >>
> >>   .. but this extension does not add anything, if SIA used.
> >>
> >
> >
> > [Stefan] Yes it does. It offers direct lookup of the CRL issuer cert
and
> > indicates that the CRL Issuer certificate actually IS available for
> > download, while SIA only offers pointer to location where the CRL
issuer
> > cert MAY be found among other unrelated certificates, 1) if it is
> > present and 2) if the client is capable of finding it.
> >
> >
> >
> >>>[Stefan] This is incorrect. The data in each DP of the CDP will
tell
> >>
> > the
> >
> >>>RP whether the DP points to an indirect CRL.
> >>
> >>    DistributionPoint ::= SEQUENCE {
> >>         distributionPoint       [0]     DistributionPointName
> >
> > OPTIONAL,
> >
> >>         reasons                 [1]     ReasonFlags OPTIONAL,
> >>         cRLIssuer               [2]     GeneralNames OPTIONAL }
> >>
> >>    DistributionPointName ::= CHOICE {
> >>         fullName                [0]     GeneralNames,
> >>         nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> >>
> >>Which field are you talking about ?
> >
> >
> > [Stefan] cRLIssuer
> >
> >
> >>>>The draft should thus address the two scenarios (i.e. an IDP is or
> >>>
> > is
> >
> >>>>not present) and for direct CRLs there is no "superiority" of the
> >>>
> > new
> >
> >>>>extension.
> >>>
> >>>[Stefan] I don't see the point with that. The use of the AIA
> >>
> > extension
> >
> >>>in CRL is not different for indirect or direct CRLs.
> >>
> >>With direct CRLs, there does not need to be any AIA extension, if
the
> >
> > SIA
> >
> >>extension in CA certificates is present. This is not said and should
> >
> > be
> >
> >>said.
> >>
> >
> >
> > [Stefan] I don't see any purpose in saying that. This standard
simply
> > recognizes the usefulness of allowing the already existing and
deployed
> > AIA extension logic, not only in certificates, but also in CRLs. It
is
> > not authoritative with regard to where and when this solution should
or
> > should not be deployed.
> >
> > The profile recognizes that there are other ways to build CRL paths.
> > This should be enough.
> >
> >
> >
> >
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1S9dTck086435; Mon, 28 Feb 2005 01:39:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1S9dT7j086434; Mon, 28 Feb 2005 01:39:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1S9dOXv086372 for <[e-mail]>; Mon, 28 Feb 2005 01:39:26 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA41936; Mon, 28 Feb 2005 10:53:01 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005022810391219:2089 ; Mon, 28 Feb 2005 10:39:12 +0100 
Message-ID: <[e-mail]>
Date: Mon, 28 Feb 2005 10:39:42 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: pkix <[e-mail]>
Subject: Re: About RFC 3280bis
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/02/2005 10:39:12, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/02/2005 10:39:14, Serialize complete at 28/02/2005 10:39:14
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

> I certainly agree that no one has the time to read all of 3280bis these days, 
> and that it is important to provide the set of changes in a straightforward 
> manner.  However, it was very difficult to convey the complete context of the 
> proposed changes without showing how they would impact the current text.   
> Describing the changes out of context and rolling them in later would surely 
> result in repetitive debates, and I personally don't see the value in arguing 
> every issue twice.  To ensure that the complete impact of all changes were 
> accurately conveyed, we felt the need to create a 3280bis draft.
> 
> To facilitate an efficient review by WG members that are already familiar with 
> 3280, the editor also has provided an html diff file that shows all changes 
> from 3280 to 3280bis. As noted earlier on list, this file is available at
> 
> http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html
> 
> The html diff file clearly identifies every change (deletions are in red and 
> strikethrough, insertions are in green) so no one should have to read the 
> entire document or spend cycles figuring out which sections were, or were not, 
> modified.

This still does not solve the concern.

We need a short document that we can print to review in the train or in the 
plane. I cannot handle a 100 pages document.

Please save our trees (since trees are transformed into paper).

  .. but more important, what we need is a summary of all the change 
requests and, even more important, how they have been addressed.

A change document will not mention the comments that have been discarded.

Denis


> Tim Polk
> 
> Quoting Denis Pinkas <[e-mail]>:
> 
> 
>>Paul Hoffman said on the list on November 8:
>>
>>"Instead of starting rfc3280bis, start a draft called something like
>>"rfc3280-changes". Have that draft be short, and contain *only*
>>changes to 3280. Only after there is consensus on the -changes draft
>>should you roll the changes in.
>>
>>No one reads all of 3280 these days, so expecting people to search
>>through rfc3280bis for different sections is not reasonable".
>>
>>I was fully agreeing with him and since I saw no neagtive response from the 
>>co-editors, I thought this was granted.
>>
>>Then what happened ? Exactly the opposite !
>>
>>What is the PKIX mailing list for, if the co-editors ignore such messages 
>>from the list ?
>>
>>Can we finally have these rfc3280-changes, the list of comments received and
>>
>>their proposed resolution, BEFORE we can start reading the new draft ?
>>
>>Denis
>>
>>-------- Original Message --------
>>Subject: Re: Suggestion for revising RFC 3280
>>Date: Mon, 08 Nov 2004 13:42:12 -0500
>>From: "Sean P. Turner" <[e-mail]>
>>Organization: IECA, Inc.
>>To: Paul Hoffman / VPNC <[e-mail]>
>>CC: [e-mail]
>>References: <p06110406bda564ea5155@[10.20.30.249]>
>>
>>
>>Or at least have a paragraph that gets removed prior to RFC publication
>>to tell everybody where changes were made.
>>
>>spt
>>
>>Paul Hoffman / VPNC wrote:
>>
>> >
>> > Instead of starting rfc3280bis, start a draft called something like
>> > "rfc3280-changes". Have that draft be short, and contain *only*
>> > changes to 3280. Only after there is consensus on the -changes draft
>> > should you roll the changes in.
>> >
>> > No one reads all of 3280 these days, so expecting people to search
>> > through rfc3280bis for different sections is not reasonable.
>> >
>> > --Paul Hoffman, Director
>> > --VPN Consortium
>> >
>> >
>>
>>
>>
>>
>>
>>
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1S9WMFT083942; Mon, 28 Feb 2005 01:32:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1S9WMs2083941; Mon, 28 Feb 2005 01:32:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1S9WKE2083899 for <[e-mail]>; Mon, 28 Feb 2005 01:32:20 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA43068; Mon, 28 Feb 2005 10:46:00 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005022810320859:2084 ; Mon, 28 Feb 2005 10:32:08 +0100 
Message-ID: <[e-mail]>
Date: Mon, 28 Feb 2005 10:32:42 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail], Sam Hartman <[e-mail]>, Stephen Kent <[e-mail]>
Subject: Re: One final week of Last Call for SCVP
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/02/2005 10:32:08, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/02/2005 10:32:12, Serialize complete at 28/02/2005 10:32:12
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

> Folks,
> 
> In my opinion, SCVP draft -18 satisfies all requirements specified in 
> RFC 3379.  I also believe that this draft has rough consensus within the 
> WG.  We have endured a rather arduous process, beginning with a -00 
> draft in 1999 and a long requirements specification process in the 
> middle of it all.  More recently, we have worked through deadlines for 
> comment submission and a very thorough review and editorial process to 
> address those comments.  While unanimous consensus has certainly *not* 
> been achieved, messages I have received both on and off list indicate 
> general satisfaction with this document.
> 
> Mike's message provided the motivation to "start the clock ticking" to 
> progression out of the WG. SCVP has been in "Last Call" forever, so 
> another two weeks of Last Call is not actually required.  However, we 
> should allow some time for those members who forgot we were in Last Call 
> to weigh in.  I believe one more week should be sufficient to review and 
> comment.
> 
> So, unless the mail on the list clearly demonstrates that rough 
> consensus has not been achieved, I intend to forward this document to 
> the AD next Friday.  Note that I will not consider the number of 
> messages, their length, or the amount of venom when determining rough 
> consensus, only the number of different submitters.

This last rule is quite strange: it is simply saying "I do not consider the 
content of the e-mail but only the number of e-mails". I have never seen 
such a rule in an IETF WG.

Since in your *next* message you said:

"I am sure that Steve will be glad to judge consensus"

then I believe that you are not allowed to set rules for a rough consensus,
  ... since there are indeed no such rules.

Anyway, I would like Steve, instead of you, to deal with the topic of rough 
consensus of this specific ID, since your cannot act both as PKIX co-chair 
and co-editor.

Consider your message deleted.

Denis

> Tim Polk
> 
> At 10:54 AM 2/25/2005 -0700, Michael Myers wrote:
> 
>> All,
>>
>> I reaffirm my opinion that the WG has amply done its work on this
>> important document.  It would be good to see the clock start ticking on
>> a two-week WG last call.
>>
>> The phrase "rough consensus" is by definition ambiguous.  However, the
>> distinction between "rough consensus" and "unanimous consent" is
>> self-evident.
>>
>> Mike
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1S9Nid3080958; Mon, 28 Feb 2005 01:23:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1S9Niod080957; Mon, 28 Feb 2005 01:23:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1S9NZ4E080838 for <[e-mail]>; Mon, 28 Feb 2005 01:23:38 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA41170; Mon, 28 Feb 2005 10:37:10 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005022810232030:2075 ; Mon, 28 Feb 2005 10:23:20 +0100 
Message-ID: <[e-mail]>
Date: Mon, 28 Feb 2005 10:23:49 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail]
Subject: Re: Comments to SCVP ID 17
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/02/2005 10:23:20, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 28/02/2005 10:23:25, Serialize complete at 28/02/2005 10:23:25
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1S9Ne4E080922
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are some revised comments, based on the previous e-mail.

1. A new wording introduced in the document which is: “PKI policies”. This
term is defined nowhere in RFC 3280, nor in this document. When it is
used, it seems to mean “validation policy”. Please delete everywhere “PKI
policy” and replace it with “validation policy”.


2. On page 7 the new term “basic certification path processing algorithm”
is introduced whereas RFC 3280 uses a different wording :

  - “certification path validation” (that is the title of section 6) and
  - “basic path validation” (that is the title of section 6.1).

Please do not introduce a new term.


3. The text refers to section 6.1.1 and it is said that one the input in
section 6.1.1 is a “Set of Trust Anchors”. This is not consistent with
section 6.1.1 from RFC3280 which deals with a *single* trust anchor,
while section 6.2 from RFC 3280 deals with multiple trust anchors.

 From the introduction, “a validation policy contains one or more trust
anchors”. The protocol should allow, with a single request-response, to
check if a certificate is valid against a validation policy which has
more than one trust anchor. These checks should be done in accordance
with section 6.2 from RFC 3280. The current ASN.1 is not conformant with
section 6.1 from RFC 3280.


4. Section 1.4 is about a validation algorithm. Different rules may apply
to every trust anchor and to the CA certificates from the certification
path under every trust anchor. The ASN.1 description of ValidationPolicy
starting on page 17 does not allow the client to define CA related
different parameters for every trust anchor.

We currently have:

ValidationPolicy ::= SEQUENCE {
        validationPolRef          ValidationPolRef,
        validationAlg         [0] ValidationAlg OPTIONAL,
        userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
        IDENTIFIER OPTIONAL,
        inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
        requireExplicitPolicy [3] BOOLEAN OPTIONAL,
        inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
        trustAnchors          [6] TrustAnchors OPTIONAL,
        keyUsages             [7] KeyUsages OPTIONAL,
        extendedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL}

and

ValidationAlg ::= SEQUENCE {
        valAlgId              OBJECT IDENTIFIER,
        parameters            ANY DEFINED BY valAlgId OPTIONAL }

If:
        trustAnchors          [6] TrustAnchors OPTIONAL,

is changed into:

        trustAnchor          [6] TrustAnchor OPTIONAL,

  ... then this would be conformant with the algorithm from section 6.1 of
RFC 3280, but validation policies with multiple trust anchors and their
own parameters could not be used.

The conditions that apply to CA certificates may be very complicated and
vary from one trust anchor to another. The goal if this document is to
support section 6.2 from FRC 3280.

A validation policy could OPTIONALLY include several “target certificate
specific parameters” as Wen-Cheng proposed, since they usually do not
change from one trust anchor to another.

This would also solve the problem that Wen-Cheng noticed about the “name
validation algorithm”.

Note that, as Wen-Cheng proposed, “target certificate” seems to be a
better term rather than “end certificate”

It is obvious that for each certification path, the algorithm from
section 6.1 of RFC 3280 is being used. The validationAlg parameter is not
needed. We could then simply have:

ValidationPolicy ::= SEQUENCE {
        validationPolRef          ValidationPolRef,
        keyUsages                [0] KeyUsages OPTIONAL,
        extendedKeyUsages        [1] SEQUENCE OF KeyPurposeId OPTIONAL,
        nameValidationAlgParms   [2] NameValidationAlgParms OPTIONAL,
        otherTests               [3] OtherTests OPTIONAL
    }

additionalTests could be used for example to test QCStatements extensions
presence and values, which would be very useful for Qualified
Certificates.


5.Section 1.5 states: “However, revocation checking is an optional
feature in [PKIX-1], ... ” This is incorrect.

RFC 3280 does not say that revocation checking is optional. Only CRLs
processing is defined in RFC 3280 but we all know that OCSP is an
alternative method. For DPV, revocation checking MUST be done to validate
a certification path, but this may be done using different means. This
means may be specified in the validation policy.


6. It should be remembered that RFC 3379 makes the separation between DPV
and DPD, while this document defines a single protocol for both of them.
At the minimum the document should be profiled so that implementers may
choose to support only DPV and not be forced to support also DPD.


7. “SCVP” is a not a good name when the request is to only build a
certification path - with or without revocation status (i.e. DPD, leaving
the validation to the client). The certificate is not VALIDATED by the
server, and even if it would, the client would not trust it. If someone
says : “I support SCVP”, how could it make clear that it only supports
the DPV variant of it ?

Better names would be:

  - DPVP: Delegated Path Validation Protocol, and
  - DPDP: Delegated Path Discovery Protocol.


8. The text correctly states on page 6: “An SCVP request needs only to
contain the certificate to be validated, the referenced validation
policy, and any run-time parameters for the request”.

It would be very beneficial to be able to have implementations that only
support the above requirements for DPV, leaving the security protection
(i.e. integrity) to the communication link (i.e. using TLS) and not
supporting other parameters (with the exception of the above optional
“target certificate specific parameters” as Wen-Cheng proposed). It is
currently not straightforward to derive from the current document a
profile for this.

It is suggested to revise the document so that this goal can be achieved
and that conformance clauses are added to be able to say that a given
implementation is conformant to this aspect only.

Additional comments (up to page 8 only) follow.


9. Page 5. Section 1. Second paragraph. The text states:

    The first class of applications wants just two things: confirmation
    that the public key belongs to the identity named in the certificate
    and confirmation that the public key can be used for the intended
    purpose.

This is not the main goal. Rephrase as:

    The first class of applications wants just confirmation
    that the certificate is valid according a given validation policy.


10. Page 5. Section 1. Second paragraph. The text states:

    The second class of applications can perform certification path
    validation, but they lack a reliable or efficient method of
    constructing a valid certification path.

Rephrase as:

    The second class of applications can perform certification path
    validation, but they lack a reliable or efficient method of
    constructing a valid certification path and the associated
    revocation status information.


11. Page 5. Section 1.1. Second paragraph.

    The primary goals of SCVP are to make it easier to deploy PKI-enabled
    applications and to allow central administration of PKI policies
    within an organization.

Rephrase as:

    The primary goals of SCVP are to make it easier to deploy PKI-enabled
    applications and to allow a server to support one or more validation
    policies against which certificates can be tested by applications.


12. Page 5. Section 1.1. Second paragraph.

    SCVP can be used by clients that do much of
    the certificate processing themselves but simply want an untrusted
    server to collect information for them.  However, when the client has
    complete trust in the SCVP server, SCVP can be used to delegate the
    work of certification path construction and validation, and SCVP can
    be used to ensure that policies are consistently enforced throughout
    an organization.

Rephrase as:

    SCVP, used for DPV, can be used by clients that have complete trust
    in a trusted DPV server. In such a case, the protocol can be used to
    delegate the work of certification path construction and validation.

    SCVP, used for DPD, can be used by clients that do much of
    the certificate processing themselves but simply want an untrusted
    DPD server to collect information for them.


Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RID4Id058320; Sun, 27 Feb 2005 10:13:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1RID43l058319; Sun, 27 Feb 2005 10:13:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RID3xA058312 for <[e-mail]>; Sun, 27 Feb 2005 10:13:04 -0800 (PST) (envelope-from [e-mail])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Sun, 27 Feb 2005 19:06:05 +0100
Received: from [10.193.106.67] ([10.193.106.67]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Sun, 27 Feb 2005 19:06:04 +0100
Message-ID: <[e-mail]>
Date: Sun, 27 Feb 2005 19:06:03 +0100
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom - Research & Development
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050111
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Comments to SCVP ID 18
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Feb 2005 18:06:04.0809 (UTC) FILETIME=[00EEFF90:01C51CF7]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester wrote:
> I am not quite sure to understand the motivations and
> goals for the ASN.1 changes because the result seems
> still somewhat strange.
> 
> Either one should use context specific tags in all sequences/choices
> or a minimal set
> 
> instead of 
>    Query ::= SEQUENCE {
>      queriedCerts             CertReferences,
>      checks                   CertChecks,
>      wantBack                 WantBack,
>      validationPolicy         ValidationPolicy,
>      responseFlags            ResponseFlags OPTIONAL,
>      serverContextInfo    [2] OCTET STRING OPTIONAL,
>      validationTime       [3] GeneralizedTime OPTIONAL,
>      intermediateCerts    [4] CertBundle OPTIONAL,
>      revInfos             [5] RevocationInfos OPTIONAL,
>      producedAt           [6] GeneralizedTime OPTIONAL,
>      queryExtensions      [7] Extensions OPTIONAL }
> 
> Why not starting with [4711] (followed by [48] as you might know)?
> 
> one could have
> 
>    Query ::= SEQUENCE {
>      queriedCerts             CertReferences,
>      checks                   CertChecks,
>      wantBack                 WantBack,
>      validationPolicy         ValidationPolicy,
>      responseFlags            ResponseFlags OPTIONAL,
>      serverContextInfo        OCTET STRING OPTIONAL,
>      validationTime           GeneralizedTime OPTIONAL,
>      intermediateCerts    [0] CertBundle OPTIONAL,
>      revInfos             [1] RevocationInfos OPTIONAL,
>      producedAt           [2] GeneralizedTime OPTIONAL,
>      queryExtensions      [3] Extensions OPTIONAL }

Why not stick "AUTOMATIC TAGS" in the module header and not bother with 
tag values?
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RIBZkR058252; Sun, 27 Feb 2005 10:11:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1RIBZ4H058251; Sun, 27 Feb 2005 10:11:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RIBXiD058225 for <[e-mail]>; Sun, 27 Feb 2005 10:11:34 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j1RIBKn06302; Sun, 27 Feb 2005 19:11:20 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sun, 27 Feb 2005 19:11:20 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j1RIBJM02137; Sun, 27 Feb 2005 19:11:19 +0100 (MET)
Date: Sun, 27 Feb 2005 19:11:19 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: SCVP Draft 17: Summary of changes
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

subject should be version 18. 

> >  Is there a particular reason to have a NULL in the keyusages and not just
> >  an empty sequence as here?
> >
> Yes.  extendedKeyUsages is defined as a sequence in which the end 
> certificate must satisfy ALL of the elements of the sequence.  If the 
> sequence if empty, then the end certificate trivially satisfies this.
> 
> keyUsages is defined as a sequence in which the end certificate must 
> satisfy AT LEAST ONE of the elements of the sequence.  If the sequence 
> were empty, it would not be possible for the certificate to satisfy at 
> least one element from the sequence.

Not only in mathematics a red herring may neither be red nor a herring. An empty
set trivially full fills any condition. 

> So, using "SEQUENCE OF KeyUsage" would not have worked for keyUsages.  
> We could have used a structure similar to the KeyUsages for extended key 
> usages, but the current structure is simpler and works just as well.

   SEQUENCE OF KeyUsage SIZE(0..MAX)

is certainly smaller text than KeyUsages.

I am saying the coding an empty sequence is technically equivalent to
coidng the null choice. Anyway, not too important since the size of the
encoding is the same, just the tag would be different, i.e.

   0500 instead of 3000

But, since the CHOICE forces the tag to be explicit, there are always two
additional 2 octets.

In fact what is happening here is typical for many texts in PKIX where
one interpretes and encoding instead of defining abstract indications
and then the encodings.definition and the interpretation of an encoding.

As an example, the text could go like this:

A client has three ways to indicate to the server what processing it
like to be performed concerning keyUsage. 

- Accept policy default processing for keyUsage
  The client informs the server that the default processsing defined
  in the server policy can be used with no additional parameters.

  To encode this, the client does not code the field XXX.

- Accept any keyusage
  The client informs the server that no checks concerning keyUsage
  should be performed.
  The client indicates this by coding an empty sequence of field XXX.

- Required keyusage pattern
  The client indicates to the server a set of bitstrings structures
  in the same way as keyusages, and requires at least one of the
  elements to match with the keyusage in the certificate, where
  match means that for any bit set to 1 in the indication element
  the corresponding bit in the certificate's keyusage is also set to 1.

  The client codes this by setting a non empty SEQUENCE. The order
  of elements in the sequence has no meaning.

Note that the abstract indication three was a SET, so if I follow
you argumentation the ASN1 should have a SET. 


> I had actually been tempted to change requestorRef to be a sequence of 
> GeneralName since GeneralName seemed to be more appropriate than OCTET 
> STRING for something that was supposed to hold an identifier.  A side 
> effect of this change is that it would have specified the encodings for 
> the identifiers as well.  However, there was a comment submitted for 
> draft 16 indicating a need to be able to use a hash value as an 
> identifier in requestorRef, an option that would have been effectively 
> precluded if OCTET STRING had been changed to GeneralName.  Since I 
> could not justify preventing use of a hash value and one can easily 
> encode any GeneralName value in an OCTET STRING, I left the syntax for 
> requestorRef unchanged.

Since you could not justify it, well then, yes, that's important ... :) 
And, you didn't even feel that this would have been worth to be
discussed a little bit.

There is nothing in 3379 that requires that you must be able to encode
a hash value. 
   
> I think this is more of a theoretical concern than a practical concern.  
> The odds that two servers that are part of the same SCVP relay network 
> would select different identifiers for use in requestorRef, but that as 
> a result of using different encoding techniques the encoded versions of 
> their names are the same are extremely small.

There are also various ways to encode a hash value into a GeneralName,
so it is wrong that this has been effectively precluded. Waht IS actually
precluded is that these identifiers can have a structure following any
global name space and you have no collisions using encoding. 

...

> I believe that SCVP already includes all of the basic fields needed to 
> support relay.  I don't believe that the base document needs to say any 
> more.  When a server implements relay, it sends out an CVRequest and 
> gets back a CVResponse just as a normal client would.  Guidance on what 
> queries a server should send and what it should do with the response is 
> just that.  Guidance on how to use a particular feature does not need to 
> be in the base standard, it can be in a separate informational 
> document.  If there is a desire for SCVP servers that implement relay to 
> exchange auxiliary information, that information can always be included 
> in non-critical response extensions.  So, I can not see any reason to 
> hold up the base standard.  There are too many people who need this 
> standard to be completed and who can use it even without guidance on how 
> to implement relay.

There is no exchange of AUXILIARY information. The requirements say
clearly that the client can request that the server returns ALL
information. The base text allows for relaying.

The current text does not honor this requierement of 3379. 

what you are suggesting, is to totally ignore relaying in the base
document which is contrary to what had been announced by Trevor, i.e. 
to specify how a relay would act, nothing had been changed. 
After having discussed that this is needed several months ago, 
and with agreement from Trevor, it is really surprising that
you haven't made your observation earlier.

Thus, as you admit, the text does not at all contain information about how 

- a relay should take a request from a client and transform it into
  a request to another server;
  At least it is already said one modification is to add the loop
  control.

- the result of the request could be returned as is with just the
  security envelope changed. But then the client does not have
  the important information required to show to a third party.
  
  one could just make a second signature in this case, 
  a counter-signature, or, when the client can authenticate the
  response from the relay, the response can be returned as is,
  i.e. with the signature from the second server.
  THIS is not possible with the current text because it is
  restrictive regarding the various authentication modes.

- Not having the ability to include a DPV response in a request/response
  similar to any other revocation information can easily be
  changed by one other type.

It is not ME who is holding the text, you, the authors are not
doing what you promised. And, if you have changed your mind,
you could have said this earlier.

peter

PS: I don't think that with a few additions the text can go
but if they are not made, fixing it might get very clumsy. 
Otherwise we would have OCSPv2 since years. 

  


  



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RI4bHc057942; Sun, 27 Feb 2005 10:04:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1RI4aOj057941; Sun, 27 Feb 2005 10:04:36 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RI4ZpO057921 for <[e-mail]>; Sun, 27 Feb 2005 10:04:36 -0800 (PST) (envelope-from [e-mail])
Received: from ftrdmel10.rd.francetelecom.fr ([10.193.117.156]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Sun, 27 Feb 2005 19:03:51 +0100
Received: from [10.193.106.67] ([10.193.106.67]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.211); Sun, 27 Feb 2005 19:03:50 +0100
Message-ID: <[e-mail]>
Date: Sun, 27 Feb 2005 19:03:49 +0100
From: Olivier Dubuisson <[e-mail]>
Organization: France Telecom - Research & Development
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20050111
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Comments to SCVP ID 17
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Feb 2005 18:03:50.0838 (UTC) FILETIME=[B114A560:01C51CF6]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester wrote:
>>>We set a DEFAULT value wherever we could do so without adding any
>>>more explicit tagging.  So, DEFAULT version numbers were set in
>>>CVRequest and ValPolRequest, but not CVResponse or ValPolResponse.
> 
> 
> ... Which can be easily achieved also by switching the order, for
> example 
> 
>      CVResponse ::= SEQUENCE { 
>        cvResponseVersion         INTEGER DEFAULT v1(1) ,

The syntax of the default value is wrong. It shall be "1" (or "v1" if 
"v1" is an INTEGER value defined elsewhere in the ASN.1 module).

>        producedAt                GeneralizedTime, 
>        policyID                  INTEGER, 
-- 
Olivier DUBUISSON
France Telecom
Recherche & Developpement
R&D/MAPS/AMS - 22307 Lannion Cedex - France
t: [phone] - f: [phone] - http://asn1.elibel.tm.fr/




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RGZfCH053196; Sun, 27 Feb 2005 08:35:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1RGZfmR053195; Sun, 27 Feb 2005 08:35:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RGZea3053185 for <[e-mail]>; Sun, 27 Feb 2005 08:35:40 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j1RGZQn05136 for <[e-mail]>; Sun, 27 Feb 2005 17:35:26 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sun, 27 Feb 2005 17:35:26 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j1RGZQG01907 for [e-mail]; Sun, 27 Feb 2005 17:35:26 +0100 (MET)
Date: Sun, 27 Feb 2005 17:35:26 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Comments to SCVP ID 18
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am not quite sure to understand the motivations and
goals for the ASN.1 changes because the result seems
still somewhat strange.

Either one should use context specific tags in all sequences/choices
or a minimal set

instead of 
   Query ::= SEQUENCE {
     queriedCerts             CertReferences,
     checks                   CertChecks,
     wantBack                 WantBack,
     validationPolicy         ValidationPolicy,
     responseFlags            ResponseFlags OPTIONAL,
     serverContextInfo    [2] OCTET STRING OPTIONAL,
     validationTime       [3] GeneralizedTime OPTIONAL,
     intermediateCerts    [4] CertBundle OPTIONAL,
     revInfos             [5] RevocationInfos OPTIONAL,
     producedAt           [6] GeneralizedTime OPTIONAL,
     queryExtensions      [7] Extensions OPTIONAL }

Why not starting with [4711] (followed by [48] as you might know)?

one could have

   Query ::= SEQUENCE {
     queriedCerts             CertReferences,
     checks                   CertChecks,
     wantBack                 WantBack,
     validationPolicy         ValidationPolicy,
     responseFlags            ResponseFlags OPTIONAL,
     serverContextInfo        OCTET STRING OPTIONAL,
     validationTime           GeneralizedTime OPTIONAL,
     intermediateCerts    [0] CertBundle OPTIONAL,
     revInfos             [1] RevocationInfos OPTIONAL,
     producedAt           [2] GeneralizedTime OPTIONAL,
     queryExtensions      [3] Extensions OPTIONAL }


instead of 

   CVRequest ::= SEQUENCE {
     cvRequestVersion           INTEGER DEFAULT 1,
     query                      Query,
     requestorRef           [0] SEQUENCE SIZE (1..MAX) OF OCTET STRING
     requestNonce           [1] OCTET STRING OPTIONAL,
     requestorName          [2] GeneralName OPTIONAL,
     reqestExtensions       [3] Extensions OPTIONAL }

one could have 

   CVRequest ::= SEQUENCE {
     cvRequestVersion           INTEGER DEFAULT 1,
     query                      Query,
     requestorRef               SEQUENCE SIZE (1..MAX) OF OCTET STRING
     requestNonce               OCTET STRING OPTIONAL,
     requestorName              GeneralName OPTIONAL,
     reqestExtensions       [0] Extensions OPTIONAL }


instead of 

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

one could have 

   CVResponse ::= SEQUENCE {
     cvResponseVersion          INTEGER DEFAULT 1,
     responseStatus             ResponseStatus,
     producedAt                 GeneralizedTime,  -- maybe OPTIONAL
     policyID                   INTEGER OPTIONAL,
     respValidationPolicy       RespValidationPolicy OPTIONAL,
     requestRef             [0] RequestReference OPTIONAL,
     requestorRef           [1] SEQUENCE SIZE (1..MAX) OF OCTET STRING
                                  OPTIONAL,
     requestorName          [2] GeneralNames OPTIONAL,
might be requestorNames

     replyObjects           [3] ReplyObjects OPTIONAL,
     respNonce              [4] OCTET STRING OPTIONAL,
     serverContextInfo      [5] OCTET STRING OPTIONAL,
     cvResponseExtensions   [6] Extensions OPTIONAL }

here I think the policyID should be optional since in case
of sime internal error the server may not be able to provide
it. (one could argue also for producedAt)

(modulo my request to add simple object addressing peremeters,
 i.e. to also have a responderName GeneralNames structure in
 both request and response and to change the requesterName in
 the request to be GeneralNames, at least the latter)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RFuUD7051677; Sun, 27 Feb 2005 07:56:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1RFuUbW051676; Sun, 27 Feb 2005 07:56:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RFuTmw051670 for <[e-mail]>; Sun, 27 Feb 2005 07:56:29 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j1RFuSn04825 for <[e-mail]>; Sun, 27 Feb 2005 16:56:28 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sun, 27 Feb 2005 16:56:28 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j1RFuRH01828 for [e-mail]; Sun, 27 Feb 2005 16:56:27 +0100 (MET)
Date: Sun, 27 Feb 2005 16:56:27 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Comments to SCVP ID 17
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >We set a DEFAULT value wherever we could do so without adding any
> >more explicit tagging.  So, DEFAULT version numbers were set in
> >CVRequest and ValPolRequest, but not CVResponse or ValPolResponse.

... Which can be easily achieved also by switching the order, for
example 

     CVResponse ::= SEQUENCE { 
       cvResponseVersion         INTEGER DEFAULT v1(1) , 
       producedAt                GeneralizedTime, 
       policyID                  INTEGER, 

'explicit' is not the right term here. 

And furthermore there are other places where universal tags
can still be used at the place of context specific tags,

> I still believe that it is better to group "name checking", "key usage checking"
> and "extended key usage checking" into the category of "end/target certificate
> requirements". This is not a simply a stylistic change. It is a matter of logicalness
> of the protocol design. However, if we are really running out of time, I can live
> with "the basic validation algorithm with name validation".

We were running out of time 2 years ago. Everything was already settled in draft 12
as far as I remember the Vienna meeting. :) I just remind that the
text was totally un-implmentable at that time. 
 

... some text removed, I mostly share Wen-Cheng Wang's views. 

>  
> The point is a validation policy can imply a validation algorithm, and therefore
> the notion of validation algorithm can be removed from SCVP.

The "small" problem is that you need to specify the parameters even for 
example the name validation algorithm. 

The validation algo OID is used to define the syntax for these parameters. 
Denis gave another way

> 
> The current SCVP syntax and semantics only support validating certificates against
> a retrospective moment. Please not that it is not the same to say "a certificate is
> valid at time t1" as to say "a certificate is valid before time t1", because the validity of
> the certificate could be suspended and then resumed before time t1. It is certainly
> different with "a certificate is valid from time t2 to time t1".

Suspended doesn't mean revoked, if a suspended cert gets resumed, then I don't
think that someone really requires "You may still use it now, but anything
you have done within the time it was suspended (and which has still not
been tested!!), will be considered as invalid." 

The time intervals in question are also not really long.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RFqciP051566; Sun, 27 Feb 2005 07:52:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1RFqciH051565; Sun, 27 Feb 2005 07:52:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RFqRht051545 for <[e-mail]>; Sun, 27 Feb 2005 07:52:28 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j1RFq2n04789; Sun, 27 Feb 2005 16:52:02 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Sun, 27 Feb 2005 16:52:02 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j1RFq0k01815; Sun, 27 Feb 2005 16:52:00 +0100 (MET)
Date: Sun, 27 Feb 2005 16:52:00 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: Re: Comments to SCVP ID 17
Cc: [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Peter,
> 
> Quoting Peter Sylvester <[e-mail]>:
> 
> >  Long ago I explained probably even in this list
> >  a difference between French and German behaviour.
> 
> I had forgotten this one.  Thanks for reviving it!

Anyway, you have not understood that I was really inviting you 
to read all of Denis' comments with an appropriate understanding 
of the diplomatic decorations. 

Thant's not the only thing you have forgotten. I have
counted exactly but it seems alost 1 out of 2 that
you announce 2 weeks deadlines or so just before
an IETF meeting. You had been reminded that this 
is not exactly an appropriate way, and you promised
not to repeat, well.

 
> > > Consider your message deleted.
> > 
> > I think you should at least consider point 16 :-)
> > 
> > Peter
> > 
> 
> I was intrigued by your reference to Denis' point 16, so I went to the archive 
> for the message and searched for "16."  Upon reading the last screen, numbers 
> 14 and 16 merit a response.  
> 
> > 14. Since both one of the security area directors and one of the co-
> >  chairs of PKIX are editors, I request that both the other security area
> >  director and the other PKIX co-chair take a look at the debate: Tim, the
> >  over-ever optimistic, being both editor of the draft and PKIX co-chair
> >  cannot be in a position to say when a rough consensus will be reached.
> 
> I am sure that Steve will be glad to judge consensus.  And yes, when the 
> document is forwarded, it has to go to Sam Hartman.

I understandt that we can consider then your other message concerning 
another announcement for deadline as obsolete. Modify my comment
above acordingly.   

Peter

PS: not having commented Denis' and Wen-Cheng's messages does not
mean that I disagree with them (at least not with all of them).




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RAPmgl036619; Sun, 27 Feb 2005 02:25:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1RAPmqr036618; Sun, 27 Feb 2005 02:25:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from lon1-mail-2.visp.demon.net (IDENT:[e-mail] [193.195.70.5]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1RAPaQV036603 for <[e-mail]>; Sun, 27 Feb 2005 02:25:45 -0800 (PST) (envelope-from [e-mail])
Received: from [80.5.216.209] (cpc1-hudd3-5-0-cust209.hudd.cable.ntl.com [80.5.216.209]) by lon1-mail-2.visp.demon.net (MOS 3.4.6-GR) with ESMTP id BZX67372 (AUTH [e-mail]); Sun, 27 Feb 2005 10:23:37 GMT
Message-ID: <[e-mail]>
Date: Sun, 27 Feb 2005 10:23:33 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: EuroPKI workshop
Content-Type: multipart/mixed; boundary="------------000903080707060300070003"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------000903080707060300070003
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Dear All

please find below the fourth call for papers for the EuroPKI workshop.

Unfortunately the third call, which was distributed approx 2 weeks ago
to the PKIX list, was trapped by the list manager because it contained a
large PDF attachment, and I was only notified today that the message was
never actually sent to the list. We have therefore extended the deadline
by a couple of days to allow PKIX members to submit a paper if they have
one.

I am glad to announce that Carlisle Adams will be giving the keynote
speech. So put the dates, 31 June-1 July in your diaries, and submit a
paper if you have one.

Regards

David

--------------000903080707060300070003
Content-Type: text/plain;
 name="2nd_EuroPKI_Workshop_4th_CfP.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="2nd_EuroPKI_Workshop_4th_CfP.txt"

2nd  EURO_PKI
2nd European PKI Workshop
Research and Applications


 

30 June- 1 July 2005, Canterbury, United Kingdom		

http://sec.cs.kent.ac.uk/europki2005/

Fourth Announcement and Call for Papers

The 2nd European PKI Workshop: Research and 
Applications is focusing on research and applications on 
all aspects of Public Key Infrastructure. Submitted papers 
may present theory, applications or practical experiences 
on topics including, but not limited to:

Modeling and Architecture 	
Key Management and Recovery
Bridge CA	
Certificate Status Information
Cross Certification	
Interoperability
Directories	
Repository Protocols
Mobile PKI	
Timestamping
Authentication
Authorisation	
Verification
Reliability in PKI 	
Standards
Certificate Policies and Certification Practice Statements
Privacy	Legal issues, Policies & Regulations
Fault-Tolerance in PKI	
Case Studies
Privilege Management	
Trust
PKI and eCommerce, eBusinees, eGovernment applications

Instructions for paper submission

The Workshop welcomes original papers from academic, 
government, and industry contributors dealing with the 
above or related issues. Papers, which describe ongoing 
research or provide an excellent surveying work, are 
welcome too. All submissions will be subjected to a 
thorough blind review by at least three reviewers. Papers 
should be up to 6000 words in English, including 
bibliography and well-marked appendices. Accepted 
papers will be presented at the Workshop and published in 
the Proceedings by Springer in Lecture Notes in 
Computer Science series 
(http://www.springeronline.com/lncs). 

The Proceedings will be distributed to the Workshop attendees. At least one 
author of each accepted paper is required to register with 
the Workshop and present the paper. To submit a paper, go 
to the conference web site 
(http://sec.cs.kent.ac.uk/europki2005/) and follow the 
instructions posted on the Instructions for Authors page 

Important dates
Submission of papers:	March 1st 2005 

Notification to authors: March 27, 2005

Camera-ready copies:	April 10, 2005 April 12, 2005





--------------000903080707060300070003--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PNSbSY023798; Fri, 25 Feb 2005 15:28:37 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PNSbM8023796; Fri, 25 Feb 2005 15:28:37 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PNSO1w023782 for <[e-mail]>; Fri, 25 Feb 2005 15:28:24 -0800 (PST) (envelope-from [e-mail])
Received: from 211.18.251.169 ([211.18.251.169]) by csexchange1.corestreet.com ([192.168.6.14]) with Microsoft Exchange Server HTTP-DAV ; Fri, 25 Feb 2005 23:31:48 +0000
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: About RFC 3280bis
Thread-Topic: About RFC 3280bis
Thread-Index: AcUbdOgDLLn/5qUcTHGQy/meJdzJYQAHTzkP
From: Dave Engberg <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>, <[e-mail]>
To: Stephen Farrell <[e-mail]>, <[e-mail]>
Cc: pkix <[e-mail]>
Message-ID: <8824C228-51E1-423D-902F-2869DBF12B9D@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.7232.34
X-MimeCtl: Produced By Microsoft Exchange V6.5.7232.34
Date: Fri, 25 Feb 2005 18:31:34 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<HTML><HEAD><TITLE>Re: About RFC 3280bis</TITLE></HEAD>
<BODY>
<DIV id=3DidOWAReplyText54195 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2></FONT>&nbsp;</D=
IV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Artificially large serial number=
s create some negative performance implications.&nbsp; The CRLs produced by=
 CAs (RSA, VeriSign, MS) that overload their serial numbers are frequently =
50% larger than those who issue low, sequential (aka "serial") numbers (Net=
scape, UniCert, etc.).&nbsp; This can translate into extra minutes of waiti=
ng every day&nbsp;for users in large PKIs.&nbsp; If the US DoD followed thi=
s recommendation, their CRLs would increase by more than 20MB.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>While this serial number overloa=
ding is syntactically permitted under the spec, I don't think the RFC needs=
 to encourage this behavior unless there's absolutely no alternative to pre=
vent an imminent SHA-1 meltdown.&nbsp; I'd prefer to see a SHA-1 solution t=
hat generalized to all of the other signatures people use (CRLs, documents,=
 emails, OCSP, etc.).</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Stephen Farrell<BR><B>Sent:</B> F=
ri 2/25/2005 2:24 PM<BR><B>To:</B> [e-mail]<BR><B>Cc:</B> pkix<BR><B>=
Subject:</B> Re: About RFC 3280bis<BR></FONT><BR></DIV>
<DIV><BR>
<P><FONT size=3D2>I did spot one possible future change - the serial number=
s<BR>of the sample certificates are small (decimal 17,18,256). One<BR>of th=
e suggestions I've seen made for handling potential<BR>hashing weaknesses w=
as to prepend some randomness to those.<BR>*If* (and I don't believe we yet=
 know...I certainly don't) this<BR>is sound guidance then we could reflect =
it in the samples (and<BR>I guess also the security considerations). Someth=
ing to think<BR>about for later maybe. Actually, since large serial numbers=
<BR>are pretty common, having at least one sample with a long<BR>serial num=
ber would seem like a good idea in any case.<BR></FONT></P></DIV></BODY></H=
TML>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PN1QI7021972; Fri, 25 Feb 2005 15:01:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PN1QFf021971; Fri, 25 Feb 2005 15:01:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PN15IJ021918 for <[e-mail]>; Fri, 25 Feb 2005 15:01:06 -0800 (PST) (envelope-from [e-mail])
Received: from real2.localdomain ([192.168.2.11]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1PN0oa3018713; Fri, 25 Feb 2005 18:00:50 -0500
Received: from real2.localdomain (real2.localdomain [127.0.0.1]) by real2.localdomain (8.12.8/8.12.8) with ESMTP id j1PN0oF6019114; Fri, 25 Feb 2005 18:00:50 -0500
Received: (from apache@localhost) by real2.localdomain (8.12.8/8.12.8/Submit) id j1PN0nXp019112; Fri, 25 Feb 2005 18:00:49 -0500
Received: from pool-141-156-40-37.res.east.verizon.net (pool-141-156-40-37.res.east.verizon.net [141.156.40.37])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Fri, 25 Feb 2005 18:00:49 -0500
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2005 18:00:49 -0500
From: [e-mail]
To: Peter Sylvester <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Comments to SCVP ID 17
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 141.156.40.37
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Quoting Peter Sylvester <[e-mail]>:

>  Long ago I explained probably even in this list
>  a difference between French and German behaviour.

I had forgotten this one.  Thanks for reviving it!

> > Consider your message deleted.
> 
> I think you should at least consider point 16 :-)
> 
> Peter
> 

I was intrigued by your reference to Denis' point 16, so I went to the archive 
for the message and searched for "16."  Upon reading the last screen, numbers 
14 and 16 merit a response.  

> 14. Since both one of the security area directors and one of the co-
>  chairs of PKIX are editors, I request that both the other security area
>  director and the other PKIX co-chair take a look at the debate: Tim, the
>  over-ever optimistic, being both editor of the draft and PKIX co-chair
>  cannot be in a position to say when a rough consensus will be reached.

I am sure that Steve will be glad to judge consensus.  And yes, when the 
document is forwarded, it has to go to Sam Hartman.

>  16. Finally, note also that, unless I can finally agree on the document,
>  I do not want to have my name placed in the acknowledgments section as it
>  is currently mentioned, since, at this time, I am not *in any way*
>  supportive of this monument.

We will certainly honor anyone's requests to remove their (own) name from the 
acknowledgements section.

Tim Polk




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PL8Gjb011922; Fri, 25 Feb 2005 13:08:16 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PL8Gju011921; Fri, 25 Feb 2005 13:08:16 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PL8ASt011907 for <[e-mail]>; Fri, 25 Feb 2005 13:08:11 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1PL72DD000876; Fri, 25 Feb 2005 16:07:02 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1PL6YEY006074; Fri, 25 Feb 2005 16:06:34 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 25 Feb 2005 16:07:25 -0500
To: <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: One final week of Last Call for SCVP
Cc: "Michael Myers" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

In my opinion, SCVP draft -18 satisfies all requirements specified in RFC 
3379.  I also believe that this draft has rough consensus within the 
WG.  We have endured a rather arduous process, beginning with a -00 draft 
in 1999 and a long requirements specification process in the middle of it 
all.  More recently, we have worked through deadlines for comment 
submission and a very thorough review and editorial process to address 
those comments.  While unanimous consensus has certainly *not* been 
achieved, messages I have received both on and off list indicate general 
satisfaction with this document.

Mike's message provided the motivation to "start the clock ticking" to 
progression out of the WG. SCVP has been in "Last Call" forever, so another 
two weeks of Last Call is not actually required.  However, we should allow 
some time for those members who forgot we were in Last Call to weigh in.  I 
believe one more week should be sufficient to review and comment.

So, unless the mail on the list clearly demonstrates that rough consensus 
has not been achieved, I intend to forward this document to the AD next 
Friday.  Note that I will not consider the number of messages, their 
length, or the amount of venom when determining rough consensus, only the 
number of different submitters.

Tim Polk

At 10:54 AM 2/25/2005 -0700, Michael Myers wrote:
>All,
>
>I reaffirm my opinion that the WG has amply done its work on this
>important document.  It would be good to see the clock start ticking on
>a two-week WG last call.
>
>The phrase "rough consensus" is by definition ambiguous.  However, the
>distinction between "rough consensus" and "unanimous consent" is
>self-evident.
>
>Mike



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PJNAos004664; Fri, 25 Feb 2005 11:23:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PJNA5f004663; Fri, 25 Feb 2005 11:23:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PJMuHo004642 for <[e-mail]>; Fri, 25 Feb 2005 11:23:09 -0800 (PST) (envelope-from [e-mail])
Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with ESMTP id 433C314C013; Fri, 25 Feb 2005 19:22:40 +0000 (GMT)
Received: from smtp3.tcd.ie by localhost.localdomain (VaMailArmor-2.0.1.16) id 07735-067C3E53; Fri, 25 Feb 2005 19:22:40 +0000
Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id 0B67014C013; Fri, 25 Feb 2005 19:22:31 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2005 19:24:04 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Cc: pkix <[e-mail]>
Subject: Re: About RFC 3280bis
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.7; VDF: 6.29.0.101; host: smtp3.tcd.ie)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

I totally agree!

And since I hadn't done it since -00 was posted, I just
did a quick flick through that html and it took about 30
minutes, start to finish. I didn't read all the changes, but
I think I'd have a reasonable chance of spotting a red flag.
If enough people do that, then I think we can be fairly
confident that the changes are sound, and that we've
improved on 3280.

(And btw - nice work from David, that's some size of a
document to be editing!)

I did spot one possible future change - the serial numbers
of the sample certificates are small (decimal 17,18,256). One
of the suggestions I've seen made for handling potential
hashing weaknesses was to prepend some randomness to those.
*If* (and I don't believe we yet know...I certainly don't) this
is sound guidance then we could reflect it in the samples (and
I guess also the security considerations). Something to think
about for later maybe. Actually, since large serial numbers
are pretty common, having at least one sample with a long
serial number would seem like a good idea in any case.

Stephen.


[e-mail] wrote:

> I certainly agree that no one has the time to read all of 3280bis these days, 
> and that it is important to provide the set of changes in a straightforward 
> manner.  However, it was very difficult to convey the complete context of the 
> proposed changes without showing how they would impact the current text.   
> Describing the changes out of context and rolling them in later would surely 
> result in repetitive debates, and I personally don't see the value in arguing 
> every issue twice.  To ensure that the complete impact of all changes were 
> accurately conveyed, we felt the need to create a 3280bis draft.
> 
> To facilitate an efficient review by WG members that are already familiar with 
> 3280, the editor also has provided an html diff file that shows all changes 
> from 3280 to 3280bis. As noted earlier on list, this file is available at
> 
> http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html
> 
> The html diff file clearly identifies every change (deletions are in red and 
> strikethrough, insertions are in green) so no one should have to read the 
> entire document or spend cycles figuring out which sections were, or were not, 
> modified.
> 
> Tim Polk
> 
> Quoting Denis Pinkas <[e-mail]>:
> 
> 
>>Paul Hoffman said on the list on November 8:
>>
>>"Instead of starting rfc3280bis, start a draft called something like
>>"rfc3280-changes". Have that draft be short, and contain *only*
>>changes to 3280. Only after there is consensus on the -changes draft
>>should you roll the changes in.
>>
>>No one reads all of 3280 these days, so expecting people to search
>>through rfc3280bis for different sections is not reasonable".
>>
>>I was fully agreeing with him and since I saw no neagtive response from the 
>>co-editors, I thought this was granted.
>>
>>Then what happened ? Exactly the opposite !
>>
>>What is the PKIX mailing list for, if the co-editors ignore such messages 
>>from the list ?
>>
>>Can we finally have these rfc3280-changes, the list of comments received and
>>
>>their proposed resolution, BEFORE we can start reading the new draft ?
>>
>>Denis
>>
>>-------- Original Message --------
>>Subject: Re: Suggestion for revising RFC 3280
>>Date: Mon, 08 Nov 2004 13:42:12 -0500
>>From: "Sean P. Turner" <[e-mail]>
>>Organization: IECA, Inc.
>>To: Paul Hoffman / VPNC <[e-mail]>
>>CC: [e-mail]
>>References: <p06110406bda564ea5155@[10.20.30.249]>
>>
>>
>>Or at least have a paragraph that gets removed prior to RFC publication
>>to tell everybody where changes were made.
>>
>>spt
>>
>>Paul Hoffman / VPNC wrote:
>>
>> >
>> > Instead of starting rfc3280bis, start a draft called something like
>> > "rfc3280-changes". Have that draft be short, and contain *only*
>> > changes to 3280. Only after there is consensus on the -changes draft
>> > should you roll the changes in.
>> >
>> > No one reads all of 3280 these days, so expecting people to search
>> > through rfc3280bis for different sections is not reasonable.
>> >
>> > --Paul Hoffman, Director
>> > --VPN Consortium
>> >
>> >
>>
>>
>>
>>
>>
>>
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PHvfdR097281; Fri, 25 Feb 2005 09:57:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PHvfG4097280; Fri, 25 Feb 2005 09:57:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PHveIN097267 for <[e-mail]>; Fri, 25 Feb 2005 09:57:40 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-47.fastq.com [65.39.92.47]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id j1PHvOc20999; Fri, 25 Feb 2005 10:57:24 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Comments to SCVP ID 17
Date: Fri, 25 Feb 2005 10:54:27 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I reaffirm my opinion that the WG has amply done its work on this
important document.  It would be good to see the clock start ticking on
a two-week WG last call.

The phrase "rough consensus" is by definition ambiguous.  However, the
distinction between "rough consensus" and "unanimous consent" is
self-evident.

Mike




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PGcBHv089553; Fri, 25 Feb 2005 08:38:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PGcBbj089552; Fri, 25 Feb 2005 08:38:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PGcAMP089527 for <[e-mail]>; Fri, 25 Feb 2005 08:38:11 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j1PGbun06901; Fri, 25 Feb 2005 17:37:56 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 25 Feb 2005 17:37:56 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j1PGbt926289; Fri, 25 Feb 2005 17:37:55 +0100 (MET)
Date: Fri, 25 Feb 2005 17:37:55 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Comments to SCVP ID 17
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim, 

Long ago I explained probably even in this list
a difference between French and German behaviour.

When a French says, 'no, this is not acceptable'
this only means, "there is work to do, let's work". 
For a German it means "The project is terminated
and DEAD, we won't continue.".

When a German says: 'yes, this is already a begin'
this only means, "there is work to do, let's work",
For the French it means "The project is terminated
and ALIVE, all work has been done".

I add: When an English tells something, it is ambiguous,
by definition of the language. ;-) 

> I was looking forward to reading thoughtful and insightful comments on the new 
> draft, and was very disappointed to find that the following message was nothing 
> but insults.  To repeatedly suggest that the editors "have not read in detail 
> RFC 3280" or its various sections is a bit much. 


> Consider your message deleted.

I think you should at least consider point 16 :-)

Peter



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PEolvd080467; Fri, 25 Feb 2005 06:50:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PEolMG080466; Fri, 25 Feb 2005 06:50:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PEokxQ080460 for <[e-mail]>; Fri, 25 Feb 2005 06:50:46 -0800 (PST) (envelope-from [e-mail])
Received: from real2.localdomain ([192.168.2.11]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1PEoYa3012744; Fri, 25 Feb 2005 09:50:34 -0500
Received: from real2.localdomain (real2.localdomain [127.0.0.1]) by real2.localdomain (8.12.8/8.12.8) with ESMTP id j1PEoXF6018726; Fri, 25 Feb 2005 09:50:33 -0500
Received: (from apache@localhost) by real2.localdomain (8.12.8/8.12.8/Submit) id j1PEoXwY018723; Fri, 25 Feb 2005 09:50:33 -0500
Received: from pool-141-156-40-37.res.east.verizon.net (pool-141-156-40-37.res.east.verizon.net [141.156.40.37])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Fri, 25 Feb 2005 09:50:32 -0500
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2005 09:50:32 -0500
From: [e-mail]
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: Comments to SCVP ID 17
References: <00a701c5150f$04a62fe0$4f85900a@wcwang> <[e-mail]> <002c01c51a11$c6f490d0$4f85900a@wcwang> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 141.156.40.37
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I was looking forward to reading thoughtful and insightful comments on the new 
draft, and was very disappointed to find that the following message was nothing 
but insults.  To repeatedly suggest that the editors "have not read in detail 
RFC 3280" or its various sections is a bit much.

Consider your message deleted.

Tim Polk

Quoting Denis Pinkas <[e-mail]>:

> 
> To the co-editors,
> 
> 1. I basically agree with the comments from Wen-Cheng sent to the list on
> February 18 : the authors have still not correctly understand the
> difference between “validation policy” and “validation algorithm”.
> 
> Sections 1.3 and 1.4 which are the foundations of the document are still
> wrong. It is very painful, time consuming and time wasting to repeat
> again and again the same comments which are not considered by the
> editors.
> 
> The authors, who are more and more numerous (since Tim Polk and David
> Cooper have now joined round 17) have not read in detail RFC 3280 and are
> making confusion between terms and are inventing new wordings which add
> to the confusion (see more details below).
> 
> 
> 2. The first new wording introduced is: “PKI policies” which is a term
> which is defined nowhere in RFC 3280 nor in this document. When it is
> used, it means “validation policy”. Please delete everywhere “PKI
> policy”
> and replace it with “validation policy”.
> 
> The author have not read in details RFC 3280 section 6.1.
> 
> On page 7 they introduce a new term “basic certification path processing
> algorithm” whereas RFC 3280 uses:
>   - “certification path validation” (that is the title of section 6) and
>   - “basic path validation” (that is the title of section 6.1).
> 
> The major mistake is to refer to section 6.1.1 and then say that the
> inputs in section 6.1.1 have a “Set of Trust Anchors”. This is wrong.
> Section 6.1.1 deals with a *single* trust anchor, whereas section 6.2
> from RFC 3280 deals with multiple trust anchors.
> 
> This demonstrates that section 1.3 is wrong.
> 
> 
> 3. Section 1.4 is about a “validation algorithm”. Does this notion, as
> explained, makes sense ? Is this notion supported in RFC 3379 ? The
> answer is no.
> 
>  From the introduction, “a validation policy contains one or more trust
> anchors »
> 
>  From section 1.3, “a validation policy specifies the rules and parameters
> to be used by the SCVP server when validating a certificate”.
> 
> Different rules may apply to every trust anchor and to the CA
> certificates from a certification path under every trust anchor. The
> ASN.1 description of ValidationPolicy starting on page 17 does not allow
> to define different rules for different trust anchors. This comes from
> the previous mistakes.
> 
> We currently have:
> 
> ValidationPolicy ::= SEQUENCE {
>         validationPolRef          ValidationPolRef,
>         validationAlg         [0] ValidationAlg OPTIONAL,
>         userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
>         IDENTIFIER OPTIONAL,
>         inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
>         requireExplicitPolicy [3] BOOLEAN OPTIONAL,
>         inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
>         trustAnchors          [6] TrustAnchors OPTIONAL,
>         keyUsages             [7] KeyUsages OPTIONAL,
>         extendedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL}
> 
> and
> 
> ValidationAlg ::= SEQUENCE {
>         valAlgId              OBJECT IDENTIFIER,
>         parameters            ANY DEFINED BY valAlgId OPTIONAL }
> 
> If:
>         trustAnchors          [6] TrustAnchors OPTIONAL,
> 
> is changed into:
> 
>         trustAnchor          [6] TrustAnchor OPTIONAL,
> 
> then only the algorithm from section 6.1 of RFC 3280 can be used, and it
> would be a pity to make three calls if a validation policy included three
> trust anchors.
> 
> PLEASE co-editors, read carefully, and think about it before answering
> too quickly.
> 
> The conditions that apply to CA certificates may be very complicated and
> vary from one trust anchor to another. The goal if this document is NOT
> to be able to specific *remotely* every single parameter of section 6.1
> from RFC 3280.
> 
> The goal if this document is to support as a whole section 6.2 from RFC
> 3280. Once again, from the introduction, “a validation policy contains
> one or more trust anchors ».
> 
> The validation policy could OPTIONALLY include several “target
> certificate specific parameters” as Wen-Cheng proposed, since these
> parameters do not change from one trust anchor to another. I fully agree
> with Wen-Cheng that “target certificate” is more appropriate than “end
> certificate”.
> 
> This would also solve the confusion that Wen-Cheng noticed about the
> “name validation algorithm” which would become one of the “target
> certificate specific parameters”. Checking the target certificate DN is
> far more important than checking the CA DNs. If both checks are really
> needed, those checks may be different.
> 
> It is obvious that for each certification path the algorithm from section
> 6.1 of RFC 3280 is being used.
> 
> A validationAlg parameter is not needed. We could then simply have:
> 
> ValidationPolicy ::= SEQUENCE {
>         validationPolRef          ValidationPolRef,
>         keyUsages                [0] KeyUsages OPTIONAL,
>         extendedKeyUsages        [1] SEQUENCE OF KeyPurposeId OPTIONAL,
>         nameValidationAlgParms   [2] NameValidationAlgParms OPTIONAL,
>         otherTests               [3] OtherTests OPTIONAL
> }
> 
>     otherTests could be used for example to test QCStatements extensions.
> 
> 
> 4. As Wen-Cheng noted, the “default validation policy” does not make
> sense.
> 
> 
> 5.Section 1.5 states: “However, revocation checking is an optional
> feature in [PKIX-1], and revocation information is distributed in
> multiple formats.” This is incorrect.
> 
> RFC 3280 does not say that revocation checking is optional. Only CRLs
> processing is defined in RFC 3280 but we all know that OCSP is an
> alternative method. Revocation checking MUST be done to validate a
> certificate, but may be done using different means. These means may be
> specified in the validation policy.
> 
> On page 49 from we have:
> 
>     Conforming CAs are not required to issue CRLs if other revocation or
>     certificate status mechanisms are provided.
> 
> When the client sends a DPV request, revocation checking MUST be done.
> When the client send a DPD request, revocation status information MAY be
> returned or not.
> 
> This illustrates once again the problem when a single document is mixing
> the protocols for DPV and DPD.
> 
> 
> 6. It should be remembered that RFC 3379 makes the separation between DPV
> and DPD, while this document mixes them. It is therefor very doubtful to
> say that this document fills in the goals of RFC 3379.
> 
> 
> 7. “SCVP” is a very bad name when the request is to build only a
> certification path, with or without revocation status (i.e. DPD, leaving
> the validation to the client). The certificate is not VALIDATED by the
> server, and even if it would, the client would not trust it. It is
> apparent that some people would like to keep the “trade name” SCVP, but
> this will add confusion; but maybe this is what is deliberately wanted ?
> 
> 
> 8. The text correctly states on page 6: “An SCVP request needs only to
> contain the certificate to be validated, the referenced validation
> policy, and any run-time parameters for the request”.
> 
> It would be very beneficial to be able to have implementations that only
> support the above requirements for DPV, leaving the security of the
> communication link (i.e. using TLS) . The problem is that is not
> straightforward to derive a profile from this huge “monument” which is
> overcomplicated because it mixes DPV and DPD requirements.
> 
> It is strong suggested to revise the document so that this goal can be
> achieved and that conformance clauses can be added to be able to say that
> a given implementation is conformant to the *simple* certificate
> validation request mentioned above.
> 
> Unless the editors can provide a profile or/and indications on how this
> goal would be achieved, it is very doubtful that the full protocol will
> be widely implemented and used by applications.
> 
> If this is not done, it would then make sense to develop “HSCVP” : Hyper
> Simple Certificate Validation Protocol” or rename the current drat as
> CCVP, as it has always be !
> 
> Hyper Simple Certificate Validation Protocol is a protocol which contains
> the certificate to be validated (i.e. just one), the referenced
> validation policy (no other parameter), any useful certificates and
> revocation information (as provided by the client), and where the server
> tells whether the certificate is valid or not against that referenced
> policy (it may also return a “I don’t know” response).
> 
> In section 1.5, the text states: “The typical use of SCVP is expected to
> be over HTTP [HTTP] ». I would rather say: “HSCVP is expected to be over
> HTTPS [HTTPS]”
> 
> 
> 9. Given the time that it took me to comments on only 8 pages of the
> documents (about 7 hours), you can imagine how long it will take me to
> comment on the full document. I believe the topic is extremely important,
> but the editors are wasting my time.
> 
> Being the lead editor of RFC 3379, I believe that I have a little
> knowledge on that topic. More consideration should be paid to my comments
> and to the comments from Wen-Cheng. As he correctly said: “how strange it
> is that the authors always reject the suggestions”.
> 
> 
> 10. Additional minor comments (up to page 8).
> 
> Page 5. Section 1. Second paragraph. The text states:
> 
>     The first class of applications wants just two things: confirmation
>     that the public key belongs to the identity named in the certificate
>     and confirmation that the public key can be used for the intended
>     purpose.
> 
> This is not the main goal. Rephrase as:
> 
>     The first class of applications wants just confirmation
>     that the certificate is valid according a given validation policy.
> 
> 
> 11. Additional minor comment.
> Page 5. Section 1. Second paragraph. The text states:
> 
>     The second class of applications can perform certification path
>     validation, but they lack a reliable or efficient method of
>     constructing a valid certification path.
> 
> Rephrase as:
> 
>     The second class of applications can perform certification path
>     validation, but lack a reliable or efficient method of
>     constructing a valid certification path and the associated
>     revocation status information.
> 
> 
> 12. Additional minor comment.
> Page 5. Section 1.1. Second paragraph.
> 
>     The primary goals of SCVP are to make it easier to deploy PKI-enabled
>     applications and to allow central administration of PKI policies
>     within an organization.
> 
> Rephrase as:
> 
>     The primary goals of SCVP are to make it easier to deploy PKI-enabled
>     applications and to allow a server to support one or more validation
>     policies against which certificates can be tested by applications.
> 
> 
> 13. Additional minor comment.
> Page 5. Section 1.1. Second paragraph.
> 
>     SCVP can be used by clients that do much of
>     the certificate processing themselves but simply want an untrusted
>     server to collect information for them.  However, when the client has
>     complete trust in the SCVP server, SCVP can be used to delegate the
>     work of certification path construction and validation, and SCVP can
>     be used to ensure that policies are consistently enforced throughout
>     an organization.
> 
> Rephrase as:
> 
>     SCVP, used for DPV, can be used by clients that have complete trust
>     in a trusted DPV server. In such a case, the protocol can be used to
>     delegate the work of certification validation against a validation
>     policy.
> 
>     SCVP, used for DPD, can be used by clients that do much of
>     the certificate processing themselves but simply want an untrusted
>     DPD server to collect certificates and revocation status information
>     for them.
> 
> 
> 14. Since both one of the security area directors and one of the co-
> chairs of PKIX are editors, I request that both the other security area
> director and the other PKIX co-chair take a look at the debate: Tim, the
> over-ever optimistic, being both editor of the draft and PKIX co-chair
> cannot be in a position to say when a rough consensus will be reached.
> 
> 
> 15. Note also that after having waited for months changes and responses to
> comments, it is not acceptable, that - AS USUAL - the document is only
> delivered two weeks ahead the PKIX meeting: it is not possible to review
> in details two major documents of this WG, i.e. SCVP-17 and RFC3280bis in
> only two weeks.
> 
> 
> 16. Finally, note also that, unless I can finally agree on the document,
> I do not want to have my name placed in the acknowledgments section as it
> is currently mentioned, since, at this time, I am not *in any way*
> supportive of this “monument”.
> 
> I certainly participated to the lively debate, but at this time my
> contributions have not yet been able to “greatly improve the document”.
> 
> Denis
> 
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PEitVc080048; Fri, 25 Feb 2005 06:44:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PEitRd080047; Fri, 25 Feb 2005 06:44:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PEispJ080041 for <[e-mail]>; Fri, 25 Feb 2005 06:44:54 -0800 (PST) (envelope-from [e-mail])
Received: from real2.localdomain ([192.168.2.11]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1PEicD1014376; Fri, 25 Feb 2005 09:44:38 -0500
Received: from real2.localdomain (real2.localdomain [127.0.0.1]) by real2.localdomain (8.12.8/8.12.8) with ESMTP id j1PEicF6018317; Fri, 25 Feb 2005 09:44:38 -0500
Received: (from apache@localhost) by real2.localdomain (8.12.8/8.12.8/Submit) id j1PEibdi018315; Fri, 25 Feb 2005 09:44:37 -0500
Received: from pool-141-156-40-37.res.east.verizon.net (pool-141-156-40-37.res.east.verizon.net [141.156.40.37])  by webmail.nist.gov (IMP) with HTTP  for <wpolk@localhost>; Fri, 25 Feb 2005 09:44:37 -0500
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2005 09:44:37 -0500
From: [e-mail]
To: Denis Pinkas <[e-mail]>
Cc: pkix <[e-mail]>
Subject: Re: About RFC 3280bis
References: <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
User-Agent: Internet Messaging Program (IMP) 3.2.1
X-Originating-IP: 141.156.40.37
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I certainly agree that no one has the time to read all of 3280bis these days, 
and that it is important to provide the set of changes in a straightforward 
manner.  However, it was very difficult to convey the complete context of the 
proposed changes without showing how they would impact the current text.   
Describing the changes out of context and rolling them in later would surely 
result in repetitive debates, and I personally don't see the value in arguing 
every issue twice.  To ensure that the complete impact of all changes were 
accurately conveyed, we felt the need to create a 3280bis draft.

To facilitate an efficient review by WG members that are already familiar with 
3280, the editor also has provided an html diff file that shows all changes 
from 3280 to 3280bis. As noted earlier on list, this file is available at

http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html

The html diff file clearly identifies every change (deletions are in red and 
strikethrough, insertions are in green) so no one should have to read the 
entire document or spend cycles figuring out which sections were, or were not, 
modified.

Tim Polk

Quoting Denis Pinkas <[e-mail]>:

> 
> Paul Hoffman said on the list on November 8:
> 
> "Instead of starting rfc3280bis, start a draft called something like
> "rfc3280-changes". Have that draft be short, and contain *only*
> changes to 3280. Only after there is consensus on the -changes draft
> should you roll the changes in.
> 
> No one reads all of 3280 these days, so expecting people to search
> through rfc3280bis for different sections is not reasonable".
> 
> I was fully agreeing with him and since I saw no neagtive response from the 
> co-editors, I thought this was granted.
> 
> Then what happened ? Exactly the opposite !
> 
> What is the PKIX mailing list for, if the co-editors ignore such messages 
> from the list ?
> 
> Can we finally have these rfc3280-changes, the list of comments received and
> 
> their proposed resolution, BEFORE we can start reading the new draft ?
> 
> Denis
> 
> -------- Original Message --------
> Subject: Re: Suggestion for revising RFC 3280
> Date: Mon, 08 Nov 2004 13:42:12 -0500
> From: "Sean P. Turner" <[e-mail]>
> Organization: IECA, Inc.
> To: Paul Hoffman / VPNC <[e-mail]>
> CC: [e-mail]
> References: <p06110406bda564ea5155@[10.20.30.249]>
> 
> 
> Or at least have a paragraph that gets removed prior to RFC publication
> to tell everybody where changes were made.
> 
> spt
> 
> Paul Hoffman / VPNC wrote:
> 
>  >
>  > Instead of starting rfc3280bis, start a draft called something like
>  > "rfc3280-changes". Have that draft be short, and contain *only*
>  > changes to 3280. Only after there is consensus on the -changes draft
>  > should you roll the changes in.
>  >
>  > No one reads all of 3280 these days, so expecting people to search
>  > through rfc3280bis for different sections is not reasonable.
>  >
>  > --Paul Hoffman, Director
>  > --VPN Consortium
>  >
>  >
> 
> 
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PDdsOZ067579; Fri, 25 Feb 2005 05:39:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1PDdsv9067578; Fri, 25 Feb 2005 05:39:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1PDdjre067458 for <[e-mail]>; Fri, 25 Feb 2005 05:39:45 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1PDdZXR006108 for <[e-mail]>; Fri, 25 Feb 2005 08:39:35 -0500
Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1PDdZ8w063188 for <[e-mail]>; Fri, 25 Feb 2005 08:39:35 -0500
Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1PDdZsH006537 for <[e-mail]>; Fri, 25 Feb 2005 08:39:35 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1PDdYNe006516; Fri, 25 Feb 2005 08:39:34 -0500
In-Reply-To: <[e-mail]>
To: "Stefan Santesson" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
MIME-Version: 1.0
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
From: Tom Gindin <[e-mail]>
Message-ID: <[e-mail]>
Date: Fri, 25 Feb 2005 08:39:28 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF8|January 11, 2005) at 02/25/2005 08:39:33, Serialize complete at 02/25/2005 08:39:33
Content-Type: text/plain; charset="US-ASCII"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

        Stefan:

        The "certstore" draft (currently 
draft-ietf-pkix-certstore-http-08) defines an access descriptor for CRL's 
(id-ad-http-crls), which would go in the AIA or SIA extension.  If the 
subject certificate's AIA extension also contained a similar descriptor 
for the CA certificate (using id-ad-http-certs), and that descriptor used 
the Name or SHash attribute, you would be able to retrieve the CRL signing 
certificate for CRL's which weren't indirect CRL's.  However, if no such 
descriptor existed, or if one which did exist used the SKIDHash attribute, 
you would not be able to retrieve the CRL signing certificate without 
using AIA in the CRL.  IMO this is a valid use case in which an AIA is 
needed within the CRL.
        A Distribution Point name containing a URI works similarly.  If 
the RP is handed the subject and issuer certificates by the signer, it can 
use the DPName to retrieve the CRL, but it cannot necessarily get the CRL 
signing certificate unless there is an AIA in the CRL. 

                Tom Gindin






"Stefan Santesson" <[e-mail]>
02/24/2005 01:57 AM
 
        To:     Tom Gindin/Watson/IBM@IBMUS
        cc:     "Denis Pinkas" <[e-mail]>, "Russ Housley" 
<[e-mail]>, "pkix" <[e-mail]>
        Subject:        RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt


Tom,

I'm sorry. I have read your e-mail repeatedly but failed to understand
what you try to say.

Example:
>       The subject certificate has an AIA extension containing a URI
for a
> CRL, but no descriptor for a CA certificate.

This is not what we are talking about. AIA in a cert does not point to a
CRL. We are discussing AIA in a CRL pointing to the CRL issuer cert.

Can you clarify your issues?

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: den 23 februari 2005 13:15
> To: Stefan Santesson
> Cc: Denis Pinkas; Russ Housley; pkix
> Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
>       Stefan:
> 
>       I take a position between you and Denis here.  There are
certainly
> use cases for this extension other than indirect CRL.  However, I
think
> the
> other use cases are rarer than indirect CRL.  Here are the ones I see:
>       The subject certificate has an AIA extension containing a URI
for a
> CRL, but no descriptor for a CA certificate.
>       The subject certificate has a distribution point containing a
URI
> Distribution Point Name, and no AIA extension.
>       In the case where the subject certificate has no CRL
information,
> this extension appears to be useful only if the CRL can be found
without
> assistance but the signing certificate cannot.  In what cases other
than
> CRL caching and indirect CRL does that frequently occur in your
> experience?
> In the case of CRL caching, why isn't the signing certificate also
cached?
>       The case where the subject certificate contains a DN
Distribution
> Point Name seems to work out in a very similar way to the case where
it
> has
> no CRL information.
> 
>             Tom Gindin
> 
> 
> 
> 
>                       "Stefan
>                       Santesson"               To:       "Denis
Pinkas"
> <[e-mail]>
>                       <stefans@microsof        cc:       "Russ
Housley"
> <[e-mail]>, "pkix" <[e-mail]>
>                       t.com>                   Subject:  RE: I-D
> ACTION:draft-ietf-pkix-crlaia-00.txt
>                       Sent by:
>                       owner-ietf-pkix@m
>                       ail.imc.org
> 
> 
>                       02/15/2005 01:29
>                       PM
> 
> 
> 
> 
> 
> 
> Comments in-line;
> (Some stuff deleted to keep volume down)
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> >
> > What about the following sentences picked from the document:
> >
> >     Standardized methods of finding the certificate of the CRL
issuer
> are
> >     currently available either though an accessible directory
location
> or
> >     through use of the Subject Information Access extension in
> >     intermediary CA certificates.  These methods are however not
> >     generally applicable, and they do not provide a generic solution
> to
> >     the problem.
> >
> > This is true only if indirect CRLs are being used, but the wording
> > "indirect
> > CRL" is absent from these lines.
> 
> [Stefan] Even if it was true ONLY for indirect CRL's, text would be
> correct. But even more, this is NOT ONLY true for indirect CRL's. For
> example, it is also true if your current CA infrastructure and its CA
> certificates (which may be valid for another 5-20 years), don't
include
> a SIA extension. AIA in CRL's can be added to the infrastructure
without
> reissuing CA certificates, SIA can't. This is just 1 example. There
are
> more.
> 
> >
> > > It is an optional mechanism to be used
> > > by those who whish to use it to find the CRL signer cert.
> >
> >   ... which is really motivated when indirect CRLs are being used,
but
> > otherwise is not and the draft does not say it.
> >
> 
> [Stefan] Because it is not useful only for indirect CRLs.
> 
> > > I think the motivation for allowing this extension in CRLs is
> > > sufficiently stated in the document.
> >
> > It is not. In addition, adding an extension does not make sense
unless
> you
> > tell how it should be used.
> >
> 
> [Stefan] What is unclear for you?
> 
> > > Nothing you suggest is changing the
> > > technical outline of the specified solution.
> >
> > In this case, the processing of this new extension may be explained
> and
> > this
> > is not the case at this time.
> >
> 
> [Stefan] What is missing?
> 
> 
> <stuff deleted>
> >
> > >> The problem is that neither the abstract nor the introduction of
> this
> > >> draft is limiting the scope to indirect CRLs only.
> >
> > > [Stefan] That is because the scope of AIA in CRLs is not limited
to
> > > indirect CRLs.
> >
> >    .. but this extension does not add anything, if SIA used.
> >
> 
> [Stefan] Yes it does. It offers direct lookup of the CRL issuer cert
and
> indicates that the CRL Issuer certificate actually IS available for
> download, while SIA only offers pointer to location where the CRL
issuer
> cert MAY be found among other unrelated certificates, 1) if it is
> present and 2) if the client is capable of finding it.
> 
> 
> >
> > > [Stefan] This is incorrect. The data in each DP of the CDP will
tell
> the
> > > RP whether the DP points to an indirect CRL.
> >
> >     DistributionPoint ::= SEQUENCE {
> >          distributionPoint       [0]     DistributionPointName
> OPTIONAL,
> >          reasons                 [1]     ReasonFlags OPTIONAL,
> >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> >
> >     DistributionPointName ::= CHOICE {
> >          fullName                [0]     GeneralNames,
> >          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> >
> > Which field are you talking about ?
> 
> [Stefan] cRLIssuer
> 
> >
> > >> The draft should thus address the two scenarios (i.e. an IDP is
or
> is
> > >> not present) and for direct CRLs there is no "superiority" of the
> new
> > >> extension.
> >
> > > [Stefan] I don't see the point with that. The use of the AIA
> extension
> > > in CRL is not different for indirect or direct CRLs.
> >
> > With direct CRLs, there does not need to be any AIA extension, if
the
> SIA
> > extension in CA certificates is present. This is not said and should
> be
> > said.
> >
> 
> [Stefan] I don't see any purpose in saying that. This standard simply
> recognizes the usefulness of allowing the already existing and
deployed
> AIA extension logic, not only in certificates, but also in CRLs. It is
> not authoritative with regard to where and when this solution should
or
> should not be deployed.
> 
> The profile recognizes that there are other ways to build CRL paths.
> This should be enough.
> 
> 
> 
> 
> 





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OExDol038899; Thu, 24 Feb 2005 06:59:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1OExDx1038898; Thu, 24 Feb 2005 06:59:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OEwwEk038829 for <[e-mail]>; Thu, 24 Feb 2005 06:59:02 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA32012; Thu, 24 Feb 2005 16:11:59 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005022415580651:1407 ; Thu, 24 Feb 2005 15:58:06 +0100 
Message-ID: <[e-mail]>
Date: Thu, 24 Feb 2005 15:58:38 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Russ Housley <[e-mail]>, pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 24/02/2005 15:58:06, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 24/02/2005 15:58:17, Serialize complete at 24/02/2005 15:58:17
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

This is a waiting response. No response from me does not mean that I agree 
with your arguments.

Since SCVP-17 was issued, I simply spent the time I had to comment on 
SCVP-17 and thus I have no more time available for this draft for the moment.

In general, I can say that, for the time being, we are still not in agreement.

Denis


> Comments in-line;
> (Some stuff deleted to keep volume down)
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
>>What about the following sentences picked from the document:
>>
>>    Standardized methods of finding the certificate of the CRL issuer
> 
> are
> 
>>    currently available either though an accessible directory location
> 
> or
> 
>>    through use of the Subject Information Access extension in
>>    intermediary CA certificates.  These methods are however not
>>    generally applicable, and they do not provide a generic solution
> 
> to
> 
>>    the problem.
>>
>>This is true only if indirect CRLs are being used, but the wording
>>"indirect
>>CRL" is absent from these lines.
> 
> 
> [Stefan] Even if it was true ONLY for indirect CRL's, text would be
> correct. But even more, this is NOT ONLY true for indirect CRL's. For
> example, it is also true if your current CA infrastructure and its CA
> certificates (which may be valid for another 5-20 years), don't include
> a SIA extension. AIA in CRL's can be added to the infrastructure without
> reissuing CA certificates, SIA can't. This is just 1 example. There are
> more.
> 
> 
>>>It is an optional mechanism to be used
>>>by those who whish to use it to find the CRL signer cert.
>>
>>  ... which is really motivated when indirect CRLs are being used, but
>>otherwise is not and the draft does not say it.
>>
> 
> 
> [Stefan] Because it is not useful only for indirect CRLs.
> 
> 
>>>I think the motivation for allowing this extension in CRLs is
>>>sufficiently stated in the document.
>>
>>It is not. In addition, adding an extension does not make sense unless
> 
> you
> 
>>tell how it should be used.
>>
> 
> 
> [Stefan] What is unclear for you?
> 
> 
>>>Nothing you suggest is changing the
>>>technical outline of the specified solution.
>>
>>In this case, the processing of this new extension may be explained
> 
> and
> 
>>this
>>is not the case at this time.
>>
> 
> 
> [Stefan] What is missing?
> 
> 
> <stuff deleted>
> 
>>>>The problem is that neither the abstract nor the introduction of
>>>
> this
> 
>>>>draft is limiting the scope to indirect CRLs only.
>>>
>>>[Stefan] That is because the scope of AIA in CRLs is not limited to
>>>indirect CRLs.
>>
>>   .. but this extension does not add anything, if SIA used.
>>
> 
> 
> [Stefan] Yes it does. It offers direct lookup of the CRL issuer cert and
> indicates that the CRL Issuer certificate actually IS available for
> download, while SIA only offers pointer to location where the CRL issuer
> cert MAY be found among other unrelated certificates, 1) if it is
> present and 2) if the client is capable of finding it.
> 
> 
> 
>>>[Stefan] This is incorrect. The data in each DP of the CDP will tell
>>
> the
> 
>>>RP whether the DP points to an indirect CRL.
>>
>>    DistributionPoint ::= SEQUENCE {
>>         distributionPoint       [0]     DistributionPointName
> 
> OPTIONAL,
> 
>>         reasons                 [1]     ReasonFlags OPTIONAL,
>>         cRLIssuer               [2]     GeneralNames OPTIONAL }
>>
>>    DistributionPointName ::= CHOICE {
>>         fullName                [0]     GeneralNames,
>>         nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
>>
>>Which field are you talking about ?
> 
> 
> [Stefan] cRLIssuer
> 
> 
>>>>The draft should thus address the two scenarios (i.e. an IDP is or
>>>
> is
> 
>>>>not present) and for direct CRLs there is no "superiority" of the
>>>
> new
> 
>>>>extension.
>>>
>>>[Stefan] I don't see the point with that. The use of the AIA
>>
> extension
> 
>>>in CRL is not different for indirect or direct CRLs.
>>
>>With direct CRLs, there does not need to be any AIA extension, if the
> 
> SIA
> 
>>extension in CA certificates is present. This is not said and should
> 
> be
> 
>>said.
>>
> 
> 
> [Stefan] I don't see any purpose in saying that. This standard simply
> recognizes the usefulness of allowing the already existing and deployed
> AIA extension logic, not only in certificates, but also in CRLs. It is
> not authoritative with regard to where and when this solution should or
> should not be deployed.
> 
> The profile recognizes that there are other ways to build CRL paths.
> This should be enough.
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OEqnKA038403; Thu, 24 Feb 2005 06:52:49 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1OEqnTM038402; Thu, 24 Feb 2005 06:52:49 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OEqiud038390 for <[e-mail]>; Thu, 24 Feb 2005 06:52:46 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA40310 for <[e-mail]>; Thu, 24 Feb 2005 16:06:23 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005022415523970:1395 ; Thu, 24 Feb 2005 15:52:39 +0100 
Message-ID: <[e-mail]>
Date: Thu, 24 Feb 2005 15:53:11 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: About RFC 3280bis
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 24/02/2005 15:52:39, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 24/02/2005 15:52:40, Serialize complete at 24/02/2005 15:52:40
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman said on the list on November 8:

"Instead of starting rfc3280bis, start a draft called something like
"rfc3280-changes". Have that draft be short, and contain *only*
changes to 3280. Only after there is consensus on the -changes draft
should you roll the changes in.

No one reads all of 3280 these days, so expecting people to search
through rfc3280bis for different sections is not reasonable".

I was fully agreeing with him and since I saw no neagtive response from the 
co-editors, I thought this was granted.

Then what happened ? Exactly the opposite !

What is the PKIX mailing list for, if the co-editors ignore such messages 
from the list ?

Can we finally have these rfc3280-changes, the list of comments received and 
their proposed resolution, BEFORE we can start reading the new draft ?

Denis

-------- Original Message --------
Subject: Re: Suggestion for revising RFC 3280
Date: Mon, 08 Nov 2004 13:42:12 -0500
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
To: Paul Hoffman / VPNC <[e-mail]>
CC: [e-mail]
References: <p06110406bda564ea5155@[10.20.30.249]>


Or at least have a paragraph that gets removed prior to RFC publication
to tell everybody where changes were made.

spt

Paul Hoffman / VPNC wrote:

 >
 > Instead of starting rfc3280bis, start a draft called something like
 > "rfc3280-changes". Have that draft be short, and contain *only*
 > changes to 3280. Only after there is consensus on the -changes draft
 > should you roll the changes in.
 >
 > No one reads all of 3280 these days, so expecting people to search
 > through rfc3280bis for different sections is not reasonable.
 >
 > --Paul Hoffman, Director
 > --VPN Consortium
 >
 >





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OEhwin037401; Thu, 24 Feb 2005 06:43:58 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1OEhwRq037400; Thu, 24 Feb 2005 06:43:58 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1OEhnh2037358 for <[e-mail]>; Thu, 24 Feb 2005 06:43:53 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA20588 for <[e-mail]>; Thu, 24 Feb 2005 15:57:16 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005022415433209:1390 ; Thu, 24 Feb 2005 15:43:32 +0100 
Message-ID: <[e-mail]>
Date: Thu, 24 Feb 2005 15:44:04 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Comments to SCVP ID 17
References: <00a701c5150f$04a62fe0$4f85900a@wcwang> <[e-mail]> <002c01c51a11$c6f490d0$4f85900a@wcwang>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 24/02/2005 15:43:32, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 24/02/2005 15:43:33, Serialize complete at 24/02/2005 15:43:33
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1OEhvh2037395
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To the co-editors,

1. I basically agree with the comments from Wen-Cheng sent to the list on
February 18 : the authors have still not correctly understand the
difference between “validation policy” and “validation algorithm”.

Sections 1.3 and 1.4 which are the foundations of the document are still
wrong. It is very painful, time consuming and time wasting to repeat
again and again the same comments which are not considered by the
editors.

The authors, who are more and more numerous (since Tim Polk and David
Cooper have now joined round 17) have not read in detail RFC 3280 and are
making confusion between terms and are inventing new wordings which add
to the confusion (see more details below).


2. The first new wording introduced is: “PKI policies” which is a term
which is defined nowhere in RFC 3280 nor in this document. When it is
used, it means “validation policy”. Please delete everywhere “PKI policy”
and replace it with “validation policy”.

The author have not read in details RFC 3280 section 6.1.

On page 7 they introduce a new term “basic certification path processing
algorithm” whereas RFC 3280 uses:
  - “certification path validation” (that is the title of section 6) and
  - “basic path validation” (that is the title of section 6.1).

The major mistake is to refer to section 6.1.1 and then say that the
inputs in section 6.1.1 have a “Set of Trust Anchors”. This is wrong.
Section 6.1.1 deals with a *single* trust anchor, whereas section 6.2
from RFC 3280 deals with multiple trust anchors.

This demonstrates that section 1.3 is wrong.


3. Section 1.4 is about a “validation algorithm”. Does this notion, as
explained, makes sense ? Is this notion supported in RFC 3379 ? The
answer is no.

 From the introduction, “a validation policy contains one or more trust
anchors »

 From section 1.3, “a validation policy specifies the rules and parameters
to be used by the SCVP server when validating a certificate”.

Different rules may apply to every trust anchor and to the CA
certificates from a certification path under every trust anchor. The
ASN.1 description of ValidationPolicy starting on page 17 does not allow
to define different rules for different trust anchors. This comes from
the previous mistakes.

We currently have:

ValidationPolicy ::= SEQUENCE {
        validationPolRef          ValidationPolRef,
        validationAlg         [0] ValidationAlg OPTIONAL,
        userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
        IDENTIFIER OPTIONAL,
        inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
        requireExplicitPolicy [3] BOOLEAN OPTIONAL,
        inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
        trustAnchors          [6] TrustAnchors OPTIONAL,
        keyUsages             [7] KeyUsages OPTIONAL,
        extendedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL}

and

ValidationAlg ::= SEQUENCE {
        valAlgId              OBJECT IDENTIFIER,
        parameters            ANY DEFINED BY valAlgId OPTIONAL }

If:
        trustAnchors          [6] TrustAnchors OPTIONAL,

is changed into:

        trustAnchor          [6] TrustAnchor OPTIONAL,

then only the algorithm from section 6.1 of RFC 3280 can be used, and it
would be a pity to make three calls if a validation policy included three
trust anchors.

PLEASE co-editors, read carefully, and think about it before answering
too quickly.

The conditions that apply to CA certificates may be very complicated and
vary from one trust anchor to another. The goal if this document is NOT
to be able to specific *remotely* every single parameter of section 6.1
from RFC 3280.

The goal if this document is to support as a whole section 6.2 from RFC
3280. Once again, from the introduction, “a validation policy contains
one or more trust anchors ».

The validation policy could OPTIONALLY include several “target
certificate specific parameters” as Wen-Cheng proposed, since these
parameters do not change from one trust anchor to another. I fully agree
with Wen-Cheng that “target certificate” is more appropriate than “end
certificate”.

This would also solve the confusion that Wen-Cheng noticed about the
“name validation algorithm” which would become one of the “target
certificate specific parameters”. Checking the target certificate DN is
far more important than checking the CA DNs. If both checks are really
needed, those checks may be different.

It is obvious that for each certification path the algorithm from section
6.1 of RFC 3280 is being used.

A validationAlg parameter is not needed. We could then simply have:

ValidationPolicy ::= SEQUENCE {
        validationPolRef          ValidationPolRef,
        keyUsages                [0] KeyUsages OPTIONAL,
        extendedKeyUsages        [1] SEQUENCE OF KeyPurposeId OPTIONAL,
        nameValidationAlgParms   [2] NameValidationAlgParms OPTIONAL,
        otherTests               [3] OtherTests OPTIONAL
}

    otherTests could be used for example to test QCStatements extensions.


4. As Wen-Cheng noted, the “default validation policy” does not make
sense.


5.Section 1.5 states: “However, revocation checking is an optional
feature in [PKIX-1], and revocation information is distributed in
multiple formats.” This is incorrect.

RFC 3280 does not say that revocation checking is optional. Only CRLs
processing is defined in RFC 3280 but we all know that OCSP is an
alternative method. Revocation checking MUST be done to validate a
certificate, but may be done using different means. These means may be
specified in the validation policy.

On page 49 from we have:

    Conforming CAs are not required to issue CRLs if other revocation or
    certificate status mechanisms are provided.

When the client sends a DPV request, revocation checking MUST be done.
When the client send a DPD request, revocation status information MAY be
returned or not.

This illustrates once again the problem when a single document is mixing
the protocols for DPV and DPD.


6. It should be remembered that RFC 3379 makes the separation between DPV
and DPD, while this document mixes them. It is therefor very doubtful to
say that this document fills in the goals of RFC 3379.


7. “SCVP” is a very bad name when the request is to build only a
certification path, with or without revocation status (i.e. DPD, leaving
the validation to the client). The certificate is not VALIDATED by the
server, and even if it would, the client would not trust it. It is
apparent that some people would like to keep the “trade name” SCVP, but
this will add confusion; but maybe this is what is deliberately wanted ?


8. The text correctly states on page 6: “An SCVP request needs only to
contain the certificate to be validated, the referenced validation
policy, and any run-time parameters for the request”.

It would be very beneficial to be able to have implementations that only
support the above requirements for DPV, leaving the security of the
communication link (i.e. using TLS) . The problem is that is not
straightforward to derive a profile from this huge “monument” which is
overcomplicated because it mixes DPV and DPD requirements.

It is strong suggested to revise the document so that this goal can be
achieved and that conformance clauses can be added to be able to say that
a given implementation is conformant to the *simple* certificate
validation request mentioned above.

Unless the editors can provide a profile or/and indications on how this
goal would be achieved, it is very doubtful that the full protocol will
be widely implemented and used by applications.

If this is not done, it would then make sense to develop “HSCVP” : Hyper
Simple Certificate Validation Protocol” or rename the current drat as
CCVP, as it has always be !

Hyper Simple Certificate Validation Protocol is a protocol which contains
the certificate to be validated (i.e. just one), the referenced
validation policy (no other parameter), any useful certificates and
revocation information (as provided by the client), and where the server
tells whether the certificate is valid or not against that referenced
policy (it may also return a “I don’t know” response).

In section 1.5, the text states: “The typical use of SCVP is expected to
be over HTTP [HTTP] ». I would rather say: “HSCVP is expected to be over
HTTPS [HTTPS]”


9. Given the time that it took me to comments on only 8 pages of the
documents (about 7 hours), you can imagine how long it will take me to
comment on the full document. I believe the topic is extremely important,
but the editors are wasting my time.

Being the lead editor of RFC 3379, I believe that I have a little
knowledge on that topic. More consideration should be paid to my comments
and to the comments from Wen-Cheng. As he correctly said: “how strange it
is that the authors always reject the suggestions”.


10. Additional minor comments (up to page 8).

Page 5. Section 1. Second paragraph. The text states:

    The first class of applications wants just two things: confirmation
    that the public key belongs to the identity named in the certificate
    and confirmation that the public key can be used for the intended
    purpose.

This is not the main goal. Rephrase as:

    The first class of applications wants just confirmation
    that the certificate is valid according a given validation policy.


11. Additional minor comment.
Page 5. Section 1. Second paragraph. The text states:

    The second class of applications can perform certification path
    validation, but they lack a reliable or efficient method of
    constructing a valid certification path.

Rephrase as:

    The second class of applications can perform certification path
    validation, but lack a reliable or efficient method of
    constructing a valid certification path and the associated
    revocation status information.


12. Additional minor comment.
Page 5. Section 1.1. Second paragraph.

    The primary goals of SCVP are to make it easier to deploy PKI-enabled
    applications and to allow central administration of PKI policies
    within an organization.

Rephrase as:

    The primary goals of SCVP are to make it easier to deploy PKI-enabled
    applications and to allow a server to support one or more validation
    policies against which certificates can be tested by applications.


13. Additional minor comment.
Page 5. Section 1.1. Second paragraph.

    SCVP can be used by clients that do much of
    the certificate processing themselves but simply want an untrusted
    server to collect information for them.  However, when the client has
    complete trust in the SCVP server, SCVP can be used to delegate the
    work of certification path construction and validation, and SCVP can
    be used to ensure that policies are consistently enforced throughout
    an organization.

Rephrase as:

    SCVP, used for DPV, can be used by clients that have complete trust
    in a trusted DPV server. In such a case, the protocol can be used to
    delegate the work of certification validation against a validation
    policy.

    SCVP, used for DPD, can be used by clients that do much of
    the certificate processing themselves but simply want an untrusted
    DPD server to collect certificates and revocation status information
    for them.


14. Since both one of the security area directors and one of the co-
chairs of PKIX are editors, I request that both the other security area
director and the other PKIX co-chair take a look at the debate: Tim, the
over-ever optimistic, being both editor of the draft and PKIX co-chair
cannot be in a position to say when a rough consensus will be reached.


15. Note also that after having waited for months changes and responses to
comments, it is not acceptable, that - AS USUAL - the document is only
delivered two weeks ahead the PKIX meeting: it is not possible to review
in details two major documents of this WG, i.e. SCVP-17 and RFC3280bis in
only two weeks.


16. Finally, note also that, unless I can finally agree on the document,
I do not want to have my name placed in the acknowledgments section as it
is currently mentioned, since, at this time, I am not *in any way*
supportive of this “monument”.

I certainly participated to the lively debate, but at this time my
contributions have not yet been able to “greatly improve the document”.

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1O6x9Xk092736; Wed, 23 Feb 2005 22:59:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1O6x9UK092735; Wed, 23 Feb 2005 22:59:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1O6wwxC092568 for <[e-mail]>; Wed, 23 Feb 2005 22:58:59 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 24 Feb 2005 06:58:40 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Date: Thu, 24 Feb 2005 06:57:58 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
thread-index: AcUZoeU6+69ZzcH2S7CG+fAon/733wAm5N3A
From: "Stefan Santesson" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 24 Feb 2005 06:58:40.0762 (UTC) FILETIME=[459515A0:01C51A3E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1O6wxxC092669
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tom,

I'm sorry. I have read your e-mail repeatedly but failed to understand
what you try to say.

Example:
>       The subject certificate has an AIA extension containing a URI
for a
> CRL, but no descriptor for a CA certificate.

This is not what we are talking about. AIA in a cert does not point to a
CRL. We are discussing AIA in a CRL pointing to the CRL issuer cert.

Can you clarify your issues?

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: Tom Gindin [mailto:[e-mail]]
> Sent: den 23 februari 2005 13:15
> To: Stefan Santesson
> Cc: Denis Pinkas; Russ Housley; pkix
> Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
>       Stefan:
> 
>       I take a position between you and Denis here.  There are
certainly
> use cases for this extension other than indirect CRL.  However, I
think
> the
> other use cases are rarer than indirect CRL.  Here are the ones I see:
>       The subject certificate has an AIA extension containing a URI
for a
> CRL, but no descriptor for a CA certificate.
>       The subject certificate has a distribution point containing a
URI
> Distribution Point Name, and no AIA extension.
>       In the case where the subject certificate has no CRL
information,
> this extension appears to be useful only if the CRL can be found
without
> assistance but the signing certificate cannot.  In what cases other
than
> CRL caching and indirect CRL does that frequently occur in your
> experience?
> In the case of CRL caching, why isn't the signing certificate also
cached?
>       The case where the subject certificate contains a DN
Distribution
> Point Name seems to work out in a very similar way to the case where
it
> has
> no CRL information.
> 
>             Tom Gindin
> 
> 
> 
> 
>                       "Stefan
>                       Santesson"               To:       "Denis
Pinkas"
> <[e-mail]>
>                       <stefans@microsof        cc:       "Russ
Housley"
> <[e-mail]>, "pkix" <[e-mail]>
>                       t.com>                   Subject:  RE: I-D
> ACTION:draft-ietf-pkix-crlaia-00.txt
>                       Sent by:
>                       owner-ietf-pkix@m
>                       ail.imc.org
> 
> 
>                       02/15/2005 01:29
>                       PM
> 
> 
> 
> 
> 
> 
> Comments in-line;
> (Some stuff deleted to keep volume down)
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> >
> > What about the following sentences picked from the document:
> >
> >     Standardized methods of finding the certificate of the CRL
issuer
> are
> >     currently available either though an accessible directory
location
> or
> >     through use of the Subject Information Access extension in
> >     intermediary CA certificates.  These methods are however not
> >     generally applicable, and they do not provide a generic solution
> to
> >     the problem.
> >
> > This is true only if indirect CRLs are being used, but the wording
> > "indirect
> > CRL" is absent from these lines.
> 
> [Stefan] Even if it was true ONLY for indirect CRL's, text would be
> correct. But even more, this is NOT ONLY true for indirect CRL's. For
> example, it is also true if your current CA infrastructure and its CA
> certificates (which may be valid for another 5-20 years), don't
include
> a SIA extension. AIA in CRL's can be added to the infrastructure
without
> reissuing CA certificates, SIA can't. This is just 1 example. There
are
> more.
> 
> >
> > > It is an optional mechanism to be used
> > > by those who whish to use it to find the CRL signer cert.
> >
> >   ... which is really motivated when indirect CRLs are being used,
but
> > otherwise is not and the draft does not say it.
> >
> 
> [Stefan] Because it is not useful only for indirect CRLs.
> 
> > > I think the motivation for allowing this extension in CRLs is
> > > sufficiently stated in the document.
> >
> > It is not. In addition, adding an extension does not make sense
unless
> you
> > tell how it should be used.
> >
> 
> [Stefan] What is unclear for you?
> 
> > > Nothing you suggest is changing the
> > > technical outline of the specified solution.
> >
> > In this case, the processing of this new extension may be explained
> and
> > this
> > is not the case at this time.
> >
> 
> [Stefan] What is missing?
> 
> 
> <stuff deleted>
> >
> > >> The problem is that neither the abstract nor the introduction of
> this
> > >> draft is limiting the scope to indirect CRLs only.
> >
> > > [Stefan] That is because the scope of AIA in CRLs is not limited
to
> > > indirect CRLs.
> >
> >    .. but this extension does not add anything, if SIA used.
> >
> 
> [Stefan] Yes it does. It offers direct lookup of the CRL issuer cert
and
> indicates that the CRL Issuer certificate actually IS available for
> download, while SIA only offers pointer to location where the CRL
issuer
> cert MAY be found among other unrelated certificates, 1) if it is
> present and 2) if the client is capable of finding it.
> 
> 
> >
> > > [Stefan] This is incorrect. The data in each DP of the CDP will
tell
> the
> > > RP whether the DP points to an indirect CRL.
> >
> >     DistributionPoint ::= SEQUENCE {
> >          distributionPoint       [0]     DistributionPointName
> OPTIONAL,
> >          reasons                 [1]     ReasonFlags OPTIONAL,
> >          cRLIssuer               [2]     GeneralNames OPTIONAL }
> >
> >     DistributionPointName ::= CHOICE {
> >          fullName                [0]     GeneralNames,
> >          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> >
> > Which field are you talking about ?
> 
> [Stefan] cRLIssuer
> 
> >
> > >> The draft should thus address the two scenarios (i.e. an IDP is
or
> is
> > >> not present) and for direct CRLs there is no "superiority" of the
> new
> > >> extension.
> >
> > > [Stefan] I don't see the point with that. The use of the AIA
> extension
> > > in CRL is not different for indirect or direct CRLs.
> >
> > With direct CRLs, there does not need to be any AIA extension, if
the
> SIA
> > extension in CA certificates is present. This is not said and should
> be
> > said.
> >
> 
> [Stefan] I don't see any purpose in saying that. This standard simply
> recognizes the usefulness of allowing the already existing and
deployed
> AIA extension logic, not only in certificates, but also in CRLs. It is
> not authoritative with regard to where and when this solution should
or
> should not be deployed.
> 
> The profile recognizes that there are other ways to build CRL paths.
> This should be enough.
> 
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1O1eUjp049884; Wed, 23 Feb 2005 17:40:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1O1eUkd049883; Wed, 23 Feb 2005 17:40:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1O1eLOa049852 for <[e-mail]>; Wed, 23 Feb 2005 17:40:29 -0800 (PST) (envelope-from [e-mail])
Received: from ms21.chttl.com.tw (ms21 [10.144.2.121]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j1O1eBiQ024433 for <[e-mail]>; Thu, 24 Feb 2005 09:40:11 +0800
Received: from wcwang ([10.144.133.79]) by ms21.chttl.com.tw (8.13.2/8.13.2) with SMTP id j1O1eBig021141 for <[e-mail]>; Thu, 24 Feb 2005 09:40:11 +0800
Message-ID: <002c01c51a11$c6f490d0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>
References: <00a701c5150f$04a62fe0$4f85900a@wcwang> <[e-mail]>
Subject: Re: Comments to SCVP ID 17
Date: Thu, 24 Feb 2005 09:40:10 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear List,

I am sorry if you received this mail more than once. The
PKIX ML server seemed to have problem to accept my
email. This is my fifth trial to send this email to PKIX ML.
 
Please see my comments in-line.
  
David A. Cooper wrote:
>Sent: Saturday, February 19, 2005 6:08 AM
>Subject: Re: Comments to SCVP ID 17
>
>
>Wen-Cheng Wang wrote: 
>>2. I suggest to let the version filed of request and
>>   response messages default to v1(1).
>>   That is:
>> 
>>      cvRequestVersion        INTEGER,
>>   ->
>>      cvRequestVersion        INTEGER DEFAULT v1(1),
>> 
>>      cvRsponseVersion        INTEGER
>>   ->
>>      cvRsponseVersion        INTEGER DEFAULT v1(1),
>> 
>>      vpRequestVersion        INTEGER,
>>   ->
>>      vpRequestVersion        INTEGER DEFAULT v1(1),
>> 
>>
>>      vpRsponseVersion        INTEGER
>>   ->
>>      vpRsponseVersion        INTEGER DEFAULT v1(1),
>> 
>>   By doing this, the DER code of every request and
>>   response message will save 3 bytes. I believe that
>>   the SCVP version will stay at v1 for a long time,
>>   asigning default value will allow clients and
>>   servers do not bother to send the version number
>>   in their requests and responses.
>> 
>>   Note that when a field become a field with DEFAULT
>>   value, it might need change to a tagged field.
>We set a DEFAULT value wherever we could do so without adding any
>more explicit tagging.  So, DEFAULT version numbers were set in
>CVRequest and ValPolRequest, but not CVResponse or ValPolResponse.

I can live with that, although I prefer to all the version numbers
omittable in both requests and responses.

>>4. I notice that SCVP 17 newly invented the term
>>   "end certificate". Personally, I understand what
>>   you mean by "end certificate" because I have been
>>   tracking this ID for a long time. However, I am
>>   worrying that using the term "end certificate"
>>   might cause confusion because it might have
>>   different interpretation for different direction
>>   of path construction (forward or reverse). As a
>>   technical spec, SCVP should be more precise in
>>   adopting technical term. Therefore, I suggest to
>>   use the term "target certificate" instead, not only
>>   for eliminating possible confucion but also for
>>   keeping alignment with RFC 3379.
>> 
>>   In addition, to make a more strong connection between
>>   the term "target certificate" and the field of the
>>   query message, I further suggest to change the field
>>   name "queriedCerts" in the "Query" data type into
>>   "targetCerts". Of course, related statements that
>>   explain or refer to that field shoul also be modified
>>   in response to the changing of the filed name.
>The term "end certificate" is used in X.509 to refer to the
>final certificate in a certification path (which is usually, but
>not always, an end entity certificate).  However, it appears that
>the term was never used in RFC 3280.  On the other hand, I could only
>find one use of the term "target certificate" in RFC 3379, and it is
>never defined.  So it is not clear that "target" would be any better
>than "end".  But, I added a definition of "end certificate" after
>its first use.

Again, I can live with that, although I prefer the term "target certificate".
Please also not that the "Certification Path Building" ID also use the term
"target certificate".

>>5. After reading SCVP 17, I finally understand the
>>   purpose of name validation algorithm. Before SCVP 17,
>>   I always thought it is used to specify the name
>>   matching rule (binary matching or X.500 name matching)
>>   during certificate chaining. Now I understand that it
>>   is use to specify the request for checking subject
>>   name of the "target certificate". If it is so, I think
>>   it is unreasonalbe to say:
>> 
>>     "The name validation is a refinement of the basic
>>      validation algorithm"
>> 
>>   The basic validation algorithm is an algorithm
>>   specifying conditions and rules for validating
>>   the whole certification path. In terms of RFC 3379,
>>   the basic validation algorithm specifies
>>   "certification path requirements". On th contrary,
>>   the name validation algorithm only specifies the
>>   request for checking subject name of the "target
>>   certificate". In terms of RFC 3379, the so-called
>>   name validation algorithm is simply one of the
>>   "end-entity certificate specific requirements".
>>   (Now I prefer to call them "target certificate
>>    specific requirements".)
>>   It is much like "keyUsages" and "extendedKeyUsages"
>>   checks, which are also "target certificate
>>   specific requirements". To make the protocol
>>   more resonable and aligned with RFC 3379, I
>>   suggest to take "name validation algorithm" out
>>   of section 3.2.4.2 and group it with "keyUsages"
>>   and "extendedKeyUsages", because they all belong
>>   to the category of "target certificate specific
>>   requirements".
>I believe that there is still a misunderstanding.  The
>name validation algorithm does not *only* specify checking
>the subject name in the end (or target) certificate.  When
>the name validation algorithm is specified, the server MUST
>perform all of the checks required by the Basic Validation
>Algorithm *in addition to* checking the subject name in the
>end (target) certificate.  That is why the name validation
>algorithm is referred to as a refinement of the basic
>validation algorithm.  As is stated in section 3.2.4.2.1
>(Basic Validation Algorithm): "That is, none of the validation
>requirements in the basic algorithm may be omitted from any
>newly defined validation algorithms."

Believe me, I understand the refinement relationship. I simply feel that
it is odd to say a "name validation algorithm" is a refinement of a path
validation algorithm. I believe that most people will not associate
path validation with the term "name validation". Maybe you should name
it "the basic validation algorithm with name checking".

>While name validation could have been implemented in a similar
>manner to the verification of keyUsage and extendedKeyUsage,
>specifying name validation as a different validation algorithm
>works just as well.  Changing the ASN.1 to group name checking
>with keyUsages and extendedKeyUsages would simply be a styistic
>change that would have no real effect on the protocol.  While Tim
>and I made changes to the ASN.1 to clean up the tagging since so
>many people insisted that they wanted the change, we really need
>to get this document finished, and so I think we should try to avoid
>making changes to the protocol that are unnecessary.

I still believe that it is better to group "name checking", "key usage checking"
and "extended key usage checking" into the category of "end/target certificate
requirements". This is not a simply a stylistic change. It is a matter of logicalness
of the protocol design. However, if we are really running out of time, I can live
with "the basic validation algorithm with name validation".

>>6. The current text of SCVP 17 tries to define a
>>   "global" default validation policy and tries to
>>   enforce all implementation to support that default
>>   validation policy. This notion of "default validation
>>   policy" does not align with the general understanding
>>   of "default validation policy".
>>   
>>   The default validation policy defined in SCVP 17 is
>>   actually simply a "basic" validation policy which
>>   adopts the basic path validation algorithm defined
>>   in RFC 3280, it is odd to specify it as the "global"
>>   default validation policy. The general understanding
>>   of "default validation policy" is the default one
>>   among the organizational validation policies.
>>    
>>   I suggest to change term "default validation policy"
>>   to "basic validation policy" to avoid confussion.
>>   With this distinction of the notion of "default
>>   validation policy" and the notion of the predefined
>>   "basic validation policy, we can clearly say that
>> 
>>     The SCVP server can define multiple vlidation
>>     policies and nominate one as its default
>>     policy. If the client does not select a
>>     validation policy in its request, the server
>>     will use the default validation policy.
>> 
>>     The SCVP server MAY list the "basic validation
>>     policy" defined in this specification as one
>>     of its supported validation policies. The SCVP
>>     server MAY select the "basic validation
>>     policy" as its default policy.
>> 
>>   Please note that I also suggest that the
>>   "validationPolicy" field in the "Query" data type
>>   should be changed to be an optional field. This
>>   allow the client to ommit the selection of
>>   the validation policy in its request and simply
>>   let the server use its default policy.
>The "default validation policy" really is the default validation
>policy for the organiztion; it is not a "global" validation policy.
>
>Section 3.2.4.1.1 states that the default validation policy MUST
>use the basic validation algorithm as its default validation
>algorithm, but each individual SCVP server is free to set the
>default values for all other parameters (e.g., trust anchors) of
>the validation policy as it wishes.  The server specifies the default
>parameter values that it uses in its default validation policy in its
>validation policy response (in the defaultPolicyValues item).
>Basically, I agree that the validation algorithm adopt by the server MUST be based
>on the basic path validation algorithm defined by RFC 3280 or its descendant, but
>it is not necessary to force every organization to accept that "basic path validation
>algorithm" as the alogorithm of their organizational default validation policy. What
>if the organization want to adopt an extended/refined version of  path validation
>algorithm in their organizational default validation policy? To allow organizations
>to define their own organizational default validation policy, I still think it is better to
>name the validation policy defined by the SCVP spec as "basic validation policy".
>It is analogy to that RFC 3280 named its path validation algorithm as "basic path
>validation algorithm" (not "default validation algorithm").
 
The point is that SCVP should give freedom to organizations to define their own
organizational default validation policy. Nevertheless, SCVP could ask organization
to adopt PKIX-compliant validation algorithm no mater if they define their own
organizational default validation policy.
 
I understand that it is good if SCVP defines a validat policy and its OID for the
convenience of organization unwilling/unable to define their own validat policy/OID.
However, it should not be "the default validation policy". It should simply be "a basic
validation policy".

>So, if a client wants to use the organizational default validation policy, it
>simply specifies the OID for the default validation policy.  Rather than
>make the validationPolicy field OPTIONAL, the editors chose to define an
>OID for the default validation policy.  The effect is the same, it is just a
>slightly different encoding.  This was done before I became involved with SCVP,
>but it may have been done in order to make it possible for the server to reject
>requests that specify the default policy OID (the server can simply not list that
>OID in the validationPolices item of its validation policy response.

I know that this is the way SCVP letting organizations overwrite the globally
defined "default validation policy". However, in the situation where an organization
only supports one validation policy and naturally uses that validation policy as its
default organizational validation policy, isn't it superfluous to request all its clients
to specify the organizational validation policy OID? In such situation, clients usually
want to omit the validation polict item in their request and let the server use its
default policy. With current syntax, it is impossible to do that.

>>7. The title of section 1.3 is "validation Policies", but
>>   in the middle of that section it mentions:
>> 
>>     "The inputs to the basic certification path processing
>>      algorithm used by SCVP are defined by [PKIX-1] in
>>      section 6.1.1 and comprise: 
>>     
>>        Certificate to be validated (by value or by reference); 
>>     
>>        Validation time; 
>>     
>>        Set of Trust Anchors (by value or by reference); 
>>     
>>        The initial policy set; 
>>     
>>        Initial inhibit policy mapping setting; 
>>     
>>        Initial inhibit anyPolicy setting; and 
>>     
>>        Initial require explicit policy setting."
>> 
>>   Isn't it be odd to define inputs to "validation
>>   algorithm" in a section titled "validation
>>   policies"?
>> 
>>   It reveals that even the authors of SCVP have no
>>   good distinction between the notion of "validation
>>   policy" and the notion of "validation algorithm",
>>   no to say an implementator who try to implement SCVP.
>> 
>>   Even several reviewers (for example Denis and I)
>>   clearly express that the notion of "validation algorithm"
>>   is redundant to the notion of "validation policy"
>>   and can be removed, how strange it is that the
>>   authors always to reject the suggestions.
>> 
>>   Now, even with SCVP 17 which authors says "the text
>>   for validation policies, validation algoriothms and
>>   name validation algorithms has all been revised for
>>   clarity, the distinction still vague.
>> 
>>   I sugest to remove the notion of "validation
>>   algorithm" from SCVP, and change the text to:
>> 
>>     "The certification path specific parameters to the
>>      basic validation policy defined by this specification
>>      are defined by [PKIX-1] in its section 6.1.1 and
>>      comprise: 
>>     
>>        Certificate to be validated (by value or by reference); 
>>     
>>        Validation time; 
>>     
>>        Set of Trust Anchors (by value or by reference); 
>>     
>>        The initial policy set; 
>>     
>>        Initial inhibit policy mapping setting; 
>>     
>>        Initial inhibit anyPolicy setting; and 
>>     
>>        Initial require explicit policy setting."
>I still believe that it is useful to have both a validation
>policy and a validation algorithm.  You suggest that it is
>odd for the validation policy to specify the inputs to the
>validation algorithm, but I disagree.  The basic validation
>algorithm, for example, is simply an algorithm.  It specifies
>the rules for creating a set of outputs from a set of inputs.
>The validation algorithm does not, however, specify the *values*
>for the inputs.  The validation policy specifies not only what
>algorithm should be used to determine whether the certificate
>is valid, but also the *values* for the inputs to the algorithm
>(e.g., trust anchors, user initial policy set, etc.).
>
>If the validation algorithm were removed as a parameter then
>it would not be possible to specify the use of an algorithm
>other than the basic validation algorithm for determining
>whether a certificate were valid given the other inputs
>specified by the policy.
>
>At the moment, there are only two validation algorithms defined
>for use with SCVP and as you stated, subject name checking could
>have been implemented with defining a new validation algorithm.
>However, including the validation algorithm as a parameter of the
>validation policy allows for other validation algorithms to be
>specified in the future.  For example, someone could define a
>validation algorithm that verifies whether a certificate is a
>valid proxy certificate according to RFC 3820.  This proxy
>certificate algorithm could either be used as the default validation
>algorithm for a validation policy or it use could be specified by
>the client in the request.  So, a client could, for example, specify
>the use of the default validation policy, but with the proxy
>certificate validation algorithm.  The result would be that the
>organizational default values would be used for the inputs (trusts
>anchors, user intial policy set, etc.), but the certificate(s)
>would be validated as a proxy certificate (RFC 3820) rather than
>being validated using the normal validation algorithm (RFC 3280).

The question is what is the relationship between "validation policy" and
"validation algorithm"? Will it be normally one-to-one relationship or
one-to-many relationship? By one-to-one relationship, I mean one validation
policy can only support one validation algorithm. By one-to-many relationship,
I mean one validation policy can support multiple validation algorithms.
In one-to-many relationship, a client might need to select one of the multiple
validation algorithms supported by the validation policy it specifies in the request.
In one-to-one relationship, since the validation policy implies the validation
algorithm, it is superfluous to ask the client to specify both of them.
 
I believe that it is easier to adopt one-to-one relationship model, let one
validation policy imply a validation algorithm, and remove the validation
algorithm item from the syntax. With one-to-one relationship model, if
an organization want to support multiple validation algorithm, they can
define multiple validation policies and let each imply one validation algorithm
respectively.
 
The point is a validation policy can imply a validation algorithm, and therefore
the notion of validation algorithm can be removed from SCVP.
 
>>8. In th end of section 1.3, it says:
>> 
>>   "The basic certification path processing algorithm
>>    also supports the following parameters, which are
>>    defined in [PKIX-1] section 4: 
>>    
>>     The usage of the key contained in the certificate
>>     (e.g., key encipherment, key agreement, signature); and 
>>      
>>     Other application-specific purposes for which the
>>     certified public key may be used."
>> 
>>   Since "the basic certification path processing algorithm"
>>   is the algorithm defined in section 6 of RFC 3280, it is
>>   not proper to say that "the certification path processing
>>   algorithm" supports parameters related to checking
>>   key usages and extended key usage. Wee all know that
>>   the lgorithm defined in section 6 of RFC 3280 does not
>>   support these two kinds of parameters.
>> 
>>   I think the text will be more proper if it is changed to:
>> 
>>   "The basic validation policy defined by this specification
>>    also supports target certificate specific parameters
>>    for specifying the following checks: 
>>    
>>     The key usages specified in the target certificate
>>     (e.g., key encipherment, key agreement, signature)
>>     are acceptable; 
>>      
>>     The extended key usages specified in the target
>>     certificate are acceptable; and
>> 
>>     The subject name or the subject alternative name
>>     specified in the certificate meet the
>>     application-specific requirement."
>> 
>>   (Note that I move the name validation requirement here.)
>> 
>>   Again, this is a sign that the distinction between
>>   the notion of "validation policy" and the notion of
>>   "validation algorithm" in SCVP 17 is still vague.
>As noted above, it would not be correct to say that "the
>basic validation policy ... also supports...."  An algorithm
>supports certain parameters, since the algorithm specifies
>how the outputs are derived from the inputs.   So, the algorithm
>supports the parameters and the policy specifies values for the
>parameters.
>
>Hopefully the discussion above along with the example of a
>possible alternative validation algorithm helps to explain
>the distinction between the validation algorithm and validaiton policy.

As commented above.

>>9. I give the following comment before but get no response,
>>   so here I raise it again.
>> 
>>   There are situations where the certificate-using
>>   applications need to check whether a certificate
>>   was valid during a period of time, not only validate
>>   it with respect to a specific moment. For example,
>>   an application verifying an archived long-term
>>   signature might need to check whether a certificate
>>   was valid during a period of time in which the
>>   signature was generated. Therefore, I suggest to
>>   extend the structure of the "validationTime" field
>>   of the "Query" data type to support this. A CHOICE
>>   between a moment and a period of time is sufficient.
>
>I have not been involved with SCVP for very long, but I have
>not heard this one before and it is not clear why it is needed.  If
>you specify a validationTime equal to "end" (as defined in your ASN.1
>below) and the response is that the certificate is not valid, then it
>was not valid.  If the certificate was valid at time "end", then there
>must be a valid certification path in which all of the certificates were
>valid at time "end".  If the certificates were valid at time "end", then
>they could not have been revoked before time "end".  So, the only way the
>certification path could have been invalid at any point between "start"
>and "end" is if "start" preceded the notBefore time in any of the
>certificates in the certification path.  If this is a concern, you could
>send a second query with a validationTime of "start".  If the server
>reports that the certificate is valid at both "start" and "end", then it
>seems that one can safely conclude that the certificate was valid during
>the entire interval.

The current SCVP syntax and semantics only support validating certificates against
a retrospective moment. Please not that it is not the same to say "a certificate is
valid at time t1" as to say "a certificate is valid before time t1", because the validity of
the certificate could be suspended and then resumed before time t1. It is certainly
different with "a certificate is valid from time t2 to time t1".


>Under what circumstances would you expect the server to indicate that the
>certificate was valid at "start" and "end", but invalid for the period
>"[start ... end]"?  If there were any such circumstances, why would the
>client need to know this?
In some situations, it is not possible to determine the time (the moment) when
the private key was used to sign a signature. For example, to verify an archived
long-term signature, it might not be possible to determine the retrospective time
when the sigature is signed. Fortunately, the archived long-term signature might
be associated with content time-stamp and signature time-stamp for helping
in validating its validity. Suppose its content time-stamp was generated at time t2 and
its signature time-stamp was generated at time t1, then the verifier can conclude that
the signature must be signed between time t2 and time t1. To validate the archived
long-term signature, the verifier must make sure that the signer's certificate is valid
from time t2 to time t1.
 
You might be interested to read the paper at http://www.timestamp.cyber.ee/principles_en.pdf
to get the idea why the signer's certificate needed to be valid during the time period in which
the archived long-term signature was signed.

>Even if the feature is needed, is there any reason that it could
>not be added through the extensions mechanism after the base
>standard has been completed?
 
Yes, the feature certainly could be added through the extensions mechanism.
I simply think it is important for SCVP to support validating certificates
against a time period (not just a a retrospective moment), therefore I
suggest to add it now.
 
Wen-Cheng Wang



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1NCJH9c067964; Wed, 23 Feb 2005 04:19:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1NCJHNZ067963; Wed, 23 Feb 2005 04:19:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1NCJ9L8067878 for <[e-mail]>; Wed, 23 Feb 2005 04:19:09 -0800 (PST) (envelope-from [e-mail])
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j1NCJ3Nn010005 for <[e-mail]>; Wed, 23 Feb 2005 07:19:03 -0500
Received: from d01av04.pok.ibm.com (d01av04.pok.ibm.com [9.56.224.64]) by d01relay02.pok.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j1NCJ3eR059786 for <[e-mail]>; Wed, 23 Feb 2005 07:19:03 -0500
Received: from d01av04.pok.ibm.com (loopback [127.0.0.1]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1NCJ3Z7009240 for <[e-mail]>; Wed, 23 Feb 2005 07:19:03 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.56.228.115]) by d01av04.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j1NCJ30R009235; Wed, 23 Feb 2005 07:19:03 -0500
In-Reply-To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
To: "Stefan Santesson" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003
Message-ID: <[e-mail]>
From: Tom Gindin <[e-mail]>
Date: Wed, 23 Feb 2005 07:15:10 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 6.53IBM1 HF8|January 11, 2005) at 02/23/2005 07:19:02
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

      Stefan:

      I take a position between you and Denis here.  There are certainly
use cases for this extension other than indirect CRL.  However, I think the
other use cases are rarer than indirect CRL.  Here are the ones I see:
      The subject certificate has an AIA extension containing a URI for a
CRL, but no descriptor for a CA certificate.
      The subject certificate has a distribution point containing a URI
Distribution Point Name, and no AIA extension.
      In the case where the subject certificate has no CRL information,
this extension appears to be useful only if the CRL can be found without
assistance but the signing certificate cannot.  In what cases other than
CRL caching and indirect CRL does that frequently occur in your experience?
In the case of CRL caching, why isn't the signing certificate also cached?
      The case where the subject certificate contains a DN Distribution
Point Name seems to work out in a very similar way to the case where it has
no CRL information.

            Tom Gindin



                                                                                                                                       
                      "Stefan                                                                                                          
                      Santesson"               To:       "Denis Pinkas" <[e-mail]>                                        
                      <stefans@microsof        cc:       "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>             
                      t.com>                   Subject:  RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt                                  
                      Sent by:                                                                                                         
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      
                                                                                                                                       
                                                                                                                                       
                      02/15/2005 01:29                                                                                                 
                      PM                                                                                                               
                                                                                                                                       





Comments in-line;
(Some stuff deleted to keep volume down)

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)

>
> What about the following sentences picked from the document:
>
>     Standardized methods of finding the certificate of the CRL issuer
are
>     currently available either though an accessible directory location
or
>     through use of the Subject Information Access extension in
>     intermediary CA certificates.  These methods are however not
>     generally applicable, and they do not provide a generic solution
to
>     the problem.
>
> This is true only if indirect CRLs are being used, but the wording
> "indirect
> CRL" is absent from these lines.

[Stefan] Even if it was true ONLY for indirect CRL's, text would be
correct. But even more, this is NOT ONLY true for indirect CRL's. For
example, it is also true if your current CA infrastructure and its CA
certificates (which may be valid for another 5-20 years), don't include
a SIA extension. AIA in CRL's can be added to the infrastructure without
reissuing CA certificates, SIA can't. This is just 1 example. There are
more.

>
> > It is an optional mechanism to be used
> > by those who whish to use it to find the CRL signer cert.
>
>   ... which is really motivated when indirect CRLs are being used, but
> otherwise is not and the draft does not say it.
>

[Stefan] Because it is not useful only for indirect CRLs.

> > I think the motivation for allowing this extension in CRLs is
> > sufficiently stated in the document.
>
> It is not. In addition, adding an extension does not make sense unless
you
> tell how it should be used.
>

[Stefan] What is unclear for you?

> > Nothing you suggest is changing the
> > technical outline of the specified solution.
>
> In this case, the processing of this new extension may be explained
and
> this
> is not the case at this time.
>

[Stefan] What is missing?


<stuff deleted>
>
> >> The problem is that neither the abstract nor the introduction of
this
> >> draft is limiting the scope to indirect CRLs only.
>
> > [Stefan] That is because the scope of AIA in CRLs is not limited to
> > indirect CRLs.
>
>    .. but this extension does not add anything, if SIA used.
>

[Stefan] Yes it does. It offers direct lookup of the CRL issuer cert and
indicates that the CRL Issuer certificate actually IS available for
download, while SIA only offers pointer to location where the CRL issuer
cert MAY be found among other unrelated certificates, 1) if it is
present and 2) if the client is capable of finding it.


>
> > [Stefan] This is incorrect. The data in each DP of the CDP will tell
the
> > RP whether the DP points to an indirect CRL.
>
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     DistributionPointName
OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
>
>     DistributionPointName ::= CHOICE {
>          fullName                [0]     GeneralNames,
>          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
>
> Which field are you talking about ?

[Stefan] cRLIssuer

>
> >> The draft should thus address the two scenarios (i.e. an IDP is or
is
> >> not present) and for direct CRLs there is no "superiority" of the
new
> >> extension.
>
> > [Stefan] I don't see the point with that. The use of the AIA
extension
> > in CRL is not different for indirect or direct CRLs.
>
> With direct CRLs, there does not need to be any AIA extension, if the
SIA
> extension in CA certificates is present. This is not said and should
be
> said.
>

[Stefan] I don't see any purpose in saying that. This standard simply
recognizes the usefulness of allowing the already existing and deployed
AIA extension logic, not only in certificates, but also in CRLs. It is
not authoritative with regard to where and when this solution should or
should not be deployed.

The profile recognizes that there are other ways to build CRL paths.
This should be enough.








Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1N4UFgb023676; Tue, 22 Feb 2005 20:30:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1N4UFok023675; Tue, 22 Feb 2005 20:30:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from boole.openldap.org ([e-mail] [204.152.186.50]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1N4UFXJ023667 for <[e-mail]>; Tue, 22 Feb 2005 20:30:15 -0800 (PST) (envelope-from [e-mail])
Received: from gypsy.OpenLDAP.org (24-205-218-53.cs-cres.charterpipeline.net [24.205.218.53]) (authenticated bits=0) by boole.openldap.org (8.13.1/8.13.1) with ESMTP id j1N4UA1a097985 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 23 Feb 2005 04:30:10 GMT (envelope-from [e-mail])
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Tue, 22 Feb 2005 20:29:26 -0800
To: [e-mail]
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: draft-zeilenga-ldap-x509 -> PS
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please review and comment on the following individual submission:
        Lightweight Directory Access Protocol (LDAP)
        schema definitions for X.509 Certificates
        <draft-zeilenga-ldap-x509-01.txt>

I intend to make a decision by the end of IETF#62 whether
to recommend this revision for IESG consideration as a
Proposed Standard.  It is my hope that this document
will be published at the same time as the revised LDAP TS
being developed by the LDAPBIS WG.

Regards, Kurt





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1N0c81S006605; Tue, 22 Feb 2005 16:38:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1N0c8R9006604; Tue, 22 Feb 2005 16:38:08 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1N0c8ln006598 for <[e-mail]>; Tue, 22 Feb 2005 16:38:08 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-47.fastq.com [65.39.92.47]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id j1N0c7c03693; Tue, 22 Feb 2005 17:38:07 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: OCSP in IKEv2, draft -02
Date: Tue, 22 Feb 2005 17:35:12 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C51904.DCAF0B70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C51904.DCAF0B70
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

All,

Apologies for the typo.  The correct URL is

http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-02.txt

The document title should refer to OCSP, not OSCP.
                                    ^^        ^^
This will be corrected.

Mike

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Tuesday, February 22, 2005 5:03 PM
To: [e-mail]; [e-mail]
Subject: OCSP in IKEv2, draft -02


Colleagues,

Please consider the following contribution from Hannes Tschoefenig and =
myself.

http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-ocsp-02.txt

We propose two IKEv2 CERT payload extensions which taken together enable =
in-band use of OCSP in IKEv2.  This -02 draft incorporates comments to =
date.

Mike
------=_NextPart_000_0005_01C51904.DCAF0B70
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3Dtext/html;charset=3DUTF-8>
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><SPAN class=3D926482200-23022005><FONT face=3D"Courier New"=20
size=3D2>All,</FONT></SPAN></DIV>
<DIV><SPAN class=3D926482200-23022005><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D926482200-23022005><FONT face=3D"Courier New" =
size=3D2>Apologies=20
for the typo.&nbsp; The correct URL is</FONT></SPAN></DIV>
<DIV><SPAN class=3D926482200-23022005><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D926482200-23022005><FONT face=3D"Courier New" =
size=3D2><SPAN=20
class=3D271363323-22022005><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-=
02.txt">http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-=
02.txt</A></SPAN></FONT></SPAN></DIV>
<DIV><SPAN class=3D926482200-23022005><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D926482200-23022005><FONT face=3D"Courier New" =
size=3D2>The document=20
title </FONT></SPAN><SPAN class=3D926482200-23022005><FONT =
face=3D"Courier New"=20
size=3D2>should refer to OCSP, not OSCP.</FONT></SPAN></DIV>
<DIV><SPAN class=3D926482200-23022005><FONT face=3D"Courier New"=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
&nbsp;&nbsp;&nbsp;&nbsp;^^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;^^</FONT></SPAN></DIV>
<DIV><SPAN class=3D926482200-23022005><FONT face=3D"Courier New" =
size=3D2>This will be=20
corrected.</FONT></SPAN></DIV>
<DIV><SPAN class=3D926482200-23022005><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D926482200-23022005><FONT face=3D"Courier New"=20
size=3D2>Mike</FONT></SPAN></DIV>
<DIV><SPAN class=3D926482200-23022005><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3D"Courier New"=20
size=3D2>-----Original Message-----<BR><B>From:</B> Michael Myers=20
[mailto:[e-mail]]<BR><B>Sent:</B> Tuesday, February 22, 2005 =
5:03=20
PM<BR><B>To:</B> [e-mail]; [e-mail]<BR><B>Subject:</B> =
OCSP in=20
IKEv2, draft -02<BR><BR></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D271363323-22022005>Colleagues,</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D271363323-22022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D271363323-22022005>Please=20
consider the following contribution from Hannes Tschoefenig and=20
myself.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D271363323-22022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#000000 size=3D2><SPAN=20
class=3D271363323-22022005><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-ocsp-=
02.txt">http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-ocsp-=
02.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D271363323-22022005>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D271363323-22022005>We propose=20
two IKEv2 CERT payload extensions which taken together enable in-band =
use of=20
OCSP in IKEv2.&nbsp; This -02&nbsp;draft incorporates comments to=20
date.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D271363323-22022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D271363323-22022005>Mike</SPAN></FONT></DIV></SPAN></DIV></BODY></=
HTML>

------=_NextPart_000_0005_01C51904.DCAF0B70--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1N05Xwh003990; Tue, 22 Feb 2005 16:05:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1N05XvY003989; Tue, 22 Feb 2005 16:05:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1N05WWD003977 for <[e-mail]>; Tue, 22 Feb 2005 16:05:33 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-47.fastq.com [65.39.92.47]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id j1N05Sc01520; Tue, 22 Feb 2005 17:05:28 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: OCSP in IKEv2, draft -02
Date: Tue, 22 Feb 2005 17:02:32 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C51900.4C5B3F70"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0013_01C51900.4C5B3F70
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Colleagues,

Please consider the following contribution from Hannes Tschoefenig and =
myself.

http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-ocsp-02.txt

We propose two IKEv2 CERT payload extensions which taken together enable =
in-band use of OCSP in IKEv2.  This -02 draft incorporates comments to =
date.

Mike
------=_NextPart_000_0013_01C51900.4C5B3F70
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE></TITLE>
<META http-equiv=3DContent-Type content=3Dtext/html;charset=3DUTF-8>
<META content=3D"MSHTML 6.00.2800.1106" name=3DGENERATOR></HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D271363323-22022005>Colleagues,</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D271363323-22022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D271363323-22022005>Please=20
consider the following contribution from Hannes Tschoefenig and=20
myself.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN=20
class=3D271363323-22022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2><SPAN =
class=3D271363323-22022005><A=20
href=3D"http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-ocsp-=
02.txt">http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-ocsp-=
02.txt</A></SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D271363323-22022005><FONT face=3DArial color=3D#0000ff =
size=3D2>
<DIV><FONT face=3D"Courier New" color=3D#000000 size=3D2><SPAN=20
class=3D271363323-22022005>We propose two IKEv2 CERT payload extensions =
which=20
taken together enable in-band use of OCSP in IKEv2.&nbsp; This =
-02&nbsp;draft=20
incorporates comments to date.</SPAN></FONT></DIV>
<DIV><FONT face=3D"Courier New" color=3D#000000 size=3D2><SPAN=20
class=3D271363323-22022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" color=3D#000000 size=3D2><SPAN=20
class=3D271363323-22022005>Mike</SPAN></FONT></DIV></FONT></SPAN></DIV></=
BODY></HTML>

------=_NextPart_000_0013_01C51900.4C5B3F70--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LKsuF0049128; Mon, 21 Feb 2005 12:54:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1LKsubI049127; Mon, 21 Feb 2005 12:54:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1LKst4k049120 for <[e-mail]>; Mon, 21 Feb 2005 12:54:56 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14181; Mon, 21 Feb 2005 15:54:53 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-18.txt
Date: Mon, 21 Feb 2005 15:54:53 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-18.txt
	Pages		: 76
	Date		: 2005-2-21
	
SCVP allows a client to delegate certificate path construction and 
   certificate path validation to a server.  The path construction or 
   validation (e.g. making sure that none of the certificates in the 
   path are revoked) is performed according to a validation policy, 
   which contains one or more trust anchors.  It allows simplification 
   of client implementations and use of a set of predefined validation 
   policies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-18.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-scvp-18.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-scvp-18.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-18.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-scvp-18.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IMAP26065481; Fri, 18 Feb 2005 14:10:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1IMAP5O065480; Fri, 18 Feb 2005 14:10:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IMAIeD065468 for <[e-mail]>; Fri, 18 Feb 2005 14:10:18 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1IM9MaB024662; Fri, 18 Feb 2005 17:09:25 -0500
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1IM8SEX009047; Fri, 18 Feb 2005 17:08:31 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 18 Feb 2005 17:08:48 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Wen-Cheng Wang <[e-mail]>
CC: [e-mail]
Subject: Re: Comments to SCVP ID 17
References: <00a701c5150f$04a62fe0$4f85900a@wcwang>
In-Reply-To: <00a701c5150f$04a62fe0$4f85900a@wcwang>
Content-Type: multipart/alternative; boundary="------------040105060502080300030408"
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------040105060502080300030408
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Wen-Cheng Wang wrote:

> Dear list,
>  
> The following are my comments to SCVP 17.
>  
> Wen-Cheng Wang
>  
> 1. Typo in the last sentence of the last second
>    paragraph of page 67:
>  
>      "Therefore in these situations use of a URI
>       many be more attractive."
>    ->
>      "Therefore, in these situations use of a URI
>       may be more attractive."
>  
>    ("many be" -> "may be")

Done.

> 2. I suggest to let the version filed of request and
>    response messages default to v1(1).
>    That is:
>  
>       cvRequestVersion        INTEGER,
>    ->
>       cvRequestVersion        INTEGER DEFAULT v1(1),
>  
>       cvRsponseVersion        INTEGER
>    ->
>       cvRsponseVersion        INTEGER DEFAULT v1(1),
>  
>       vpRequestVersion        INTEGER,
>    ->
>       vpRequestVersion        INTEGER DEFAULT v1(1),
>  
>
>       vpRsponseVersion        INTEGER
>    ->
>       vpRsponseVersion        INTEGER DEFAULT v1(1),
>  
>    By doing this, the DER code of every request and
>    response message will save 3 bytes. I believe that
>    the SCVP version will stay at v1 for a long time,
>    asigning default value will allow clients and
>    servers do not bother to send the version number
>    in their requests and responses.
>  
>    Note that when a field become a field with DEFAULT
>    value, it might need change to a tagged field.

We set a DEFAULT value wherever we could do so without adding any more 
explicit tagging.  So, DEFAULT version numbers were set in CVRequest and 
ValPolRequest, but not CVResponse or ValPolResponse.

> 3. The tagging rule for ASN.1 syntax is odd. I list
>    the following as oddness:
>  
>       (1) In the "ValidationPolicy" data type, the tag
>           numbers skip from [4] to [6]. (There is no
>           tag [5].)
>       (2) In the "CVResponse" data type, the tag numbers
>           skip from [3] to [5]. (There is no tag [4].)
>  
>    I know that the editors of SCVP ID do not like to
>    discuss ASN.1 stylistic change, but the fix is simple.

Fixed.

> 4. I notice that SCVP 17 newly invented the term
>    "end certificate". Personally, I understand what
>    you mean by "end certificate" because I have been
>    tracking this ID for a long time. However, I am
>    worrying that using the term "end certificate"
>    might cause confusion because it might have
>    different interpretation for different direction
>    of path construction (forward or reverse). As a
>    technical spec, SCVP should be more precise in
>    adopting technical term. Therefore, I suggest to
>    use the term "target certificate" instead, not only
>    for eliminating possible confucion but also for
>    keeping alignment with RFC 3379.
>  
>    In addition, to make a more strong connection between
>    the term "target certificate" and the field of the
>    query message, I further suggest to change the field
>    name "queriedCerts" in the "Query" data type into
>    "targetCerts". Of course, related statements that
>    explain or refer to that field shoul also be modified
>    in response to the changing of the filed name.

The term "end certificate" is used in X.509 to refer to the final 
certificate in a certification path (which is usually, but not always, 
an end entity certificate).  However, it appears that the term was never 
used in RFC 3280.  On the other hand, I could only find one use of the 
term "target certificate" in RFC 3379, and it is never defined.  So it 
is not clear that "target" would be any better than "end".  But, I added 
a definition of "end certificate" after its first use.

> 5. After reading SCVP 17, I finally understand the
>    purpose of name validation algorithm. Before SCVP 17,
>    I always thought it is used to specify the name
>    matching rule (binary matching or X.500 name matching)
>    during certificate chaining. Now I understand that it
>    is use to specify the request for checking subject
>    name of the "target certificate". If it is so, I think
>    it is unreasonalbe to say:
>  
>      "The name validation is a refinement of the basic
>       validation algorithm"
>  
>    The basic validation algorithm is an algorithm
>    specifying conditions and rules for validating
>    the whole certification path. In terms of RFC 3379,
>    the basic validation algorithm specifies
>    "certification path requirements". On th contrary,
>    the name validation algorithm only specifies the
>    request for checking subject name of the "target
>    certificate". In terms of RFC 3379, the so-called
>    name validation algorithm is simply one of the
>    "end-entity certificate specific requirements".
>    (Now I prefer to call them "target certificate
>     specific requirements".)
>    It is much like "keyUsages" and "extendedKeyUsages"
>    checks, which are also "target certificate
>    specific requirements". To make the protocol
>    more resonable and aligned with RFC 3379, I
>    suggest to take "name validation algorithm" out
>    of section 3.2.4.2 and group it with "keyUsages"
>    and "extendedKeyUsages", because they all belong
>    to the category of "target certificate specific
>    requirements".

I believe that there is still a misunderstanding.  The name validation 
algorithm does not *only* specify checking the subject name in the end 
(or target) certificate.  When the name validation algorithm is 
specified, the server MUST perform all of the checks required by the 
Basic Validation Algorithm *in addition to* checking the subject name in 
the end (target) certificate.  That is why the name validation algorithm 
is referred to as a refinement of the basic validation algorithm.  As is 
stated in section 3.2.4.2.1 (Basic Validation Algorithm): "That is, none 
of the validation requirements in the basic algorithm may be omitted 
from any newly defined validation algorithms."

While name validation could have been implemented in a similar manner to 
the verification of keyUsage and extendedKeyUsage, specifying name 
validation as a different validation algorithm works just as well.  
Changing the ASN.1 to group name checking with keyUsages and 
extendedKeyUsages would simply be a styistic change that would have no 
real effect on the protocol.  While Tim and I made changes to the ASN.1 
to clean up the tagging since so many people insisted that they wanted 
the change, we really need to get this document finished, and so I think 
we should try to avoid making changes to the protocol that are unnecessary.

> 6. The current text of SCVP 17 tries to define a
>    "global" default validation policy and tries to
>    enforce all implementation to support that default
>    validation policy. This notion of "default validation
>    policy" does not align with the general understanding
>    of "default validation policy".
>   
>    The default validation policy defined in SCVP 17 is
>    actually simply a "basic" validation policy which
>    adopts the basic path validation algorithm defined
>    in RFC 3280, it is odd to specify it as the "global"
>    default validation policy. The general understanding
>    of "default validation policy" is the default one
>    among the organizational validation policies.
>    
>    I suggest to change term "default validation policy"
>    to "basic validation policy" to avoid confussion.
>    With this distinction of the notion of "default
>    validation policy" and the notion of the predefined
>    "basic validation policy, we can clearly say that
>  
>      The SCVP server can define multiple vlidation
>      policies and nominate one as its default
>      policy. If the client does not select a
>      validation policy in its request, the server
>      will use the default validation policy.
>  
>      The SCVP server MAY list the "basic validation
>      policy" defined in this specification as one
>      of its supported validation policies. The SCVP
>      server MAY select the "basic validation
>      policy" as its default policy.
>  
>    Please note that I also suggest that the
>    "validationPolicy" field in the "Query" data type
>    should be changed to be an optional field. This
>    allow the client to ommit the selection of
>    the validation policy in its request and simply
>    let the server use its default policy.

The "default validation policy" really is the default validation policy 
for the organiztion; it is not a "global" validation policy.

Section 3.2.4.1.1 states that the default validation policy MUST use the 
basic validation algorithm as its default validation algorithm, but each 
individual SCVP server is free to set the default values for all other 
parameters (e.g., trust anchors) of the validation policy as it wishes.  
The server specifies the default parameter values that it uses in its 
default validation policy in its validation policy response (in the 
defaultPolicyValues item).

So, if a client wants to use the organizational default validation 
policy, it simply specifies the OID for the default validation policy.  
Rather than make the validationPolicy field OPTIONAL, the editors chose 
to define an OID for the default validation policy.  The effect is the 
same, it is just a slightly different encoding.  This was done before I 
became involved with SCVP, but it may have been done in order to make it 
possible for the server to reject requests that specify the default 
policy OID (the server can simply not list that OID in the 
validationPolices item of its validation policy response.

> 7. The title of section 1.3 is "validation Policies", but
>    in the middle of that section it mentions:
>  
>      "The inputs to the basic certification path processing
>       algorithm used by SCVP are defined by [PKIX-1] in
>       section 6.1.1 and comprise:
>     
>         Certificate to be validated (by value or by reference);
>     
>         Validation time;
>     
>         Set of Trust Anchors (by value or by reference);
>     
>         The initial policy set;
>     
>         Initial inhibit policy mapping setting;
>     
>         Initial inhibit anyPolicy setting; and
>     
>         Initial require explicit policy setting."
>  
>    Isn't it be odd to define inputs to "validation
>    algorithm" in a section titled "validation
>    policies"?
>  
>    It reveals that even the authors of SCVP have no
>    good distinction between the notion of "validation
>    policy" and the notion of "validation algorithm",
>    no to say an implementator who try to implement SCVP.
>  
>    Even several reviewers (for example Denis and I)
>    clearly express that the notion of "validation algorithm"
>    is redundant to the notion of "validation policy"
>    and can be removed, how strange it is that the
>    authors always to reject the suggestions.
>  
>    Now, even with SCVP 17 which authors says "the text
>    for validation policies, validation algoriothms and
>    name validation algorithms has all been revised for
>    clarity, the distinction still vague.
>  
>    I sugest to remove the notion of "validation
>    algorithm" from SCVP, and change the text to:
>  
>      "The certification path specific parameters to the
>       basic validation policy defined by this specification
>       are defined by [PKIX-1] in its section 6.1.1 and
>       comprise:
>     
>         Certificate to be validated (by value or by reference);
>     
>         Validation time;
>     
>         Set of Trust Anchors (by value or by reference);
>     
>         The initial policy set;
>     
>         Initial inhibit policy mapping setting;
>     
>         Initial inhibit anyPolicy setting; and
>     
>         Initial require explicit policy setting."

I still believe that it is useful to have both a validation policy and a 
validation algorithm.  You suggest that it is odd for the validation 
policy to specify the inputs to the validation algorithm, but I 
disagree.  The basic validation algorithm, for example, is simply an 
algorithm.  It specifies the rules for creating a set of outputs from a 
set of inputs.  The validation algorithm does not, however, specify the 
*values* for the inputs.  The validation policy specifies not only what 
algorithm should be used to determine whether the certificate is valid, 
but also the *values* for the inputs to the algorithm (e.g., trust 
anchors, user initial policy set, etc.).

If the validation algorithm were removed as a parameter then it would 
not be possible to specify the use of an algorithm other than the basic 
validation algorithm for determining whether a certificate were valid 
given the other inputs specified by the policy.

At the moment, there are only two validation algorithms defined for use 
with SCVP and as you stated, subject name checking could have been 
implemented with defining a new validation algorithm.  However, 
including the validation algorithm as a parameter of the validation 
policy allows for other validation algorithms to be specified in the 
future.  For example, someone could define a validation algorithm that 
verifies whether a certificate is a valid proxy certificate according to 
RFC 3820.  This proxy certificate algorithm could either be used as the 
default validation algorithm for a validation policy or it use could be 
specified by the client in the request.  So, a client could, for 
example, specify the use of the default validation policy, but with the 
proxy certificate validation algorithm.  The result would be that the 
organizational default values would be used for the inputs (trusts 
anchors, user intial policy set, etc.), but the certificate(s) would be 
validated as a proxy certificate (RFC 3820) rather than being validated 
using the normal validation algorithm (RFC 3280).

> 8. In th end of section 1.3, it says:
>  
>    "The basic certification path processing algorithm
>     also supports the following parameters, which are
>     defined in [PKIX-1] section 4:
>    
>      The usage of the key contained in the certificate
>      (e.g., key encipherment, key agreement, signature); and
>      
>      Other application-specific purposes for which the
>      certified public key may be used."
>  
>    Since "the basic certification path processing algorithm"
>    is the algorithm defined in section 6 of RFC 3280, it is
>    not proper to say that "the certification path processing
>    algorithm" supports parameters related to checking
>    key usages and extended key usage. Wee all know that
>    the lgorithm defined in section 6 of RFC 3280 does not
>    support these two kinds of parameters.
>  
>    I think the text will be more proper if it is changed to:
>  
>    "The basic validation policy defined by this specification
>     also supports target certificate specific parameters
>     for specifying the following checks:
>    
>      The key usages specified in the target certificate
>      (e.g., key encipherment, key agreement, signature)
>      are acceptable;
>      
>      The extended key usages specified in the target
>      certificate are acceptable; and
>  
>      The subject name or the subject alternative name
>      specified in the certificate meet the
>      application-specific requirement."
>  
>    (Note that I move the name validation requirement here.)
>  
>    Again, this is a sign that the distinction between
>    the notion of "validation policy" and the notion of
>    "validation algorithm" in SCVP 17 is still vague.

As noted above, it would not be correct to say that "the basic 
validation policy ... also supports...."  An algorithm supports certain 
parameters, since the algorithm specifies how the outputs are derived 
from the inputs.   So, the algorithm supports the parameters and the 
policy specifies values for the parameters.

Hopefully the discussion above along with the example of a possible 
alternative validation algorithm helps to explain the distinction 
between the validation algorithm and validaiton policy.

> 9. I give the following comment before but get no response,
>    so here I raise it again.
>  
>    There are situations where the certificate-using
>    applications need to check whether a certificate
>    was valid during a period of time, not only validate
>    it with respect to a specific moment. For example,
>    an application verifying an archived long-term
>    signature might need to check whether a certificate
>    was valid during a period of time in which the
>    signature was generated. Therefore, I suggest to
>    extend the structure of the "validationTime" field
>    of the "Query" data type to support this. A CHOICE
>    between a moment and a period of time is sufficient.

I have not been involved with SCVP for very long, but I have not heard 
this one before and it is not clear why it is needed.  If you specify a 
validationTime equal to "end" (as defined in your ASN.1 below) and the 
response is that the certificate is not valid, then it was not valid.  
If the certificate was valid at time "end", then there must be a valid 
certification path in which all of the certificates were valid at time 
"end".  If the certificates were valid at time "end", then they could 
not have been revoked before time "end".  So, the only way the 
certification path could have been invalid at any point between "start" 
and "end" is if "start" preceded the notBefore time in any of the 
certificates in the certification path.  If this is a concern, you could 
send a second query with a validationTime of "start".  If the server 
reports that the certificate is valid at both "start" and "end", then it 
seems that one can safely conclude that the certificate was valid during 
the entire interval.

Under what circumstances would you expect the server to indicate that 
the certificate was valid at "start" and "end", but invalid for the 
period "[start ... end]"?  If there were any such circumstances, why 
would the client need to know this?

Even if the feature is needed, is there any reason that it could not be 
added through the extensions mechanism after the base standard has been 
completed?

> To summarize the above comments, the "Query" needs to
> be changed to the following:
>  
> (Of course, the related text in the ID should also be
> changed. However, at this moment, I simply use the
> following syntax to demonstrate my idea to editors
> and the list. If my proposal is accepted, then I
> will be happy to help revising the related text.)
>  
> Query ::= SEQUENCE {
>      targetCerts              CertReferences,
>      checks                   CertChecks,
>      wantBack                 WantBack,
>      validationPolicy     [2] ValidationPolicy OPTIONAL,
>      responseFlags        [3] ResponseFlags OPTIONAL,
>      serverContextInfo    [4] OCTET STRING OPTIONAL,
>      validationTime           ValidationTime OPTIONAL,
>      intermediateCerts    [7] CertBundle OPTIONAL,
>      revInfos             [8] RevocationInfos OPTIONAL,
>      producedAt           [9] GeneralizedTime OPTIONAL,
>      queryExtensions      [10] Extensions OPTIONAL }
>  
> ValidationTime ::= CHOICE {
>      moment               [5] GeneralizedTime,
>      period               [6] ValidationPeriod}
>  
> ValidationPeriod ::= SEQUENCE {
>      start                GeneralizedTime,
>      end                  GeneralizedTime}
>  
> ValidationPolicy ::= SEQUENCE {
>      validationPolRef               ValidationPolRef,
>      pathSpecificParams         [1] PathSpecificParams OPTIONAL,
>      targetCertSpecificParams   [2] TargetCertSpecificParams OPTIONAL}
>  
> PathSpecificParams ::= SEQUENCE {
>      userPolicySet          [1] SEQUENCE SIZE (1..MAX) OF OBJECT
>                                   IDENTIFIER OPTIONAL,
>      inhibitPolicyMapping   [2] BOOLEAN OPTIONAL,
>      requireExplicitPolicy  [3] BOOLEAN OPTIONAL,
>      inhibitAnyPolicy       [4] BOOLEAN OPTIONAL,
>      trustAnchors           [6] TrustAnchors OPTIONAL}
>  
> targetCertSpecificParams ::= SEQUENCE {
>      keyUsages              [1] KeyUsages OPTIONAL,
>      extendedKeyUsages      [2] SEQUENCE OF KeyPurposeId OPTIONAL,
>      nameValidation         [3] NameValidationAlgParms OPTIONAL}
>  
> NameValidationAlgParams ::= SEQUENCE {
>      nameCompAlgId          OBJECT IDENTIFIER,
>      validationNames        GeneralNames }
>  
> -- SCVP Validation Policy and Algorithm Identifiers
>    
> id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)
>           dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 }
>  
> -- SCVP Basic Validation Policy Identifier
>    
> id-svp-basicValPolicy OBJECT IDENTIFIER ::= { id-svp 1 }
>  
> -- SCVP Basic Validation Policy Errors
>    
> id-bvpe OBJECT IDENTIFIER ::= id-svp-basicValPolicy
>    
> id-bvpe-expired              OBJECT IDENTIFIER ::= { id-bvae 1 }
> id-bvpe-not-yet-valid        OBJECT IDENTIFIER ::= { id-bvae 2 }
> id-bvpe-wrong-anchor         OBJECT IDENTIFIER ::= { id-bvae 3 }
> id-bvpe-invalid-key-usage    OBJECT IDENTIFIER ::= { id-bvae 10 }
> id-bvpe-invalid-purpose      OBJECT IDENTIFIER ::= { id-bvae 11 }
> id-bvpe-revoked              OBJECT IDENTIFIER ::= { id-bvae 16 }
>    
> -- SCVP Name Validation Algorithm Identifier
>  
> -- SCVP Name Validation Algorithm DN comparison algorithm
>    
> id-nva-dnCompAlg   OBJECT IDENTIFIER ::= { id-svp 4 }
>    
> -- SCVP Name Validation Algorithm Errors
>    
> id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg
>    
> id-nvae-name-mismatch          OBJECT IDENTIFIER ::= { id-nvae 1 }
> id-nvae-no-name                OBJECT IDENTIFIER ::= { id-nvae 2 }
> id-nvae-unknown-alg            OBJECT IDENTIFIER ::= { id-nvae 3 }
> id-nvae-bad-name               OBJECT IDENTIFIER ::= { id-nvae 4 }
> id-nvae-bad-name-type          OBJECT IDENTIFIER ::= { id-nvae 5 }
> id-nvae-mixed-names            OBJECT IDENTIFIER ::= { id-nvae 6 }
>  
>  



--------------040105060502080300030408
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Wen-Cheng Wang wrote:
<blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang" type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta content="MSHTML 6.00.2800.1491" name="GENERATOR">
  <style></style>
  <div><font face="Courier New" size="2">Dear list,</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">The following are my comments
to SCVP 17.</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">Wen-Cheng Wang</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">1. Typo in the last sentence
of the last second<br>
   paragraph of page 67:</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">     "Therefore in these
situations use of a URI<br>
      many be more attractive."<br>
   -&gt;<br>
     "Therefore, in these situations use of a URI<br>
      may be more attractive."</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   ("many be" -&gt; "may be")</font><br>
  </div>
</blockquote>
Done.<br>
<blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang" type="cite">
  <div><font face="Courier New" size="2">2. I suggest to let the
version filed of request and<br>
   response messages default to v1(1).<br>
   That is:</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">      cvRequestVersion       
INTEGER,<br>
   -&gt;<br>
      cvRequestVersion        INTEGER DEFAULT v1(1),</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">      cvRsponseVersion       
INTEGER<br>
   -&gt;<br>
      cvRsponseVersion        INTEGER DEFAULT v1(1),</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">      vpRequestVersion       
INTEGER,<br>
   -&gt;<br>
      vpRequestVersion        INTEGER DEFAULT v1(1),</font></div>
  <div> </div>
  <div><br>
  <font face="Courier New" size="2">      vpRsponseVersion       
INTEGER<br>
   -&gt;<br>
      vpRsponseVersion        INTEGER DEFAULT v1(1),</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   By doing this, the DER code
of every request and<br>
   response message will save 3 bytes. I believe that<br>
   the SCVP version will stay at v1 for a long time,<br>
   asigning default value will allow clients and<br>
   servers do not bother to send the version number<br>
   in their requests and responses.</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   Note that when a field
become a field with DEFAULT<br>
   value, it might need change to a tagged field.</font></div>
</blockquote>
We set a DEFAULT value wherever we could do so without adding any more
explicit tagging.  So, DEFAULT version numbers were set in CVRequest
and ValPolRequest, but not CVResponse or ValPolResponse.<br>
<blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang" type="cite">
  <div><font face="Courier New" size="2">3. The tagging rule for ASN.1
syntax is odd. I list<br>
   the following as oddness:</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">      (1) In the
"ValidationPolicy" data type, the tag<br>
          numbers skip from [4] to [6]. (There is no<br>
          tag [5].)<br>
      (2) In the "CVResponse" data type, the tag numbers<br>
          skip from [3] to [5]. (There is no tag [4].)</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   I know that the editors of
SCVP ID do not like to<br>
   discuss ASN.1 stylistic change, but the fix is simple.</font></div>
</blockquote>
Fixed.<br>
<blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang" type="cite">
  <div><font face="Courier New" size="2">4. I notice that SCVP 17 newly
invented the term<br>
   "end certificate". Personally, I understand what<br>
   you mean by "end certificate" because I have been<br>
   tracking this ID for a long time. However, I am<br>
   worrying that using the term "end certificate"<br>
   might cause confusion because it might have<br>
   different interpretation for different direction<br>
   of path construction (forward or reverse). As a<br>
   technical spec, SCVP should be more precise in<br>
   adopting technical term. Therefore, I suggest to<br>
   use the term "target certificate" instead, not only<br>
   for eliminating possible confucion but also for<br>
   keeping alignment with RFC 3379.</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   In addition, to make a more
strong connection between<br>
   the term "target certificate" and the field of the<br>
   query message, I further suggest to change the field<br>
   name "queriedCerts" in the "Query" data type into<br>
   "targetCerts". Of course, related statements that<br>
   explain or refer to that field shoul also be modified<br>
   in response to the changing of the filed name.</font></div>
</blockquote>
The term "end certificate" is used in X.509 to refer to the final
certificate in a certification path (which is usually, but not always,
an end entity certificate).  However, it appears that the term was
never used in RFC 3280.  On the other hand, I could only find one use
of the term "target certificate" in RFC 3379, and it is never defined. 
So it is not clear that "target" would be any better than "end".  But,
I added a definition of "end certificate" after its first use.<br>
<blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang" type="cite">
  <div><font face="Courier New" size="2">5. After reading SCVP 17, I
finally understand the<br>
   purpose of name validation algorithm. Before SCVP 17,<br>
   I always thought it is used to specify the name<br>
   matching rule (binary matching or X.500 name matching)<br>
   during certificate chaining. Now I understand that it<br>
   is use to specify the request for checking subject<br>
   name of the "target certificate". If it is so, I think<br>
   it is unreasonalbe to say:</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">     "The name validation is a
refinement of the basic<br>
      validation algorithm"</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   The basic validation
algorithm is an algorithm<br>
   specifying conditions and rules for validating<br>
   the whole certification path. In terms of RFC 3379,<br>
   the basic validation algorithm specifies<br>
   "certification path requirements". On th contrary,<br>
   the name validation algorithm only specifies the<br>
   request for checking subject name of the "target<br>
   certificate". In terms of RFC 3379, the so-called<br>
   name validation algorithm is simply one of the<br>
   "end-entity certificate specific requirements".<br>
   (Now I prefer to call them "target certificate<br>
    specific requirements".)<br>
   It is much like "keyUsages" and "extendedKeyUsages"<br>
   checks, which are also "target certificate<br>
   specific requirements". To make the protocol<br>
   more resonable and aligned with RFC 3379, I<br>
   suggest to take "name validation algorithm" out<br>
   of section 3.2.4.2 and group it with "keyUsages"<br>
   and "extendedKeyUsages", because they all belong<br>
   to the category of "target certificate specific<br>
   requirements".</font></div>
</blockquote>
I believe that there is still a misunderstanding.  The name validation
algorithm does not *only* specify checking the subject name in the end
(or target) certificate.  When the name validation algorithm is
specified, the server MUST perform all of the checks required by the
Basic Validation Algorithm *in addition to* checking the subject name
in the end (target) certificate.  That is why the name validation
algorithm is referred to as a refinement of the basic validation
algorithm.  As is stated in section 3.2.4.2.1 (Basic Validation
Algorithm): "That is, none of the validation requirements in the basic
algorithm may be omitted from any newly defined validation algorithms."<br>
<br>
While name validation could have been implemented in a similar manner
to the verification of keyUsage and extendedKeyUsage, specifying name
validation as a different validation algorithm works just as well. 
Changing the ASN.1 to group name checking with keyUsages and
extendedKeyUsages would simply be a styistic change that would have no
real effect on the protocol.  While Tim and I made changes to the ASN.1
to clean up the tagging since so many people insisted that they wanted
the change, we really need to get this document finished, and so I
think we should try to avoid making changes to the protocol that are
unnecessary.<br>
<blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang" type="cite">
  <div><font face="Courier New" size="2">6. The current text of SCVP 17
tries to define a<br>
   "global" default validation policy and tries to<br>
   enforce all implementation to support that default<br>
   validation policy. This notion of "default validation<br>
   policy" does not align with the general understanding<br>
   of "default validation policy".<br>
   <br>
   The default validation policy defined in SCVP 17 is<br>
   actually simply a "basic" validation policy which<br>
   adopts the basic path validation algorithm defined<br>
   in RFC 3280, it is odd to specify it as the "global"<br>
   default validation policy. The general understanding<br>
   of "default validation policy" is the default one<br>
   among the organizational validation policies.<br>
    <br>
   I suggest to change term "default validation policy"<br>
   to "basic validation policy" to avoid confussion.<br>
   With this distinction of the notion of "default<br>
   validation policy" and the notion of the predefined<br>
   "basic validation policy, we can clearly say that</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">     The SCVP server can
define multiple vlidation<br>
     policies and nominate one as its default<br>
     policy. If the client does not select a<br>
     validation policy in its request, the server<br>
     will use the default validation policy.</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">     The SCVP server MAY list
the "basic validation<br>
     policy" defined in this specification as one<br>
     of its supported validation policies. The SCVP<br>
     server MAY select the "basic validation<br>
     policy" as its default policy.</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   Please note that I also
suggest that the<br>
   "validationPolicy" field in the "Query" data type<br>
   should be changed to be an optional field. This<br>
   allow the client to ommit the selection of<br>
   the validation policy in its request and simply<br>
   let the server use its default policy.</font></div>
</blockquote>
The "default validation policy" really is the default validation policy
for the organiztion; it is not a "global" validation policy.<br>
<br>
Section 3.2.4.1.1 states that the default validation policy MUST use
the basic validation algorithm as its default validation algorithm, but
each individual SCVP server is free to set the default values for all
other parameters (e.g., trust anchors) of the validation policy as it
wishes.  The server specifies the default parameter values that it uses
in its default validation policy in its validation policy response (in
the defaultPolicyValues item).<br>
<br>
So, if a client wants to use the organizational default validation
policy, it simply specifies the OID for the default validation policy. 
Rather than make the validationPolicy field OPTIONAL, the editors chose
to define an OID for the default validation policy.  The effect is the
same, it is just a slightly different encoding.  This was done before I
became involved with SCVP, but it may have been done in order to make
it possible for the server to reject requests that specify the default
policy OID (the server can simply not list that OID in the
validationPolices item of its validation policy response.<br>
<blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang" type="cite">
  <div><font face="Courier New" size="2">7. The title of section 1.3 is
"validation Policies", but<br>
   in the middle of that section it mentions:</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">     "The inputs to the basic
certification path processing<br>
      algorithm used by SCVP are defined by [PKIX-1] in<br>
      section 6.1.1 and comprise: <br>
     <br>
        Certificate to be validated (by value or by reference); <br>
     <br>
        Validation time; <br>
     <br>
        Set of Trust Anchors (by value or by reference); <br>
     <br>
        The initial policy set; <br>
     <br>
        Initial inhibit policy mapping setting; <br>
     <br>
        Initial inhibit anyPolicy setting; and <br>
     <br>
        Initial require explicit policy setting."</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   Isn't it be odd to define
inputs to "validation<br>
   algorithm" in a section titled "validation<br>
   policies"?</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   It reveals that even the
authors of SCVP have no<br>
   good distinction between the notion of "validation<br>
   policy" and the notion of "validation algorithm",<br>
   no to say an implementator who try to implement SCVP.</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   Even several reviewers (for
example Denis and I)<br>
   clearly express that the notion of "validation algorithm"<br>
   is redundant to the notion of "validation policy"<br>
   and can be removed, how strange it is that the<br>
   authors always to reject the suggestions.</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   Now, even with SCVP 17
which authors says "the text<br>
   for validation policies, validation algoriothms and<br>
   name validation algorithms has all been revised for<br>
   clarity, the distinction still vague.</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   I sugest to remove the
notion of "validation<br>
   algorithm" from SCVP, and change the text to:</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">     "The certification path
specific parameters to the<br>
      basic validation policy defined by this specification<br>
      are defined by [PKIX-1] in its section 6.1.1 and<br>
      comprise: <br>
     <br>
        Certificate to be validated (by value or by reference); <br>
     <br>
        Validation time; <br>
     <br>
        Set of Trust Anchors (by value or by reference); <br>
     <br>
        The initial policy set; <br>
     <br>
        Initial inhibit policy mapping setting; <br>
     <br>
        Initial inhibit anyPolicy setting; and <br>
     <br>
        Initial require explicit policy setting."</font></div>
</blockquote>
I still believe that it is useful to have both a validation policy and
a validation algorithm.  You suggest that it is odd for the validation
policy to specify the inputs to the validation algorithm, but I
disagree.  The basic validation algorithm, for example, is simply an
algorithm.  It specifies the rules for creating a set of outputs from a
set of inputs.  The validation algorithm does not, however, specify the
*values* for the inputs.  The validation policy specifies not only what
algorithm should be used to determine whether the certificate is valid,
but also the *values* for the inputs to the algorithm (e.g., trust
anchors, user initial policy set, etc.).<br>
<br>
If the validation algorithm were removed as a parameter then it would
not be possible to specify the use of an algorithm other than the basic
validation algorithm for determining whether a certificate were valid
given the other inputs specified by the policy.<br>
<br>
At the moment, there are only two validation algorithms defined for use
with SCVP and as you stated, subject name checking could have been
implemented with defining a new validation algorithm.  However,
including the validation algorithm as a parameter of the validation
policy allows for other validation algorithms to be specified in the
future.  For example, someone could define a validation algorithm that
verifies whether a certificate is a valid proxy certificate according
to RFC 3820.  This proxy certificate algorithm could either be used as
the default validation algorithm for a validation policy or it use
could be specified by the client in the request.  So, a client could,
for example, specify the use of the default validation policy, but with
the proxy certificate validation algorithm.  The result would be that
the organizational default values would be used for the inputs (trusts
anchors, user intial policy set, etc.), but the certificate(s) would be
validated as a proxy certificate (RFC 3820) rather than being validated
using the normal validation algorithm (RFC 3280).<br>
<blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang" type="cite">
  <div><font face="Courier New" size="2">8. In th end of section 1.3,
it says:</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   "The basic certification
path processing algorithm<br>
    also supports the following parameters, which are<br>
    defined in [PKIX-1] section 4: <br>
    <br>
     The usage of the key contained in the certificate<br>
     (e.g., key encipherment, key agreement, signature); and <br>
      <br>
     Other application-specific purposes for which the<br>
     certified public key may be used."</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   Since "the basic
certification path processing algorithm"<br>
   is the algorithm defined in section 6 of RFC 3280, it is<br>
   not proper to say that "the certification path processing<br>
   algorithm" supports parameters related to checking<br>
   key usages and extended key usage. Wee all know that<br>
   the lgorithm defined in section 6 of RFC 3280 does not<br>
   support these two kinds of parameters.</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   I think the text will be
more proper if it is changed to:</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   "The basic validation
policy defined by this specification<br>
    also supports target certificate specific parameters<br>
    for specifying the following checks: <br>
    <br>
     The key usages specified in the target certificate<br>
     (e.g., key encipherment, key agreement, signature)<br>
     are acceptable; <br>
      <br>
     The extended key usages specified in the target<br>
     certificate are acceptable; and</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">     The subject name or the
subject alternative name<br>
     specified in the certificate meet the<br>
     application-specific requirement."</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   (Note that I move the name
validation requirement here.)</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   Again, this is a sign that
the distinction between<br>
   the notion of "validation policy" and the notion of<br>
   "validation algorithm" in SCVP 17 is still vague.</font></div>
</blockquote>
As noted above, it would not be correct to say that "the basic
validation policy ... also supports...."  An algorithm supports certain
parameters, since the algorithm specifies how the outputs are derived
from the inputs.   So, the algorithm supports the parameters and the
policy specifies values for the parameters.<br>
<br>
Hopefully the discussion above along with the example of a possible
alternative validation algorithm helps to explain the distinction
between the validation algorithm and validaiton policy.<br>
<blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang" type="cite">
  <div><font face="Courier New" size="2">9. I give the following
comment before but get no response,<br>
   so here I raise it again.</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">   There are situations where
the certificate-using<br>
   applications need to check whether a certificate<br>
   was valid during a period of time, not only validate<br>
   it with respect to a specific moment. For example,<br>
   an application verifying an archived long-term<br>
   signature might need to check whether a certificate<br>
   was valid during a period of time in which the<br>
   signature was generated. Therefore, I suggest to<br>
   extend the structure of the "validationTime" field<br>
   of the "Query" data type to support this. A CHOICE<br>
   between a moment and a period of time is sufficient.</font><br>
  </div>
</blockquote>
I have not been involved with SCVP for very long, but I have not heard
this one before and it is not clear why it is needed.  If you specify a
validationTime equal to "end" (as defined in your ASN.1 below) and the
response is that the certificate is not valid, then it was not valid. 
If the certificate was valid at time "end", then there must be a valid
certification path in which all of the certificates were valid at time
"end".  If the certificates were valid at time "end", then they could
not have been revoked before time "end".  So, the only way the
certification path could have been invalid at any point between "start"
and "end" is if "start" preceded the notBefore time in any of the
certificates in the certification path.  If this is a concern, you
could send a second query with a validationTime of "start".  If the
server reports that the certificate is valid at both "start" and "end",
then it seems that one can safely conclude that the certificate was
valid during the entire interval.<br>
<br>
Under what circumstances would you expect the server to indicate that
the certificate was valid at "start" and "end", but invalid for the
period "[start ... end]"?  If there were any such circumstances, why
would the client need to know this?<br>
<br>
Even if the feature is needed, is there any reason that it could not be
added through the extensions mechanism after the base standard has been
completed?<br>
<blockquote cite="mid00a701c5150f$04a62fe0$4f85900a@wcwang" type="cite">
  <div><font face="Courier New" size="2">To summarize the above
comments, the "Query" needs to<br>
be changed to the following:</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">(Of course, the related text
in the ID should also be<br>
changed. However, at this moment, I simply use the<br>
following syntax to demonstrate my idea to editors<br>
and the list. If my proposal is accepted, then I<br>
will be happy to help revising the related text.)</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">Query ::= SEQUENCE { <br>
     targetCerts              CertReferences,<br>
     checks                   CertChecks, <br>
     wantBack                 WantBack, <br>
     validationPolicy     [2] ValidationPolicy OPTIONAL, <br>
     responseFlags        [3] ResponseFlags OPTIONAL, <br>
     serverContextInfo    [4] OCTET STRING OPTIONAL, <br>
     validationTime           ValidationTime OPTIONAL, <br>
     intermediateCerts    [7] CertBundle OPTIONAL, <br>
     revInfos             [8] RevocationInfos OPTIONAL, <br>
     producedAt           [9] GeneralizedTime OPTIONAL, <br>
     queryExtensions      [10] Extensions OPTIONAL }</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">ValidationTime ::= CHOICE {<br>
     moment               [5] GeneralizedTime,<br>
     period               [6] ValidationPeriod}</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">ValidationPeriod ::= SEQUENCE {<br>
     start                GeneralizedTime,<br>
     end                  GeneralizedTime}</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">ValidationPolicy ::= SEQUENCE
{ <br>
     validationPolRef               ValidationPolRef,<br>
     pathSpecificParams         [1] PathSpecificParams OPTIONAL,<br>
     targetCertSpecificParams   [2] TargetCertSpecificParams OPTIONAL}</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">PathSpecificParams ::=
SEQUENCE {<br>
     userPolicySet          [1] SEQUENCE SIZE (1..MAX) OF OBJECT <br>
                                  IDENTIFIER OPTIONAL, <br>
     inhibitPolicyMapping   [2] BOOLEAN OPTIONAL, <br>
     requireExplicitPolicy  [3] BOOLEAN OPTIONAL, <br>
     inhibitAnyPolicy       [4] BOOLEAN OPTIONAL, <br>
     trustAnchors           [6] TrustAnchors OPTIONAL}</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">targetCertSpecificParams ::=
SEQUENCE {<br>
     keyUsages              [1] KeyUsages OPTIONAL, <br>
     extendedKeyUsages      [2] SEQUENCE OF KeyPurposeId OPTIONAL,<br>
     nameValidation         [3] NameValidationAlgParms OPTIONAL}</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">NameValidationAlgParams ::=
SEQUENCE { <br>
     nameCompAlgId          OBJECT IDENTIFIER, <br>
     validationNames        GeneralNames }</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">-- SCVP Validation Policy and
Algorithm Identifiers <br>
    <br>
id-svp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) <br>
          dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 } </font></div>
  <div> </div>
  <div><font face="Courier New" size="2">-- SCVP Basic Validation
Policy Identifier<br>
    <br>
id-svp-basicValPolicy OBJECT IDENTIFIER ::= { id-svp 1 } <br>
 <br>
-- SCVP Basic Validation Policy Errors <br>
    <br>
id-bvpe OBJECT IDENTIFIER ::= id-svp-basicValPolicy<br>
    <br>
id-bvpe-expired              OBJECT IDENTIFIER ::= { id-bvae 1 } <br>
id-bvpe-not-yet-valid        OBJECT IDENTIFIER ::= { id-bvae 2 } <br>
id-bvpe-wrong-anchor         OBJECT IDENTIFIER ::= { id-bvae 3 } <br>
id-bvpe-invalid-key-usage    OBJECT IDENTIFIER ::= { id-bvae 10 } <br>
id-bvpe-invalid-purpose      OBJECT IDENTIFIER ::= { id-bvae 11 } <br>
id-bvpe-revoked              OBJECT IDENTIFIER ::= { id-bvae 16 } <br>
    <br>
-- SCVP Name Validation Algorithm Identifier</font></div>
  <div> </div>
  <div><font face="Courier New" size="2">-- SCVP Name Validation
Algorithm DN comparison algorithm <br>
    <br>
id-nva-dnCompAlg   OBJECT IDENTIFIER ::= { id-svp 4 } <br>
    <br>
-- SCVP Name Validation Algorithm Errors <br>
    <br>
id-nvae OBJECT IDENTIFIER ::= id-svp-nameValAlg <br>
    <br>
id-nvae-name-mismatch          OBJECT IDENTIFIER ::= { id-nvae 1 } <br>
id-nvae-no-name                OBJECT IDENTIFIER ::= { id-nvae 2 } <br>
id-nvae-unknown-alg            OBJECT IDENTIFIER ::= { id-nvae 3 } <br>
id-nvae-bad-name               OBJECT IDENTIFIER ::= { id-nvae 4 } <br>
id-nvae-bad-name-type          OBJECT IDENTIFIER ::= { id-nvae 5 } <br>
id-nvae-mixed-names            OBJECT IDENTIFIER ::= { id-nvae 6 } </font></div>
  <div> </div>
  <div> </div>
</blockquote>
<br>
</body>
</html>

--------------040105060502080300030408--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IHsiA6045124; Fri, 18 Feb 2005 09:54:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1IHsiEo045123; Fri, 18 Feb 2005 09:54:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IHsXhd045102 for <[e-mail]>; Fri, 18 Feb 2005 09:54:33 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1IHsKaN031888; Fri, 18 Feb 2005 12:54:21 -0500
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1IHrdEX028589; Fri, 18 Feb 2005 12:53:40 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 18 Feb 2005 12:53:58 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP Draft 17: Summary of changes
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: multipart/alternative; boundary="------------060804040803020006000508"
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.
--------------060804040803020006000508
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Peter Sylvester wrote:

>Thanks for the fast response. 
>
>I leave the comments for which I don't want to continue, and
>other are also finished. ;-)
>
>  
>
>>>3 -
>>>
>>>        "The checks item MUST contain a sequence of object identifiers
>>>  (OIDs)."  
>>>
>>>This sentence seems superflous to me, since the syntax already says that.
>>> 
>>>
>>>      
>>>
>>The text is consistent, and reinforces the information that an ASN.1 
>>mechanic would glean from the syntax.  There isn't any harm in leaving 
>>it, is there?
>>    
>>
>
>An additional MUST is something that you have to address explicitely in an
>interop test.
>  
>
We removed the word "MUST".

>>>4 - The usage of anyKeyUsage in the keyUsages is not explicitely defined.
>>>  (It can be guessed to a certain degree..)
>>> 
>>>
>>>      
>>>
>>The text currently says:
>>
>>  The keyUsages item may indicate either the particular key usages that
>>  are required by the client or that the client does not require any
>>  particular key usage.
>>
>>The anyKeyUsage is implicitly described by the "or that the client does 
>>not require any particular key usage".  This can be made more explicit 
>>if necessary.
>>
The text now says: "The keyUsages item may indicate either the 
particular key usages that are required by the client (using 
requiredKeyUsages) or that the client does not require any particular 
key usage (using anyKeyUsage)."

>>>  in other words, the requiredKeyUsages is defined, but not the anyKeyUsage
>>>
>>>  What is the difference of having a NULL option and not having coded
>>>  the optional field?
>>> 
>>>
>>>      
>>>
>>If the client includes the keyUsages item in the validationPolicy in the 
>>request and specifies the anyKeyUsage choice (encoded as NULL), the 
>>client is indicating that it does not want validation to fail as a 
>>result of the contents of the keyUsage extension in the end certificate 
>>(or the absence of the keyUsage extension from the certificate).
>>
>>    
>>
>>>  Note that if the requiredKeyUsages is used, non existance of the 
>>>  key usage in a cert extension is a match.
>>> 
>>>
>>>      
>>>
>>If the client omits the keyUsages item from the the validationPolicy in 
>>the request, the client is indicating that validation should be 
>>performed using the default value for the validation policy specified in 
>>the validationPolRef item.
>>
>>For example, a validation policy may, by default, require that the end 
>>certificate either not include a keyUsage extension or include a 
>>keyUsage extension with the digitalSignature bit set.  If the client 
>>specifies the use of this validation policy and omits the keyUsages item 
>>from the the validationPolicy in the request, then any end certificate 
>>that included a keyUsage extension without the digitalSignature bit set 
>>would be rejected.  If the client specifies the use of this validation 
>>policy but includes the keyUsages item with the anyKeyUsage choice, then 
>>the client is indicating that end certificates should be considered 
>>valid if they include keyUsage extensions with digitalSignature set to 0.
>>    
>>
>
>Couldn't just NULL be replaced by an empty sequence. 0..MAX but well, this again
>enters int ASN1 considerations, but it seem that the entendedkeyusage uses
>this approach? 
>
>As later on with one boolean, it seems that there is no way in the policy
>definition to indicate that a server prohibits a client to specify a value.
>Or, a server needs another configuration parameter to do this. IMO, this 
>does not seem to be compatible with the idea of what consitutes a policy.  
>
>  
>
>>>5- 3.2.4.9  
>>>
>>>  "If the client wishes to confirm 
>>>  the extended key usage, then it can communicate the usage it wants to
>>>  validate by the same extension using the same semantics as defined in
>>>  [PKIX-1]."
>>>  
>>>  
>>>  shouldn't 
>>>
>>>     SEQUENCE SIZE (1..MAX) OF KeyPurposeId
>>>
>>>  then be replaced by 
>>>
>>>     ExtKeyUsageSyntax
>>>
>>>  otherwise "same extension" is not well defined. (and even then)
>>>  
>>> 
>>>
>>>      
>>>
>>Acutally, in the validationPolicy structure, extendedKeyUsages is now 
>>defined as:
>>
>>         extendedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL
>>
>>Unlike in a certificate, there needed to be the option to include 
>>extendedKeyUsages in an SCVP request with an empty sequence.  The effect 
>>of including extendedKeyUsages in a request with an empty sequence is 
>>similar to the effect of including keyUsages with anyKeyUsage.  That is, 
>>the client is explcitly stating that it has no requirements with respect 
>>to extended key usages.
>>
>>We will re-word the above sentence to more clearly convey this.
>>    
>>
>
>Ok.
>
>  Is there a particular reason to have a NULL in the keyusages and not just
>  an empty sequence as here?
>
Yes.  extendedKeyUsages is defined as a sequence in which the end 
certificate must satisfy ALL of the elements of the sequence.  If the 
sequence if empty, then the end certificate trivially satisfies this.

keyUsages is defined as a sequence in which the end certificate must 
satisfy AT LEAST ONE of the elements of the sequence.  If the sequence 
were empty, it would not be possible for the certificate to satisfy at 
least one element from the sequence.

So, using "SEQUENCE OF KeyUsage" would not have worked for keyUsages.  
We could have used a structure similar to the KeyUsages for extended key 
usages, but the current structure is simpler and works just as well.

>>For relay, one uses requestorRef.  requestorRef allows for a sequence of 
>>identities, there is text in section 7 stating that the sequence needs 
>>to list all of the servers involved in processing the request, and there 
>>is a requirement that the response MUST copy the value of requestorRef 
>>from the request.
>>    
>>
>
>There requesterrefs are not identities which can be interpreted.
>
>They are globally unique values that may have defined relation to any 
>identity of a server, since one does not know how to interprete the octet string.
> 
>It may be useful to distunguish some opaque octet string stuff for loop
>control, although I stronly believe that remove the requestorRef
>octet strings and replacing this by a sequence in the requesterName
>is a better solution even for the loop control. 
>
>Note that earlier proposals only had octet strings for all purposes,
>and the requeserName was introduced silently after I had asked for
>guidance on how to encode an identifier in an octet string.  
>  
>
I had actually been tempted to change requestorRef to be a sequence of 
GeneralName since GeneralName seemed to be more appropriate than OCTET 
STRING for something that was supposed to hold an identifier.  A side 
effect of this change is that it would have specified the encodings for 
the identifiers as well.  However, there was a comment submitted for 
draft 16 indicating a need to be able to use a hash value as an 
identifier in requestorRef, an option that would have been effectively 
precluded if OCTET STRING had been changed to GeneralName.  Since I 
could not justify preventing use of a hash value and one can easily 
encode any GeneralName value in an OCTET STRING, I left the syntax for 
requestorRef unchanged.

>>>12 - 7:
>>>      "SCVP 
>>>  servers that support relay SHOULD populate this item with the DNS 
>>>  name of the server or the distinguished name in the server's 
>>>  certificate.  SCVP servers MAY choose other procedures for generating
>>>  identifiers that are unique within their community." 
>>>
>>>  I don't think the SHOULD is appropriate. DNS or distingushed name may 
>>>  not exist, and there is no indication who an octet string can be populated.
>>> 
>>>
>>>      
>>>
>>The entire paragraph reads:
>>
>>  To prevent false loop detection, servers should use identifiers that
>>  are unique within their network of cooperating SCVP servers.  SCVP
>>  servers that support relay SHOULD populate this item with the DNS
>>  name of the server or the distinguished name in the server's
>>  certificate.  SCVP servers MAY choose other procedures for generating
>>  identifiers that are unique within their community.
>>
>>As you state, a DNS name or DN may not be appropriate in all 
>>circumstances, which is why the document says "SHOULD" instead of 
>>"MUST".  The most important part is that identifiers be chosen "that are 
>>unique within their network of cooperating SCVP servers".  DNS names and 
>>DNs are just two types of identifiers that are likely to provide this 
>>property.
>>    
>>
>
>I am not saying this, I am saying that there is not even a hint to how
>create an octet string from such information, thus it is a SHOULD without
>specification. 
>
>Choosing something for uniqueness without knowning how it gets mapped into
>another space entities from other universes can land, and without knowing
>how you are mapped does not guarantee uniqueness.
>
>
>  
>
>>Since the only requirement is that the identifiers be "unique within 
>>their network of cooperating SCVP servers", there is no need to mandate 
>>how the identifiers are encoded within the OCTET STRING.
>>    
>>
>
>You have to ensure that the encoding is unique, not the source values.
>
>Although it is somewhat unlikely that two implementations would use different
>encodings of a dns name given a false match, or a false match with a DN, or so.  
>
>The historical example is
>
>  cs.some.ac.uk vs  uk.ac.some.cs 
>  
>
I think this is more of a theoretical concern than a practical concern.  
The odds that two servers that are part of the same SCVP relay network 
would select different identifiers for use in requestorRef, but that as 
a result of using different encoding techniques the encoded versions of 
their names are the same are extremely small.

>>>13 - 7:
>>>
>>>  It is quite nice to have loop detection for relaying,
>>>
>>>  but nothing is said how a relay constructs a request from 
>>>  a received on, and how a response is created from the 
>>>  received response.
>>> 
>>>  (E.g. what to do with requesterName in the request? )
>>>
>>>  The SCVP still does not contain a means to include the respons 
>>>  of another SCVP server in a response.
>>> 
>>>
>>>      
>>>
>>SCVP should not include a means to include the response of another SCVP 
>>server in a response.  An SCVP client sends a request to an SCVP server 
>>    
>>
>
>The requirements say, that
>
>  " When the certificate is valid
>   according to the validation policy, the server MUST, upon request,
>   include that information in the response."
>
>and 
>
>   "Such information may (not necessarily exclusively) consist of ...
>
>    or a DPV response from a DPV server that is
>    trusted under the validation policy."
>
>The requirement does not say that the response may only contain the information
>of the a relayed DPV response. You would loose some important information,
>WHO has told it under what policy, etc. 
>
>  
>
>>and gets a response from that server.  How the server derives the answer 
>>that it provides in the response is a local matter to the server.  The 
>>    
>>
>
>Yes, but it has to respond with ALL elements that have been used for
>making the decision if the clients request it. The server has no freedom here. 
>
>  
>
>>server may call upon the services of other SCVP servers in generating 
>>the response (i.e., the server may use SCVP relay), but that should be 
>>transparent to the reponse.  If the SCVP server were allowed to simply 
>>include the reponse from another SCVP server in its response, then this 
>>would impose more complexity on the SCVP client, which would need to 
>>parse responses that differed based on how the SCVP server derived the 
>>response.
>>    
>>
>
>I cannot follow at all your conclusion.
>
>It depends largely on what type of server you are talking. in a DPV case, 
>the client believes in the response, and may just show it to a user.
>
>Since parsing of a response structure is already one of its capabilities,
>I don't see the extra overhead (for the client), I am not talking about
>an end user.
> 
>   "For the client to be able prove to a third party that trusts the same
>   DPV server that the certificate validation was handled correctly, the
>   DPV response MUST be digitally signed, unless an error is reported.
>   The DPV server's certificate MUST authenticate the DPV server."
>
>The third party may only trust the relayed server and not the client's
>SCVP server. Assume an client SCVP server which operates as in the equivalent
>of the 'locally trusted' OCSP model, which is the normal one, 
>and a relay which is associated to a CA or common to some community. 
>
>I am not saying that a CA must have an associated SCVP server. 
>  
>
I believe that SCVP already includes all of the basic fields needed to 
support relay.  I don't believe that the base document needs to say any 
more.  When a server implements relay, it sends out an CVRequest and 
gets back a CVResponse just as a normal client would.  Guidance on what 
queries a server should send and what it should do with the response is 
just that.  Guidance on how to use a particular feature does not need to 
be in the base standard, it can be in a separate informational 
document.  If there is a desire for SCVP servers that implement relay to 
exchange auxiliary information, that information can always be included 
in non-critical response extensions.  So, I can not see any reason to 
hold up the base standard.  There are too many people who need this 
standard to be completed and who can use it even without guidance on how 
to implement relay.


Dave




--------------060804040803020006000508
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Peter Sylvester wrote:
<blockquote cite="[e-mail]"
 type="cite">
  <pre wrap="">Thanks for the fast response. 

I leave the comments for which I don't want to continue, and
other are also finished. ;-)

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">3 -

        "The checks item MUST contain a sequence of object identifiers
  (OIDs)."  

This sentence seems superflous to me, since the syntax already says that.
 

      </pre>
    </blockquote>
    <pre wrap="">The text is consistent, and reinforces the information that an ASN.1 
mechanic would glean from the syntax.  There isn't any harm in leaving 
it, is there?
    </pre>
  </blockquote>
  <pre wrap=""><!---->
An additional MUST is something that you have to address explicitely in an
interop test.
  </pre>
</blockquote>
We removed the word "MUST".<br>
<blockquote cite="[e-mail]"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">4 - The usage of anyKeyUsage in the keyUsages is not explicitely defined.
  (It can be guessed to a certain degree..)
 

      </pre>
    </blockquote>
    <pre wrap="">The text currently says:

  The keyUsages item may indicate either the particular key usages that
  are required by the client or that the client does not require any
  particular key usage.

The anyKeyUsage is implicitly described by the "or that the client does 
not require any particular key usage".  This can be made more explicit 
if necessary.</pre>
  </blockquote>
</blockquote>
The text now says: "The keyUsages item may indicate either the
particular key usages that are required by the client (using
requiredKeyUsages) or that the client does not require any particular
key usage (using anyKeyUsage)."<br>
<blockquote cite="[e-mail]"
 type="cite">
  <blockquote type="cite">
    <pre wrap=""></pre>
    <blockquote type="cite">
      <pre wrap="">  in other words, the requiredKeyUsages is defined, but not the anyKeyUsage

  What is the difference of having a NULL option and not having coded
  the optional field?
 

      </pre>
    </blockquote>
    <pre wrap="">If the client includes the keyUsages item in the validationPolicy in the 
request and specifies the anyKeyUsage choice (encoded as NULL), the 
client is indicating that it does not want validation to fail as a 
result of the contents of the keyUsage extension in the end certificate 
(or the absence of the keyUsage extension from the certificate).

    </pre>
    <blockquote type="cite">
      <pre wrap="">  Note that if the requiredKeyUsages is used, non existance of the 
  key usage in a cert extension is a match.
 

      </pre>
    </blockquote>
    <pre wrap="">If the client omits the keyUsages item from the the validationPolicy in 
the request, the client is indicating that validation should be 
performed using the default value for the validation policy specified in 
the validationPolRef item.

For example, a validation policy may, by default, require that the end 
certificate either not include a keyUsage extension or include a 
keyUsage extension with the digitalSignature bit set.  If the client 
specifies the use of this validation policy and omits the keyUsages item 
from the the validationPolicy in the request, then any end certificate 
that included a keyUsage extension without the digitalSignature bit set 
would be rejected.  If the client specifies the use of this validation 
policy but includes the keyUsages item with the anyKeyUsage choice, then 
the client is indicating that end certificates should be considered 
valid if they include keyUsage extensions with digitalSignature set to 0.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Couldn't just NULL be replaced by an empty sequence. 0..MAX but well, this again
enters int ASN1 considerations, but it seem that the entendedkeyusage uses
this approach? 

As later on with one boolean, it seems that there is no way in the policy
definition to indicate that a server prohibits a client to specify a value.
Or, a server needs another configuration parameter to do this. IMO, this 
does not seem to be compatible with the idea of what consitutes a policy.  

  </pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">5- 3.2.4.9  

  "If the client wishes to confirm 
  the extended key usage, then it can communicate the usage it wants to
  validate by the same extension using the same semantics as defined in
  [PKIX-1]."
  
  
  shouldn't 

     SEQUENCE SIZE (1..MAX) OF KeyPurposeId

  then be replaced by 

     ExtKeyUsageSyntax

  otherwise "same extension" is not well defined. (and even then)
  
 

      </pre>
    </blockquote>
    <pre wrap="">Acutally, in the validationPolicy structure, extendedKeyUsages is now 
defined as:

         extendedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL

Unlike in a certificate, there needed to be the option to include 
extendedKeyUsages in an SCVP request with an empty sequence.  The effect 
of including extendedKeyUsages in a request with an empty sequence is 
similar to the effect of including keyUsages with anyKeyUsage.  That is, 
the client is explcitly stating that it has no requirements with respect 
to extended key usages.

We will re-word the above sentence to more clearly convey this.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Ok.

  Is there a particular reason to have a NULL in the keyusages and not just
  an empty sequence as here?</pre>
</blockquote>
Yes.&nbsp; extendedKeyUsages is defined as a sequence in which the end
certificate must satisfy ALL of the elements of the sequence.&nbsp; If the
sequence if empty, then the end certificate trivially satisfies this.<br>
<br>
keyUsages is defined as a sequence in which the end certificate must
satisfy AT LEAST ONE of the elements of the sequence.&nbsp; If the sequence
were empty, it would not be possible for the certificate to satisfy at
least one element from the sequence.<br>
<br>
So, using "SEQUENCE OF KeyUsage" would not have worked for keyUsages.&nbsp;
We could have used a structure similar to the KeyUsages for extended
key usages, but the current structure is simpler and works just as well.
<blockquote cite="[e-mail]"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <pre wrap="">For relay, one uses requestorRef.  requestorRef allows for a sequence of 
identities, there is text in section 7 stating that the sequence needs 
to list all of the servers involved in processing the request, and there 
is a requirement that the response MUST copy the value of requestorRef 
from the request.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
There requesterrefs are not identities which can be interpreted.

They are globally unique values that may have defined relation to any 
identity of a server, since one does not know how to interprete the octet string.
 
It may be useful to distunguish some opaque octet string stuff for loop
control, although I stronly believe that remove the requestorRef
octet strings and replacing this by a sequence in the requesterName
is a better solution even for the loop control. 

Note that earlier proposals only had octet strings for all purposes,
and the requeserName was introduced silently after I had asked for
guidance on how to encode an identifier in an octet string.  
  </pre>
</blockquote>
I had actually been tempted to change requestorRef to be a sequence of
GeneralName since GeneralName seemed to be more appropriate than OCTET
STRING for something that was supposed to hold an identifier.&nbsp; A side
effect of this change is that it would have specified the encodings for
the identifiers as well.&nbsp; However, there was a comment submitted for
draft 16 indicating a need to be able to use a hash value as an
identifier in requestorRef, an option that would have been effectively
precluded if OCTET STRING had been changed to GeneralName.&nbsp; Since I
could not justify preventing use of a hash value and one can easily
encode any GeneralName value in an OCTET STRING, I left the syntax for
requestorRef unchanged.<br>
<blockquote cite="[e-mail]"
 type="cite">
  <pre wrap=""></pre>
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">12 - 7:
      "SCVP 
  servers that support relay SHOULD populate this item with the DNS 
  name of the server or the distinguished name in the server's 
  certificate.  SCVP servers MAY choose other procedures for generating
  identifiers that are unique within their community." 

  I don't think the SHOULD is appropriate. DNS or distingushed name may 
  not exist, and there is no indication who an octet string can be populated.
 

      </pre>
    </blockquote>
    <pre wrap="">The entire paragraph reads:

  To prevent false loop detection, servers should use identifiers that
  are unique within their network of cooperating SCVP servers.  SCVP
  servers that support relay SHOULD populate this item with the DNS
  name of the server or the distinguished name in the server's
  certificate.  SCVP servers MAY choose other procedures for generating
  identifiers that are unique within their community.

As you state, a DNS name or DN may not be appropriate in all 
circumstances, which is why the document says "SHOULD" instead of 
"MUST".  The most important part is that identifiers be chosen "that are 
unique within their network of cooperating SCVP servers".  DNS names and 
DNs are just two types of identifiers that are likely to provide this 
property.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I am not saying this, I am saying that there is not even a hint to how
create an octet string from such information, thus it is a SHOULD without
specification. 

Choosing something for uniqueness without knowning how it gets mapped into
another space entities from other universes can land, and without knowing
how you are mapped does not guarantee uniqueness.


  </pre>
  <blockquote type="cite">
    <pre wrap="">Since the only requirement is that the identifiers be "unique within 
their network of cooperating SCVP servers", there is no need to mandate 
how the identifiers are encoded within the OCTET STRING.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
You have to ensure that the encoding is unique, not the source values.

Although it is somewhat unlikely that two implementations would use different
encodings of a dns name given a false match, or a false match with a DN, or so.  

The historical example is

  cs.some.ac.uk vs  uk.ac.some.cs 
  </pre>
</blockquote>
I think this is more of a theoretical concern than a practical
concern.&nbsp; The odds that two servers that are part of the same SCVP
relay network would select different identifiers for use in
requestorRef, but that as a result of using different encoding
techniques the encoded versions of their names are the same are
extremely small.<br>
<blockquote cite="[e-mail]"
 type="cite">
  <blockquote type="cite">
    <blockquote type="cite">
      <pre wrap="">13 - 7:

  It is quite nice to have loop detection for relaying,

  but nothing is said how a relay constructs a request from 
  a received on, and how a response is created from the 
  received response.
 
  (E.g. what to do with requesterName in the request? )

  The SCVP still does not contain a means to include the respons 
  of another SCVP server in a response.
 

      </pre>
    </blockquote>
    <pre wrap="">SCVP should not include a means to include the response of another SCVP 
server in a response.  An SCVP client sends a request to an SCVP server 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
The requirements say, that

  " When the certificate is valid
   according to the validation policy, the server MUST, upon request,
   include that information in the response."

and 

   "Such information may (not necessarily exclusively) consist of ...

    or a DPV response from a DPV server that is
    trusted under the validation policy."

The requirement does not say that the response may only contain the information
of the a relayed DPV response. You would loose some important information,
WHO has told it under what policy, etc. 

  </pre>
  <blockquote type="cite">
    <pre wrap="">and gets a response from that server.  How the server derives the answer 
that it provides in the response is a local matter to the server.  The 
    </pre>
  </blockquote>
  <pre wrap=""><!---->
Yes, but it has to respond with ALL elements that have been used for
making the decision if the clients request it. The server has no freedom here. 

  </pre>
  <blockquote type="cite">
    <pre wrap="">server may call upon the services of other SCVP servers in generating 
the response (i.e., the server may use SCVP relay), but that should be 
transparent to the reponse.  If the SCVP server were allowed to simply 
include the reponse from another SCVP server in its response, then this 
would impose more complexity on the SCVP client, which would need to 
parse responses that differed based on how the SCVP server derived the 
response.
    </pre>
  </blockquote>
  <pre wrap=""><!---->
I cannot follow at all your conclusion.

It depends largely on what type of server you are talking. in a DPV case, 
the client believes in the response, and may just show it to a user.

Since parsing of a response structure is already one of its capabilities,
I don't see the extra overhead (for the client), I am not talking about
an end user.
 
   "For the client to be able prove to a third party that trusts the same
   DPV server that the certificate validation was handled correctly, the
   DPV response MUST be digitally signed, unless an error is reported.
   The DPV server's certificate MUST authenticate the DPV server."

The third party may only trust the relayed server and not the client's
SCVP server. Assume an client SCVP server which operates as in the equivalent
of the 'locally trusted' OCSP model, which is the normal one, 
and a relay which is associated to a CA or common to some community. 

I am not saying that a CA must have an associated SCVP server. 
  </pre>
</blockquote>
I believe that SCVP already includes all of the basic fields needed to
support relay.&nbsp; I don't believe that the base document needs to say any
more.&nbsp; When a server implements relay, it sends out an CVRequest and
gets back a CVResponse just as a normal client would.&nbsp; Guidance on what
queries a server should send and what it should do with the response is
just that.&nbsp; Guidance on how to use a particular feature does not need
to be in the base standard, it can be in a separate informational
document.&nbsp; If there is a desire for SCVP servers that implement relay
to exchange auxiliary information, that information can always be
included in non-critical response extensions.&nbsp; So, I can not see any
reason to hold up the base standard.&nbsp; There are too many people who
need this standard to be completed and who can use it even without
guidance on how to implement relay.<br>
<br>
<br>
Dave<br>
<br>
<br>
<br>
</body>
</html>

--------------060804040803020006000508--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IFBZup030621; Fri, 18 Feb 2005 07:11:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1IFBYuY030620; Fri, 18 Feb 2005 07:11:34 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1IFBU63030589 for <[e-mail]>; Fri, 18 Feb 2005 07:11:30 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1IFBIDL006378; Fri, 18 Feb 2005 10:11:19 -0500
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1IFAiEX018976; Fri, 18 Feb 2005 10:10:44 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 18 Feb 2005 10:11:03 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Seth Hitchings <[e-mail]>
CC: [e-mail], Tim Polk <[e-mail]>
Subject: Re: SCVP Draft 17: Summary of changes
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Seth Hitchings wrote:

>If you do decide to put together another draft to address some of the
>aesthetic issues, I'd like to see some of the tagging oddities (skipping
>from 4 to 6, for example) addressed.
>  
>
Several people have now commented stating that they believe it is 
important to modify the ASN.1 in SCVP so that explicit tags are 
sequential, etc.

So, Tim and I went through the document and made changes to the ASN.1 as 
follows:

(1) We renumbered explicit tags wherever there was a gap in the sequence 
in draft 17.
(2) We removed the explicit tagging where it was clear that the explicit 
tagging was not necessary.
(3) We defined DEFAULT values for several of the INTEGER and ENUMERATED 
values when defining a default value could be done without affecting the 
ASN.1 for any other fields.

I plan to submit draft 18 later today.  Below is a copy of all of the 
ASN.1 structures that have been changed since draft 17 (at least, I 
believe that this is all of them).

Dave

-----------------------------------------------------------------------------------


   CVRequest ::= SEQUENCE {
     cvRequestVersion           INTEGER DEFAULT 1,
     query                      Query,
     requestorRef           [0] SEQUENCE SIZE (1..MAX) OF OCTET STRING
                                  OPTIONAL,
     requestNonce           [1] OCTET STRING OPTIONAL,
     requestorName          [2] GeneralName OPTIONAL,
     reqestExtensions       [3] Extensions OPTIONAL }

   ValidationPolicy ::= SEQUENCE {
     validationPolRef           ValidationPolRef,
     validationAlg          [0] ValidationAlg OPTIONAL,
     userPolicySet          [1] SEQUENCE SIZE (1..MAX) OF OBJECT
                                  IDENTIFIER OPTIONAL,
     inhibitPolicyMapping   [2] BOOLEAN OPTIONAL,
     requireExplicitPolicy  [3] BOOLEAN OPTIONAL,
     inhibitAnyPolicy       [4] BOOLEAN OPTIONAL,
     trustAnchors           [5] TrustAnchors OPTIONAL,
     keyUsages              [6] KeyUsages OPTIONAL,
     extendedKeyUsages      [7] SEQUENCE OF KeyPurposeId OPTIONAL }

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

   ResponseStatus ::= SEQUENCE {
       statusCode               CVStatusCode DEFAULT okay,
       errorMessage             UTF8String OPTIONAL }

   CertReply ::= SEQUENCE {
     cert                       CertReference,
     replyStatus                ReplyStatus DEFAULT success,
     replyValTime               GeneralizedTime,
     replyChecks                ReplyChecks,
     replyWantBacks             ReplyWantBacks,
     validationErrors       [0] SEQUENCE SIZE (1..MAX) OF
                                  OBJECT IDENTIFIER OPTIONAL,
     nextUpdate             [1] GeneralizedTime OPTIONAL,
     certReplyExtensions    [2] Extensions OPTIONAL }

   ReplyCheck ::= SEQUENCE {
     check                      OBJECT IDENTIFIER,
     status                     INTEGER DEFAULT 0 }

   ValPolRequest ::= SEQUENCE {
     vpRequestVersion           INTEGER DEFAULT 1,
     requestNonce               OCTET STRING }

   ValPolResponse ::= SEQUENCE {
     vpResponseVersion                INTEGER,
     maxCVResponseVersion             INTEGER,
     maxVPResponseVersion             INTEGER,
     defaultPolicyID                  INTEGER,
     thisUpdate                       GeneralizedTime,
     nextUpdate                       GeneralizedTime OPTIONAL,
     validationPolices                SEQUENCE OF ValidationPolRef,
     validationAlgs                   SEQUENCE OF OBJECT IDENTIFIER,
     authPolicies                     SEQUENCE OF AuthPolicy,
     responseTypes                    ResponseTypes,
     defaultPolicyValues              RespValidationPolicy,
     revocationInfoTypes              RevocationInfoTypes,
     serverPublicKeys                 SEQUENCE OF KeyAgreePublicKey
                                        OPTIONAL,
     clockSkew                        INTEGER DEFAULT 10,
     requestNonce                     OCTET STRING OPTIONAL }

   AuthPolicy ::= CHOICE {
     authPolRefByOID       OBJECT IDENTIFIER,
     authPolRefByURI       IA5String }





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I1sis7020786; Thu, 17 Feb 2005 17:54:44 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1I1six2020785; Thu, 17 Feb 2005 17:54:44 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpc.itss.auckland.ac.nz (harpo.itss.auckland.ac.nz [130.216.190.13]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1I1sdEO020757 for <[e-mail]>; Thu, 17 Feb 2005 17:54:39 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id 7B28A33FAC; Fri, 18 Feb 2005 14:54:34 +1300 (NZDT)
Received: from smtpc.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26102-25; Fri, 18 Feb 2005 14:54:34 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpc.itss.auckland.ac.nz (Postfix) with ESMTP id F102534C55; Fri, 18 Feb 2005 14:54:29 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C6EDE37745; Fri, 18 Feb 2005 14:54:29 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1D1xLl-0003gz-00; Fri, 18 Feb 2005 14:54:33 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: PKIX implications of SHA-1 collisions
In-Reply-To: <00ec01c51504$52571b60$[e-mail]>
Message-Id: <[e-mail]>
Date: Fri, 18 Feb 2005 14:54:33 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Santosh Chokhani" <[e-mail]> writes:

>I agree with Peter that we should first understand the attack well enough
>(which I do not) before providing the solutions.

Ian Grigg has posted more info at 
http://www.financialcryptography.com/mt/archives/000357.html#more.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HLRZ8f095640; Thu, 17 Feb 2005 13:27:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HLRZJ9095639; Thu, 17 Feb 2005 13:27:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HLRVaT095615 for <[e-mail]>; Thu, 17 Feb 2005 13:27:34 -0800 (PST) (envelope-from [e-mail])
Received: from gw (52.san-jose-06-08rs.ca.dial-access.att.net[12.72.194.52]) by worldnet.att.net (mtiwmhc12) with SMTP id <200502172127081120027boge>; Thu, 17 Feb 2005 21:27:19 +0000
Message-ID: <031101c51537$7671ef10$010aff0a@gw>
From: "todd glassey" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, <[e-mail]>
References: <00ec01c51504$52571b60$[e-mail]>
Subject: Re: PKIX implications of SHA-1 collisions
Date: Thu, 17 Feb 2005 13:27:06 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It also may be true that in the risk models where SHA-1 is used it could be
fine still. This may be more as important as understanding the attack.

Todd

----- Original Message ----- 
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Sent: Thursday, February 17, 2005 7:21 AM
Subject: RE: PKIX implications of SHA-1 collisions


>
> I agree with Peter that we should first understand the attack well enough
> (which I do not) before providing the solutions.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
On
> Behalf Of Peter Gutmann
> Sent: Wednesday, February 16, 2005 11:27 PM
> To: [e-mail]; [e-mail]
> Subject: Re: PKIX implications of SHA-1 collisions
>
>
>
> Russ Housley <[e-mail]> writes:
>
> >I think this can documented very quickly in a BCP.  It should just be a
> >few pages.  I am willing to help write it.
>
> I think it'd be better to wait a bit to get the full details.  Here's a
> boilerplate summary I've been sending out to people who have mailed me
about
> this (personal opinion disclaimer, etc etc):
>
> - It only affects the use of SHA-1 as a hash function, not as a PRF or
HMAC,
>   so the core of SSH, SSL/TLS, etc etc are unaffected.
>
> - I've seen one report that it only affects the compression function and
not
>   the full hash function, which sounds plausible.  SHA-1 (and indeed all
of
>   the MD4-type UFN hashes) use a core compression function and then
perform
>   extra operations for the full hash function, so finding collisions in
the
>   full hash is somewhat more difficult than just the compression function.
>
> - It takes 2^69 ops on average to find a second input value that produces
> the
>   same output as the first one (the ambiguous phrasing here is meant to
>   indicate that probably what's meant is that the compression function
>   produces the same output rather than the full SHA-1 hash producing the
> same
>   output, see above).  The second input value can't be chosen by the
> attacker,
>   so the chances of forging a signature on structured data like a
> certificate
>   or CMS/PGP message are fairly remote.
>
> So while it's a very interesting result, it's more a hint to consider
moving
> to something else rather than time to hit the panic button.  RIPEMD-160
> still looks fairly secure, my gut feeling is that its dual-path
construction
> is safer than the SHA-1 derived SHA-256 et al, but I suspect that in the
> light of the current work on attacking UFN-based designs we'll be seeing a
> pile of new non-UFN hash functions in the same way that differential
> cryptanalysis spurred a burst of work on new ciphers.
>
> Peter.
>
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HK36O0087490; Thu, 17 Feb 2005 12:03:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HK36Xq087489; Thu, 17 Feb 2005 12:03:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HK35O1087478 for <[e-mail]>; Thu, 17 Feb 2005 12:03:05 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1HK17Ej013188 for <[e-mail]>; Thu, 17 Feb 2005 15:01:09 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1HJxlEY020689 for <[e-mail]>; Thu, 17 Feb 2005 14:59:47 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 17 Feb 2005 15:00:46 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: 3280bis available from NIST web site
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

FYI - the initial 3280bis draft was submitted by David Cooper before the 
-00 cutoff (with about sixteen hours to spare!), but has not shown up on 
the PKIX site as of yet.  The secretariat tends to get swamped with all the 
last minute document postings, so there can be a lag between submission and 
appearance of the document on the web site.  To give the WG the maximum 
review time before Minneapolis, David has also posted the initial draft of 
3280bis on a NIST website.  The document is available at the following URL:

http://csrc.nist.gov/pki/documents/PKIX/draft-ietf-pkix-rfc3280bis-00.txt

David has also created an html diff file that shows all changes from 3280 
to 3280bis.

http://csrc.nist.gov/pki/documents/PKIX/rfc3280todraft3280bis-00_diff.html

He has not had time to pull together a "disposition of comments" email, 
since I have him triple booked at the moment.   (In particular, he is 
working on SCVP as well.)  He will try to get that to the list before the 
meeting, but the diff file makes it very easy to identify the changes that 
have been made.

Many thanks to the design team (Sharon Boeyen, Dave Cooper, Stephen 
Farrell, Steve Hanna, Russ Housley, Stefan Santesson, and Warwick Ford) for 
their efforts, and especially to Dave for getting the draft together.

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HJPN9R083870; Thu, 17 Feb 2005 11:25:23 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HJPNod083869; Thu, 17 Feb 2005 11:25:23 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from csexchange1.corestreet.com (csexchange1.corestreet.com [68.162.232.134]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HJPLPi083847 for <[e-mail]>; Thu, 17 Feb 2005 11:25:22 -0800 (PST) (envelope-from [e-mail])
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: SCVP Draft 17: Summary of changes
Date: Thu, 17 Feb 2005 14:28:29 -0500
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0012_01C514FC.F363DF50"
Message-ID: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP Draft 17: Summary of changes
Thread-Index: AcUS8DR96smBm1GPQ9C25YUJAIXWKQCNWcQg
From: "Seth Hitchings" <[e-mail]>
To: "Tim Polk" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01C514FC.F363DF50
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Tim, 

I'd like to thank you and all of the other editors for pulling together
draft 17. I have no functional issues with this draft and would like to see
it achieve consensus. Our products will support draft 17 shortly.

If you do decide to put together another draft to address some of the
aesthetic issues, I'd like to see some of the tagging oddities (skipping
from 4 to 6, for example) addressed.

Thanks again,

Seth Hitchings
CoreStreet, Ltd.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Tim Polk
Sent: Monday, February 14, 2005 5:59 PM
To: [e-mail]
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: SCVP Draft 17: Summary of changes



Folks,

A new version of SCVP-17 was posted this afternoon.  IMHO, this version
fully satisfies RFC 3379, and is responsive to the comments submitted on the
WG mailing list.  Ever the optimist, I believe this draft is a strong
candidate for WG consensus.

Please spend some time reviewing the new draft so we can gauge consensus and
either tweak the document before the ID submission deadline (next
Monday!) or forward it to the ADs.

In the interest of an efficient review, here is a summary of the changes:

(1) All of the comments submitted to the list before Christmas were
reviewed.  Comments where Trevor had worked out a resolution on the list are
included here and many (but not all) of the remaining comments were
addressed.
(2) Inconsistencies between the text and any ASN.1 structures have been
resolved.
(3) Draft 16 used the term "signed" to refer to messages protected by either
a digital signature or a (H)MAC.  Draft 17 refers to these messages as
"protected" and reserves the word "signed" for messages protected by a
digital signature.
(4) The Diffie-Hellman based authentication method was changed from MUST to
SHOULD implement.
(5) The text for validation policies, validation algoriothms and name
validation algorithms has all been revised for clarity.
(6) A field has been added to the validation policy response message so that
servers can indicate the type(s) of status information the server is capable
of using, as required in RFC 3379.
(7) Validation policies are now required to include default values for all
parameters.  Draft -16 permitted servers to create policies where clients
were forced to supply values for some parameters.
(8) A requestor name field was added to the cv request message, so that
clients can include an asserted identity, as required in RFC 3379.  Servers
may still return an authenticated identity for the client if available.
(9) The key usage and extended key usage specifications have been enhanced
to permit a client to state "no requirements".
(10) The SCVP server now uses the ValdiationPolicy ASN.1 data structure from
the scvp request message to indicate its policy (in the scvp response and
policy response messages).
(11) The validation error OIDs associated with the basic validation
algorithm and name validation algorithm have been scrubbed.
(12) The keyPurposeID in the name validation algorithm was renamed
nameCompAlgId.  While some of the OIDs specified in this document correspond
to extended key usages, that is not a requirement of the specification.  The
important point was that the OID identified the algorithm used to compare
names in the end certificate.
(13) The isCA option to support partial path validation was removed from the
validation policy.  To use this feature securely, extensive additions to the
protocol were required to return a set of interim state variables from an
incomplete run of RFC 3280 Section 6.1 path validation.  The complexity was
considered an impediment to completion of the document and was not a
requirement in RFC 3379.  (This feature may be specified in a separate
document in the future, using the SCVP extensions mechanism.)
(14) Clients signal whether a cached response is acceptable using the
responseFlags rather than a wantback as in draft -16.
(15) When providing a list of certificates in the replyWantbacks in an scvp
response message, servers are now required to order the certificates
beginning with the end certificate.  (This is a requirement stated in RFC
3379.)
(16) When performing Diffie-Hellman where the client has an ephemeral key
and the server has a static key, the ephemeral key is conveyed in the
authenticated data wrapper rather than the cv request.  The draft does not
allow ephemeral - ephemeral but does support pre-shared keys.
(17) A new failure code was added to reply status to handle the case where
all checks were performed successfully, however one or more of the wantBacks
could not be satisfied.
(18) The replychecks for status checking were extended to cover the case
where the server cannot locate a source of status information.  (This
differentiates the failure from one where a source is known but network or
other errors prevented getting the information.)

Of the comments which were not incorporated into the document:

(A) The editors disagreed with the comment that path validation algorithms
other than that in RFC 3280 should be supported.  This is a PKIX WG
specification, and there is no requirement in RFC 3379 to support non-PKIX
path validation.  Consequently, this change was not made.
(B) The descriptions of validation algorithm and validation policy more
clearly delineate the differences, but I am unsure if all of that class of
comments are satisfied.
(C) Changes to ASN.1 syntax for elegance alone were not implemented; beauty
is in the eye of the beholder and that debate would never end.  ASN.1
changes were only made to enforce restrictions specified in the text or for
consistency with the text (e.g., add a missing item described elsewhere.)

Thanks,

Tim Polk


------=_NextPart_000_0012_01C514FC.F363DF50
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIIVzCCAoIw
ggHroAMCAQICAQQwDQYJKoZIhvcNAQEEBQAwUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0VxdWlm
YXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0xMB4X
DTk5MDYyMTA0MDAwMFoXDTIwMDYyMTA0MDAwMFowUzELMAkGA1UEBhMCVVMxHDAaBgNVBAoTE0Vx
dWlmYXggU2VjdXJlIEluYy4xJjAkBgNVBAMTHUVxdWlmYXggU2VjdXJlIGVCdXNpbmVzcyBDQS0x
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDOLxm8F7d33pOpX1oNF080GgyY9CLZWdTEaEbw
tDXFhQMgxq9FpSFRRUHrFlg2Mm/iUGJk+f1RnKok2fSdgyqHCiHTEjg0bI0Ablqg2ULuGiGV+VJM
VVrFDzhPRvpt+C411h186+LwsHWAyKkTrL6I7zpuq18qOGICsBJ7/o+mAwIDAQABo2YwZDARBglg
hkgBhvhCAQEEBAMCAAcwDwYDVR0TAQH/BAUwAwEB/zAfBgNVHSMEGDAWgBRKeDJSEdtZFjZe38EU
NkBqR3xMoTAdBgNVHQ4EFgQUSngyUhHbWRY2Xt/BFDZAakd8TKEwDQYJKoZIhvcNAQEEBQADgYEA
dVuomwMR5ulWTM35qUzADZrzzGVp5iV2zFm31lTDHc2ZrBndtIXV4D38YiCnhEtYZfHi+ZUhP/XU
flgeR4dUPlihtbX4Ku9x57zD9rFJRuLXoGvlVnqaJ5h8RmIU58n8bgMSeYA4HUiCjfwX/iqWK7Vi
pqY9vX+SWc1aKoKyN3kwggK8MIICJaADAgECAgIA2DANBgkqhkiG9w0BAQUFADBTMQswCQYDVQQG
EwJVUzEcMBoGA1UEChMTRXF1aWZheCBTZWN1cmUgSW5jLjEmMCQGA1UEAxMdRXF1aWZheCBTZWN1
cmUgZUJ1c2luZXNzIENBLTEwHhcNMDQwNjAyMTk1NzQyWhcNMjAwNjIxMDQwMDAwWjBSMQswCQYD
VQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENl
cnRpZmljYXRlIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAr0HhHsWZ2xkS
6BbojMXvdGPoRJLcAs2nUBSZ6XnJvnHxBwVvRUkqrCSBwKBurhjqGqe3oOxh6tC6wUuGhwLdhyWT
BSYO469PJUx02lyiohqUZ8u0yshCL35/lA+MkZubcmFxHsLlTPCkS/+A7PZwzIjKrLAUT0VmwNTL
TYEg1F8CAwEAAaOBnzCBnDAOBgNVHQ8BAf8EBAMCAYYwHQYDVR0OBBYEFNjsf5MYxWYDwxBsPAT2
d4U+/wu2MB8GA1UdIwQYMBaAFEp4MlIR21kWNl7fwRQ2QGpHfEyhMA8GA1UdEwEB/wQFMAMBAf8w
OQYDVR0fBDIwMDAuoCygKoYoaHR0cDovL2NybC5nZW90cnVzdC5jb20vY3Jscy9lYml6Y2ExLmNy
bDANBgkqhkiG9w0BAQUFAAOBgQDCHD9PBDwPPDktSLC/jRpe9Crdpj8Cj7GB1od44j1D+5IJji+w
rhuJ3tlR3p5MlzXGUEj8eFBtZymYBiWdLvIVqwMz2nYWBeFWXou6T+n4akcF708jM3MhFXP82ove
f/xJzw9IzlVmI9DjDrkL2wXXw/IR5XTP2iQYPcbxento6zCCAw0wggJ2oAMCAQICASEwDQYJKoZI
hvcNAQEFBQAwUjELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD0NvcmVTdHJlZXQgTHRkLjEpMCcGA1UE
AxMgQ29yZVN0cmVldCBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMDQwNzE0MTQyNDExWhcNMDUw
NzI4MTQyNDExWjBqMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMRcwFQYD
VQQDEw5TZXRoIEhpdGNoaW5nczEoMCYGCSqGSIb3DQEJARYZc2hpdGNoaW5nc0Bjb3Jlc3RyZWV0
LmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEApU+vUXkZtNS8zIbCun9DLBIPm3s0KGJ7
Zi8g1nng+sa1AQYZWl0+E66CVVtqz87H2rJeRuWPSTlP3aLBh24tHWHh5Yifx6PGJ2aDzYa6BMrz
+dscn7MASmDOk3gVJyl0enKKzhpfwu32YzgoftV0oMXk5iFYDbejwrTDJgGWEhUCAwEAAaOB2jCB
1zAOBgNVHQ8BAf8EBAMCBeAwPAYDVR0fBDUwMzAxoC+gLYYraHR0cDovL2NybC5nZW90cnVzdC5j
b20vY3Jscy9jb3Jlc3RyZWV0LmNybDAkBgNVHREEHTAbgRlzaGl0Y2hpbmdzQGNvcmVzdHJlZXQu
Y29tMB8GA1UdIwQYMBaAFNjsf5MYxWYDwxBsPAT2d4U+/wu2MEAGCCsGAQUFBwEBBDQwMjAwBggr
BgEFBQcwAYYkaHR0cDovL2dlb3RydXN0LW9jc3AuY29yZXN0cmVldC5jb20vMA0GCSqGSIb3DQEB
BQUAA4GBAHaph4KaKdbtUyu1sgOlvLWWR6N4MDr3Kecna8npqNUs6bs2Ym77r8UtdvNbVpC9QnLl
6YgxvEN/kLiOYCgakyA1kIFefeZEL1WiRFkFoW7Y2OAHowT20LaRoOJnDuOiqDPUJb6fI88JHBad
gIg4rjN62pQIhj63BoZ4OpFGDVzaMYICmTCCApUCAQEwVzBSMQswCQYDVQQGEwJVUzEYMBYGA1UE
ChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3JlU3RyZWV0IENlcnRpZmljYXRlIEF1dGhv
cml0eQIBITAJBgUrDgMCGgUAoIIBmDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3
DQEJBTEPFw0wNTAyMTcxOTI4MjlaMCMGCSqGSIb3DQEJBDEWBBR0qnHpyYVbn5RvymB1wbfG4J2S
LTBmBgkrBgEEAYI3EAQxWTBXMFIxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9Db3JlU3RyZWV0IEx0
ZC4xKTAnBgNVBAMTIENvcmVTdHJlZXQgQ2VydGlmaWNhdGUgQXV0aG9yaXR5AgEhMGcGCSqGSIb3
DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsO
AwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMGgGCyqGSIb3DQEJEAILMVmg
VzBSMQswCQYDVQQGEwJVUzEYMBYGA1UEChMPQ29yZVN0cmVldCBMdGQuMSkwJwYDVQQDEyBDb3Jl
U3RyZWV0IENlcnRpZmljYXRlIEF1dGhvcml0eQIBITANBgkqhkiG9w0BAQEFAASBgGIs/m5sriy9
q6gbHjp03r5Ug6m9YGnZARIePY8DYx6aychbvV2LxMQPZ/UtGU2m5BF45THIpIf3gHZ2RnAH7Zds
ztESEvdXdco9GyI393Z8IloQJmbSyAnMu2mOe2sVnNQfruwj9RcNxJIU4f7mgOyEg61/OLZj2y04
QNBaSbZqAAAAAAAA

------=_NextPart_000_0012_01C514FC.F363DF50--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HGcApv067741; Thu, 17 Feb 2005 08:38:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HGcAAB067740; Thu, 17 Feb 2005 08:38:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HGc56X067722 for <[e-mail]>; Thu, 17 Feb 2005 08:38:06 -0800 (PST) (envelope-from [e-mail])
Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j1HGbpLB008585; Fri, 18 Feb 2005 00:37:53 +0800
Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id j1HGbgis030934; Fri, 18 Feb 2005 00:37:43 +0800
Message-ID: <00a701c5150f$04a62fe0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>
Cc: "Tim Polk" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Comments to SCVP ID 17
Date: Fri, 18 Feb 2005 00:37:41 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01C51552.0DEF1100"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00A2_01C51552.0DEF1100
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Dear list,

The following are my comments to SCVP 17.

Wen-Cheng Wang

1. Typo in the last sentence of the last second
   paragraph of page 67:

     "Therefore in these situations use of a URI
      many be more attractive."
   ->
     "Therefore, in these situations use of a URI
      may be more attractive."

   ("many be" -> "may be")


2. I suggest to let the version filed of request and
   response messages default to v1(1).
   That is:

      cvRequestVersion        INTEGER,
   ->
      cvRequestVersion        INTEGER DEFAULT v1(1),

      cvRsponseVersion        INTEGER
   ->
      cvRsponseVersion        INTEGER DEFAULT v1(1),

      vpRequestVersion        INTEGER,
   ->
      vpRequestVersion        INTEGER DEFAULT v1(1),


      vpRsponseVersion        INTEGER
   ->
      vpRsponseVersion        INTEGER DEFAULT v1(1),

   By doing this, the DER code of every request and
   response message will save 3 bytes. I believe that
   the SCVP version will stay at v1 for a long time,
   asigning default value will allow clients and
   servers do not bother to send the version number
   in their requests and responses.

   Note that when a field become a field with DEFAULT
   value, it might need change to a tagged field.

3. The tagging rule for ASN.1 syntax is odd. I list
   the following as oddness:

      (1) In the "ValidationPolicy" data type, the tag
          numbers skip from [4] to [6]. (There is no
          tag [5].)
      (2) In the "CVResponse" data type, the tag numbers
          skip from [3] to [5]. (There is no tag [4].)

   I know that the editors of SCVP ID do not like to
   discuss ASN.1 stylistic change, but the fix is simple.

4. I notice that SCVP 17 newly invented the term
   "end certificate". Personally, I understand what
   you mean by "end certificate" because I have been
   tracking this ID for a long time. However, I am
   worrying that using the term "end certificate"
   might cause confusion because it might have
   different interpretation for different direction
   of path construction (forward or reverse). As a
   technical spec, SCVP should be more precise in
   adopting technical term. Therefore, I suggest to
   use the term "target certificate" instead, not only
   for eliminating possible confucion but also for
   keeping alignment with RFC 3379.

   In addition, to make a more strong connection between
   the term "target certificate" and the field of the
   query message, I further suggest to change the field
   name "queriedCerts" in the "Query" data type into
   "targetCerts". Of course, related statements that
   explain or refer to that field shoul also be modified
   in response to the changing of the filed name.

5. After reading SCVP 17, I finally understand the
   purpose of name validation algorithm. Before SCVP 17,
   I always thought it is used to specify the name
   matching rule (binary matching or X.500 name matching)
   during certificate chaining. Now I understand that it
   is use to specify the request for checking subject
   name of the "target certificate". If it is so, I think
   it is unreasonalbe to say:

     "The name validation is a refinement of the basic
      validation algorithm"

   The basic validation algorithm is an algorithm
   specifying conditions and rules for validating
   the whole certification path. In terms of RFC 3379,
   the basic validation algorithm specifies
   "certification path requirements". On th contrary,
   the name validation algorithm only specifies the
   request for checking subject name of the "target
   certificate". In terms of RFC 3379, the so-called
   name validation algorithm is simply one of the
   "end-entity certificate specific requirements".
   (Now I prefer to call them "target certificate
    specific requirements".)
   It is much like "keyUsages" and "extendedKeyUsages"
   checks, which are also "target certificate
   specific requirements". To make the protocol
   more resonable and aligned with RFC 3379, I
   suggest to take "name validation algorithm" out
   of section 3.2.4.2 and group it with "keyUsages"
   and "extendedKeyUsages", because they all belong
   to the category of "target certificate specific
   requirements".

6. The current text of SCVP 17 tries to define a
   "global" default validation policy and tries to
   enforce all implementation to support that default
   validation policy. This notion of "default validation
   policy" does not align with the general understanding
   of "default validation policy".
  =20
   The default validation policy defined in SCVP 17 is
   actually simply a "basic" validation policy which
   adopts the basic path validation algorithm defined
   in RFC 3280, it is odd to specify it as the "global"
   default validation policy. The general understanding
   of "default validation policy" is the default one
   among the organizational validation policies.
   =20
   I suggest to change term "default validation policy"
   to "basic validation policy" to avoid confussion.
   With this distinction of the notion of "default
   validation policy" and the notion of the predefined
   "basic validation policy, we can clearly say that

     The SCVP server can define multiple vlidation
     policies and nominate one as its default
     policy. If the client does not select a
     validation policy in its request, the server
     will use the default validation policy.

     The SCVP server MAY list the "basic validation
     policy" defined in this specification as one
     of its supported validation policies. The SCVP
     server MAY select the "basic validation
     policy" as its default policy.

   Please note that I also suggest that the
   "validationPolicy" field in the "Query" data type
   should be changed to be an optional field. This
   allow the client to ommit the selection of
   the validation policy in its request and simply
   let the server use its default policy.

7. The title of section 1.3 is "validation Policies", but
   in the middle of that section it mentions:

     "The inputs to the basic certification path processing
      algorithm used by SCVP are defined by [PKIX-1] in
      section 6.1.1 and comprise:=20
    =20
        Certificate to be validated (by value or by reference);=20
    =20
        Validation time;=20
    =20
        Set of Trust Anchors (by value or by reference);=20
    =20
        The initial policy set;=20
    =20
        Initial inhibit policy mapping setting;=20
    =20
        Initial inhibit anyPolicy setting; and=20
    =20
        Initial require explicit policy setting."

   Isn't it be odd to define inputs to "validation
   algorithm" in a section titled "validation
   policies"?

   It reveals that even the authors of SCVP have no
   good distinction between the notion of "validation
   policy" and the notion of "validation algorithm",
   no to say an implementator who try to implement SCVP.

   Even several reviewers (for example Denis and I)
   clearly express that the notion of "validation algorithm"
   is redundant to the notion of "validation policy"
   and can be removed, how strange it is that the
   authors always to reject the suggestions.

   Now, even with SCVP 17 which authors says "the text
   for validation policies, validation algoriothms and
   name validation algorithms has all been revised for
   clarity, the distinction still vague.

   I sugest to remove the notion of "validation
   algorithm" from SCVP, and change the text to:

     "The certification path specific parameters to the
      basic validation policy defined by this specification
      are defined by [PKIX-1] in its section 6.1.1 and
      comprise:=20
    =20
        Certificate to be validated (by value or by reference);=20
    =20
        Validation time;=20
    =20
        Set of Trust Anchors (by value or by reference);=20
    =20
        The initial policy set;=20
    =20
        Initial inhibit policy mapping setting;=20
    =20
        Initial inhibit anyPolicy setting; and=20
    =20
        Initial require explicit policy setting."

8. In th end of section 1.3, it says:

   "The basic certification path processing algorithm
    also supports the following parameters, which are
    defined in [PKIX-1] section 4:=20
   =20
     The usage of the key contained in the certificate
     (e.g., key encipherment, key agreement, signature); and=20
     =20
     Other application-specific purposes for which the
     certified public key may be used."

   Since "the basic certification path processing algorithm"
   is the algorithm defined in section 6 of RFC 3280, it is
   not proper to say that "the certification path processing
   algorithm" supports parameters related to checking
   key usages and extended key usage. Wee all know that
   the lgorithm defined in section 6 of RFC 3280 does not
   support these two kinds of parameters.

   I think the text will be more proper if it is changed to:

   "The basic validation policy defined by this specification
    also supports target certificate specific parameters
    for specifying the following checks:=20
   =20
     The key usages specified in the target certificate
     (e.g., key encipherment, key agreement, signature)
     are acceptable;=20
     =20
     The extended key usages specified in the target
     certificate are acceptable; and

     The subject name or the subject alternative name
     specified in the certificate meet the
     application-specific requirement."

   (Note that I move the name validation requirement here.)

   Again, this is a sign that the distinction between
   the notion of "validation policy" and the notion of
   "validation algorithm" in SCVP 17 is still vague.

9. I give the following comment before but get no response,
   so here I raise it again.

   There are situations where the certificate-using
   applications need to check whether a certificate
   was valid during a period of time, not only validate
   it with respect to a specific moment. For example,
   an application verifying an archived long-term
   signature might need to check whether a certificate
   was valid during a period of time in which the
   signature was generated. Therefore, I suggest to
   extend the structure of the "validationTime" field
   of the "Query" data type to support this. A CHOICE
   between a moment and a period of time is sufficient.


To summarize the above comments, the "Query" needs to
be changed to the following:

(Of course, the related text in the ID should also be
changed. However, at this moment, I simply use the
following syntax to demonstrate my idea to editors
and the list. If my proposal is accepted, then I
will be happy to help revising the related text.)

Query ::=3D SEQUENCE {=20
     targetCerts              CertReferences,
     checks                   CertChecks,=20
     wantBack                 WantBack,=20
     validationPolicy     [2] ValidationPolicy OPTIONAL,=20
     responseFlags        [3] ResponseFlags OPTIONAL,=20
     serverContextInfo    [4] OCTET STRING OPTIONAL,=20
     validationTime           ValidationTime OPTIONAL,=20
     intermediateCerts    [7] CertBundle OPTIONAL,=20
     revInfos             [8] RevocationInfos OPTIONAL,=20
     producedAt           [9] GeneralizedTime OPTIONAL,=20
     queryExtensions      [10] Extensions OPTIONAL }

ValidationTime ::=3D CHOICE {
     moment               [5] GeneralizedTime,
     period               [6] ValidationPeriod}

ValidationPeriod ::=3D SEQUENCE {
     start                GeneralizedTime,
     end                  GeneralizedTime}

ValidationPolicy ::=3D SEQUENCE {=20
     validationPolRef               ValidationPolRef,
     pathSpecificParams         [1] PathSpecificParams OPTIONAL,
     targetCertSpecificParams   [2] TargetCertSpecificParams OPTIONAL}

PathSpecificParams ::=3D SEQUENCE {
     userPolicySet          [1] SEQUENCE SIZE (1..MAX) OF OBJECT=20
                                  IDENTIFIER OPTIONAL,=20
     inhibitPolicyMapping   [2] BOOLEAN OPTIONAL,=20
     requireExplicitPolicy  [3] BOOLEAN OPTIONAL,=20
     inhibitAnyPolicy       [4] BOOLEAN OPTIONAL,=20
     trustAnchors           [6] TrustAnchors OPTIONAL}

targetCertSpecificParams ::=3D SEQUENCE {
     keyUsages              [1] KeyUsages OPTIONAL,=20
     extendedKeyUsages      [2] SEQUENCE OF KeyPurposeId OPTIONAL,
     nameValidation         [3] NameValidationAlgParms OPTIONAL}

NameValidationAlgParams ::=3D SEQUENCE {=20
     nameCompAlgId          OBJECT IDENTIFIER,=20
     validationNames        GeneralNames }

-- SCVP Validation Policy and Algorithm Identifiers=20
   =20
id-svp OBJECT IDENTIFIER ::=3D { iso(1) identified-organization(3)=20
          dod(6) internet(1) security(5) mechanisms(5) pkix(7) 19 }=20

-- SCVP Basic Validation Policy Identifier
   =20
id-svp-basicValPolicy OBJECT IDENTIFIER ::=3D { id-svp 1 }=20
=20
-- SCVP Basic Validation Policy Errors=20
   =20
id-bvpe OBJECT IDENTIFIER ::=3D id-svp-basicValPolicy
   =20
id-bvpe-expired              OBJECT IDENTIFIER ::=3D { id-bvae 1 }=20
id-bvpe-not-yet-valid        OBJECT IDENTIFIER ::=3D { id-bvae 2 }=20
id-bvpe-wrong-anchor         OBJECT IDENTIFIER ::=3D { id-bvae 3 }=20
id-bvpe-invalid-key-usage    OBJECT IDENTIFIER ::=3D { id-bvae 10 }=20
id-bvpe-invalid-purpose      OBJECT IDENTIFIER ::=3D { id-bvae 11 }=20
id-bvpe-revoked              OBJECT IDENTIFIER ::=3D { id-bvae 16 }=20
   =20
-- SCVP Name Validation Algorithm Identifier

-- SCVP Name Validation Algorithm DN comparison algorithm=20
   =20
id-nva-dnCompAlg   OBJECT IDENTIFIER ::=3D { id-svp 4 }=20
   =20
-- SCVP Name Validation Algorithm Errors=20
   =20
id-nvae OBJECT IDENTIFIER ::=3D id-svp-nameValAlg=20
   =20
id-nvae-name-mismatch          OBJECT IDENTIFIER ::=3D { id-nvae 1 }=20
id-nvae-no-name                OBJECT IDENTIFIER ::=3D { id-nvae 2 }=20
id-nvae-unknown-alg            OBJECT IDENTIFIER ::=3D { id-nvae 3 }=20
id-nvae-bad-name               OBJECT IDENTIFIER ::=3D { id-nvae 4 }=20
id-nvae-bad-name-type          OBJECT IDENTIFIER ::=3D { id-nvae 5 }=20
id-nvae-mixed-names            OBJECT IDENTIFIER ::=3D { id-nvae 6 }=20


------=_NextPart_000_00A2_01C51552.0DEF1100
Content-Type: text/html;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable

=EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8">
<META content=3D"MSHTML 6.00.2800.1491" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff background=3D"">
<DIV><FONT face=3D"Courier New" size=3D2>Dear list,</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>The following&nbsp;are my =
comments to SCVP=20
17.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Wen-Cheng Wang</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>1. Typo in the last sentence of =
the last=20
second<BR>&nbsp;&nbsp; paragraph of page 67:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; =
"Therefore in=20
these situations use of a URI<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; many be =
more=20
attractive."<BR>&nbsp;&nbsp; -&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
"Therefore, in=20
these situations use of a URI<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; may be =
more=20
attractive."</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; ("many be" -&gt; =
"may=20
be")</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><BR><FONT face=3D"Courier New" size=3D2>2. I suggest to let the =
version filed=20
of request and<BR>&nbsp;&nbsp; response messages default to=20
v1(1).<BR>&nbsp;&nbsp; That is:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
cvRequestVersion&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
INTEGER,<BR>&nbsp;&nbsp; -&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
cvRequestVersion&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
DEFAULT=20
v1(1),</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
cvRsponseVersion&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
INTEGER<BR>&nbsp;&nbsp; -&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
cvRsponseVersion&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
DEFAULT=20
v1(1),</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
vpRequestVersion&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
INTEGER,<BR>&nbsp;&nbsp; -&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
vpRequestVersion&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
DEFAULT=20
v1(1),</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><BR><FONT face=3D"Courier New" =
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
vpRsponseVersion&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
INTEGER<BR>&nbsp;&nbsp; -&gt;<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
vpRsponseVersion&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; INTEGER =
DEFAULT=20
v1(1),</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; By doing this, the =
DER code of=20
every request and<BR>&nbsp;&nbsp; response message will save 3 bytes. I =
believe=20
that<BR>&nbsp;&nbsp; the SCVP version will stay at v1 for a long=20
time,<BR>&nbsp;&nbsp; asigning default value will allow clients=20
and<BR>&nbsp;&nbsp; servers do not bother to send the version=20
number<BR>&nbsp;&nbsp; in their requests and responses.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; Note that when a =
field become=20
a field with DEFAULT<BR>&nbsp;&nbsp; value, it might need change to a =
tagged=20
field.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>3. The tagging rule for ASN.1 =
syntax is=20
odd. I list<BR>&nbsp;&nbsp; the following as oddness:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(1) In the=20
"ValidationPolicy" data type, the=20
tag<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; numbers =
skip from=20
[4] to [6]. (There is=20
no<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tag=20
[5].)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (2) In the "CVResponse" data =
type, the=20
tag numbers<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
skip from=20
[3] to [5]. (There is no tag [4].)</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; I know that the =
editors of=20
SCVP ID do not like to<BR>&nbsp;&nbsp; discuss ASN.1 stylistic change, =
but the=20
fix is simple.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>4. I notice that SCVP 17 newly =
invented the=20
term<BR>&nbsp;&nbsp; "end certificate". Personally, I understand=20
what<BR>&nbsp;&nbsp; you mean by "end certificate" because I have=20
been<BR>&nbsp;&nbsp; tracking this ID for a long time. However, I=20
am<BR>&nbsp;&nbsp; worrying that using the term "end=20
certificate"<BR>&nbsp;&nbsp; might cause confusion because it might=20
have<BR>&nbsp;&nbsp; different interpretation for different=20
direction<BR>&nbsp;&nbsp; of path construction (forward or reverse). As=20
a<BR>&nbsp;&nbsp; technical spec, SCVP should be more precise =
in<BR>&nbsp;&nbsp;=20
adopting technical term. Therefore, I suggest to<BR>&nbsp;&nbsp; use the =
term=20
"target certificate" instead, not only<BR>&nbsp;&nbsp; for eliminating =
possible=20
confucion but also for<BR>&nbsp;&nbsp; keeping alignment with RFC=20
3379.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; In addition, to =
make a more=20
strong connection between<BR>&nbsp;&nbsp; the term "target certificate" =
and the=20
field of the<BR>&nbsp;&nbsp; query message, I further suggest to change =
the=20
field<BR>&nbsp;&nbsp; name "queriedCerts" in the "Query" data type=20
into<BR>&nbsp;&nbsp; "targetCerts". Of course, related statements=20
that<BR>&nbsp;&nbsp; explain or refer to that field shoul also be=20
modified<BR>&nbsp;&nbsp; in response to the changing of the filed=20
name.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>5. After reading SCVP 17, I =
finally=20
understand the<BR>&nbsp;&nbsp; purpose of name validation algorithm. =
Before SCVP=20
17,<BR>&nbsp;&nbsp; I always thought it is used to specify the=20
name<BR>&nbsp;&nbsp; matching rule (binary matching or X.500 name=20
matching)<BR>&nbsp;&nbsp; during certificate chaining. Now I understand =
that=20
it<BR>&nbsp;&nbsp; is use to specify the request for checking=20
subject<BR>&nbsp;&nbsp; name of the "target certificate". If it is so, I =

think<BR>&nbsp;&nbsp; it is unreasonalbe to say:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; "The =
name=20
validation is a refinement of the =
basic<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
validation algorithm"</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; The basic =
validation algorithm=20
is an algorithm<BR>&nbsp;&nbsp; specifying conditions and rules for=20
validating<BR>&nbsp;&nbsp; the whole certification path. In terms of RFC =

3379,<BR>&nbsp;&nbsp; the basic validation algorithm =
specifies<BR>&nbsp;&nbsp;=20
"certification path requirements". On th contrary,<BR>&nbsp;&nbsp; the =
name=20
validation algorithm only specifies the<BR>&nbsp;&nbsp; request for =
checking=20
subject name of the "target<BR>&nbsp;&nbsp; certificate". In terms of =
RFC 3379,=20
the so-called<BR>&nbsp;&nbsp; name validation algorithm is simply one of =

the<BR>&nbsp;&nbsp; "end-entity certificate specific=20
requirements".<BR>&nbsp;&nbsp; (Now I prefer to call them "target=20
certificate<BR>&nbsp;&nbsp;&nbsp; specific =
requirements".)<BR>&nbsp;&nbsp; It is=20
much like "keyUsages" and "extendedKeyUsages"<BR>&nbsp;&nbsp; checks, =
which are=20
also "target certificate<BR>&nbsp;&nbsp; specific requirements". To make =
the=20
protocol<BR>&nbsp;&nbsp; more resonable and aligned with RFC 3379,=20
I<BR>&nbsp;&nbsp; suggest to take "name validation algorithm"=20
out<BR>&nbsp;&nbsp; of section 3.2.4.2 and group it with=20
"keyUsages"<BR>&nbsp;&nbsp; and "extendedKeyUsages", because they all=20
belong<BR>&nbsp;&nbsp; to the category of "target certificate=20
specific<BR>&nbsp;&nbsp; requirements".</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>6. The current text of SCVP 17 =
tries to=20
define a<BR>&nbsp;&nbsp; "global" default validation policy and tries=20
to<BR>&nbsp;&nbsp; enforce all implementation to support that=20
default<BR>&nbsp;&nbsp; validation policy. This notion of "default=20
validation<BR>&nbsp;&nbsp; policy" does not align with the general=20
understanding<BR>&nbsp;&nbsp; of "default validation =
policy".<BR>&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp; The default validation policy defined in SCVP 17=20
is<BR>&nbsp;&nbsp; actually simply a "basic" validation policy=20
which<BR>&nbsp;&nbsp; adopts the basic path validation algorithm=20
defined<BR>&nbsp;&nbsp; in RFC 3280, it is odd to specify it as the=20
"global"<BR>&nbsp;&nbsp; default validation policy. The general=20
understanding<BR>&nbsp;&nbsp; of "default validation policy" is the =
default=20
one<BR>&nbsp;&nbsp; among the organizational validation=20
policies.<BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp; I suggest to change =
term=20
"default validation policy"<BR>&nbsp;&nbsp; to "basic validation policy" =
to=20
avoid confussion.<BR>&nbsp;&nbsp; With this distinction of the notion of =

"default<BR>&nbsp;&nbsp; validation policy" and the notion of the=20
predefined<BR>&nbsp;&nbsp; "basic validation policy, we can clearly say=20
that</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; The =
SCVP server=20
can define multiple vlidation<BR>&nbsp;&nbsp;&nbsp;&nbsp; policies and =
nominate=20
one as its default<BR>&nbsp;&nbsp;&nbsp;&nbsp; policy. If the client =
does not=20
select a<BR>&nbsp;&nbsp;&nbsp;&nbsp; validation policy in its request, =
the=20
server<BR>&nbsp;&nbsp;&nbsp;&nbsp; will use the default validation=20
policy.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; The =
SCVP server=20
MAY list the "basic validation<BR>&nbsp;&nbsp;&nbsp;&nbsp; policy" =
defined in=20
this specification as one<BR>&nbsp;&nbsp;&nbsp;&nbsp; of its supported=20
validation policies. The SCVP<BR>&nbsp;&nbsp;&nbsp;&nbsp; server MAY =
select the=20
"basic validation<BR>&nbsp;&nbsp;&nbsp;&nbsp; policy" as its default=20
policy.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; Please note that I =
also=20
suggest that the<BR>&nbsp;&nbsp; "validationPolicy" field in the "Query" =
data=20
type<BR>&nbsp;&nbsp; should be changed to be an optional field.=20
This<BR>&nbsp;&nbsp; allow the client to ommit the selection =
of<BR>&nbsp;&nbsp;=20
the validation policy in its request and simply<BR>&nbsp;&nbsp; let the =
server=20
use its default policy.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>7. The title of section 1.3 is =
"validation=20
Policies", but<BR>&nbsp;&nbsp; in the middle of that section it=20
mentions:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; "The =
inputs to the=20
basic certification path processing<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
algorithm=20
used by SCVP are defined by [PKIX-1] =
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
section 6.1.1 and comprise: <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Certificate to be =
validated (by=20
value or by reference); <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Validation time;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Set=20
of Trust Anchors (by value or by reference); =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The initial policy set;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Initial inhibit policy mapping setting; <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Initial inhibit anyPolicy =

setting; and <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Initial require explicit =
policy=20
setting."</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; Isn't it be odd to =
define=20
inputs to "validation<BR>&nbsp;&nbsp; algorithm" in a section titled=20
"validation<BR>&nbsp;&nbsp; policies"?</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; It reveals that =
even the=20
authors of SCVP have no<BR>&nbsp;&nbsp; good distinction between the =
notion of=20
"validation<BR>&nbsp;&nbsp; policy" and the notion of "validation=20
algorithm",<BR>&nbsp;&nbsp; no to say an implementator who try to =
implement=20
SCVP.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; Even several =
reviewers (for=20
example Denis and I)<BR>&nbsp;&nbsp; clearly express that the notion of=20
"validation algorithm"<BR>&nbsp;&nbsp; is redundant to the notion of =
"validation=20
policy"<BR>&nbsp;&nbsp; and can be removed, how strange it is that=20
the<BR>&nbsp;&nbsp; authors always to reject the =
suggestions.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; Now, even with =
SCVP 17 which=20
authors says "the text<BR>&nbsp;&nbsp; for validation policies, =
validation=20
algoriothms and<BR>&nbsp;&nbsp; name validation algorithms has all been =
revised=20
for<BR>&nbsp;&nbsp; clarity, the distinction still vague.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; I sugest to remove =
the notion=20
of "validation<BR>&nbsp;&nbsp; algorithm" from SCVP, and change the text =

to:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; "The =
certification=20
path specific parameters to the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; basic=20
validation policy defined by this=20
specification<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; are defined by [PKIX-1] =
in its=20
section 6.1.1 and<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; comprise:=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Certificate to be validated (by value or by reference);=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Validation time; <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Set of Trust Anchors (by =
value or=20
by reference); <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The initial policy set;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
Initial inhibit policy mapping setting; <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Initial inhibit anyPolicy =

setting; and <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Initial require explicit =
policy=20
setting."</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>8. In th end of section 1.3, it =

says:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; "The basic =
certification path=20
processing algorithm<BR>&nbsp;&nbsp;&nbsp; also supports the following=20
parameters, which are<BR>&nbsp;&nbsp;&nbsp; defined in [PKIX-1] section =
4:=20
<BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; The usage of the key =

contained in the certificate<BR>&nbsp;&nbsp;&nbsp;&nbsp; (e.g., key=20
encipherment, key agreement, signature); and =
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp; Other application-specific purposes for =
which=20
the<BR>&nbsp;&nbsp;&nbsp;&nbsp; certified public key may be =
used."</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; Since "the basic =
certification=20
path processing algorithm"<BR>&nbsp;&nbsp; is the algorithm defined in =
section 6=20
of RFC 3280, it is<BR>&nbsp;&nbsp; not proper to say that "the =
certification=20
path processing<BR>&nbsp;&nbsp; algorithm" supports parameters related =
to=20
checking<BR>&nbsp;&nbsp; key usages and extended key usage. Wee all know =

that<BR>&nbsp;&nbsp; the lgorithm defined in section 6 of RFC 3280 does=20
not<BR>&nbsp;&nbsp; support these two kinds of parameters.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; I think the text =
will be more=20
proper if it is changed to:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; "The basic =
validation policy=20
defined by this specification<BR>&nbsp;&nbsp;&nbsp; also supports target =

certificate specific parameters<BR>&nbsp;&nbsp;&nbsp; for specifying the =

following checks: <BR>&nbsp;&nbsp;&nbsp; <BR>&nbsp;&nbsp;&nbsp;&nbsp; =
The key=20
usages specified in the target certificate<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
(e.g.,=20
key encipherment, key agreement, signature)<BR>&nbsp;&nbsp;&nbsp;&nbsp; =
are=20
acceptable; <BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
<BR>&nbsp;&nbsp;&nbsp;&nbsp; The=20
extended key usages specified in the target<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
certificate are acceptable; and</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp;&nbsp;&nbsp; The =
subject name=20
or the subject alternative name<BR>&nbsp;&nbsp;&nbsp;&nbsp; specified in =
the=20
certificate meet the<BR>&nbsp;&nbsp;&nbsp;&nbsp; application-specific=20
requirement."</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; (Note that I move =
the name=20
validation requirement here.)</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; Again, this is a =
sign that the=20
distinction between<BR>&nbsp;&nbsp; the notion of "validation policy" =
and the=20
notion of<BR>&nbsp;&nbsp; "validation algorithm" in SCVP 17 is still=20
vague.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>9. I give the following comment =
before but=20
get no response,<BR>&nbsp;&nbsp; so here I raise it again.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>&nbsp;&nbsp; There are =
situations where the=20
certificate-using<BR>&nbsp;&nbsp; applications need to check whether a=20
certificate<BR>&nbsp;&nbsp; was valid during a period of time, not only=20
validate<BR>&nbsp;&nbsp; it with respect to a specific moment. For=20
example,<BR>&nbsp;&nbsp; an application verifying an archived=20
long-term<BR>&nbsp;&nbsp; signature might need to check whether a=20
certificate<BR>&nbsp;&nbsp; was valid during a period of time in which=20
the<BR>&nbsp;&nbsp; signature was generated. Therefore, I suggest=20
to<BR>&nbsp;&nbsp; extend the structure of the "validationTime"=20
field<BR>&nbsp;&nbsp; of the "Query" data type to support this. A=20
CHOICE<BR>&nbsp;&nbsp; between a moment and a period of time is=20
sufficient.</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><BR><FONT face=3D"Courier New" size=3D2>To summarize the above =
comments, the=20
"Query" needs to<BR>be changed to the following:</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>(Of course, the related text in =
the ID=20
should also be<BR>changed. However, at this moment, I simply use=20
the<BR>following syntax to demonstrate my idea to editors<BR>and the =
list. If my=20
proposal is accepted, then I<BR>will be happy to help revising the =
related=20
text.)</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Query ::=3D SEQUENCE {=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
targetCerts&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
CertReferences,<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
checks&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
CertChecks, <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
wantBack&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
WantBack, <BR>&nbsp;&nbsp;&nbsp;&nbsp; =
validationPolicy&nbsp;&nbsp;&nbsp;&nbsp;=20
[2] ValidationPolicy OPTIONAL, <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
responseFlags&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [3] =
ResponseFlags=20
OPTIONAL, <BR>&nbsp;&nbsp;&nbsp;&nbsp; =
serverContextInfo&nbsp;&nbsp;&nbsp; [4]=20
OCTET STRING OPTIONAL, <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
validationTime&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;=20
ValidationTime OPTIONAL, <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
intermediateCerts&nbsp;&nbsp;&nbsp; [7] CertBundle OPTIONAL,=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
revInfos&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
[8] RevocationInfos OPTIONAL, <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
producedAt&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[9]=20
GeneralizedTime OPTIONAL, <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
queryExtensions&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [10] Extensions OPTIONAL=20
}</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>ValidationTime ::=3D CHOICE=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
moment&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
[5] GeneralizedTime,<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
period&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;&nbsp;=20
[6] ValidationPeriod}</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>ValidationPeriod ::=3D SEQUENCE =

{<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
start&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;=20
GeneralizedTime,<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
end&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
GeneralizedTime}</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>ValidationPolicy ::=3D SEQUENCE =
{=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
validationPolRef&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
ValidationPolRef,<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
pathSpecificParams&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [1]=20
PathSpecificParams OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
targetCertSpecificParams&nbsp;&nbsp; [2] TargetCertSpecificParams=20
OPTIONAL}</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>PathSpecificParams ::=3D =
SEQUENCE=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
userPolicySet&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [1] =
SEQUENCE=20
SIZE (1..MAX) OF OBJECT=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
IDENTIFIER OPTIONAL, <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
inhibitPolicyMapping&nbsp;&nbsp; [2] BOOLEAN OPTIONAL,=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp; requireExplicitPolicy&nbsp; [3] BOOLEAN =
OPTIONAL,=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
inhibitAnyPolicy&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [4] BOOLEAN =
OPTIONAL,=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
trustAnchors&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[6]=20
TrustAnchors OPTIONAL}</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>targetCertSpecificParams ::=3D =
SEQUENCE=20
{<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
keyUsages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
[1] KeyUsages OPTIONAL, <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
extendedKeyUsages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [2] SEQUENCE OF =
KeyPurposeId=20
OPTIONAL,<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
nameValidation&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [3]=20
NameValidationAlgParms OPTIONAL}</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>NameValidationAlgParams ::=3D =
SEQUENCE {=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
nameCompAlgId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OBJECT=20
IDENTIFIER, <BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
validationNames&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GeneralNames=20
}</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>-- SCVP Validation Policy and =
Algorithm=20
Identifiers <BR>&nbsp;&nbsp;&nbsp; <BR>id-svp OBJECT IDENTIFIER ::=3D { =
iso(1)=20
identified-organization(3)=20
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; dod(6) =
internet(1)=20
security(5) mechanisms(5) pkix(7) 19 } </FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>-- SCVP Basic Validation Policy =

Identifier<BR>&nbsp;&nbsp;&nbsp; <BR>id-svp-basicValPolicy OBJECT =
IDENTIFIER ::=3D=20
{ id-svp 1 } <BR>&nbsp;<BR>-- SCVP Basic Validation Policy Errors=20
<BR>&nbsp;&nbsp;&nbsp; <BR>id-bvpe OBJECT IDENTIFIER ::=3D=20
id-svp-basicValPolicy<BR>&nbsp;&nbsp;&nbsp;=20
<BR>id-bvpe-expired&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
OBJECT IDENTIFIER ::=3D { id-bvae 1 }=20
<BR>id-bvpe-not-yet-valid&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OBJECT=20
IDENTIFIER ::=3D { id-bvae 2 }=20
<BR>id-bvpe-wrong-anchor&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OBJECT=20
IDENTIFIER ::=3D { id-bvae 3 } =
<BR>id-bvpe-invalid-key-usage&nbsp;&nbsp;&nbsp;=20
OBJECT IDENTIFIER ::=3D { id-bvae 10 }=20
<BR>id-bvpe-invalid-purpose&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT =
IDENTIFIER ::=3D=20
{ id-bvae 11 }=20
<BR>id-bvpe-revoked&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;=20
OBJECT IDENTIFIER ::=3D { id-bvae 16 } <BR>&nbsp;&nbsp;&nbsp; <BR>-- =
SCVP Name=20
Validation Algorithm Identifier</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>-- SCVP Name Validation =
Algorithm DN=20
comparison algorithm <BR>&nbsp;&nbsp;&nbsp; =
<BR>id-nva-dnCompAlg&nbsp;&nbsp;=20
OBJECT IDENTIFIER ::=3D { id-svp 4 } <BR>&nbsp;&nbsp;&nbsp; <BR>-- SCVP =
Name=20
Validation Algorithm Errors <BR>&nbsp;&nbsp;&nbsp; <BR>id-nvae OBJECT =
IDENTIFIER=20
::=3D id-svp-nameValAlg <BR>&nbsp;&nbsp;&nbsp;=20
<BR>id-nvae-name-mismatch&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
OBJECT IDENTIFIER ::=3D { id-nvae 1 }=20
<BR>id-nvae-no-name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
OBJECT IDENTIFIER ::=3D { id-nvae 2 }=20
<BR>id-nvae-unknown-alg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
OBJECT IDENTIFIER ::=3D { id-nvae 3 }=20
<BR>id-nvae-bad-name&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
OBJECT IDENTIFIER ::=3D { id-nvae 4 }=20
<BR>id-nvae-bad-name-type&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;=20
OBJECT IDENTIFIER ::=3D { id-nvae 5 }=20
<BR>id-nvae-mixed-names&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;=20
OBJECT IDENTIFIER ::=3D { id-nvae 6 } </FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" =
size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00A2_01C51552.0DEF1100--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HFLLtc059917; Thu, 17 Feb 2005 07:21:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1HFLLS0059916; Thu, 17 Feb 2005 07:21:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1HFLI3b059905 for <[e-mail]>; Thu, 17 Feb 2005 07:21:21 -0800 (PST) (envelope-from [e-mail])
Received: from wchokhani3 (c-24-5-4-98.client.comcast.net [24.5.4.98]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id j1HFLEQ7017095 for <[e-mail]>; Thu, 17 Feb 2005 10:21:15 -0500
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: PKIX implications of SHA-1 collisions
Date: Thu, 17 Feb 2005 10:21:09 -0500
Message-ID: <00ec01c51504$52571b60$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.6626
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1HFLL3b059911
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I agree with Peter that we should first understand the attack well enough
(which I do not) before providing the solutions.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Peter Gutmann
Sent: Wednesday, February 16, 2005 11:27 PM
To: [e-mail]; [e-mail]
Subject: Re: PKIX implications of SHA-1 collisions



Russ Housley <[e-mail]> writes:

>I think this can documented very quickly in a BCP.  It should just be a
>few pages.  I am willing to help write it.

I think it'd be better to wait a bit to get the full details.  Here's a
boilerplate summary I've been sending out to people who have mailed me about
this (personal opinion disclaimer, etc etc):

- It only affects the use of SHA-1 as a hash function, not as a PRF or HMAC,
  so the core of SSH, SSL/TLS, etc etc are unaffected.

- I've seen one report that it only affects the compression function and not
  the full hash function, which sounds plausible.  SHA-1 (and indeed all of
  the MD4-type UFN hashes) use a core compression function and then perform
  extra operations for the full hash function, so finding collisions in the
  full hash is somewhat more difficult than just the compression function.

- It takes 2^69 ops on average to find a second input value that produces
the
  same output as the first one (the ambiguous phrasing here is meant to
  indicate that probably what's meant is that the compression function
  produces the same output rather than the full SHA-1 hash producing the
same
  output, see above).  The second input value can't be chosen by the
attacker,
  so the chances of forging a signature on structured data like a
certificate
  or CMS/PGP message are fairly remote.

So while it's a very interesting result, it's more a hint to consider moving
to something else rather than time to hit the panic button.  RIPEMD-160
still looks fairly secure, my gut feeling is that its dual-path construction
is safer than the SHA-1 derived SHA-256 et al, but I suspect that in the
light of the current work on attacking UFN-based designs we'll be seeing a
pile of new non-UFN hash functions in the same way that differential
cryptanalysis spurred a burst of work on new ciphers.

Peter.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1H4RWIa080477; Wed, 16 Feb 2005 20:27:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1H4RWrP080476; Wed, 16 Feb 2005 20:27:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtpa.itss.auckland.ac.nz (groucho.itss.auckland.ac.nz [130.216.190.11]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1H4RSc8080468 for <[e-mail]>; Wed, 16 Feb 2005 20:27:28 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 7AD8F351CF; Thu, 17 Feb 2005 17:26:39 +1300 (NZDT)
Received: from smtpa.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04504-11; Thu, 17 Feb 2005 17:26:39 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by smtpa.itss.auckland.ac.nz (Postfix) with ESMTP id 0DF12351B1; Thu, 17 Feb 2005 17:26:38 +1300 (NZDT)
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D8E6437745; Thu, 17 Feb 2005 17:26:38 +1300 (NZDT)
Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1D1dFT-00025Z-00; Thu, 17 Feb 2005 17:26:43 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: PKIX implications of SHA-1 collisions
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Date: Thu, 17 Feb 2005 17:26:43 +1300
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley <[e-mail]> writes:

>I think this can documented very quickly in a BCP.  It should just be a few
>pages.  I am willing to help write it.

I think it'd be better to wait a bit to get the full details.  Here's a
boilerplate summary I've been sending out to people who have mailed me about
this (personal opinion disclaimer, etc etc):

- It only affects the use of SHA-1 as a hash function, not as a PRF or HMAC,
  so the core of SSH, SSL/TLS, etc etc are unaffected.

- I've seen one report that it only affects the compression function and not
  the full hash function, which sounds plausible.  SHA-1 (and indeed all of
  the MD4-type UFN hashes) use a core compression function and then perform
  extra operations for the full hash function, so finding collisions in the
  full hash is somewhat more difficult than just the compression function.

- It takes 2^69 ops on average to find a second input value that produces the
  same output as the first one (the ambiguous phrasing here is meant to
  indicate that probably what's meant is that the compression function
  produces the same output rather than the full SHA-1 hash producing the same
  output, see above).  The second input value can't be chosen by the attacker,
  so the chances of forging a signature on structured data like a certificate
  or CMS/PGP message are fairly remote.

So while it's a very interesting result, it's more a hint to consider moving
to something else rather than time to hit the panic button.  RIPEMD-160 still
looks fairly secure, my gut feeling is that its dual-path construction is
safer than the SHA-1 derived SHA-256 et al, but I suspect that in the light of
the current work on attacking UFN-based designs we'll be seeing a pile of new
non-UFN hash functions in the same way that differential cryptanalysis spurred
a burst of work on new ciphers.

Peter.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GJlQcV040967; Wed, 16 Feb 2005 11:47:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1GJlQTg040966; Wed, 16 Feb 2005 11:47:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GJlNlU040959 for <[e-mail]>; Wed, 16 Feb 2005 11:47:23 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1GJkrDd000841; Wed, 16 Feb 2005 14:46:54 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1GJkGEY007585; Wed, 16 Feb 2005 14:46:16 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 16 Feb 2005 14:47:16 -0500
To: Russ Housley <[e-mail]>, [e-mail]
From: Tim Polk <[e-mail]>
Subject: Re: PKIX implications of SHA-1 collisions
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

This is extremely important to us here at NIST, of course.  I expect that 
we will be applying significant resources to this topic in general, and its 
impact on PKI specifically, over the coming weeks.  Count on us to 
participate in this effort.

Tim Polk

At 12:26 PM 2/16/2005 -0500, Russ Housley wrote:

>I am sure that almost everyone on this list is already aware of the news 
>regarding SHA-1.  For those who have not, see 
>http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
>
>A 2^69 work factor is bad, but not a complete disaster.  At least not 
>yet.  Of course, as Bruce Schneier has noted, attacks never get worse; 
>they only improve.
>
> From the information that we have so far, two messages that have 
> collisions will have a particular structure.  I propose we have a pretty 
> easy way to make sure that we can avoid that structure in X.509 
> certificates.  We can construct the certificate serial number, which is 
> always part of the first hash block, from a random number in addition to 
> any other CA-specific serial number assignment scheme.  For example, the 
> serial number might be a counter concatenated with a 64-bit random value.
>
>I think this can documented very quickly in a BCP.  It should just be a 
>few pages.  I am willing to help write it.
>
>Russ
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GI2RTg031288; Wed, 16 Feb 2005 10:02:27 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1GI2Rmn031287; Wed, 16 Feb 2005 10:02:27 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GI2E0p031253 for <[e-mail]>; Wed, 16 Feb 2005 10:02:15 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j1GI1Tn23504; Wed, 16 Feb 2005 19:01:29 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 16 Feb 2005 19:01:29 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j1GI1NQ20335; Wed, 16 Feb 2005 19:01:23 +0100 (MET)
Date: Wed, 16 Feb 2005 19:01:23 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: SCVP Draft 17: Summary of changes
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for the fast response. 

I leave the comments for which I don't want to continue, and
other are also finished. ;-)

> >3 -
> >
> >         "The checks item MUST contain a sequence of object identifiers
> >   (OIDs)."  
> >
> >This sentence seems superflous to me, since the syntax already says that.
> >  
> >
> The text is consistent, and reinforces the information that an ASN.1 
> mechanic would glean from the syntax.  There isn't any harm in leaving 
> it, is there?

An additional MUST is something that you have to address explicitely in an
interop test.
 
> >4 - The usage of anyKeyUsage in the keyUsages is not explicitely defined.
> >   (It can be guessed to a certain degree..)
> >  
> >
> The text currently says:
> 
>   The keyUsages item may indicate either the particular key usages that
>   are required by the client or that the client does not require any
>   particular key usage.
> 
> The anyKeyUsage is implicitly described by the "or that the client does 
> not require any particular key usage".  This can be made more explicit 
> if necessary.
> 
> >   in other words, the requiredKeyUsages is defined, but not the anyKeyUsage
> >
> >   What is the difference of having a NULL option and not having coded
> >   the optional field?
> >  
> >
> If the client includes the keyUsages item in the validationPolicy in the 
> request and specifies the anyKeyUsage choice (encoded as NULL), the 
> client is indicating that it does not want validation to fail as a 
> result of the contents of the keyUsage extension in the end certificate 
> (or the absence of the keyUsage extension from the certificate).
> 
> >   Note that if the requiredKeyUsages is used, non existance of the 
> >   key usage in a cert extension is a match.
> >  
> >
> If the client omits the keyUsages item from the the validationPolicy in 
> the request, the client is indicating that validation should be 
> performed using the default value for the validation policy specified in 
> the validationPolRef item.
> 
> For example, a validation policy may, by default, require that the end 
> certificate either not include a keyUsage extension or include a 
> keyUsage extension with the digitalSignature bit set.  If the client 
> specifies the use of this validation policy and omits the keyUsages item 
> from the the validationPolicy in the request, then any end certificate 
> that included a keyUsage extension without the digitalSignature bit set 
> would be rejected.  If the client specifies the use of this validation 
> policy but includes the keyUsages item with the anyKeyUsage choice, then 
> the client is indicating that end certificates should be considered 
> valid if they include keyUsage extensions with digitalSignature set to 0.

Couldn't just NULL be replaced by an empty sequence. 0..MAX but well, this again
enters int ASN1 considerations, but it seem that the entendedkeyusage uses
this approach? 

As later on with one boolean, it seems that there is no way in the policy
definition to indicate that a server prohibits a client to specify a value.
Or, a server needs another configuration parameter to do this. IMO, this 
does not seem to be compatible with the idea of what consitutes a policy.  

> 
> >5- 3.2.4.9  
> >
> >   "If the client wishes to confirm 
> >   the extended key usage, then it can communicate the usage it wants to
> >   validate by the same extension using the same semantics as defined in
> >   [PKIX-1]."
> >   
> >   
> >   shouldn't 
> >
> >      SEQUENCE SIZE (1..MAX) OF KeyPurposeId
> >
> >   then be replaced by 
> >
> >      ExtKeyUsageSyntax
> >
> >   otherwise "same extension" is not well defined. (and even then)
> >   
> >  
> >
> Acutally, in the validationPolicy structure, extendedKeyUsages is now 
> defined as:
> 
>          extendedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL
> 
> Unlike in a certificate, there needed to be the option to include 
> extendedKeyUsages in an SCVP request with an empty sequence.  The effect 
> of including extendedKeyUsages in a request with an empty sequence is 
> similar to the effect of including keyUsages with anyKeyUsage.  That is, 
> the client is explcitly stating that it has no requirements with respect 
> to extended key usages.
> 
> We will re-word the above sentence to more clearly convey this.

Ok.

  Is there a particular reason to have a NULL in the keyusages and not just
  an empty sequence as here?

> 
> >8 - 3.2. 4     
> >
> 
> So, it seems to me that any other information about validation policies, 
> including which default parameter values can be overridden and which can 
> not must be provided through out of band means.  Either that or the 
> client figures it out through trial and error :)

ok, it seems that we agree that the sentence

 "For each parameter, a validation policy may either allow the client to specify a non-
 default value or forbid the use of a non-default value."

cannot be reflected at all in the validation policy data structure. 
  
> >9 - 3.5  requestorName 
> >       
> >   "The optional requestorName item is used by the client to include an 
> >   identifier in the request.  The client MAY include this information 
> >   for the DPV server to copy into the response. 
> >    
> >   SCVP servers MUST be able to process requests that include this
> >   field."
> >
> >   Please add:
> >
> >   A server MAY require this to match with some authenticated identity
> >   depending on a server defined rule.
> >  
> >
> Why do we need to say this explicitly?  It seems out of scope to me.  
> The server may choose to support clients on whatever basis it wishes, 
> including the contents of the requestorName field in the request and 
> some authneticated identity.  We do not need to specify the variety of 
> mechanisms that might be considered...

Well, I can live with that. 

But to prepare soem discussion later down: There is no single
authenticated identity. There may be several possible. 

> 
> >10 - 4.8  
> >
> >   "Alternatively, the SCVP server MAY omit this item."
> >
> >   I don't think that this is not a alternative if the client has set a
> >   requestorName, if if my reading of 3.5  "to copy into the response"
> >   mean that the server MUST copy.
> >  
> >
> RFC 3379 states:
> 
>   When the DPV request is authenticated, the client SHOULD be able to
>   include a client identifier in the request for the DPV server to copy
>   into the response.  Mechanisms for matching this identifier with the
>   authenticated identity depends on local DPV server conditions and/or
>   the validation policy.  The DPV server MAY choose to blindly copy the
>   identifier, omit the identifier, or return an error response.
> 
> The last sentence in this paragraph is very clear that the server may 
> omit the identifier in the response even when the client sends an 
> authenticated request with and asserts an identity in the request.

You are right. I always objected to the text in 3379.

It doesn't give any idea to a client whether it can count on getting
it back. Which may be necessary to have in in a response destined
to a third party. 

It should be at least clear in a server policy, and a server should
always behave in a consistent way, or to say that it is not the case.  

> >   Mildly speaking, after total silence since my last remark concerning
> >   these fields, I was not sure whether anything at all was accepted
> >   by the authors, or not, anyway, the tendancy has continued to 
> >   partially respond, and not say anything to concrete proposal, which
> >   is simply to have a requesterName in both requests and responses
> >   as a GeneralNames (note the s), so taht a relay can add an id etc.
> >  
> >
> For relay, one uses requestorRef.  requestorRef allows for a sequence of 
> identities, there is text in section 7 stating that the sequence needs 
> to list all of the servers involved in processing the request, and there 
> is a requirement that the response MUST copy the value of requestorRef 
> from the request.

There requesterrefs are not identities which can be interpreted.

They are globally unique values that may have defined relation to any 
identity of a server, since one does not know how to interprete the octet string.
 
It may be useful to distunguish some opaque octet string stuff for loop
control, although I stronly believe that remove the requestorRef
octet strings and replacing this by a sequence in the requesterName
is a better solution even for the loop control. 

Note that earlier proposals only had octet strings for all purposes,
and the requeserName was introduced silently after I had asked for
guidance on how to encode an identifier in an octet string.  

> >11 -
> >
> >   "In the case of non-cached responses to signed requests, the SCVP 
> >   server SHOULD return a requestor name."
> >
> >   For what reason a SHOULD? What is the reason for returning anything
> >   for a "signed" requst if the client doesn't need this? And, why
> >   'signed' and not protected?
> >  
> >
> I agree that signed should be replaced with "authenticated".  The change 
> from "signed" to "protected" was made at the last minute and this was 
> overlooked.  The term "protected" would be inappropriate here since 
> "protected" includes unauthenticated requests in which the client used 
> an ephemeral Diffie-Hellman key.
> 
> >12 - 7:
> >       "SCVP 
> >   servers that support relay SHOULD populate this item with the DNS 
> >   name of the server or the distinguished name in the server's 
> >   certificate.  SCVP servers MAY choose other procedures for generating
> >   identifiers that are unique within their community." 
> >
> >   I don't think the SHOULD is appropriate. DNS or distingushed name may 
> >   not exist, and there is no indication who an octet string can be populated.
> >  
> >
> The entire paragraph reads:
> 
>   To prevent false loop detection, servers should use identifiers that
>   are unique within their network of cooperating SCVP servers.  SCVP
>   servers that support relay SHOULD populate this item with the DNS
>   name of the server or the distinguished name in the server's
>   certificate.  SCVP servers MAY choose other procedures for generating
>   identifiers that are unique within their community.
> 
> As you state, a DNS name or DN may not be appropriate in all 
> circumstances, which is why the document says "SHOULD" instead of 
> "MUST".  The most important part is that identifiers be chosen "that are 
> unique within their network of cooperating SCVP servers".  DNS names and 
> DNs are just two types of identifiers that are likely to provide this 
> property.

I am not saying this, I am saying that there is not even a hint to how
create an octet string from such information, thus it is a SHOULD without
specification. 

Choosing something for uniqueness without knowning how it gets mapped into
another space entities from other universes can land, and without knowing
how you are mapped does not guarantee uniqueness.


> Since the only requirement is that the identifiers be "unique within 
> their network of cooperating SCVP servers", there is no need to mandate 
> how the identifiers are encoded within the OCTET STRING.

You have to ensure that the encoding is unique, not the source values.

Although it is somewhat unlikely that two implementations would use different
encodings of a dns name given a false match, or a false match with a DN, or so.  

The historical example is

  cs.some.ac.uk vs  uk.ac.some.cs 
 
> >13 - 7:
> >
> >   It is quite nice to have loop detection for relaying,
> >
> >   but nothing is said how a relay constructs a request from 
> >   a received on, and how a response is created from the 
> >   received response.
> >  
> >   (E.g. what to do with requesterName in the request? )
> >
> >   The SCVP still does not contain a means to include the respons 
> >   of another SCVP server in a response.
> >  
> >
> SCVP should not include a means to include the response of another SCVP 
> server in a response.  An SCVP client sends a request to an SCVP server 

The requirements say, that

  " When the certificate is valid
   according to the validation policy, the server MUST, upon request,
   include that information in the response."

and 

   "Such information may (not necessarily exclusively) consist of ...

    or a DPV response from a DPV server that is
    trusted under the validation policy."

The requirement does not say that the response may only contain the information
of the a relayed DPV response. You would loose some important information,
WHO has told it under what policy, etc. 

> and gets a response from that server.  How the server derives the answer 
> that it provides in the response is a local matter to the server.  The 

Yes, but it has to respond with ALL elements that have been used for
making the decision if the clients request it. The server has no freedom here. 

> server may call upon the services of other SCVP servers in generating 
> the response (i.e., the server may use SCVP relay), but that should be 
> transparent to the reponse.  If the SCVP server were allowed to simply 
> include the reponse from another SCVP server in its response, then this 
> would impose more complexity on the SCVP client, which would need to 
> parse responses that differed based on how the SCVP server derived the 
> response.

I cannot follow at all your conclusion.

It depends largely on what type of server you are talking. in a DPV case, 
the client believes in the response, and may just show it to a user.

Since parsing of a response structure is already one of its capabilities,
I don't see the extra overhead (for the client), I am not talking about
an end user.
 
   "For the client to be able prove to a third party that trusts the same
   DPV server that the certificate validation was handled correctly, the
   DPV response MUST be digitally signed, unless an error is reported.
   The DPV server's certificate MUST authenticate the DPV server."

The third party may only trust the relayed server and not the client's
SCVP server. Assume an client SCVP server which operates as in the equivalent
of the 'locally trusted' OCSP model, which is the normal one, 
and a relay which is associated to a CA or common to some community. 

I am not saying that a CA must have an associated SCVP server. 

> >14 - Since it seems that it has been agreed somehow that a id cannot
> >   necessarily be derived from a security envelope, or, at least for
> >   symmetric reason, a response should have an value identifying
> >   the responder.
> >
> >   Ah well, the previous responder item whihc had context 4 had been
> >   silently dropped (instead of being replaced by a generalnames.)
> >  
> >
> >     CVResponse ::= SEQUENCE { 
> >       cvResponseVersion         INTEGER, 
> >       policyID                  INTEGER, 
> >       producedAt                GeneralizedTime, 
> >       responseStatus            ResponseStatus, 
> >       respValidationPolicy  [0] RespValidationPolicy OPTIONAL, 
> >       requestRef            [1] RequestReference OPTIONAL, 
> >       requestorRef          [2] SEQUENCE SIZE (1..MAX) OF OCTET  
> >                                   STRING OPTIONAL, 
> >       requestorName         [3] GeneralNames OPTIONAL, 
> >           replyObjects          [5] ReplyObjects OPTIONAL, 

I meant to remove 4 blanks here.  

> >       respNonce             [6] OCTET STRING OPTIONAL, 
> >       serverContextInfo     [7] OCTET STRING OPTIONAL, 
> >       cvResponseExtensions  [8] Extensions OPTIONAL } 
> >
> >   please "align" the syntax.
> >  
> >
> 
> A self asserted identity has a value to the client, as established in 
> RFC 3379, when returned in the response.  Since this requirement was 
> agreed upon by the WG and included in RFC 3379, we wanted to be sure the 
> specification supported it.


to start: So seem to agree with Trevor that a from field in email is non existing
and is not used for identification (since I have not seen an answer to
from Trevor). :-)

The value has a meaning to other third parties, what you are saying
is the same as: "The value of 'tsa' in a time stamp token is useless."

   When the DPV request is authenticated, the client SHOULD be able to
   include a client identifier in the request for the DPV server to copy
   into the response.  Mechanisms for matching this identifier with the
   authenticated identity depends on local DPV server conditions and/or
   the validation policy.  The DPV server MAY choose to blindly copy the
   identifier, omit the identifier, or return an error response.

To me, 3379 does not say WHY this is a requirement, or

 "A self asserted identity has a value to the client"

is not established in 3379. It has been established by the discussions.

ONE of the possiblities is to declare the identity because a single ONE
cannot be derived from a signing certificate, when you have more than 
one name form. 

This argument also applies to the server. I have not seen any
counterargument for that so far.  And only because I was ensured that 
a protocol may have other required features than those expressed in 3379
I didn't not continue with the discussion. I did not even expect 
that it would take years and versions to even get the requesterName 
aligned with 3379. In all my comments I mentioned the similar 
requirement for a servber identity.

I know the different possibilities to interprete silence
and partial responses. :-)

> Our reading of RFC 3379 does not support inclusion of a self asserted 
> server identity.  

See above. 

>                   Where the client cares about the identity, it can 
> obtain that information from the security envelope.  Where no security 
> envelope is available, the client is performing all security relevant 
> processing locally, and does not need the server's identity.  Unlike the 
> requestorName, this information is not returned in future messages, so 
> it has no value to the server either. 

Thanks for accepting a discussion. The identity has a value to
a third party. (cf tsa field in a time stamp token). 

  " For the client to be able prove to a third party that trusts the same
   DPV server that the certificate validation was handled correctly, the
   DPV response MUST be digitally signed, unless an error is reported. "

I do not only require a SELF ASSERTED identity of the server. I require that
the client may also instruct a server to work under a particular identity.

In TLS one recently found that just connecting to some point is not sufficient
to select the appropriate identity of the endpoint. 

And, in a request, the serverName is a list of names, a local client
should be able to tell his proxy: "Dear server, I know who YOU are, I need
a status request from the PKIX SCVP server concerning the cert from Dave'.
This is useful for proxies. 

> In short, a self asserted server identity has no security value, and we 
> could not come up with other useful semantics  - we tried -  so we 
> deleted it.
> 
> >15 - ReplyWantBack
> >
> >   I have never any explication why the
> >
> >     ReplyWantBack::= SEQUENCE { 
> >       wb                         OBJECT IDENTIFIER, 
> >       value                      OCTET STRING } 
> >
> >   is an encapsulating octet string. Since the client
> >   makes a particular wantback, one could assume that
> >   it knows the syntax? 
> >   
> >     ReplyWantBack::= SEQUENCE { 
> >       wb                         OBJECT IDENTIFIER, 
> >       value                      ANY DEFINED BY wb } 
> >
> >   seems better to me.
> >  
> >
> This is an "elegance" issue again, and we can make similar arguments 
> about the encoding of Extensions, etc.  Changing from "OCTET STRING" to 
> "ANY DEFINED BY wb" would be a stylistic change that would not improve 
> the protocol.

IMHO, this is not elegance, it changes the nature of the parsing code.
You need to explicitely invoke a new parser for the content.  

> >17 - 9
> >
> >   I think all staements of what a client or server MUST do with
> >   certain field should go to the section defining the protocol
> >   element. 
> >
> >   example the first statement in
> >
> >   "Clients MUST check the requestRef item in the response and ensure 
> >   that it matches their original request.  Requests contain a lot of 
> >   information that affects the response and clients need to ensure that
> >   the server response corresponds to the request."
> >
> >  
> >
> We missed this one in the security requirements section.  Since 
> non-cached responses may omit the requestRef item, this cannot be a 
> MUST.  Matching the request message with the contents of requestRef is 
> one option, but there are other ways for the client to verify that the 
> response properly corresponds to the request.  So, we would propose 
> changing the referenced text in the security considerations section. 
> 
>    Clients MUST verify that the response matches their orignal 
> request.   Clients need to ensure that
>    the server has performed the appropriate checks for the correct 
> certificates under the requested
>    validation policy for the specified validation time, and that the 
> response includes the requested want
>    backs and meets the client's freshness requirements.

> 
> It's a mouthful, but I believe this is the correct statement.  As 
> restated, it should stay in the security considerations section.

I don't think that this is a topic for the security considerations,
it is a feature of the protocol, but rather belongs to the description
of the way how each protocol element has to be treated, so you can
void to have too much in your mouth. 

Security considerations may be things like what happens when the
time goes out of sync, or when the server is not available, or ...

But that may be a question of elegance. :-)

> 
> >18 - 9
> >
> >   "Therefore in these situations use 
> >            of a URI many be more attractive."
> >
> >   Is there a comma missing behind the first word? if so, there are other places, too.
> >
> >  
> >
> We'll ask our local tech editor, but I think that the comma is not 
> required.  However, we should change the "many" to "may".

It seems that it depends on whether you want the reader to pause or not. 
one may even say

   Therefore, in these situations, use

   Therefore in these situations, use

as far as I understand some grammar explications. I was pretty (=VERY ***)
schlecht in der Schule. 


> >23 - Paul Hoffman used to be one of the authors. Even when nothing of what
> >   was written by Paul has remained, the contributions section could
> >   still name him, unless ... 
> >
> >   "The lively debate"  may you consider to replace it by 'the lively or almost deadly debate' 
> >
> >Peter
> >
> >  
> >
> This predates my involvement, but you are correct.  Tim tells me we 
> should add Paul to the list of guilty parties.
> 
> As to the debate, how much honesty do we really need?
See *** above. 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GHRJll028029; Wed, 16 Feb 2005 09:27:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1GHRJld028028; Wed, 16 Feb 2005 09:27:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j1GHREpa028006 for <[e-mail]>; Wed, 16 Feb 2005 09:27:18 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 16847 invoked by uid 0); 16 Feb 2005 17:27:03 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (12.174.85.231) by woodstock.binhost.com with SMTP; 16 Feb 2005 17:27:03 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Wed, 16 Feb 2005 12:26:47 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: PKIX implications of SHA-1 collisions
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am sure that almost everyone on this list is already aware of the news 
regarding SHA-1.  For those who have not, see 
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html

A 2^69 work factor is bad, but not a complete disaster.  At least not 
yet.  Of course, as Bruce Schneier has noted, attacks never get worse; they 
only improve.

 From the information that we have so far, two messages that have 
collisions will have a particular structure.  I propose we have a pretty 
easy way to make sure that we can avoid that structure in X.509 
certificates.  We can construct the certificate serial number, which is 
always part of the first hash block, from a random number in addition to 
any other CA-specific serial number assignment scheme.  For example, the 
serial number might be a counter concatenated with a 64-bit random value.

I think this can documented very quickly in a BCP.  It should just be a few 
pages.  I am willing to help write it.

Russ



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GFVlg0018713; Wed, 16 Feb 2005 07:31:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1GFVlFt018712; Wed, 16 Feb 2005 07:31:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx07.ms.so-net.ne.jp (mx07.ms.so-net.ne.jp [202.238.82.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GFVb3j018666 for <[e-mail]>; Wed, 16 Feb 2005 07:31:46 -0800 (PST) (envelope-from [e-mail])
Received: from [127.0.0.1] (pdd3b6a.tkyoac00.ap.so-net.ne.jp [218.221.59.106]) by mx07.ms.so-net.ne.jp  with ESMTP id j1GFV94s013153; Thu, 17 Feb 2005 00:31:10 +0900 (JST)
Date: Thu, 17 Feb 2005 00:31:08 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>
Subject: Re[2]: Question about updating the CA to change its DN encoding
Cc: <[e-mail]>
In-Reply-To: <01a801c51414$d22b1f30$4f85900a@wcwang>
References: <[e-mail]> <01a801c51414$d22b1f30$4f85900a@wcwang>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.12.01 [ja]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Wen-Cheng Wang" <[e-mail]> wrote:

> You seem to mix up "name rollover" with "key rollover". However, these
> two kinds of rollover are orthogonal. A CA performing "name rollover"
> does not necessarily change its cert/CRL sining key.

Yes, I think basically a CA should also change its keypair when the CA
renews its certificate.  If the CA change only encoding of DN in the
certificate, changing its keypair is not necessary because it does not
affect to the strength of keypair.  But, most CA may change its validity
such as notAfter not only the encoding of its DN.  
Of course it is not a technical issue, but an operational issue.  But,
for this issue I say "basically a CA should also change its keypair".

> Anyway, if your CA needs a migration of name encoding, do not count on
> issuing a "name rollover" certificate because it won't work.

Okay, folks can wait an updating of 3280bis;)


-- shima



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GFPX4q018198; Wed, 16 Feb 2005 07:25:33 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1GFPXuf018196; Wed, 16 Feb 2005 07:25:33 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GFPWHS018188 for <[e-mail]>; Wed, 16 Feb 2005 07:25:33 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23388; Wed, 16 Feb 2005 10:25:29 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-trans-03.txt
Date: Wed, 16 Feb 2005 10:25:29 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: CMC Transport
	Author(s)	: J. Schaad, et al.
	Filename	: draft-ietf-pkix-cmc-trans-03.txt
	Pages		: 0
	Date		: 2005-2-15
	
This document defines a number of transport mechanisms that are used
to move [CMC] messages.  The transport mechanisms described in this
document are: HTTP, file, mail and TCP.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-trans-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-trans-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-trans-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-trans-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-trans-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GCJxP8082228; Wed, 16 Feb 2005 04:19:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1GCJx0J082227; Wed, 16 Feb 2005 04:19:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GCJrUa082065 for <[e-mail]>; Wed, 16 Feb 2005 04:19:53 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j1GCJUn17638; Wed, 16 Feb 2005 13:19:31 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 16 Feb 2005 13:19:31 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j1GCJUX19026; Wed, 16 Feb 2005 13:19:30 +0100 (MET)
Date: Wed, 16 Feb 2005 13:19:30 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: SCVP Draft 17: Summary of changes
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> AUTOMATIC tagging would actually give you this:
> 
>     CertReferences ::= CHOICE {
>       pkcRefs           [0] IMPLICIT SEQUENCE SIZE (1..MAX) OF PKCReference,
>       acRefs            [1] IMPLICIT SEQUENCE SIZE (1..MAX) OF ACReference }
> 
> Similarly for the other two.
> 
Thanks for the correction.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GAlJn2049631; Wed, 16 Feb 2005 02:47:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1GAlJ4e049630; Wed, 16 Feb 2005 02:47:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GAl8o3049543 for <[e-mail]>; Wed, 16 Feb 2005 02:47:18 -0800 (PST) (envelope-from [e-mail])
Received: from ms20.chttl.com.tw (ms20 [10.144.2.120]) by fw.chttl.com.tw (8.13.3/8.13.3) with ESMTP id j1GAkqrd001715; Wed, 16 Feb 2005 18:46:52 +0800
Received: from wcwang ([10.144.133.79]) by ms20.chttl.com.tw (8.13.2/8.13.2) with SMTP id j1GAknWO013753; Wed, 16 Feb 2005 18:46:50 +0800
Message-ID: <01a801c51414$d22b1f30$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Masaki SHIMAOKA" <[e-mail]>, "Jean-Marc Desperrier" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Question about updating the CA to change its DN encoding
Date: Wed, 16 Feb 2005 18:46:48 +0800
Organization: Chunghwa Telecom
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Masaki,

You seem to mix up "name rollover" with "key rollover". However, these
two kinds of rollover are orthogonal. A CA performing "name rollover"
does not necessarily change its cert/CRL sining key.

Anyway, if your CA needs a migration of name encoding, do not count on
issuing a "name rollover" certificate because it won't work.
I had ever raised this as a 3280bis issue. I hope that 3280bis obsoletes
the recommendation of using "name rollover" certificates. The following is
quoted from my previous post:

  ----- Original Message ----- 
  From: "Wen-Cheng Wang" <[e-mail]>
  Sent: Wednesday, November 17, 2004 6:36 PM
  Subject: 3280bis issue: Name Rollover certificate
  
  > The current text of RFC 3280 recommend using "name rollover" certificates to
  > support an orderly migration to UTF8String encoding.
  > 
  > However, I recall that there being a number of threads discussing whether
  > the recommendation works. It was finally concluded that the recommendation
  > does not work. Therefore, shouldn't the recommendation of using "name rollover"
  > certificates be removed from son of RFC 3280.
  > 

Wen-Cheng Wang

----- Original Message ----- 
> 
> Jean-Marc,
> 
> > "name rollover" certificates are needed only for client that don't 
> > support encoding conversions when comparing DN.
> 
> Right.
> 
> > If thoses clients also fully implement the CRL checking rules, then they 
> > should consider a CRLs emitted under either the old or the new key as 
> > valid for certificates emitted under both keys.
> 
> Sorry, for my English problem, I could not catch correctly what you say.
> I guess you mentioned that a client that implements fully the CRL
> checking rules should be able to validate a certificate that is issued
> by both the new key and the old key with a CRL regardless of its signing
> key.
> 
> If so, I guess what to share the revocation information with the old key
> and the new key means that new key MUST NOT use any serial number which
> was used already by the old key.
> Right?
> 
> > The answer is YES, even if it might be in practice difficult to find 
> > even one single client that is actually affected.
> 
> I agree.
> 
> -- shima
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GAXZRs044739; Wed, 16 Feb 2005 02:33:35 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1GAXZP2044738; Wed, 16 Feb 2005 02:33:35 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft6.fr.colt.net (smtp-ft6.fr.colt.net [213.41.78.209]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1GAXX35044662 for <[e-mail]>; Wed, 16 Feb 2005 02:33:34 -0800 (PST) (envelope-from [e-mail])
Received: from [10.0.0.51] (host.107.92.68.195.rev.coltfrance.com [195.68.92.107]) by smtp-ft6.fr.colt.net with ESMTP id j1GAXOM31582 for <[e-mail]>; Wed, 16 Feb 2005 11:33:24 +0100
Message-ID: <[e-mail]>
Date: Wed, 16 Feb 2005 11:33:22 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en, fr, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Question about updating the CA to change its DN encoding
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Masaki SHIMAOKA wrote:

>I guess you mentioned that a client that implements fully the CRL
>checking rules should be able to validate a certificate that is issued
>by both the new key and the old key with a CRL regardless of its signing
>key.
>  
>
Yes.
There has been lengthly discussions on the list a few month ago about 
this point that definitively confirmed that.

>If so, I guess what to share the revocation information with the old key
>and the new key means that new key MUST NOT use any serial number which
>was used already by the old key.
>Right?
>  
>
Yes again.

The encoding change doesn't modify the rule.

It only restricts even more the set of clients that completely respect 
it, and would be endangered by reusing the serial numbers or not 
including in both CRL the serial numbers for the certs emitted by the 
old and the new key.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1G8jjdZ004298; Wed, 16 Feb 2005 00:45:45 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1G8jjCR004297; Wed, 16 Feb 2005 00:45:45 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns01.secom.co.jp (ns01.secom.co.jp [61.114.178.247]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1G8jZnj004108 for <[e-mail]>; Wed, 16 Feb 2005 00:45:35 -0800 (PST) (envelope-from [e-mail])
Received: from mldsit02.intra.secom.co.jp ([172.21.1.41]) by ns01.secom.co.jp (8.11.7-20030918/3.7W) with ESMTP id j1G8jGZ16884; Wed, 16 Feb 2005 17:45:16 +0900 (JST)
Received: from sectrl.isl.secom.co.jp (localhost [127.0.0.1]) by mldsit02.intra.secom.co.jp (8.12.10+Sun/3.7W) with ESMTP id j1G8jGGE014505; Wed, 16 Feb 2005 17:45:16 +0900 (JST)
X-Authentication-Warning: mldsit02.intra.secom.co.jp: iscan owned process doing -bs
Received: from isis.sp.isl.secom.co.jp (isis.isl.secom.co.jp [10.131.16.23]) by sectrl.isl.secom.co.jp (Postfix) with ESMTP id 404EE1E72E; Wed, 16 Feb 2005 17:45:16 +0900 (JST)
Received: from [127.0.0.1] (jonathan [10.131.129.67] (may be forged)) by isis.sp.isl.secom.co.jp (8.9.1+3.1W/3.7W-Isis.1) with ESMTP id RAA09348; Wed, 16 Feb 2005 17:45:16 +0900
Date: Wed, 16 Feb 2005 17:45:14 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: Jean-Marc Desperrier <[e-mail]>
Subject: Re[2]: Question about updating the CA to change its DN encoding
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.12.01 [ja]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jean-Marc,

> "name rollover" certificates are needed only for client that don't 
> support encoding conversions when comparing DN.

Right.

> If thoses clients also fully implement the CRL checking rules, then they 
> should consider a CRLs emitted under either the old or the new key as 
> valid for certificates emitted under both keys.

Sorry, for my English problem, I could not catch correctly what you say.
I guess you mentioned that a client that implements fully the CRL
checking rules should be able to validate a certificate that is issued
by both the new key and the old key with a CRL regardless of its signing
key.

If so, I guess what to share the revocation information with the old key
and the new key means that new key MUST NOT use any serial number which
was used already by the old key.
Right?

> The answer is YES, even if it might be in practice difficult to find 
> even one single client that is actually affected.

I agree.

-- shima




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FNsMDf007963; Tue, 15 Feb 2005 15:54:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FNsMWE007962; Tue, 15 Feb 2005 15:54:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from micah.software-aus.com.au (cust3103.vic01.dataco.com.au [202.63.62.31]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FNsLk0007918 for <[e-mail]>; Tue, 15 Feb 2005 15:54:21 -0800 (PST) (envelope-from [e-mail])
Received: from eb2bcom.com (192.168.1.165) by micah.software-aus.com.au (7.1.016.1) (authenticated as steven.legg) id 41A13B74000070BA; Wed, 16 Feb 2005 10:58:40 +1100
Message-ID: <[e-mail]>
Date: Wed, 16 Feb 2005 10:52:16 +1100
From: Steven Legg <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP Draft 17: Summary of changes
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Peter Sylvester wrote:
> 2 - 
> 
> I vaguely remember that concerning comment C there was my suggestion 
> to use tagging that is an explicit version of what would happen with 
> AUTOMATIC tagging, unless I'm wrong this would give something like
> 
>      CertReferences ::= CHOICE { 
>        pkcRefs           SEQUENCE SIZE (1..MAX) OF PKCReference, 
>        acRefs            [0] SEQUENCE SIZE (1..MAX) OF ACReference }

AUTOMATIC tagging would actually give you this:

    CertReferences ::= CHOICE {
      pkcRefs           [0] IMPLICIT SEQUENCE SIZE (1..MAX) OF PKCReference,
      acRefs            [1] IMPLICIT SEQUENCE SIZE (1..MAX) OF ACReference }

Similarly for the other two.

The IMPLICIT keyword is redundant in this case because
the module already uses IMPLICIT TAGS.

Regards,
Steven



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FMuEo5003160; Tue, 15 Feb 2005 14:56:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FMuEJI003159; Tue, 15 Feb 2005 14:56:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.149]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FMuDsk003140 for <[e-mail]>; Tue, 15 Feb 2005 14:56:13 -0800 (PST) (envelope-from [e-mail])
Received: from df-edge-01.exchange.corp.microsoft.com ([157.54.8.149]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 14:56:03 -0800
Received: from df-hub-02.exchange.corp.microsoft.com (157.54.8.23) by df-edge-01.exchange.corp.microsoft.com (157.54.8.149) with Microsoft SMTP Server id 8.0.00218.8; Tue, 15 Feb 2005 14:56:02 -0800
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 14:56:02 -0800
Received: from df-courage-msg.exchange.corp.microsoft.com ([157.54.4.14]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 15 Feb 2005 14:56:01 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5.7408.0
X-OriginalArrivalTime: 15 Feb 2005 22:56:01.0986 (UTC) FILETIME=[85808A20:01C513B1]
Subject: RE: SCVP 16 comments deadline
Date: Tue, 15 Feb 2005 14:56:02 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments deadline
Thread-Index: AcTbfdnnQM8sCGUwQ1+o/ms74r26bABGmo+wAZn7R1AAKa9pIAv37v1w
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
CC: <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1FMuDsk003153
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are 46 onwards

Trevor

* -----Original Message-----
* From: Trevor Freeman
* Sent: Thursday, December 16, 2004 12:49 PM
* To: Denis Pinkas
* Cc: [e-mail]
* Subject: RE: SCVP 16 comments deadline
* 
* Here is 23-45
* Trevor
* 
* * -----Original Message-----
* * From: Trevor Freeman
* * Sent: Wednesday, December 15, 2004 4:02 PM
* * To: 'Denis Pinkas'
* * Cc: '[e-mail]'
* * Subject: RE: SCVP 16 comments deadline
* *
* * Here is 17-22
* * Trevor
* *
* * * -----Original Message-----
* * * From: Trevor Freeman
* * * Sent: Tuesday, December 07, 2004 12:47 PM
* * * To: 'Denis Pinkas'
* * * Cc: [e-mail]
* * * Subject: RE: SCVP 16 comments deadline
* * *
* * * Hi Denis,
* * * Below are responses to 1-16. Others will follow later.
* * * Trevor
* * *
* * * * -----Original Message-----
* * * * From: Denis Pinkas [mailto:[e-mail]]
* * * * Sent: Monday, December 06, 2004 2:25 AM
* * * * To: Trevor Freeman
* * * * Cc: [e-mail]
* * * * Subject: Re: SCVP 16 comments deadline
* * * *
* * * * Trevor,
* * * *
* * * * > The deadline communicated at the DC meeting for making
comments on
* * * SCVP
* * * * > 16 was Nov 30th which has now passed. I have had only three
people
* * * send
* * * * > me comments to date. SCVP 17 will be closing very shortly so
this
* is
* * * the
* * * * > last reminder.
* * * *
* * * * Thank for the remainder. I missed the initial announcement.
* * * * My comments are below.
* * * *
* * * *
* * * * 1. Typo. There are two IPR statements related to RFC 3668 on the
* first
* * * * page. Delete one.
* * * *
* * * * " By submitting this Internet-Draft, I certify that any
applicable
* * * *    patent or other IPR claims of which I am aware have been
* disclosed,
* * * *    or will be disclosed, and any of which I become aware will be
* * * *    disclosed, in accordance with RFC 3668".
* * * [TF] Fixed
* * * *
* * * *
* * * * 2. Page 11. Typos. First paragraph on top of the page.
* * * * Replace "signers" by "signer's".
* * * [TF] Fixed
* * * *
* * * *
* * * * 3. Page 11. Typo. First paragraph on top of the page. Last
sentence.
* * * * Replace "certificate" by "certificates".
* * * [TF] Fixed
* * * *
* * * *
* * * * 4. Page 13. Typo. Section 3.1.2 "checks"
* * * * The two following lines are in fact one line:
* * * *
* * * * Change:
* * * *
* * * *      - Build a validated certification path to a trust anchor;
and
* * * *
* * * *      - Do revocation status checks on the certification path.
* * * *
* * * * into:
* * * *
* * * *      - Build a validated certification path to a trust anchor
and
* * * *        do revocation status checks on the certification path.
* * * *
* * * [TF] Since this paragraph is listing the possible checks and
building
* a
* * * path is a separate check to revocation checking, I think the
current
* * text
* * * is more accurate.
* * * *
* * * * 5. Page 15. Typo. Section 3.1.4 validationPolicy
* * * *
* * * * This is the error left intentionally by the editor to know who
read
* * the
* * * * document. The following sentence is duplicated: " The
* * validationPolicy
* * * * item, defines the validation policy". Please delete one
sentence.
* * * [TF] Just checking <g> Fixed
* * * *
* * * *
* * * * 6. Page 24. Typo. Section 3.1.5.9 keyUsages
* * * *
* * * * Change "keyUasge" into "keyUsage".
* * * [TF] Fixed
* * * *
* * * *
* * * * 7. Page 27. Typo. Section 3.1.8 valididationTime
* * * * Last line of the first paragraph. Change "servers" into
"server's"
* * * [TF] Fixed
* * * *
* * * *
* * * * 8. Page 32. Typo. Section 3.5 dhPublicKey
* * * * Change: Diffie-Hellamn into Diffie-Hellman.
* * * [TF] Fixed
* * * *
* * * *
* * * * 9. Page 32. Typo. Section 3.5 dhPublicKey
* * * * Fifth line. Change "an does" into "and does"
* * * [TF] Fixed
* * * *
* * * *
* * * * 10. Page 32. Typo. Section 3.5 dhPublicKey
* * * * Delete: (see section Error! Reference source not found.)
* * * *
* * * *
* * * * 11. Page 33. Typo. Section 4. Validation Response
* * * *
* * * * After the eight items. The following sentence has a grammar
problem:
* * * *   "Successful responses are be made when the server has fully
* * complied
* * * *    with the request".
* * * [TF] Deleted the "be"
* * * *
* * * *
* * * * 12. Page 52. Typo. Section 6 Validation Policy Response
* * * *
* * * * The second sentence is incorrect. It is:
* * * * The valPolResponse MAY not unique to any valPolRequest, ..."
* * * *
* * * * Change into:
* * * * "The valPolResponse MAY not be unique to any valPolRequest, ..."
* * * [TF] Fixed
* * * *
* * * *
* * * * 13. The abstract does not reflect accurately the content of the
* * * * document.
* * * * "certificate handling" is too vague.
* * * *
* * * * Proposed abstract:
* * * *
* * * *    SCVP allows a client to delegate certificate path
construction
* and
* * * *    certificate path validation to a server. The path
construction or
* * * *    validation (i.e. making sure that none of the certificates of
the
* * * *    path is revoked) is made according to a validation policy
which
* * * *    contains one or more trust anchors. It allows to simplify
client
* * * *    implementations and to use a set of predefined validation
* policies.
* * * [TF] Suggested text substituted
* * * *
* * * *
* * * * 14. Section 1.3
* * * *
* * * * The text on validation policy is new. There is no concept of
* * "mutually
* * * * agreed" validation policy between the client on the server. The
* * server
* * * * supports a set of validation policies which may or may not fit
the
* * need
* * * * of the client.
* * * *
* * * * Change the second sentence of section 1.3 which is:
* * * *
* * * * " In SCVP, a validation policy can be either mutually
* * * *    agreed between client and server, and subsequently referenced
in
* * * *    request, or explicitly expressed in the request by passing
all of
* * * *    the necessary parameters."
* * * *
* * * * into:
* * * *
* * * * " In SCVP, the validation policy to be used by the server can be
* * either
* * * * fully referenced in the request by the client (and thus no
* additional
* * * * parameter is necessary), referenced in the request by the client
* with
* * * * additional parameters or supported by default by the server if
the
* * * * client does not reference it."
* * * [TF] Suggested text substituted
* * * *
* * * *
* * * * 15. Section 1.3. The second paragraph needs to be reworded.
* Currently,
* * * * it is the following:
* * * *
* * * * " Policy definitions can be quite long and complex, and some
* policies
* * * *    may allow for the setting of a few parameters such as a set
of
* * * *    trust anchors.  The request can therefore be simplified if
these
* * * *    previously agreed policy dependent parameters are referenced
in
* the
* * * *    request by a mutually agreed OBJECT IDENTIFIER (OID) or URL
* value.
* * * *    The referenced value indicates either a partial or full set
of
* * * *    parameters. The client can therefore omit these agreed
parameters
* * * *    from the request, only passing any parameters which are not
* * * *    specified by the previously agreed policy.  Therefore in the
* * * *    simplest form, with validation polices which define every
* parameter
* * * *    necessary, a SCVP request need only contain the certificate
to be
* * * *    validated, the validation policy and any run-time parameters
for
* * * *    the request".
* * * *
* * * * Proposed rewording:
* * * *
* * * * " Policy definitions can be quite long and complex, and some
* policies
* * * *    may allow for the setting of a few parameters.  The request
can
* * * *    therefore be very simple if OBJECT IDENTIFIERS (OIDs) are
used to
* * * *    specify both the algorithm to be used and all the associated
* * * *    parameters of the validation policy. The request can be more
* * complex
* * * *    if the validation policy fixes many of the parameters but
allows
* * the
* * * *    client to specify some of them. When the validation policy
* defines
* * * *    every parameter necessary, a SCVP request needs only to
contain
* the
* * * *    certificate to be validated, the referenced validation policy
and
* * any
* * * *    run-time parameters for the request. In its simplest form, a
SCVP
* * * *    request contains the certificate to be validated and any
run-time
* * * *    parameters for the request. In that case the server uses a
* default
* * * *    validation policy".
* * * [TF] Suggested text substituted
* * * *
* * * *
* * * * 16. Section 1.3. Paragraph 3.
* * * *
* * * * The text is missing the fact that at least one validation policy
* must
* * * * be supported by the server. This is the default policy which is
used
* * * * when the client omits to specify it.
* * * *
* * * * The current text is the following:
* * * *
* * * *   "SCVP server also publishes its default validation policy
* settings.
* * * *    The default policy can be requested for validation and the
client
* * * *    can override any default value in the request if required.
The
* * * *    default values are also used when processing requests which
* * * *    reference a validation policy other than the default one that
* does
* * * *    not contain the full set of parameters necessary for
validation
* and
* * * *    the client has also omitted the missing values in the
request.
* * * *
* * * *    Therefore a client can also simplify the request by omitting
a
* * * *    parameter from a request if the default value published by
the
* * * *    server is acceptable".
* * * *
* * * * Replace it with:
* * * *
* * * * " A SCVP server must support a default validation policy which
will
* * * *    be used if the client does not specify any in its request. A
* server
* * * *    publishes the references of the validation policies it
supports.
* * * *    When these policies have parameters that may be overridden,
the
* * * *    default value for these parameters are communicated by the
server
* * as
* * * *    well. The client can simplify the request by omitting a
parameter
* * * *    from a request if the default value published by the server
for a
* * * *    given validation policy reference is acceptable. However if
there
* * is
* * * *    a desire to demonstrate to someone else that a specific
* validation
* * * *    policy with all its parameters has been used, it will need to
ask
* * the
* * * *    server for the inclusion of the full validation policy with
all
* the
* * * *    parameters in the response".
* * * [TF] Suggested text substituted
* * * *
* * * *
* * * * 17. On top of page 7, the relationship between the validation
policy
* * * * and the basic certification path algorithm is not explained.
Then in
* * * * section 1.4 The concept of validation algorithm is introduced
but
* its
* * * * relationship with the validation policy is not explained. This
is
* * * * confusing.
* * * *
* * * * Later on when observing the ASN.1 syntax it may be discovered
that
* two
* * * * OIDs are being used:
* * * *
* * * *   - one for the validation policy (ValidationPolRef) and
* * * *   - one for the validation algorithm (ValidationAlg).
* * * *
* * * * This is overcomplicated and unnecessary.
* * [TF] Is there a specific issue with the current draft such as a
scenario
* * which is not addressed?
* * * *
* * * * An important simplification is obtained if, as the previous text
* * * * states, there is an OID to defined the validation policy and
there
* may
* * * * be or may not be additional parameters.
* * * *
* * * * We could then have:
* * * *
* * * * valPolByOID::= SEQUENCE {
* * * *        valPolId              OBJECT IDENTIFIER,
* * * *        parameters            ANY DEFINED BY ValPolId OPTIONAL }
* * * *
* * * * Specifying a path processing compliant with section 6.1 of RFC
3280
* * * * would be possible (notice however that the text from RFC 3280 is
too
* * * * vague to support the case where a CRL is not signed by the CA).
* * * *
* * * * It would be desirable to be able to communicate easily and in a
* * * * standard way the parameters that may be set in section 6.1 from
RFC
* * * * 3280. In addition, key usage should be added to that list.
* * * *
* * * * The document should then define a bundle of all these previous
* useful
* * * * parameters and allow for the addition of other parameters.
* * * *
* * * * It is thus proposed to define an OID for a validation policy
* compliant
* * * * with section 6.1 of RFC 3280 (some differences with section 6
from
* * * * 3280bis, i.e. adding precision, may be expected)
* * * *
* * * * It is thus proposed to modify the text starting from :
* * * *
* * * * " The inputs to the basic certification path processing
algorithm
* * * *    used by SCVP are defined by [PKIX-1] in section 6.1.1 and
* * comprise"
* * * *    up to the end of section 1.3 with the following:
* * * *
* * * * "For clients able to specify the parameters of a validation
policy,
* * it
* * * * may be useful to define a standard data structure (using a
bundle)
* * able
* * * * to support the parameters of the basic certification path
processing
* * * * algorithm defined by in section 6.1.1 from [PKIX-1] :
* * * *
* * * *   - a set of Trust Anchors (by value or by reference),
* * * *   - the initial Certificate Policy set,
* * * *   - initial Certificate Policy mapping setting,
* * * *   - initial any-Policy setting,
* * * *   - initial explicit Certificate Policy setting.
* * * *
* * * * as well as :
* * * *
* * * *    - the usage of the key contained in the certificate (e.g.,
key
* * * *      encipherment, key agreement, signature)
* * * *
* * * * This will be done using a bundle which encapsulates all these
* * * * parameters.
* * * *
* * * * Other application-specific purposes parameters may be added".
* * * *
* * * *
* * * * 18. Section 1.4 is about a "Validation Algorithm". Given what
was
* * said
* * * * before, the header of this section should be changed. If we make
a
* * * * subsection 1.3.1 called "1.3.1. General" for encapsulating the
* * * previous
* * * * text, then we can introduce a new section 1.3.2 called:
* * * *
* * * * "1.3.2. Validation policy according to section 6.1 of RFC 3280"
* * [TF] See comment to 17
* * * *
* * * * Some of the text present in the current section 1.4 has been
used to
* * * * build the new text that is proposed below:
* * * *
* * * * "1.3.2. Validation policy according to section 6.1 of RFC 3280
* * * *
* * * *    SCVP defines a specific validation policy which implements
the
* * * *    certification path validation algorithm as defined in section
6.1
* * of
* * * *    [PKIX-1]. This specific validation policy, called "rfc-3280
basic
* * * *    validation policy" uses the parameters defined in the bundle
* * * *    mentioned above.
* * * *
* * * *    Note that this algorithm does not support in its full
generality
* * the
* * * *    algorithm described in section 6.2 of [PKIX-1] since, when
more
* * than
* * * *    one trust anchor is being defined, all the conditions that
are
* * * *    specified apply to all trust anchors, whereas section 6.2
allows
* to
* * * *    have different conditions for every trust anchor.
* * * *
* * * *    The rfc-3280 basic validation policy may be the default
* validation
* * * *    policy supported by the server, but does not need to".
* * * *
* * * *
* * * * 19. Section 2 "Protocol Overview"
* * * *
* * * * In order to allow for interoperability and testing a common
protocol
* * * * needs to be supported. It should be defined.
* * [TF] There is plenty of precedence for this to be in a separate
* document.
* * CMS itself just defines the syntax.
* * * *
* * * *
* * * * 20. Section 3 "Validation Request"
* * * *
* * * * The unsigned request form is not explained and there is a
confusion
* * for
* * * * the signed request which indeed authenticates the client and is
thus
* * * * not anonymous. The current text is :
* * * *
* * * *    "A signed
* * * *    request is used to authenticate the client to the server or
to
* * * *    provide an anonymous client integrity over the
request-response
* * * *    pair."
* * * *
* * * * It should be rephrased as:
* * * *
* * * *    "An unsigned request provides an anonymous client integrity
over
* * * *     the request since the hash of the request or the full
request is
* * * *     incorporated in the response. A signed request is used to
* * * *     authenticate the client to the server".
* * [TF] Since by definition the anonymous client has to sign the
request as
* * well this does not make sense. A server can also return a cached
* response
* * in which case there is no hash of the request in the response. How
about
* *
* * An anonymous client signs the request to provide integrity over
* * the request. A identifiable signs the request to authenticate itself
to
* * the server.
* *
* *
* *
* *
* * * *
* * * *
* * * * 21. Page 13. Section 3.1.2 "checks"
* * * *
* * * * The following sentence adds nothing and should be removed:
* * * *
* * * *    "A server may still choose to
* * * *    perform revocation status checks when performing path
* construction,
* * * *    although this information cannot be returned to the client."
* * [TF] I think it reinforces that with some checks, don't require
* revocation
* * status checking but a server may still elect to do so.
* * * *
* * * *
* * * * 22. Page 15. Section 3.1.3 "wantBack"
* * * *
* * * * The text states:
* * * *
* * * *      - Proof of revocation status for each certificate in the AC
* * * *         issuer certification path;
* * * *
* * * * It would be important to refer the section of the RFC which
explains
* * * * how to
* * * * check the "revocation status for each certificate in the AC
issuer
* * * * certification path".
* * [TF] OK, I will add a reference to 3281 section 5.
* * * *
* * * *
* * * * 23. Page 15. Section 3.1.3 "wantBack"
* * * *
* * * * The text states:
* * * *
* * * *    The client can also request a non-cached response to the
request
* by
* * * *    including wantback id-swb-non-cached-resp in the request.
* * * *
* * * * The default behavior should be the reverse: fresh information is
* * * * provided, unless the client accept cached information. The item
* should
* * * * be changed into:
* * * * id-swb-cached-resp
* [TF] This has been moved to response flags and the default is
non-cached.
* * * *
* * * *
* * * * 24. Page 15. Section 3.1.3 "wantBack"
* * * *
* * * * The text states:
* * * *
* * * * id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb
13}
* * * *
* * * * It should be mentioned that this item is only possible for DPD.
* [TF] Why is this only possible with DPD?
* * * *
* * * *
* * * * 25. Page 16. Section 3.1.4 validationPolicy
* * * *
* * * * The following sentence is talking of an agreement whereas such
* * * * agreement does not exist. Delete the sentence:
* * * *
* * * *   "The client and server can optionally agree on a set of
parameters
* * * *    which may fully or partially define a validation policy".
* [TF] OK
* * * *
* * * *
* * * * 26. Page 16. Section 3.1.4 validationPolicy
* * * * The text states:
* * * *
* * * *    "If a partial set of parameters has been agreed upon,
* * * *    then the client supplies a reference to the policy plus
whatever
* * * *    parameters are necessary to complete the request in this
item.
* * * *
* * * * This should be replaced with:
* * * *
* * * *    "If the validation policy does not define all parameters
* necessary
* * * *    for processing an SCVP request, then the client need to
supply
* * these
* * * *    parameters".
* [TF] Thats is not true. The client can omit whatever parameters match
the
* server default value.
* * * *
* * * * 27. Page 16. Section 3.1.4 validationPolicy
* * * *
* * * *    The syntax of the validationPolicy item is defined as:
* * * *
* * * *    ValidationPolicy ::= SEQUENCE {
* * * *      validationPolRef          ValidationPolRef,
* * * *      validationAlg         [0] ValidationAlg OPTIONAL,
* * * *      userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
* * * *                                  IDENTIFIER OPTIONAL,
* * * *      inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
* * * *      requireExplicitPolicy [3] BOOLEAN OPTIONAL,
* * * *      inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
* * * *      isCA                  [5] BOOLEAN OPTIONAL,
* * * *      trustAnchors          [6] TrustAnchors OPTIONAL,
* * * *      keyUsages             [7] SEQUENCE SIZE (1..MAX) OF
KeyUsage
* * * *                                   OPTIONAL,
* * * *      extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}
* * * *
* * * *
* * * * This structure is quite odd, because it only allows to pass
* additional
* * * * parameters as parameters of the validationAlg. Suppressing the
* * * * validationAlg item add adding validationParamExtensions would be
a
* * * * simpler and cleaner way.
* [TF] The only way to include other parameters is because the algorithm
* needs them. You cannot introduce new parameters without at the same
time
* defining there use. Therefore mandating additional parameters be
passed
* which the corresponding identifier for their is the right thing to do.
* * * *
* * * * Each validation policies uses its own parameters.
* * * * We should have something like :
* * * *
* * * * ValPolByOID  ::= SEQUENCE {
* * * *        valPolgId             OBJECT IDENTIFIER,
* * * *        parameters            ANY DEFINED BY valPolId OPTIONAL }
* * * *
* * * * More details follow.
* * * *
* * * *
* * * * 28. It is highly debatable if URIs should be supported or not to
* * * * reference a validation policy. URIs are not stable over time and
* thus
* * * * unless there are dereferenced and a hash value is computed over
* them,
* * * * it is insecure to use them. There is a discussion in the
security
* * * * consideration section, but no warning and no pointer here. If we
* keep
* * * * them, we should warn the user.
* [TF] The argument over the stability of URIs is discussed in the
security
* section - which is the appropriate place. The reality is in many
* organizations are stable enough and much more manageable. The issue
over
* dereferencing and hashing is bogus. Both OID and URI are both opaque
* stings for this purpose and rely on you trusting the management doing
the
* right thing.
* * * *
* * * * If the WG should decides that they should be supported (and if
the
* * IESG
* * * * agrees) on page 17, the ASN.1 description should then be:
* * * *
* * * * ValidationPolicy ::= CHOICE {
* * * *      valPolByOID         [0] ValPolByOID,
* * * *      valPolByURI         [1] ValPolByURI }
* * * *
* * * * ValPolByOID  ::= SEQUENCE {
* * * *        valPolgId             OBJECT IDENTIFIER,
* * * *        parameters            ANY DEFINED BY valPolId OPTIONAL }
* * * *
* * * * ValPolByURI ::= SEQUENCE {
* * * *      uri            IA5String,
* * * *      hashAlgo       OBJECT IDENTIFIER,
* * * *      hashValue      OCTET STRING}
* * * *
* * * *
* * * * 29. It is proposed to define the following bundle:
* * * *
* * * * ValidationParamBundle ::= SEQUENCE {
* * * *      certificatePolicySet      [0] SEQUENCE SIZE (1..MAX) OF
OBJECT
* * * *                                    IDENTIFIER OPTIONAL,
* * * *      inhibitPolicyMapping      [1] BOOLEAN OPTIONAL,
* * * *      requireExplicitPolicy     [2] BOOLEAN OPTIONAL,
* * * *      inhibitAnyPolicy          [3] BOOLEAN OPTIONAL,
* * * *      isCA                      [4] BOOLEAN OPTIONAL,
* * * *      trustAnchors              [5] TrustAnchors OPTIONAL,
* * * *      keyUsages                 [6] SEQUENCE SIZE (1..MAX) OF
* KeyUsage
* * * *                                    OPTIONAL,
* * * *      extendedKeyUsages         [7] ExtKeyUsageSyntax OPTIONAL
* * * *      extensions                [8] EXPLICIT Extensions OPTIONAL
}
* * * *
* * * * Note that userPolicySet" is unclear and has been changed into
* * * * "certificatePolicySet".
* [TF] The use of userPolicySet aligns with 3280. I don't think the name
to
* the existing structure is ambiguous or misleading.
* * * *
* * * * The text would need to be aligned with the new structure and, of
* * course
* * * * the parameters of the rfc-3280 basic validation policy will
simply
* * * * include the bundle above as its parameters.
* * * *
* * * * It should also be mentioned somewhere in the document that the
* support
* * * * of the rfc-3280 basic validation policy is not mandatory for
* * * * conformance but, if supported then the bundle needs to be
supported.
* * * *
* * * *
* * * * 30. Page 17. Section 3.1.5 validationAlg should be deleted.
* [TF] Already done
* * * *
* * * *
* * * * 31. Page 17. Section 3.1.5.1 Default Validation Algorithm should
be
* * * * deleted and replaced by a section later on the "rfc-3280 basic
* * * * validation policy", which should have its OID defined under the
scvp
* * * * tree for OIDs.
* [TF] the basic validation algorithm references the 3280 section 6.
* * * *
* * * *
* * * * 32. Page 17. Section 3.1.5.1. Some text of this section might be
re-
* * * * sued to build a new section on the rfc-3280 basic validation
policy.
* * * * Note that the last sentence at the bottom of page 17, should be
* * * * removed. This sentence is: "The default validation policy MUST
use
* * the
* * * * basic validation algorithm". Any default validation policy can
be
* * used.
* * * *
* [TF] See answer to 31
* * * *
* * * * 33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5
!)
* * * * should be as well deleted.
* [TF] The duplicate has been deleted
* * * *
* * * *
* * * * 34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm
* * * *
* * * * This goal of this section seems to introduce an additional test
to
* the
* * * * basic "rfc-3280 basic validation policy". It would come
naturally as
* * * an
* * * * extension of ValidationParamBundle, rather than as a parameter
of
* the
* * * * validationAlgo which has been proposed to be removed. The text
* should
* * * * be modified accordingly.
* [TF] See answer 27
* * * *
* * * *
* * * * 35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm
* * * *
* * * *      NameValidationAlgParms ::= SEQUENCE {
* * * *        keyPurposeId      KeyPurposeId,
* * * *        validationNames   GeneralNames }
* * * *
* * * * This construct is artificial since KeyPurposeId is about the
* Extended
* * * * Key Usage and has nothing to do with name validation.
* [TF] Its simple reuses and existing practice.
* * * *
* * * * It could indeed be interesting to test the Extended Key Usage
* * extension
* * * * of a certificate, but this should be supported as an extension
of
* * * * ValidationParamBundle. The text should be modified accordingly.
* * * *
* * * *
* * * * 36. Page 22. Section 3.1.5.3 userPolicySet
* * * *
* * * * userPolicySet should be changed everywhere into
* certificatePolicySet.
* [TF] userPolicySet aligs with 3280 sectuin 6.
* * * *
* * * *
* * * * 37. Page 22. Section 3.1.5.3 userPolicySet
* * * *
* * * * The text has many sentences like:
* * * *
* * * *    SCVP clients SHOULD support userPolicySet item in requests,
and
* * * *    SCVP servers MUST support userPolicySet item in requests.
* * * *
* * * * These requirements only apply for the rfc-3280 basic validation
* * policy,
* * * * and this should be clearly mentioned.
* [TF] Since all validation polices contain userPolicySet, it can be in
any
* policy.
* * * *
* * * *
* * * * 38. Page 22. Section 3.1.5.4 inhibitPolicyMapping
* * * *
* * * * The text states:
* * * *
* * * *    By default the server allows policy mapping as
* * * *    part of certification path validation.
* * * *
* * * * For simplicity, this should be the reverse. Replace with:
* * * *
* * * *   "By default the server does not perform policy mapping as
* * * *    part of certification path validation. If the client wants
the
* * * *    server to support policy mapping, allowPolicyMapping must be
set
* * * *    to TRUE in the request".
* [TF] This conflicts with 3280 section 6.
* * * *
* * * *
* * * * 39. Page 24. Section 3.1.5.8 trustAnchors
* * * *
* * * * The text states:
* * * *
* * * *   "A certificate reference can be used to identify the
* * * *    trust anchor by certificate hash and optionally a
distinguished
* * * *    name with serial number".
* * * *
* * * * This is not consistent with the ASN.1 definition of PKCReference
* which
* * * * is:
* * * *
* * * *    PKCReference ::= CHOICE {
* * * *      cert                   [0] Certificate,
* * * *      pkcRef                 [1] ESSCertID }
* * * *
* * * * Please correct.
* * * *
* * * *
* * * * 40. Page 25. Section 3.1.6 responseRefHash
* * * *
* * * * The text states:
* * * *
* * * *    "By default, the server includes a hash
* * * *    of the request in the response.  If the client wants the
server
* to
* * * *    include the full request in the response, responseRefHash is
set
* to
* * * *    FALSE."
* * * *
* * * * The server shall always include a hash of the request in the
* response.
* [TF] A server cannot include a hash of the request in a cached
response.
* * * * This is an easy way to allow to test the integrity of the
request.
* * * * Since the full description of the validation policy may be much
* longer
* * * * a flag should be used to say that the full validation policy is
not
* * * * returned unless requested.
* [TF] There is one, it is responseValidationPolByRef. The reponce flags
now
* has a FullRequestInResponse in place of the requestRefHash
* 
* It is thus proposed to have instead the
* * * * following:
* * * *
* * * * "3.1.6.1 fullRequestInResponse
* * * *
* * * *    The fullRequestInResponse controls if the client wants the
server
* * * *    to include the full request in the response. By default,
* * * *    fullRequestInResponse is set to FALSE. If the client wants
back
* * * *    the full request then it must set this parameter to TRUE. The
* main
* * * *    reason a client would request the server to include the full
* * request
* * * *    in the response is to archive the request-response exchange
in a
* * * *    single object.  That is, the client wants to archive a single
* * object
* * * *    which includes both request and response".
* * * *
* * * *
* * * * 41. Page 26. Section 3.1.6.2 responseValidationPolByRef
* * * *
* * * * This item should be renamed: fullValPolInResponse
* * * *
* * * * The text should be changed into:
* * * *
* * * * "The fullValPolInResponse controls whether the response includes
the
* * * * identifier of the validation policy with all the parameters that
* have
* * * * been used by the server, i.e. all the variable parameters
* independent
* * * * from the fact that there were specified by the client or
defaulted
* if
* * * * not specified. By default, fullValPolInResponse is set to FALSE.
If
* * the
* * * * client wants the full validation policy to be included, then
* * * * fullValPolInResponse is set to TRUE. The main reason a client
would
* * * * request the server to include validation policy to be included
by
* * value
* * * * is to archive the request-response exchange in a single object.
That
* * * * is, the client wants to archive the CVResponse and have it
include
* * * * every aspect of the validation policy."
* [TF] I have not chages the name, but the section now reads
* 
* The responseValidationPolByRef controls whether the response includes
just
* a reference to the policy or the reference to the policy plus all the
* parameters by value of the policy used to process the request.
* the response MUST contain references to the validation policy.  If the
* client wants the validation policy parameters to be also included by
* value, then the responseValidationPolByRef is set to FALSE.  The main
* reason a client would request the server to include validation policy
to
* be included by value is to archive the request-response exchange in a
* single object.  That is, the client wants to archive the CVResponse
and
* have it include every aspect of the validation policy.
* 
* * * *
* * * * The ResponseFlags should be changed as follows:
* * * *
* * * *    ResponseFlags ::= SEQUENCE {
* * * *      fullRequestInResponse      BOOLEAN DEFAULT FALSE,
* * * *      fullValPolInResponse       BOOLEAN DEFAULT FALSE,
* * * *      signResponse               BOOLEAN DEFAULT TRUE }
* * * *
* * * *
* * * * 42. Page 28. Section 3.1.9 intermediateCerts. Minor.
* * * *
* * * * Change:
* * * *
* * * *    The optional intermediateCerts item helps the SCVP server
create
* * * *    valid certification paths.
* * * *
* * * * into:
* * * *
* * * *    The optional intermediateCerts item may help the SCVP server
to
* * * * create
* * * *    valid certification paths.
* [TF] Fixed
* * * *
* * * * 43. Page 29. Section 3.1.11. producedAt
* * * *
* * * * Last sentence. Change:
* * * *
* * * *    SCVP server SHOULD support the producedAt values in the
request.
* * * *
* * * * into:
* * * *
* * * *    SCVP server MAY support the producedAt values in the request.
* * * *
* * * * Reason: cached responses should not need to be implemented in
order
* to
* * * * be compliant with the specification.
* [TF] Fixed
* * * *
* * * *
* * * * 44. Page 32. Section 3.5 dhPublicKey
* * * *
* * * * The text states:
* * * *
* * * *   "For the server to compute the shared
* * * *    secret, it must lean the public values the client generates,
* * * *    therefore the client MUST include this in the request if it
uses
* * * *    this mechanism to integrity protect the request-response
pair."
* * * *
* * * * Replace:
* * * *
* * * * "to integrity protect the request-response pair"
* * * *
* * * * with :
* * * *
* * * * "to authenticate and integrity protect the first response and
* * * * authenticate and integrity protect subsequent request-response
* * pairs".
* [TF] draft now read " integrity protect the request and the subsequent
* response." The use of DH does not necessarily authenticate the
request.
* * * *
* * * * 45. Page 32. Section 3.6 SCVP Request Authentication
* * * *
* * * * The text states:
* * * *
* * * *   "It is a matter of local policy what validation policy is used
by
* * * *    the server when validating requests".
* * * *
* * * * This sentence could be misinterpreted because the word
"validating"
* * is
* * * * being used. Change into:
* * * *
* * * *    It is a matter of local policy what validation policy is used
by
* * * *    the server when authentication requests".
* * * *
* [TF] Fixed
* * * *
* * * * 46. Page 35. Section 4. Validation Response
* * * *
* * * *    The CVResponse is defined as follows:
* * * *
* * * *      CVResponse ::= SEQUENCE {
* * * *        cvResponseVersion         cvResponseVersion
INTEGER,
* * * *        policyID                  INTEGER,
* * * *        producedAt                GeneralizedTime,
* * * *        ....
* * * *
* * * * On the next page the test states:
* * * *
* * * *   "The policy ID used by the SCVP server when it processed the
* * request.
* * * *    See section 6.4 for details."
* * * *
* * * * In section 6.4 the text states:
* * * *
* * * * "6.4 defaultPolicyID
* * * *
* * * *    An integer that uniquely represents the version of the
default
* * * *    validation policy as represented by the trustAnchors, ..."
* * * *
* * * * This is not understandable, over-engineering and very
complicated.
* * * * Please delete this item.
[TF] This allows the client to track if any of the data previous
published has changed without polling the server. Forcing client to poll
is very inefficient.
* * * *
* * * *
* * * * 47. Page 35. Section 4. Validation Response
* * * *
* * * *    The CVResponse contains:
* * * *
* * * *        requestRef            [1] RequestReference OPTIONAL,
* * * *
* * * * Remove "OPTIONAL" since it is very beneficial to mandate this
item
* * * * since it allows to make sure that the request has not be
modified if
* * * * the response is integrity protected. The computation is fast and
* easy
* * * * and the hash value does not overload the response.
* * * *
[TF] This must be optional since cached responses cannot include this
value.
* * * *
* * * * 48. Page 38. Section 4.5 respValidationPolicy
* * * *
* * * * The definition of this item is overcomplicated and not tailored
to
* * * * support any kind of validation policy.
* * * *
* * * * If the client does not specify the validation policy or if the
* client
* * * * specifies a validation policy which has default parameters, then
the
* * * * full description of the validation policy shall be given back.
* * * *
* * * * If the client specifies a validation policy which has no default
* * * * parameters, then the reference and parameters, if any, of the
* * * * validation policy are in the request.
* * * *
* * * * The full description of the validation policy shall be given
back in
* * * * any case, if the fullValPolInResponse Boolean in ResponseFlags
is
* set.
* * * *
* * * * respValidationPolicy :: = ValidationPolicy
* * * *
[TF] This has been simplified along the line you describe. Validation
policies must also not define defaults for all values which also helps
in the simplification.
* * * *
* * * *
* * * * 49. Page 41. Section 4.6 requestRef
* * * *
* * * * As stated earlier, requestRef should be mandatory and always be
a
* hash
* * * * of the request.
[TF] See previous answer.
* * * *
* * * * In addition a fullRequest OPTIONAL parameter should be added as
an
* * * * optional item for CVResponse.
[TF] I don't see any value in retuning both the hash of the request and
the full request itself. If you have the full request it trivial to
calculate the hash.
* * * *
* * * * The full description of the validation policy shall be given
back in
* * * * any case, if the fullRequestInResponse Boolean in ResponseFlags
is
* * set.
[TF] SCVP 16 already does this.
* * * *
* * * * Change the text and the syntax accordingly.
* * * *
* * * *
* * * * 50. Page 41. Section 4.6 requestRef
* * * *
* * * * The text states:
* * * *
* * * *    "The requestRef item allows the client to associate a
response
* * with
* * * *    a request"
* * * *
* * * * This is wrong. This does not protect against a replay.
* * * *
* * * * Change with:
* * * *
* * * * "When the response is authenticated, the requestRef item allows
the
* * * * client to make sure that the request was not modified in
transit".
[TF] Denis, the original text is accurate, and your suggested
modification does not address the issue you raised. It is also not clear
this is a significant issue. At best it's a fairly minor denial of
service.
* * * *
* * * *
* * * * 51. Page 41. Section 4.6 requestRef
* * * *
* * * * The text states:
* * * *
* * * * " The requestNonce provides an alternative mechanism for
* * * *    matching requests and responses if the client has selected to
* * * *    include a full response."
* * * *
* * * * This is wrong. This is not an alternative for matching requests
and
* * * * responses.
* * * *
* * * * Replace with:
* * * *
* * * *   "The requestNonce allows to protect against replay, even if
time
* * * * synchronization is not good between the client and the server".
[TF] I agree the sentence needs refining and this was missed from SCVP17
but it does not protect against a replay.
* * * *
* * * *
* * * * 52. Page 42. Section 4.6.1 requestHash
* * * *
* * * * The text states:
* * * *
* * * * " The requestNonce provides an alternative mechanism for
matching
* * * * requests and responses".
* * * *
* * * * This is wrong. See above. Delete.
[TF] The client can match the response to the request by comparison of
ether the hash of the request or the full request.
* * * *
* * * *
* * * * 53. Page 45. Section 4.10.4 replyChecks
* * * *
* * * * ReplyCheck is defined as:
* * * *
* * * *      ReplyCheck ::= SEQUENCE {
* * * *        check                      OBJECT IDENTIFIER,
* * * *        status                     INTEGER }
* * * *
* * * * It should be defined as:
* * * *
* * * *      ReplyCheck ::= SEQUENCE {
* * * *        check                      OBJECT IDENTIFIER,
* * * *        status                     INTEGER DEFAULT 0}
[TF] I don't see this addresses any problems or issues.
* * * *
* * * *
* * * * 54. Page 46. Section 4.10.4 replyChecks
* * * *
* * * * The text states
* * * *
* * * *    "The status value for public key certification path building
to a
* * * *    trusted root along with complete status checking, { id-stc 3
},
* can
* * * *    be one of the following:
* * * *
* * * *        0: Good
* * * *        1: Revoked
* * * *        2: Revocation Offline
* * * *        3: Revocation Unavailable
* * * *
* * * * It is unclear to understand the benefits that a client can have
from
* * * * the difference between "Revocation Offline" and "Revocation
* * * * Unavailable". In addition, these wordings do not match the
* * explanations
* * * * of what there are.
[TF] If the SCVP server is experiencing network problems then an client
could try another server immediately. Also anyone auditing events would
hopefully understand that if some SCVP server were experiencing network
difficulties then not all clients would have the same status whereas
when the revocation information is offline all clients will have the
same status.
* * * *
* * * * A much more important response is missing: suspended. Suspended
is a
* * * * variation of revoked, but the client then knows it may attempt
* another
* * * * try later on.
[TF] Do you mean certificateHold? In which case retrying does not seem
in the spirit of hold instructions where you either reject or call the
CA issuer.
* * * *
* * * * It is thus suggested to change it into:
* * * *
* * * *        0: Good
* * * *        1: Revoked
* * * *        2: Suspended
* * * *        3: Revocation info unavailable"
* * * *
* * * *
* * * * 55. Page 46. Section 4.10.4 replyChecks
* * * *
* * * *
* * * * The same comment applies for the status value for AC issuer
* * * * certification path.
[TF] Same reply
* * * *
* * * *
* * * * 56. Page 48. Section 4.10.6 validationAlg
* * * * For reasons given before, delete validationAlg.
[TF] Same reply
* * * *
* * * *
* * * * 57. Page 48. Section 4.10.8 nextUpdate
* * * *
* * * * If CRLs are used, should this field contain the value of the
next
* * * * update field for the smallest value of all the CRLs ? What is
the
* real
[TF] Since the text specify refers to the status of the certificate so
the smallest next update from a CRL would be one criteria. It is useful
in that a client could determine how long to cache a successful
validation response.

* * * * benefit of supporting this element besides added complexity ? It
is
* * * * suggested to delete that item.
* * * *
* * * *
* * * * 58. Page 49. Section 4.11 responseNonce
* * * *
* * * * The text states:
* * * *
* * * * "The responseNonce item contains an identifier to binds the
request
* * * * to the response."
* * * *
* * * * This is incorrect. The nonce is to detect replay.
       [TF] See previous answer
* * * *
* * * * Change into:
* * * *
* * * * "The responseNonce item contains a unique number which allows to
* * detect
* * * * replay".
* * * *
* * * *
* * * * 59. Page 51. Section 5 Server Policy Request
* * * *
* * * * The text states:
* * * *
* * * *   "A SCVP client uses the valPolRequest item to request the list
of
* * * *    validation policies supported by the SCVP server."
* * * *
* * * * This is not a correct description of what this request is doing.
* When
* * * * looking at the ASN.1 it is doing much more. So the question is
* whether
* * * * two requests should be provided or one. In the later case, it is
* * * * important to advertise correctly what the request is doing.
        [TF] We will just update the description to broaden the scope
beyond validation policies.
* * * *
* * * *
* * * * 60. Page 52. Section 6 Validation Policy Response
* * * *
* * * * The ASN.1 of the VPResponse is over-complicated.
* * * *
* * * * The first three items are overengineering:
* * * *
* * * *        vpResponseVersion          INTEGER,
* * * *        maxCVResponseVersion       INTEGER,
* * * *        maxVPResponseVersion       INTEGER,
* * * *
* * * * Further more they are mandatory. Please delete.
[TF] They are in for forwards compatibility. A client can always query
with VP=1 and find out what other capabilities the server has.
* * * *
* * * *
* * * * 61. Page 52. Section 6 Validation Policy Response
* * * *
* * * * The ASN.1 of the VPResponse is over-complicated.
* * * *
* * * *         defaultPolicyID            INTEGER,
* * * *
* * * * This item does not make sense. When an OID references a
validation
* * * * policy, there is no concept of versioning. Another version will
* simply
* * * * get another OID (hopefully in the same branch). Please delete.
[TF} this is simply used by the server to indicate a configuration
change, therefore a integer is simple to implement. 
* * * *
* * * *
* * * * 62. Page 52. Section 6 Validation Policy Response
* * * *
* * * * The ASN.1 of the VPResponse is over-complicated.
* * * *
* * * *        validationPolices          SEQUENCE OF ValidationPolRef,
* * * *        validationAlgs             SEQUENCE OF OBJECT IDENTIFIER,
* * * *
* * * * validationAlgs is unnecessary. Please delete.
[TF] See previous answer.
* * * *
* * * * validationPolicies (not validationPolices) is the main
component.
* See
* * * * below for a full proposal for restructuring VPResponse.
* * * *
* * * *
* * * * 63. Page 52. Section 6 Validation Policy Response
* * * *
* * * *        authPolicies               SEQUENCE OF AuthPolicy,
* * * *        responseTypes              ResponseTypes,
* * * *        dhPublicKeyInfo            SEQUENCE OF DHPublicKeyInfo,
* * * *
* * * * are elements which have nothing to do with the list of
validation
* * * * policies, and they are mandatory ! Either group them in one
OPTIONAL
* * * * item or define another command to get them.
[TF] The server public key is now optional.
* * * *
* * * *
* * * * 64. Page 52. Section 6 Validation Policy Response
* * * *
* * * *       defaultPolicyValues        ValidationPolValues,
* * * *
* * * * This is simply the set of parameters which are related to the
rfc-
* 3280
* * * * basic validation policy. This set could be used by other
validation
* * * * policies. Please delete.
[TF] Deleted. We now reuse the same structure as the validation
response.
* * * *
* * * *
* * * * 65. Page 52. Section 6 Validation Policy Response
* * * *
* * * * What follows is a sketch for a proposal for VPResponse.
* * * *
* * * *     VPResponse ::= SEQUENCE {
* * * *        requestNonce               OCTET STRING      OPTIONAL
* * * *        thisUpdate                 GeneralizedTime,
* * * *        nextUpdate                 GeneralizedTime   OPTIONAL,
* * * *        validationPolicies         SEQUENCE OF ValidationPolicy,
* * * *        serverParams               ServerParams      OPTIONAL }
* * * *
* * * *
* * * *     ServerParams ::= SEQUENCE {
* * * *        responseTypes              ResponseTypes,
* * * *        authPolicies           [0] SEQUENCE OF AuthPolicy
* * OPTIONAL,
* * * *        dhPublicKeyInfo        [1] SEQUENCE OF DHPublicKeyInfo
* * OPTIONAL,
* * * *        clockSkew              [2] INTEGER OPTIONAL }
* * * *
* * * * Note: it is re-called that ValidationPolicy should be redefined
as:
* * * *
* * * * ValidationPolicy ::= CHOICE {
* * * *      valPolByOID         [0] ValPolByOID,
* * * *      valPolByURI         [1] ValPolByURI }
* * * *
* * * * ValPolByOID  ::= SEQUENCE {
* * * *        valPolgId             OBJECT IDENTIFIER,
* * * *        parameters            ANY DEFINED BY valPolId OPTIONAL }
* * * *
* * * * ValPolByURI ::= SEQUENCE {
* * * *      uri            IA5String,
* * * *      hashAlgo       OBJECT IDENTIFIER,
* * * *      hashValue      OCTET STRING}
* * * *
[TF] This is a stylistic change so is out of scope.
* * * *
* * * *
* * * * 66. Page 56. Section 7 SCVP Server Relay
* * * *
* * * * This section is incomplete and lacking explanations. Please
explain
* * how
* * * * relaying is achieved.
[TF] Do you have specific question or area which is unclear?
* * * *
* * * *
* * * * 67. Page 65. Section 9 Security Considerations
* * * *
* * * * In the second paragraph, there is a discussion about the use of
URIs
* * to
* * * * reference validation policies.
* * * *
* * * * Firstly, if URIs are going to stay, a pointer to the security
* * * * consideration section should be present in the main body of the
* * * * document.
[TF] We will add a reference to the security secion. This was missed for
SCVP17.
* * * *
* * * * Secondly, the text should mention the need for the ability to
* * * * dereference the URI and the need to compute a hash, while the
main
* * body
* * * * of the document should explain the computation of a hash on the
* * content
* * * * of the URI.
[TF] We don't have this requirement for OIDs so I don't see we need it
for URI.
* * * *
* * * *
* * * * 68. Page 65. Section 9 Security Considerations
* * * *
* * * * The text states:
* * * *
* * * *   "It can also do this by using the Diffie-hellman keys to sign
the
* * * * request".
* * * *
* * * * Replace "sign" by "authenticate".
[TF] We use the term protect the request since the request can also be
anonymous.
* * * *
* * * * END OF COMMENTS
* * * *
* * * *




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FMdrtX002009; Tue, 15 Feb 2005 14:39:53 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FMdrFC002008; Tue, 15 Feb 2005 14:39:53 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FMdqBN002000 for <[e-mail]>; Tue, 15 Feb 2005 14:39:53 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1FMdfa9025412; Tue, 15 Feb 2005 17:39:41 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1FMckEY017999; Tue, 15 Feb 2005 17:38:48 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 15 Feb 2005 14:31:09 -0500
To: Denis Pinkas <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: SCVP 16 comments 1-16
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 05:45 PM 2/15/2005 +0100, Denis Pinkas wrote:
>Tim,
>
>1) Would you explain the difference between:
>
>  - Build a certification path to a trust anchor
>    (i.e. id-stc-build-pkc-path)

id-stc-build-pkc-path is asserted to indicate that a client wants the 
server to construct a certification path but is not asking the server to 
guarantee it is valid, or provide status information.

This functionality is the minimum required to support DPD.  The DPD client 
will perform path validation itself, so the server need not perform this step.

>   and
>
>  - Build a validated certification path to a trust anchor
>    (id-stc-build-valid-pkc-path) ?

id-stc-build-pkc-path is asserted to indicate that a client wants the 
server to construct and validate a certification path but is not asking the 
server to check status information.  This functionality is the minimum 
required to support DPV.

>2) I would then presume that a conforming SCVP server implementations
>    MUST support the id-stc-build-status-checked-pkc-path check
>    instead of the id-stc-build-pkc-path check
>    (but the answer to the first question might possibly solve this one).

Here is the text with respect to mandatory to implements:


>>>>>    Conforming SCVP server implementations MUST support the id-stc-build-
>>>>>    pkc-path check.  Conforming SCVP server implementations that support
>>>>>    delegated path validation (DPV) as defined in [RQMTS] MUST support
>>>>>    the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-
>>>>>    path checks.


SCVP servers that perform DPV MUST support all three checks.  Most 
importantly, DPV server need to support 
id-stc-build-status-checked-pkc-path, where the server constructs and 
validates a path including checking status information.  Supporting all 
three checks is not burden, since a path that satisfies this check 
satisfies the other checks as well.

However, SCVP servers that only support DPD need only support 
id-stc-build-pkc-path.  It would be very burdensome to require DPD servers 
to support id-stc-build-status-checked-pkc-path when that functionality is 
not required by its clients.

Does that clarify things?

Thanks,

Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FMd8SC001913; Tue, 15 Feb 2005 14:39:08 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FMd7SO001912; Tue, 15 Feb 2005 14:39:07 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FMd6H9001905 for <[e-mail]>; Tue, 15 Feb 2005 14:39:06 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1FMcfD9017835; Tue, 15 Feb 2005 17:38:41 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1FMbrEY017430; Tue, 15 Feb 2005 17:37:54 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 15 Feb 2005 17:38:54 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: PKIX Agenda Requests for 62nd IETF
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

I am working on the agenda for the PKIX meeting at Minneapolis.  WG agendas 
are due in Monday the 28th at noon, but I would like to post the first 
draft to the list by Tuesday the 22nd.

Please let me know ASAP if you would like space on the agenda.  I would 
appreciate it if requests include the word "agenda" in the subject 
line.  Filtering out the important emails from the spam isn't always easy!

Preference as always goes to presentation of PKIX documents and related 
IETF work.  Time *may* allow for a few "liaison" presentations regarding 
non-IETF work.

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FM9efw098885; Tue, 15 Feb 2005 14:09:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FM9eBP098884; Tue, 15 Feb 2005 14:09:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FM9MGi098856 for <[e-mail]>; Tue, 15 Feb 2005 14:09:22 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1FM8eDR011219; Tue, 15 Feb 2005 17:08:41 -0500
Received: from [129.6.54.72] (st26.ncsl.nist.gov [129.6.54.72]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1FM7rEX007649; Tue, 15 Feb 2005 17:07:55 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 15 Feb 2005 17:08:03 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040804
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], Tim Polk <[e-mail]>, Trevor Freeman <[e-mail]>, Russ Housley <[e-mail]>, Ambarish Malpani <[e-mail]>
Subject: Re: SCVP Draft 17: Summary of changes
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester wrote:

>Here some comments to the new draft. 
>
>
>1 - on page 12: 
>
>   "The list of certificate references in the query item"
>
> replace this by
>
>   "The list of certificate references in the queriedCerts item"
>
> It might be usefule to consider to add quotes to enhance some
> readability `queriedCerts'  in particular whether the syntax elements
> could be confused.
>  
>
OK.

>2 - 
>
>I vaguely remember that concerning comment C there was my suggestion 
>to use tagging that is an explicit version of what would happen with 
>AUTOMATIC tagging, unless I'm wrong this would give something like
>
>     CertReferences ::= CHOICE { 
>       pkcRefs           SEQUENCE SIZE (1..MAX) OF PKCReference, 
>       acRefs            [0] SEQUENCE SIZE (1..MAX) OF ACReference } 
>    
>     PKCReference ::= CHOICE { 
>       cert              Certificate, 
>       pkcRef            [0] ESSCertID } 
>    
>     ACReference ::= CHOICE { 
>       attrCert          AttributeCertificate, 
>       acRef             [0] ESSCertID } 
>
>see also point 14.
>
>  
>
This seems to be a proposal to change the ASN.1 to make it more 
"elegant".  Making this change would in no way improve the protocol.  
Tim wants this document to be completed and has declared that changes to 
the protocol for "stylistic" reasons only are out of scope.

>3 -
>
>         "The checks item MUST contain a sequence of object identifiers
>   (OIDs)."  
>
>This sentence seems superflous to me, since the syntax already says that.
>  
>
The text is consistent, and reinforces the information that an ASN.1 
mechanic would glean from the syntax.  There isn't any harm in leaving 
it, is there?

>4 - The usage of anyKeyUsage in the keyUsages is not explicitely defined.
>   (It can be guessed to a certain degree..)
>  
>
The text currently says:

  The keyUsages item may indicate either the particular key usages that
  are required by the client or that the client does not require any
  particular key usage.

The anyKeyUsage is implicitly described by the "or that the client does 
not require any particular key usage".  This can be made more explicit 
if necessary.

>   in other words, the requiredKeyUsages is defined, but not the anyKeyUsage
>
>   What is the difference of having a NULL option and not having coded
>   the optional field?
>  
>
If the client includes the keyUsages item in the validationPolicy in the 
request and specifies the anyKeyUsage choice (encoded as NULL), the 
client is indicating that it does not want validation to fail as a 
result of the contents of the keyUsage extension in the end certificate 
(or the absence of the keyUsage extension from the certificate).

>   Note that if the requiredKeyUsages is used, non existance of the 
>   key usage in a cert extension is a match.
>  
>
If the client omits the keyUsages item from the the validationPolicy in 
the request, the client is indicating that validation should be 
performed using the default value for the validation policy specified in 
the validationPolRef item.

For example, a validation policy may, by default, require that the end 
certificate either not include a keyUsage extension or include a 
keyUsage extension with the digitalSignature bit set.  If the client 
specifies the use of this validation policy and omits the keyUsages item 
from the the validationPolicy in the request, then any end certificate 
that included a keyUsage extension without the digitalSignature bit set 
would be rejected.  If the client specifies the use of this validation 
policy but includes the keyUsages item with the anyKeyUsage choice, then 
the client is indicating that end certificates should be considered 
valid if they include keyUsage extensions with digitalSignature set to 0.

>5- 3.2.4.9  
>
>   "If the client wishes to confirm 
>   the extended key usage, then it can communicate the usage it wants to
>   validate by the same extension using the same semantics as defined in
>   [PKIX-1]."
>   
>   
>   shouldn't 
>
>      SEQUENCE SIZE (1..MAX) OF KeyPurposeId
>
>   then be replaced by 
>
>      ExtKeyUsageSyntax
>
>   otherwise "same extension" is not well defined. (and even then)
>   
>  
>
Acutally, in the validationPolicy structure, extendedKeyUsages is now 
defined as:

         extendedKeyUsages     [8] SEQUENCE OF KeyPurposeId OPTIONAL

Unlike in a certificate, there needed to be the option to include 
extendedKeyUsages in an SCVP request with an empty sequence.  The effect 
of including extendedKeyUsages in a request with an empty sequence is 
similar to the effect of including keyUsages with anyKeyUsage.  That is, 
the client is explcitly stating that it has no requirements with respect 
to extended key usages.

We will re-word the above sentence to more clearly convey this.

>6-
>
>  suggestion to replace: 
>
>   "Therefore if the client obtained the certificate in the 
>   context of a TLS server," 
>
>   "E.g., if the client obtained the certificate in the 
>   context of a TLS server," 
>
>  
>
We will replace "Therefore" with "For example".

>7 -
>
>   "When using the default validation policy, the client can override any
>   of the default parameter values by supplying a specific value in the
>   request.  The SCVP server MUST make use of the provided parameter 
>   values or return an error response."
>
>   How are default values specified?
>  
>
For the default validation policy, the server provides the default 
paramers in its validation policy response message.

>8 - 3.2. 4     
>
>   "A validation policy MUST define default values for all parameters 
>   necessary for processing an SCVP request.  For each parameter, a 
>   validation policy may either allow the client to specify a non-
>   default value or forbid the use of a non-default value."
>
>  - How are default values specified?  if there is a MUST, then
>    why are all of them OPTIONAL?
>  
>
In section 3.2.4, the client is specifying the validation policy under 
which it wants certificates to be validated.  The fields are OPTIONAL 
since the client only needs to specify values that are different from 
the default values for the validation policy specified in 
validationPolRef.  Since the client could opt to use the server's 
default values for all parameters, the parameter values are OPTIONAL in 
the request.

In the server's response message,  if the server is including the full 
validation policy in the response, then all of these fields MUST be 
populated.

>  - How is 'forbid the use of a non-default value' indicated in the
>    policy, and how, in this case the policy contains a the fixed
>    non-default value? 
>  
>
In the validation policy response, the server indicates the default 
values it uses for the default validation policy.  The validation policy 
response also allows the server to list which validation policies it 
supports, but without providing any information about them.  In the 
certificate validation response, the server may indicate the parameter 
values that it used when processing a particular request (if the client 
set responseValidationPolByRef to FALSE in the request).

So, it seems to me that any other information about validation policies, 
including which default parameter values can be overridden and which can 
not must be provided through out of band means.  Either that or the 
client figures it out through trial and error :)

>9 - 3.5  requestorName 
>       
>   "The optional requestorName item is used by the client to include an 
>   identifier in the request.  The client MAY include this information 
>   for the DPV server to copy into the response. 
>    
>   SCVP servers MUST be able to process requests that include this
>   field."
>
>   Please add:
>
>   A server MAY require this to match with some authenticated identity
>   depending on a server defined rule.
>  
>
Why do we need to say this explicitly?  It seems out of scope to me.  
The server may choose to support clients on whatever basis it wishes, 
including the contents of the requestorName field in the request and 
some authneticated identity.  We do not need to specify the variety of 
mechanisms that might be considered...

>10 - 4.8  
>
>   "Alternatively, the SCVP server MAY omit this item."
>
>   I don't think that this is not a alternative if the client has set a
>   requestorName, if if my reading of 3.5  "to copy into the response"
>   mean that the server MUST copy.
>  
>
RFC 3379 states:

  When the DPV request is authenticated, the client SHOULD be able to
  include a client identifier in the request for the DPV server to copy
  into the response.  Mechanisms for matching this identifier with the
  authenticated identity depends on local DPV server conditions and/or
  the validation policy.  The DPV server MAY choose to blindly copy the
  identifier, omit the identifier, or return an error response.

The last sentence in this paragraph is very clear that the server may 
omit the identifier in the response even when the client sends an 
authenticated request with and asserts an identity in the request.

>   Mildly speaking, after total silence since my last remark concerning
>   these fields, I was not sure whether anything at all was accepted
>   by the authors, or not, anyway, the tendancy has continued to 
>   partially respond, and not say anything to concrete proposal, which
>   is simply to have a requesterName in both requests and responses
>   as a GeneralNames (note the s), so taht a relay can add an id etc.
>  
>
For relay, one uses requestorRef.  requestorRef allows for a sequence of 
identities, there is text in section 7 stating that the sequence needs 
to list all of the servers involved in processing the request, and there 
is a requirement that the response MUST copy the value of requestorRef 
from the request.

>11 -
>
>   "In the case of non-cached responses to signed requests, the SCVP 
>   server SHOULD return a requestor name."
>
>   For what reason a SHOULD? What is the reason for returning anything
>   for a "signed" requst if the client doesn't need this? And, why
>   'signed' and not protected?
>  
>
I agree that signed should be replaced with "authenticated".  The change 
from "signed" to "protected" was made at the last minute and this was 
overlooked.  The term "protected" would be inappropriate here since 
"protected" includes unauthenticated requests in which the client used 
an ephemeral Diffie-Hellman key.

>12 - 7:
>       "SCVP 
>   servers that support relay SHOULD populate this item with the DNS 
>   name of the server or the distinguished name in the server's 
>   certificate.  SCVP servers MAY choose other procedures for generating
>   identifiers that are unique within their community." 
>
>   I don't think the SHOULD is appropriate. DNS or distingushed name may 
>   not exist, and there is no indication who an octet string can be populated.
>  
>
The entire paragraph reads:

  To prevent false loop detection, servers should use identifiers that
  are unique within their network of cooperating SCVP servers.  SCVP
  servers that support relay SHOULD populate this item with the DNS
  name of the server or the distinguished name in the server's
  certificate.  SCVP servers MAY choose other procedures for generating
  identifiers that are unique within their community.

As you state, a DNS name or DN may not be appropriate in all 
circumstances, which is why the document says "SHOULD" instead of 
"MUST".  The most important part is that identifiers be chosen "that are 
unique within their network of cooperating SCVP servers".  DNS names and 
DNs are just two types of identifiers that are likely to provide this 
property.

Since the only requirement is that the identifiers be "unique within 
their network of cooperating SCVP servers", there is no need to mandate 
how the identifiers are encoded within the OCTET STRING.

>13 - 7:
>
>   It is quite nice to have loop detection for relaying,
>
>   but nothing is said how a relay constructs a request from 
>   a received on, and how a response is created from the 
>   received response.
>  
>   (E.g. what to do with requesterName in the request? )
>
>   The SCVP still does not contain a means to include the respons 
>   of another SCVP server in a response.
>  
>
SCVP should not include a means to include the response of another SCVP 
server in a response.  An SCVP client sends a request to an SCVP server 
and gets a response from that server.  How the server derives the answer 
that it provides in the response is a local matter to the server.  The 
server may call upon the services of other SCVP servers in generating 
the response (i.e., the server may use SCVP relay), but that should be 
transparent to the reponse.  If the SCVP server were allowed to simply 
include the reponse from another SCVP server in its response, then this 
would impose more complexity on the SCVP client, which would need to 
parse responses that differed based on how the SCVP server derived the 
response.

>14 - Since it seems that it has been agreed somehow that a id cannot
>   necessarily be derived from a security envelope, or, at least for
>   symmetric reason, a response should have an value identifying
>   the responder.
>
>   Ah well, the previous responder item whihc had context 4 had been
>   silently dropped (instead of being replaced by a generalnames.)
>  
>
>     CVResponse ::= SEQUENCE { 
>       cvResponseVersion         INTEGER, 
>       policyID                  INTEGER, 
>       producedAt                GeneralizedTime, 
>       responseStatus            ResponseStatus, 
>       respValidationPolicy  [0] RespValidationPolicy OPTIONAL, 
>       requestRef            [1] RequestReference OPTIONAL, 
>       requestorRef          [2] SEQUENCE SIZE (1..MAX) OF OCTET  
>                                   STRING OPTIONAL, 
>       requestorName         [3] GeneralNames OPTIONAL, 
>           replyObjects          [5] ReplyObjects OPTIONAL, 
>       respNonce             [6] OCTET STRING OPTIONAL, 
>       serverContextInfo     [7] OCTET STRING OPTIONAL, 
>       cvResponseExtensions  [8] Extensions OPTIONAL } 
>
>   please "align" the syntax.
>  
>

A self asserted identity has a value to the client, as established in 
RFC 3379, when returned in the response.  Since this requirement was 
agreed upon by the WG and included in RFC 3379, we wanted to be sure the 
specification supported it.

Our reading of RFC 3379 does not support inclusion of a self asserted 
server identity.   Where the client cares about the identity, it can 
obtain that information from the security envelope.  Where no security 
envelope is available, the client is performing all security relevant 
processing locally, and does not need the server's identity.  Unlike the 
requestorName, this information is not returned in future messages, so 
it has no value to the server either. 

In short, a self asserted server identity has no security value, and we 
could not come up with other useful semantics  - we tried -  so we 
deleted it.

>15 - ReplyWantBack
>
>   I have never any explication why the
>
>     ReplyWantBack::= SEQUENCE { 
>       wb                         OBJECT IDENTIFIER, 
>       value                      OCTET STRING } 
>
>   is an encapsulating octet string. Since the client
>   makes a particular wantback, one could assume that
>   it knows the syntax? 
>   
>     ReplyWantBack::= SEQUENCE { 
>       wb                         OBJECT IDENTIFIER, 
>       value                      ANY DEFINED BY wb } 
>
>   seems better to me.
>  
>
This is an "elegance" issue again, and we can make similar arguments 
about the encoding of Extensions, etc.  Changing from "OCTET STRING" to 
"ANY DEFINED BY wb" would be a stylistic change that would not improve 
the protocol.

>17 - 9
>
>   I think all staements of what a client or server MUST do with
>   certain field should go to the section defining the protocol
>   element. 
>
>   example the first statement in
>
>   "Clients MUST check the requestRef item in the response and ensure 
>   that it matches their original request.  Requests contain a lot of 
>   information that affects the response and clients need to ensure that
>   the server response corresponds to the request."
>
>  
>
We missed this one in the security requirements section.  Since 
non-cached responses may omit the requestRef item, this cannot be a 
MUST.  Matching the request message with the contents of requestRef is 
one option, but there are other ways for the client to verify that the 
response properly corresponds to the request.  So, we would propose 
changing the referenced text in the security considerations section. 

   Clients MUST verify that the response matches their orignal 
request.   Clients need to ensure that
   the server has performed the appropriate checks for the correct 
certificates under the requested
   validation policy for the specified validation time, and that the 
response includes the requested want
   backs and meets the client's freshness requirements.

It's a mouthful, but I believe this is the correct statement.  As 
restated, it should stay in the security considerations section.

>18 - 9
>
>   "Therefore in these situations use 
>            of a URI many be more attractive."
>
>   Is there a comma missing behind the first word? if so, there are other places, too.
>
>  
>
We'll ask our local tech editor, but I think that the comma is not 
required.  However, we should change the "many" to "may".

>19 - 9
>   
>   "... ensure that the response cannot be a replay
>   of a cached response obtained by another client."
>
>   Are you sure? replay of cached responses are a feature
>   of a server. A client may well accept a response that
>   has no client identifiers etc IF the response is
>   timely etc.
>
>  
>
We will delete "and ensure that the response cannot be a replay of a 
cached response obtained by another client".  This will require 
rewriting the remainder of the paragraph.  How about the following text:

   If an SCVP client is not operating on a network with good physical
   protection, it must ensure that there is integrity over the SCVP
   request-response pair.  The client can ensure integrity by using a
   protected transport such as TLS.  It can ensure integrity by using
   MACs or digital signatures to individually protect the request and
   response messages.

>20 - 9
>
>   The last paragraph in 9 seems to me to belong elsewhere. 
>
>  
>
Section 3.2.7 already contains advice on how to use the validationTime 
field.  Section 9 describes the security considerations associated with 
use of a historical validationTime.

>   And, in fact, nothing has been said anywhere that setting
>   a validationTime has something to do with history.
> 
>   It can simply mean that the client has the best idea of what
>   is 'NOW', and gives that time. (Although I would imagine that
>   a server probably knows better). 
>
>   The definition of validationTime does not say what a client can
>   set into ythat field.
>  
>
Section 3.2.7 states:

  The validationTime provided MUST be a
  retrospective time since the server can only perform a validity check
  using the current time (default) or previous time.  A server can
  ignore the validationTime provided in the request if the time is
  within the clock skew of the server's current time.

So, validationTime is really only intended to be used when the specified 
time is in the past.  While the specified time could be in the recent 
past or distant past, there is nothing in section 3.2.7 or section 9 
that suggests otherwise.

>21 - 9 
>
>   "A certificate may
>   have been revoked after the time specified in validationTime, but an 
>   invalidity date that precedes the validationTime."
>  
>   I cannot parse that sequence of words.
>  
>
This does need to be fixed.  It should say:

    A certificate may have been revoked after the time specified in 
validationTime,
    but the revocation notice may specify an invalidity date that 
precedes the
    validationTime.

>22 - B.1
>
>    "The body of the message is the binary value of the DER encoding 
>       of the CVRequest"
>
>   what is the reason for the "DER" here. If no wrapping occurs, then ...
>   and also the resulting CMS is not necessarily DER.
>  
>
OK.  We will change DER to BER.  That change will probably need to occur 
in sections B.2, etc., as well.

>23 - Paul Hoffman used to be one of the authors. Even when nothing of what
>   was written by Paul has remained, the contributions section could
>   still name him, unless ... 
>
>   "The lively debate"  may you consider to replace it by 'the lively or almost deadly debate' 
>
>Peter
>
>  
>
This predates my involvement, but you are correct.  Tim tells me we 
should add Paul to the list of guilty parties.

As to the debate, how much honesty do we really need?



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FIUC4m080972; Tue, 15 Feb 2005 10:30:12 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FIUCou080971; Tue, 15 Feb 2005 10:30:12 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FIUBTG080956 for <[e-mail]>; Tue, 15 Feb 2005 10:30:11 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 15 Feb 2005 18:30:00 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Date: Tue, 15 Feb 2005 18:29:39 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
thread-index: AcUTbDOrYwtonW1CQ8WKqdfWoTcLngACbfGg
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 15 Feb 2005 18:30:00.0347 (UTC) FILETIME=[5B9FB6B0:01C5138C]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1FIUCTG080966
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments in-line;
(Some stuff deleted to keep volume down)

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> 
> What about the following sentences picked from the document:
> 
>     Standardized methods of finding the certificate of the CRL issuer
are
>     currently available either though an accessible directory location
or
>     through use of the Subject Information Access extension in
>     intermediary CA certificates.  These methods are however not
>     generally applicable, and they do not provide a generic solution
to
>     the problem.
> 
> This is true only if indirect CRLs are being used, but the wording
> "indirect
> CRL" is absent from these lines.

[Stefan] Even if it was true ONLY for indirect CRL's, text would be
correct. But even more, this is NOT ONLY true for indirect CRL's. For
example, it is also true if your current CA infrastructure and its CA
certificates (which may be valid for another 5-20 years), don't include
a SIA extension. AIA in CRL's can be added to the infrastructure without
reissuing CA certificates, SIA can't. This is just 1 example. There are
more.

> 
> > It is an optional mechanism to be used
> > by those who whish to use it to find the CRL signer cert.
> 
>   ... which is really motivated when indirect CRLs are being used, but
> otherwise is not and the draft does not say it.
> 

[Stefan] Because it is not useful only for indirect CRLs.

> > I think the motivation for allowing this extension in CRLs is
> > sufficiently stated in the document.
> 
> It is not. In addition, adding an extension does not make sense unless
you
> tell how it should be used.
> 

[Stefan] What is unclear for you?

> > Nothing you suggest is changing the
> > technical outline of the specified solution.
> 
> In this case, the processing of this new extension may be explained
and
> this
> is not the case at this time.
> 

[Stefan] What is missing?


<stuff deleted>
> 
> >> The problem is that neither the abstract nor the introduction of
this
> >> draft is limiting the scope to indirect CRLs only.
> 
> > [Stefan] That is because the scope of AIA in CRLs is not limited to
> > indirect CRLs.
> 
>    .. but this extension does not add anything, if SIA used.
> 

[Stefan] Yes it does. It offers direct lookup of the CRL issuer cert and
indicates that the CRL Issuer certificate actually IS available for
download, while SIA only offers pointer to location where the CRL issuer
cert MAY be found among other unrelated certificates, 1) if it is
present and 2) if the client is capable of finding it.


> 
> > [Stefan] This is incorrect. The data in each DP of the CDP will tell
the
> > RP whether the DP points to an indirect CRL.
> 
>     DistributionPoint ::= SEQUENCE {
>          distributionPoint       [0]     DistributionPointName
OPTIONAL,
>          reasons                 [1]     ReasonFlags OPTIONAL,
>          cRLIssuer               [2]     GeneralNames OPTIONAL }
> 
>     DistributionPointName ::= CHOICE {
>          fullName                [0]     GeneralNames,
>          nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }
> 
> Which field are you talking about ?

[Stefan] cRLIssuer

> 
> >> The draft should thus address the two scenarios (i.e. an IDP is or
is
> >> not present) and for direct CRLs there is no "superiority" of the
new
> >> extension.
> 
> > [Stefan] I don't see the point with that. The use of the AIA
extension
> > in CRL is not different for indirect or direct CRLs.
> 
> With direct CRLs, there does not need to be any AIA extension, if the
SIA
> extension in CA certificates is present. This is not said and should
be
> said.
> 

[Stefan] I don't see any purpose in saying that. This standard simply
recognizes the usefulness of allowing the already existing and deployed
AIA extension logic, not only in certificates, but also in CRLs. It is
not authoritative with regard to where and when this solution should or
should not be deployed.

The profile recognizes that there are other ways to build CRL paths.
This should be enough.






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FHD2eY074042; Tue, 15 Feb 2005 09:13:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FHD2Jm074041; Tue, 15 Feb 2005 09:13:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FHD1C2074033 for <[e-mail]>; Tue, 15 Feb 2005 09:13:01 -0800 (PST) (envelope-from [e-mail])
Received: from MMyersLapTop (dslstat-ppp-47.fastq.com [65.39.92.47]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id j1FHCvc60529; Tue, 15 Feb 2005 10:12:57 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Tim Polk" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: SCVP Draft 17: Summary of changes
Date: Tue, 15 Feb 2005 10:09:57 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

I have read through your summary and the -17 draft and have no issues.
Many thanks to you, Trevor and others for staying on task.

Mike




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FGj0WJ071117; Tue, 15 Feb 2005 08:45:00 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FGj08o071116; Tue, 15 Feb 2005 08:45:00 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FGix3h071100 for <[e-mail]>; Tue, 15 Feb 2005 08:44:59 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA28862; Tue, 15 Feb 2005 17:58:24 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021517444573:392 ; Tue, 15 Feb 2005 17:44:45 +0100 
Message-ID: <[e-mail]>
Date: Tue, 15 Feb 2005 17:45:17 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP 16 comments 1-16
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 17:44:45, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 17:44:47, Serialize complete at 15/02/2005 17:44:47
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

> Please reread my message.  I said *you* suggested reducing the set from 
> three to two, but we retained all three.  

OK.

> The rationalization is clearly stated in the message.

1) Would you explain the difference between:

  - Build a certification path to a trust anchor
    (i.e. id-stc-build-pkc-path)

   and

  - Build a validated certification path to a trust anchor
    (id-stc-build-valid-pkc-path) ?

2) I would then presume that a conforming SCVP server implementations
    MUST support the id-stc-build-status-checked-pkc-path check
    instead of the id-stc-build-pkc-path check
    (but the answer to the first question might possibly solve this one).

Denis

 >>>>        to a trust anchor (revocation checking not required);

id-stc-build-pkc-path: Build a certification path to a trust
 >>>>        anchor;
 >>>>
 >>>>     - id-stc-build-valid-pkc-path: Build a validated certification path
 >>>>        to a trust anchor (revocation checking not required);


> 
> At 04:53 PM 2/15/2005 +0100, you wrote:
> 
>> Tim,
>>
>>> Denis,
>>
>>
>>> Comment 4 was addressed in the new draft.  Your comment that 
>>> "revocation checking without building a validated path does not make 
>>> sense" was accepted, and the client now asserts a single check to 
>>> request a validated path with revocation checking, as in your proposal.
>>
>>
>>> Our resolution was slightly different from your proposal.  You 
>>> proposed to resolve this issue by reducing the set of checks from 
>>> three to two.
>>> We retained three different checks because we wanted to allow for the 
>>> case where a path is built and validated without considering status 
>>> information.  This is explicitly permitted in both RFC 2459 and 3280, 
>>> and should be covered by SCVP as well.
>>
>>
>>> Our text follows:
>>
>>
>>> Excerpt form draft -17, section 3.2.2 Checks
>>
>>
>>
>>>>    For public key certificates, the following checks are defined:
>>>>
>>>>     - id-stc-build-pkc-path: Build a certification path to a trust
>>>>        anchor;
>>>>
>>>>     - id-stc-build-valid-pkc-path: Build a validated certification path
>>>>        to a trust anchor (revocation checking not required);
>>>>
>>>>     - id-stc-build-status-checked-pkc-path: Build a validated
>>>>        certification path to a trust anchor and perform revocation
>>>>        status checks on the certification path.
>>>
>>
>> Humm !! humm !!
>>
>> You say above "reducing the set of checks from three to two.".
>>
>> If I count correctly I see three choices above.
>>
>> Would you explain ?
>>
>> Denis
>>
>>>>    Conforming SCVP server implementations MUST support the 
>>>> id-stc-build-
>>>>    pkc-path check.  Conforming SCVP server implementations that support
>>>>    delegated path validation (DPV) as defined in [RQMTS] MUST support
>>>>    the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-
>>>>    path checks.
>>>
>>> Your thoughts?
>>> Tim
>>
>>
>>
>>
>>
>>
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FGfBZS070849; Tue, 15 Feb 2005 08:41:11 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FGfB8e070848; Tue, 15 Feb 2005 08:41:11 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FGf955070838 for <[e-mail]>; Tue, 15 Feb 2005 08:41:10 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j1FGegn01191; Tue, 15 Feb 2005 17:40:42 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 15 Feb 2005 17:40:42 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j1FGefW15618; Tue, 15 Feb 2005 17:40:41 +0100 (MET)
Date: Tue, 15 Feb 2005 17:40:41 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: SCVP Draft 17: Summary of changes
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here some comments to the new draft. 


1 - on page 12: 

   "The list of certificate references in the query item"

 replace this by

   "The list of certificate references in the queriedCerts item"

 It might be usefule to consider to add quotes to enhance some
 readability `queriedCerts'  in particular whether the syntax elements
 could be confused. 

2 - 

I vaguely remember that concerning comment C there was my suggestion 
to use tagging that is an explicit version of what would happen with 
AUTOMATIC tagging, unless I'm wrong this would give something like

     CertReferences ::= CHOICE { 
       pkcRefs           SEQUENCE SIZE (1..MAX) OF PKCReference, 
       acRefs            [0] SEQUENCE SIZE (1..MAX) OF ACReference } 
    
     PKCReference ::= CHOICE { 
       cert              Certificate, 
       pkcRef            [0] ESSCertID } 
    
     ACReference ::= CHOICE { 
       attrCert          AttributeCertificate, 
       acRef             [0] ESSCertID } 

see also point 14.

3 -

         "The checks item MUST contain a sequence of object identifiers
   (OIDs)."  

This sentence seems superflous to me, since the syntax already says that.        


4 - The usage of anyKeyUsage in the keyUsages is not explicitely defined.
   (It can be guessed to a certain degree..)

   in other words, the requiredKeyUsages is defined, but not the anyKeyUsage

   What is the difference of having a NULL option and not having coded
   the optional field?

   Note that if the requiredKeyUsages is used, non existance of the 
   key usage in a cert extension is a match. 

5- 3.2.4.9  

   "If the client wishes to confirm 
   the extended key usage, then it can communicate the usage it wants to
   validate by the same extension using the same semantics as defined in
   [PKIX-1]."
   
   
   shouldn't 

      SEQUENCE SIZE (1..MAX) OF KeyPurposeId

   then be replaced by 

      ExtKeyUsageSyntax

   otherwise "same extension" is not well defined. (and even then)
   
6-

  suggestion to replace: 

   "Therefore if the client obtained the certificate in the 
   context of a TLS server," 

   "E.g., if the client obtained the certificate in the 
   context of a TLS server," 

7 -

   "When using the default validation policy, the client can override any
   of the default parameter values by supplying a specific value in the
   request.  The SCVP server MUST make use of the provided parameter 
   values or return an error response."

   How are default values specified?  

8 - 3.2. 4     

   "A validation policy MUST define default values for all parameters 
   necessary for processing an SCVP request.  For each parameter, a 
   validation policy may either allow the client to specify a non-
   default value or forbid the use of a non-default value."

  - How are default values specified?  if there is a MUST, then
    why are all of them OPTIONAL?

  - How is 'forbid the use of a non-default value' indicated in the
    policy, and how, in this case the policy contains a the fixed
    non-default value? 
  
  
9 - 3.5  requestorName 
       
   "The optional requestorName item is used by the client to include an 
   identifier in the request.  The client MAY include this information 
   for the DPV server to copy into the response. 
    
   SCVP servers MUST be able to process requests that include this
   field."

   Please add:

   A server MAY require this to match with some authenticated identity
   depending on a server defined rule.   

10 - 4.8  

   "Alternatively, the SCVP server MAY omit this item."

   I don't think that this is not a alternative if the client has set a
   requestorName, if if my reading of 3.5  "to copy into the response"
   mean that the server MUST copy.

   Mildly speaking, after total silence since my last remark concerning
   these fields, I was not sure whether anything at all was accepted
   by the authors, or not, anyway, the tendancy has continued to 
   partially respond, and not say anything to concrete proposal, which
   is simply to have a requesterName in both requests and responses
   as a GeneralNames (note the s), so taht a relay can add an id etc. 

11 -

   "In the case of non-cached responses to signed requests, the SCVP 
   server SHOULD return a requestor name."

   For what reason a SHOULD? What is the reason for returning anything
   for a "signed" requst if the client doesn't need this? And, why
   'signed' and not protected?  

12 - 7:
       "SCVP 
   servers that support relay SHOULD populate this item with the DNS 
   name of the server or the distinguished name in the server's 
   certificate.  SCVP servers MAY choose other procedures for generating
   identifiers that are unique within their community." 

   I don't think the SHOULD is appropriate. DNS or distingushed name may 
   not exist, and there is no indication who an octet string can be populated.
   
13 - 7:

   It is quite nice to have loop detection for relaying,

   but nothing is said how a relay constructs a request from 
   a received on, and how a response is created from the 
   received response.
  
   (E.g. what to do with requesterName in the request? )

   The SCVP still does not contain a means to include the respons 
   of another SCVP server in a response. 
 

14 - Since it seems that it has been agreed somehow that a id cannot
   necessarily be derived from a security envelope, or, at least for
   symmetric reason, a response should have an value identifying
   the responder.

   Ah well, the previous responder item whihc had context 4 had been
   silently dropped (instead of being replaced by a generalnames.)
  

     CVResponse ::= SEQUENCE { 
       cvResponseVersion         INTEGER, 
       policyID                  INTEGER, 
       producedAt                GeneralizedTime, 
       responseStatus            ResponseStatus, 
       respValidationPolicy  [0] RespValidationPolicy OPTIONAL, 
       requestRef            [1] RequestReference OPTIONAL, 
       requestorRef          [2] SEQUENCE SIZE (1..MAX) OF OCTET  
                                   STRING OPTIONAL, 
       requestorName         [3] GeneralNames OPTIONAL, 
           replyObjects          [5] ReplyObjects OPTIONAL, 
       respNonce             [6] OCTET STRING OPTIONAL, 
       serverContextInfo     [7] OCTET STRING OPTIONAL, 
       cvResponseExtensions  [8] Extensions OPTIONAL } 

   please "align" the syntax. 

15 - ReplyWantBack

   I have never any explication why the

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

   is an encapsulating octet string. Since the client
   makes a particular wantback, one could assume that
   it knows the syntax? 
   
     ReplyWantBack::= SEQUENCE { 
       wb                         OBJECT IDENTIFIER, 
       value                      ANY DEFINED BY wb } 

   seems better to me. 

17 - 9

   I think all staements of what a client or server MUST do with
   certain field should go to the section defining the protocol
   element. 

   example the first statement in

   "Clients MUST check the requestRef item in the response and ensure 
   that it matches their original request.  Requests contain a lot of 
   information that affects the response and clients need to ensure that
   the server response corresponds to the request."

18 - 9

   "Therefore in these situations use 
            of a URI many be more attractive."

   Is there a comma missing behind the first word? if so, there are other places, too.

19 - 9
   
   "... ensure that the response cannot be a replay
   of a cached response obtained by another client."

   Are you sure? replay of cached responses are a feature
   of a server. A client may well accept a response that
   has no client identifiers etc IF the response is
   timely etc.

20 - 9

   The last paragraph in 9 seems to me to belong elsewhere. 

   And, in fact, nothing has been said anywhere that setting
   a validationTime has something to do with history.
 
   It can simply mean that the client has the best idea of what
   is 'NOW', and gives that time. (Although I would imagine that
   a server probably knows better). 

   The definition of validationTime does not say what a client can
   set into ythat field. 

21 - 9 

   "A certificate may
   have been revoked after the time specified in validationTime, but an 
   invalidity date that precedes the validationTime."
  
   I cannot parse that sequence of words. 


22 - B.1

    "The body of the message is the binary value of the DER encoding 
       of the CVRequest"

   what is the reason for the "DER" here. If no wrapping occurs, then ...
   and also the resulting CMS is not necessarily DER. 

23 - Paul Hoffman used to be one of the authors. Even when nothing of what
   was written by Paul has remained, the contributions section could
   still name him, unless ... 

   "The lively debate"  may you consider to replace it by 'the lively or almost deadly debate' 

Peter

 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FGM4MS069419; Tue, 15 Feb 2005 08:22:04 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FGM4UE069418; Tue, 15 Feb 2005 08:22:04 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FGM3OQ069408 for <[e-mail]>; Tue, 15 Feb 2005 08:22:04 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1FGLbDT027010; Tue, 15 Feb 2005 11:21:38 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1FGKmEY021969; Tue, 15 Feb 2005 11:20:48 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 15 Feb 2005 11:21:49 -0500
To: Denis Pinkas <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: SCVP 16 comments 1-16
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Please reread my message.  I said *you* suggested reducing the set from 
three to two, but we retained all three.  The rationalization is clearly 
stated in the message.

At 04:53 PM 2/15/2005 +0100, you wrote:
>Tim,
>
>>Denis,
>
>>Comment 4 was addressed in the new draft.  Your comment that "revocation 
>>checking without building a validated path does not make sense" was 
>>accepted, and the client now asserts a single check to request a 
>>validated path with revocation checking, as in your proposal.
>
>>Our resolution was slightly different from your proposal.  You proposed 
>>to resolve this issue by reducing the set of checks from three to two.
>>We retained three different checks because we wanted to allow for the 
>>case where a path is built and validated without considering status 
>>information.  This is explicitly permitted in both RFC 2459 and 3280, and 
>>should be covered by SCVP as well.
>
>>Our text follows:
>
>>Excerpt form draft -17, section 3.2.2 Checks
>
>
>>>    For public key certificates, the following checks are defined:
>>>
>>>     - id-stc-build-pkc-path: Build a certification path to a trust
>>>        anchor;
>>>
>>>     - id-stc-build-valid-pkc-path: Build a validated certification path
>>>        to a trust anchor (revocation checking not required);
>>>
>>>     - id-stc-build-status-checked-pkc-path: Build a validated
>>>        certification path to a trust anchor and perform revocation
>>>        status checks on the certification path.
>
>Humm !! humm !!
>
>You say above "reducing the set of checks from three to two.".
>
>If I count correctly I see three choices above.
>
>Would you explain ?
>
>Denis
>
>>>    Conforming SCVP server implementations MUST support the id-stc-build-
>>>    pkc-path check.  Conforming SCVP server implementations that support
>>>    delegated path validation (DPV) as defined in [RQMTS] MUST support
>>>    the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-
>>>    path checks.
>>Your thoughts?
>>Tim
>
>
>
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FGEVSP068808; Tue, 15 Feb 2005 08:14:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FGEVfk068807; Tue, 15 Feb 2005 08:14:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FGEUlq068800 for <[e-mail]>; Tue, 15 Feb 2005 08:14:30 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1FGDbDB024989; Tue, 15 Feb 2005 11:13:37 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1FGD2EY018630; Tue, 15 Feb 2005 11:13:02 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 15 Feb 2005 11:14:04 -0500
To: Denis Pinkas <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: SCVP 16 comments 17-45
Cc: pkix <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

The editors' resolution of the outstanding comments from your 17-45 are 
inserted in line below.

Thanks,

Tim

 >
 >Trevor,
 >
 >Here are my responses on 17-45. There are still many major points on 
which we do not
 >agree.  The MAJOR one has still to do with the deletion of the validation 
ALGORITHM
 >so that all validation POLICY dependent parameters can be placed under 
the validation
 >policy reference.
 >
 >>> 17. On top of page 7, the relationship between the validation policy 
and the basic
 >>> certification path algorithm is not explained.  Then in section 1.4 
The concept of
 >>> validation algorithm is introduced but its relationship with the 
validation policy is not
 >>> explained. This is confusing.
 >
We have done a lot to elaborate on the difference!

 >>>
 >>> Later on when observing the ASN.1 syntax it may be discovered that two 
OIDs are
 >>> being used:
 >>>         - one for the validation policy (ValidationPolRef) and
 >>>         - one for the validation algorithm (ValidationAlg).
 >>>
 >>> This is overcomplicated and unnecessary.
 >>
 >> [TF] Is there a specific issue with the current draft such as a 
scenario which is not
 >> addressed ?
 >
 >I do not believe that raising this question is a good way to solve my 
concern.  The "S"
 >from SCVP was supposed to mean "Simple".  The current description is the 
description
 >of CCVP "Complex Certificate Validation Protocol".  Now, since you asked, 
CCVP is
 >unable to support the validation algorithm described in section 6.2 of 
RFC 3280 (with
 >many trustpoints, each one with its set of parameters).  Adding more 
complexity to solve
 >it would not be the right answer.
 >

We agree that such scenarios are out of scope for SCVP!  Adding such 
complexity would
be a mistake.

 >>> A major simplification is obtained if there is an OID to define the 
validation policy
 >>> while there may be or not be additional parameters.
 >>>
 >>> We should then have:
 >>>
 >>>   valPolByOID::= SEQUENCE {
 >>>     valPolId      OBJECT IDENTIFIER,
 >>>     parameters    ANY DEFINED BY ValPolId OPTIONAL }
 >
 >>>
 >>> Specifying a path processing compliant with section 6.1 of RFC 3280 
would not be
 >>> possible in the general case, since the current text from RFC 3280 is too
 >>> vague/ambiguous to support the case where a CRL is not signed by the CA.
 >>>
 >>> It would be desirable to be able to communicate easily and in a 
standard way the
 >>> parameters that may be set in section 6.1 from RFC 3280.  In addition, 
key usage
 >>> should be added to that list.
 >>>
 >>> The document should then define a bundle of all these previous useful 
parameters and
 >>> allow for the addition of other parameters.
 >>>
 >>> It is thus proposed to define an OID for a validation policy compliant 
with section 6.1
 >>> of RFC 3280 (some differences with section 6 from 3280bis, i.e. adding 
precision, may
 >>> be expected). It is thus proposed to modify the text starting from:
 >>>
 >>>         "The inputs to the basic certification path processing 
algorithm used by SCVP are
 >>>         defined by [PKIX-1] in section 6.1.1 and comprise"
 >>>
 >>> up to the end of section 1.3 with the following:
 >>>
 >>>    "For clients able to specify the parameters of a validation policy, 
it may be useful to
 >>>    define a standard data structure (using a bundle) able to support 
the parameters of the
 >>>    basic certification path processing algorithm defined by in section 
6.1.1 from
 >>>    [PKIX-1]:
 >>>           - a set of Trust Anchors (by value or by reference),
 >>>           - the initial Certificate Policy set,
 >>>           - initial Certificate Policy mapping setting,
 >>>           - initial any-Policy setting,
 >>>           - initial explicit Certificate Policy setting.
 >>>    as well as :
 >>>           - the usage of the key contained in the certificate (e.g., 
key encipherment, key
 >>>             agreement, signature)
 >>>
 >>>    This will be done using a bundle which encapsulates all these 
parameters. Other
 >>>    application-specific purposes parameters may be added".
 >>>
 >>> 18. Section 1.4 is about a "Validation Algorithm".  Given what was 
said before, the
 >>> header of this section should be changed.  If we make a subsection 
1.3.1 called "1.3.1.
 >>> General" for encapsulating the previous text, then we can introduce a 
new section 1.3.2
 >>> called: "1.3.2. Validation policy according to section 6.1 of RFC 3280"
 >>
 >> [TF] See comment to 17
 >
 >See my response above.
 >

First, it is entirely appropriate for SCVP to focus exclusively on 3280 
path validation.
This is a PKIX spec, and 3280 defines the PKIX path validation algorithm.

Secondly, the proposed ASN.1 requires a great deal more complexity in SCVP 
client
implementations.  The client will need to process the validation policy 
definition to
identify parameters that can be modified and determine their structure.  In 
theory, every
validation policy could have its own policy syntax and that would require a 
lot more
coding in the client.

So, we believe the current ASN.1 should be retained.

 >
 >>> Some of the text present in the current section 1.4 has been used to 
build the new text
 >>> that is proposed below:
 >>>
 >>> "1.3.2. Validation policy according to section 6.1 of RFC 3280 SCVP 
defines a specific
 >>> validation policy which implements the certification path validation 
algorithm as
 >>> defined in section 6.1 of [PKIX-1].  This specific validation policy, 
called "rfc-3280
 >>> basic validation policy" uses the parameters defined in the bundle 
mentioned above.
 >>>
 >>> Note that this algorithm does not support in its full generality the 
algorithm described in
 >>> section 6.2 of [PKIX-1] since, when more than one trust anchor is 
being defined, all the
 >>> conditions that are specified apply to all trust anchors, whereas 
section 6.2 allows to
 >>> have different conditions for every trust anchor.
 >>>
 >>> The rfc-3280 basic validation policy may be the default validation 
policy supported by
 >>> the server, but does not need to".
 >>>
 >

The algorithm defined in 6.1 of 3280 always begins with a single  trust 
anchor.  Section 6.2, "Using the Path Validation Algorithm", states "the 
path validation algorithm presented in section 6.1 defines the minimum 
conditions for a path to be considered valid."  This algorithm could be 
extended to support multiple trust anchors or refined to require an 
alternative name form, but the path itself would still satisfy 6.1.

Specification of multiple trust anchors, even with different initialization 
parameters, could be supported through pre-established validation 
policies.  I suspect this meets 99% of all real world use cases.  It has 
the added virtue that it does not add any complexity at the client.

 >>> 19. Section 2 "Protocol Overview"
 >>> In order to allow for interoperability and testing a common protocol 
needs to be
 >>> supported. It should be defined.
 >>
 >> [TF] There is plenty of precedence for this to be in a separate 
document. CMS itself just
 >> defines the syntax.
 >
 >Would you be more explicit ?
 >

Like most of the PKIX protocols, SCVP does not mandate a particular 
transport.  HTTP is highlighted in the appendices as the most common 
transport.  If the details for HTTP are insufficient for interoperable 
implementations, this should be corrected.

 >>> 20. Section 3 "Validation Request"
 >>> The unsigned request form is not explained and there is a confusion 
for the signed
 >>> request which indeed authenticates the client and is thus not 
anonymous. The current
 >>> text is :
 >>>
 >>> "A signed request is used to authenticate the client to the server or 
to provide an
 >>> anonymous client integrity over the request-response pair."
 >>>
 >>> It should be rephrased as:
 >>>
 >>> "An unsigned request provides an anonymous client integrity over the 
request since the
 >>> hash of the request or the full request is incorporated in the 
response. A signed request
 >>> is used to authenticate the client to the server".
 >>
 >> [TF] Since by definition the anonymous client has to sign the request 
as well this does
 >> not make sense. A server can also return a cached response in which 
case there is no
 >> hash of the request in the response. How about : An anonymous client 
signs the request
 >> to provide integrity over the request. A identifiable signs the request 
to authenticate itself
 >> to the server.
 >

If the response is a live response (not cached) then including the hash of 
the request in the response is fine and the request does not need to be 
signed.  If the response is a cached response, then the cached response 
must include "sufficient" information to make sure for the client that it 
is not a replay from a too old response.  The only way is to copy all the 
parameters of the original request.  In either case, signing the request 
does not help.

The phrase signed in SCVP indicates an electronic signature.  Both a 
digital signature and an HMAC are supported.  The digital signature 
authenticates the client to the server.  The HMAC "signature" can provide 
anonymous client integrity.  This has been clarified in the new draft.

 >>> 21. Page 13. Section 3.1.2 "checks"
 >>>
 >>> The following sentence adds nothing and should be removed:
 >>>
 >>>    "A server may still choose to perform revocation status checks when 
performing path
 >>>    construction, although this information cannot be returned to the 
client."
 >
 >> [TF] I think it reinforces that with some checks, don't require 
revocation status checking
 >> but a server may still elect to do so.
 >
 >I disagree.  A server SHALL do what the client asks, no more no 
less.  Please, delete the
 > sentence.
 >

So a server should return an affirmative response with a path including 
certificates it knows to be revoked?  That places the server in an 
untenable position.

 >
 >>> 22. Page 15. Section 3.1.3 "wantBack"
 >>>
 >>> The text states:
 >>>     - Proof of revocation status for each certificate in the AC issuer 
certification path;
 >>>
 >>> It would be important to refer the section of the RFC which explains 
how to check the
 >>> "revocation status for each certificate in the AC issuer certification 
path".
 >>
 >> [TF] OK, I will add a reference to 3281 section 5.
 >
 >RFC 3281 is "An Internet Attribute Certificate Profile for 
Authorization".  I do not
 >believe that it is the correct reference.  The basic problem is that 
there exists no RFC
 >that explains how to check the "revocation status for each certificate in 
the AC issuer
 >certification path". So leaving details to the validation policy is the 
only solution.
 >

An AC issuer certification is a 3280-compliant certification path where the 
end certificate contains the key used to issue the attribute 
certificate.  Where is the ambiguity?

 >
 >>> 23. Page 15. Section 3.1.3 "wantBack"
 >>>
 >>> The text states:
 >>>
 >>>    The client can also request a non-cached response to the request by 
including
 >>>    wantback id-swb-non-cached-resp in the request. The default 
behavior should be the
 >>>    reverse: fresh information is provided, unless the client accept 
cached information.
 >>>    The item should be changed into: id-swb-cached-resp
 >>
 >> [TF] This has been moved to response flags and the default is non-cached.
 >
 >Fine, finally one point on which we agree.
 >
 >>> 24. Page 15. Section 3.1.3 "wantBack"
 >>>
 >>> The text states:
 >>>
 >>>    id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}
 >>>
 >>> It should be mentioned that this item is only possible for DPD.
 >>
 >> [TF] Why is this only possible with DPD?
 >
 >Because DPV returns only the fist valid path (i.e. a single path)
 >

A DPV server might sensibly be designed to return the first valid path it 
encountered, but that isn't the only solution.  It is certainly possible 
for multiple valid paths to exist, and be known to a server.  In such a 
case, the server could certainly return multiple paths.  I checked 3379, 
and did not see any contradiction.

 >
 >>> 25. Page 16. Section 3.1.4 validationPolicy
 >>>
 >>> The following sentence is talking of an agreement whereas such 
agreement does not
 >>> exist. Delete the sentence:
 >>>
 >>>    "The client and server can optionally agree on a set of parameters 
which may fully or
 >>>    partially define a validation policy".
 >>
 >> [TF] OK
 >>
 >>> 26. Page 16. Section 3.1.4 validationPolicy
 >>>
 >>> The text states:
 >>>
 >>>     "If a partial set of parameters has been agreed upon, then the 
client supplies a
 >>>     reference to the policy plus whatever parameters are necessary to 
complete the
 >>>     request in this item.
 >>>
 >>> This should be replaced with:
 >>>
 >>>     "If the validation policy does not define all parameters necessary 
for processing an
 >>>     SCVP request, then the client need to supply these parameters".
 >>
 >> [TF] Thats is not true. The client can omit whatever parameters match 
the server default
 >> value.
 >
 >This would mean that the default validation policy always have a full set 
of parameters.
 >In that case the quoted sentence is still incorrect since it states "a 
partial set of
 >parameters".  That sentence still needs to be corrected.  What about "The 
client supplies
 >a reference to the policy plus whatever parameters which are allowed to 
change the
 >default parameters".
 >


New text: "A validation policy MUST define default values for all 
parameters necessary for processing an SCVP request."


 >>> 27. Page 16. Section 3.1.4 validationPolicy
 >>>
 >>> The syntax of the validationPolicy item is defined as:
 >>>
 >>>     ValidationPolicy ::= SEQUENCE {
 >>>       validationPolRef          ValidationPolRef,
 >>>       validationAlg         [0] ValidationAlg OPTIONAL,
 >>>       userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
 >>>                                   IDENTIFIER OPTIONAL,
 >>>       inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
 >>>       requireExplicitPolicy [3] BOOLEAN OPTIONAL,
 >>>       inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
 >>>       isCA                  [5] BOOLEAN OPTIONAL,
 >>>       trustAnchors          [6] TrustAnchors OPTIONAL,
 >>>       keyUsages             [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
 >>>                                   OPTIONAL,
 >>>       extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}
 >>>
 >>> This structure is quite odd, because it only allows to pass additional 
parameters as
 >>> parameters of the validationAlg. Suppressing the validationAlg item 
add adding
 >>> validationParamExtensions would be a simpler and cleaner way.
 >>
 >> [TF] The only way to include other parameters is because the algorithm 
needs them.
 >> You cannot introduce new parameters without at the same time defining 
there use.
 >> Therefore mandating additional parameters be passed which the corresponding
 >> identifier for their is the right thing to do.
 >
 >I disagree.  I could say: the only way to include other parameters is to 
place them as
 >parameters of the validation policy because the validation policy needs 
them.  Your
 >response is placed too early and does not consider the proposal made just 
after.  See the
 >proposal hereafter and please reconsider your position.  This is one of 
the major issues.
 >

We believe the new draft clarifies the difference between validation 
policies and algorithms.  Given this clarification, we believe the current 
ASN.1 structure provides appropriate mechanisms to specify any required 
parameters.

 >
 >>> Each validation policies uses its own parameters. We should have 
something like :
 >
 >>>   ValPolByOID  ::= SEQUENCE {
 >>>     valPolgId        OBJECT IDENTIFIER,
 >>>     parameters       ANY DEFINED BY valPolId OPTIONAL }
 >>>
 >>> More details follow.
 >>>
 >>> 28. It is highly debatable if URIs should be supported or not to 
reference a validation
 >>> policy.  URIs are not stable over time and thus unless there are 
dereferenced and a hash
 >>> value is computed over them, it is insecure to use them.  There is a 
discussion in the
 >>> security consideration section, but no warning and no pointer 
here.  If we keep them, we
 >>> should warn the user.
 >>
 >> [TF] The argument over the stability of URIs is discussed in the 
security section - which
 >> is the appropriate place. The reality is in many organizations are 
stable enough and
 >> much more manageable. The issue over dereferencing and hashing is 
bogus. Both OID
 >> and URI are both opaque stings for this purpose and rely on you 
trusting the
 >> management doing the right thing.
 >
 >Anyway a reference to the security consideration section is missing.  If 
you believe that a
 >URI is opaque, it should be said, because dereferencing is very often 
announced by some
 >people as being an advantage.  You can place that information in the security
 >considerations section if you wish and then let the IESG decide.
 >

The security considerations section includes the following text.  We 
believe this addresses the concern.

    The only validation policy references that are truly persistent are
    OIDs.  If the ownership of the policy could in any way be an issue,
    then OIDs should be the reference type of choice.  However in many
    situations, even though URIs are technically non-persistent, the use
    of a URI is much more readily understood because of its widespread
    use elsewhere, and with many organizations they may be viewed as
    persistent for practical purposes. Therefore in these situations use
    of a URI many be more attractive.


 >>> If the WG should decides that they should be supported (and if the 
IESG agrees) on
 >>> page 17, the ASN.1 description should then be:
 >>>
 >>>     ValidationPolicy ::= CHOICE {
 >>>       valPolByOID     [0] ValPolByOID,
 >>>       valPolByURI     [1] ValPolByURI }
 >>>
 >>>     ValPolByOID  ::= SEQUENCE {
 >>>       valPolgId           OBJECT IDENTIFIER,
 >>>       parameters          ANY DEFINED BY valPolId OPTIONAL }
 >>>
 >>>     ValPolByURI ::= SEQUENCE {
 >>>       uri                 IA5String,
 >>>       hashAlgo            OBJECT IDENTIFIER,
 >>>       hashValue           OCTET STRING}
 >>>
 >

First, this would preclude the client from supplying parameters to any 
validation policy supplied by reference to a URI.  There is no reason for 
this distinction.

Second, both the OID and the URI simply represent a name for the validation 
policy.  The client is already trusting the server to perform path 
validation on its behalf.  If the client does not trust the server to 
validate against the appropriate policy, it should require specification of 
the policy by value in the response.  This is required whether an OID or 
URI is used to specify the policy!

 >>> 29. It is proposed to define the following bundle:
 >
 >>>     ValidationParamBundle ::= SEQUENCE {
 >>>       certificatePolicySet    [0] SEQUENCE SIZE (1..MAX) OF
 >>>                                     OBJECT IDENTIFIER OPTIONAL,
 >>>       inhibitPolicyMapping    [1] BOOLEAN OPTIONAL,
 >>>       requireExplicitPolicy   [2] BOOLEAN OPTIONAL,
 >>>       inhibitAnyPolicy        [3] BOOLEAN OPTIONAL,
 >>>       isCA                    [4] BOOLEAN OPTIONAL,
 >>>       trustAnchors            [5] TrustAnchors OPTIONAL,
 >>>       keyUsages               [6] SEQUENCE SIZE (1..MAX) OF
 >>>                                     KeyUsage OPTIONAL,
 >>>       extendedKeyUsages       [7] ExtKeyUsageSyntax OPTIONAL,
 >>>       extensions              [8] EXPLICIT Extensions OPTIONAL }
 >>>
 >>> Note that userPolicySet" is unclear and has been changed into 
"certificatePolicySet".
 >>
 >> [TF] The use of userPolicySet aligns with 3280.  I don't think the name 
to the existing
 >> structure is ambiguous or misleading.
 >
 >Your response arguments about the note but omits to respond to the main 
argument of
 >this comment.  So I consider that a response to this comment is still 
awaited.  BTW,
 >userPolicySet is not a term used in RFC 3280, so you can't say it aligns 
with RFC 3280.
 >
 >>> The text would need to be aligned with the new structure and, of 
course the parameters
 >>> of the rfc-3280 basic validation policy will simply include the bundle 
above as its
 >>> parameters. It should also be mentioned somewhere in the document that 
the support of
 >>> the rfc-3280 basic validation policy is not mandatory for conformance 
but, if supported
 >>> then the bundle needs to be supported.
 >>>
 >

As noted above, using "ANY DEFINED BY" to specify parameters has serious 
implications for complexity of clients.  Again, this is PKIX and support 
for the 3280 validation algorithm is mandatory.

 >
 >>> 30. Page 17. Section 3.1.5 validationAlg should be deleted.
 >>
 >> [TF] Already done
 >
 >Let us see what the next text will look like to know whether this comment 
is solved or
 >not. I fear it is not.
 >
 >>> 31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be 
deleted and
 >>> replaced by a section later on the "rfc-3280 basic validation policy", 
which should have
 >>> its OID defined under the scvp tree for OIDs.
 >>
 >> [TF] the basic validation algorithm references the 3280 section 6.
 >
 >What you call the basic validation algorithm is one of the many elements 
of the rfc-3280
 >basic validation policy.  It is buried within the validation policy and 
does not need to be
 >identified independently of the validation policy.  The default 
Validation Algorithm still
 >needs to be deleted.  This relates to comment 17.
 >
 >Hopefully, this has been resolved by the clarifications between 
validation policy and
 >algorithm.
 >
 >>> 32. Page 17. Section 3.1.5.1. Some text of this section might be 
re-used to build a new
 >>> section on the rfc-3280 basic validation policy. Note that the last 
sentence at the bottom
 >>> of page 17, should be removed. This sentence is: "The default 
validation policy MUST
 >>> use the basic validation algorithm". Any default validation policy can 
be used.
 >>
 >> [TF] See answer to 31
 >
 >See my response above.
 >

As specified, this states that the default policy uses the 3280 validation 
algorithm as specified in section 6.1 for identity certificates and as 
supplemented in 3281 for attribute certificates.  It is wholly appropriate 
for the PKIX DPD/DPV protocol default to the PKIX specs!

Note that servers are not forced to accept requests that specify this policy.

 >
 >>> 33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !) 
should be as well
 >>> deleted.
 >>
 >> [TF] The duplicate has been deleted
 >>
 >>> 34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm
 >>>
 >>> This goal of this section seems to introduce an additional test to the 
basic "rfc-3280
 >>> basic validation policy".  It would come naturally as an extension of
 >>> ValidationParamBundle, rather than as a parameter of the 
validationAlgo which has
 >>> been proposed to be removed.  The text should be modified accordingly.
 >>
 >> [TF] See answer 27.
 >
 >See my response: your response does not consider the proposal made in 
comment 27.
 >

There are always multiple ways to describe things.  The current structure 
is no worse than any other, so there is no reason to change.

 >
 >>> 35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm
 >>>
 >>>      NameValidationAlgParms ::= SEQUENCE {
 >>>        keyPurposeId        KeyPurposeId,
 >>>        validationNames     GeneralNames }
 >>>
 >>> This construct is artificial since KeyPurposeId is about the Extended 
Key Usage and
 >>> has nothing to do with name validation.
 >>
 >> [TF] Its simple reuses and existing practice.
 >
 >I do not understand the argument about "existing practice".
 >

Renamed keyPurposeId as name comparison algorithm, which more accurately 
describes its function.

 >
 >>> It could indeed be interesting to test the Extended Key Usage 
extension of a certificate,
 >>> but this should be supported as an extension of ValidationParamBundle. 
The text
 >>> should be modified accordingly.
 >>>
 >

This feature is provided by the extendedKeyUsages field in the validation 
policy.

 >
 >>>
 >>> 36. Page 22. Section 3.1.5.3 userPolicySet
 >>>
 >>> userPolicySet should be changed everywhere into certificatePolicySet.
 >>
 >> [TF] userPolicySet aligns with 3280 section 6.
 >
 >userPolicySet is not a term used in RFC 3280, so you cant't say it aligns 
with RFC 3280
 >section 6.  You are probably reading a different document.
 >

The userPolicySet is used to specify the user-initial-policy-set.  The 
"initial" is implied in the context, as with all the other variables.  That 
is, the inhibitAnyPolicy field is used to specify the 
initial-any-policy-inhibit state variable in 6.1, etc., etc.

Adding initial to all the names would be tedious and verbose.

 >
 >>> 37. Page 22. Section 3.1.5.3 userPolicySet
 >>>
 >>> The text has many sentences like:
 >>>     SCVP clients SHOULD support userPolicySet item in requests, and 
SCVP servers
 >>>     MUST support userPolicySet item in requests.
 >>>
 >>> These requirements only apply for the rfc-3280 basic validation 
policy, and this should
 >>> be clearly mentioned.
 >>
 >> [TF] Since all validation polices contain userPolicySet, it can be in 
any policy.
 >
 >I disagree.  There may be some validation policies where no parameter at 
all can be
 >changed by the client.  I would expect that most clients will use OIDs 
for validation
 >policies with no parameter at all.  A client is not necessarily allowed 
to change any
 >parameter of a validation policy.  In some cases clients will be allowed 
to specify only
 >some parameters (but not all).
 >


We agree that a validation policy may not let you change this 
value.  Essentially, this text mandates that implementations of SCVP 
servers support policies that allow changing this value.  That does not 
mean a specific SCVP server can't be configured to reject requests that 
change this value.

 >
 >>> 38. Page 22. Section 3.1.5.4 inhibitPolicyMapping
 >>>
 >>> The text states:
 >>>
 >>>     By default the server allows policy mapping as part of 
certification path validation.
 >>>
 >>> For simplicity, this should be the reverse. Replace with:
 >>>
 >>>     "By default the server does not perform policy mapping as part of 
certification path
 >>>     validation. If the client wants the server to support policy mapping,
 >>>     allowPolicyMapping must be set to TRUE in the request".
 >>
 >> [TF] This conflicts with 3280 section 6.
 >
 >It does not.  Section 6 does not mandate policy mapping.  The default is 
simplicity: no
 >policy mapping.
 >

If a server (or any other implementation) recognizes an extension, it is 
required to process it.  This is a requirement in both X.509 and RFC 3280.


The behavior you described above is achieved when the validation policy 
inhibit policy mapping or the client asserts inhibitPolicyMapping in the 
request.  Note that the policy mapping extension is still processed if 
recognized, but the results are different..

 >>> 39. Page 24. Section 3.1.5.8 trustAnchors
 >>>
 >>> The text states:
 >>>
 >>>      "A certificate reference can be used to identify the trust anchor 
by certificate hash
 >>>      and optionally a distinguished name with serial number".
 >>>
 >>> This is not consistent with the ASN.1 definition of PKCReference which 
is:
 >>>
 >>>     PKCReference ::= CHOICE {
 >>>       cert         [0] Certificate,
 >>>       pkcRef       [1] ESSCertID }
 >>>
 >>> Please correct.
 >
 >A response is missing.
 >

The quoted text is describing the ESSCertID option.  When this option is 
used the certificate IS identified by a hash and optionally a distinguished 
name with serial number.  Section 3.1.5.8 also includes a sentence that 
indicates that the certificate itself can be included.

 >
 >>> 40. Page 25. Section 3.1.6 responseRefHash
 >>> The text states:
 >>>
 >>>     "By default, the server includes a hash of the request in the 
response. If the client
 >>>     wants the server to include the full request in the response, 
responseRefHash is set to
 >>>     FALSE."
 >>>
 >>> The server shall always include a hash of the request in the response.
 >>
 >> [TF] A server cannot include a hash of the request in a cached response.
 >
 >See my new response to comment 20. If the response is a live response 
(not cached) then
 >including the hash of the request in the response is fine. If the 
response is a cached
 >response, then the cached response must include "sufficient" information 
to make sure
 >for the client that it is not a replay from a too old response. The only 
way is to copy all
 >the parameters of the original request.
 >

If the server includes the entire request in the response, there is no 
reason to include a hash as well.  The "produced at" time should be 
sufficient to check the age of your response (assuming you trust your server!)

 >
 >>> This is an easy way to allow to test the integrity of the request. 
Since the full
 >>> description of the validation policy may be much longer a flag should 
be used to say
 >>> that the full validation policy is not returned unless requested.
 >>
 >> [TF] There is one, it is responseValidationPolByRef.  The response 
flags now has a
 >> FullRequestInResponse in place of the requestRefHash.
 >
 >Let us see what the full new proposal is. If you agree with my response 
to comment 20, maybe we are converging.
 >
 >>> It is thus proposed to have instead the following:
 >>>
 >>> "3.1.6.1 fullRequestInResponse
 >>>
 >>>   The fullRequestInResponse controls if the client wants the server to 
include the full
 >>>   request in the response. By default, fullRequestInResponse is set to 
FALSE. If the
 >>>   client wants back the full request then it must set this parameter 
to TRUE. The main
 >>>   reason a client would request the server to include the full request 
in the response is to
 >>>   archive the request-response exchange in a single object.  That is, 
the client wants to
 >>>   archive a single object which includes both request and response".
 >>>
 >>>
 >>> 41. Page 26. Section 3.1.6.2 responseValidationPolByRef
 >>>
 >>> This item should be renamed: fullValPolInResponse
 >>>
 >>> The text should be changed into:
 >>>
 >>>   "The fullValPolInResponse controls whether the response includes the 
identifier of the
 >>>   validation policy with all the parameters that have been used by the 
server, i.e. all the
 >>>   variable parameters independent from the fact that there were 
specified by the client or
 >>>   defaulted if not specified. By default, fullValPolInResponse is set 
to FALSE. If the
 >>>   client wants the full validation policy to be included, then 
fullValPolInResponse is set
 >>>   to TRUE. The main reason a client would request the server to 
include validation
 >>>   policy to be included by value is to archive the request-response 
exchange in a single
 >>>   object. That is, the client wants to archive the CVResponse and have 
it include every
 >>>   aspect of the validation policy."
 >>
 >> [TF] I have not changed the name, but the section now reads
 >>
 >>   The responseValidationPolByRef controls whether the response includes 
just a
 >>   reference to the policy or the reference to the policy plus all the 
parameters by value of
 >>   the policy used to process the request. the response MUST contain 
references to the
 >>   validation policy. If the client wants the validation policy 
parameters to be also
 >>   included by value, then the responseValidationPolByRef is set to 
FALSE. The main
 >>   reason a client would request the server to include validation policy 
to be included by
 >>   value is to archive the request-response exchange in a single object. 
That is, the client
 >>   wants to archive the CVResponse and have it include every aspect of 
the validation
 >>   policy.
 >
 >This new proposed text is still incorrect: "just a reference to the 
validation policy" does
 >not help, (unless the validation policy has no variable parameter).  We 
need to have a
 >mechanism for replay protection and/or for making sure that the response 
relates to the
 >right request: "just a reference to the validation policy" does not 
provide this property.
 >However, my proposal provides that property.  Please reconsider my text.
 >

Please review Section 4.5.1.  Even if responseValidationPolByRef is TRUE, 
the response includes any items for which the value in the request differs 
from the value from the referenced validation policy.

 >
 >>> The ResponseFlags should be changed as follows:
 >>>
 >>>    ResponseFlags ::= SEQUENCE {
 >>>      fullRequestInResponse    BOOLEAN DEFAULT FALSE,
 >>>      fullValPolInResponse     BOOLEAN DEFAULT FALSE,
 >>>      signResponse             BOOLEAN DEFAULT TRUE }
 >>>
 >>>
 >>> 42. Page 28. Section 3.1.9 intermediateCerts. Minor.
 >>>
 >>> Change:
 >>>
 >>>   The optional intermediateCerts item helps the SCVP server create 
valid certification >>   paths.
 >>>
 >>> into:
 >>>
 >>>   The optional intermediateCerts item may help the SCVP server to 
create valid
 >>>   certification paths.
 >>
 >> [TF] Fixed
 >>
 >>> 43. Page 29. Section 3.1.11. producedAt
 >>>
 >>> Last sentence. Change:
 >>>
 >>>     SCVP server SHOULD support the producedAt values in the request.
 >>>
 >>> into:
 >>>
 >>>     SCVP server MAY support the producedAt values in the request.
 >>>
 >>> Reason: cached responses should not need to be implemented in order to 
be compliant
 >>> with the specification.
 >>
 >> [TF] Fixed
 >>
 >>>
 >>> 44. Page 32. Section 3.5 dhPublicKey
 >>>
 >>> The text states:
 >>>
 >>>   "For the server to compute the shared secret, it must lean the 
public values the client
 >>>   generates, therefore the client MUST include this in the request if 
it uses this
 >>>   mechanism to integrity protect the request- response pair."
 >>>
 >>> Replace:
 >>>
 >>>    "to integrity protect the request-response pair"
 >>>
 >>> with :
 >>>
 >>>    "to authenticate and integrity protect the first response and 
authenticate and integrity
 >>>    protect subsequent request-response pairs".
 >>
 >> [TF] draft now read " integrity protect the request and the subsequent 
response." The
 >> use of DH does not necessarily authenticate the request.
 >>
 >>>
 >>> 45. Page 32. Section 3.6 SCVP Request Authentication
 >>>
 >>> The text states:
 >>>
 >>>    "It is a matter of local policy what validation policy is used by 
the server when
 >>>    validating requests".
 >>>
 >>> This sentence could be misinterpreted because the word "validating" is 
being used.
 >>> Change into:
 >>>
 >>>    It is a matter of local policy what validation policy is used by 
the server when
 >>>    authentication requests".
 >>
 >> [TF] Fixed
 >>
 >>> END OF COMMENTS
 >
 >Denis
 >
 >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFrQBM067257; Tue, 15 Feb 2005 07:53:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FFrQev067256; Tue, 15 Feb 2005 07:53:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFrMqE067239 for <[e-mail]>; Tue, 15 Feb 2005 07:53:24 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA32866; Tue, 15 Feb 2005 17:06:47 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021516530953:345 ; Tue, 15 Feb 2005 16:53:09 +0100 
Message-ID: <[e-mail]>
Date: Tue, 15 Feb 2005 16:53:41 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: SCVP 16 comments 1-16
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 16:53:09, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 16:53:10, Serialize complete at 15/02/2005 16:53:10
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

> Denis,

> Comment 4 was addressed in the new draft.  Your comment that "revocation 
> checking without building a validated path does not make sense" was 
> accepted, and the client now asserts a single check to request a 
> validated path with revocation checking, as in your proposal.

> Our resolution was slightly different from your proposal.  You proposed 
> to resolve this issue by reducing the set of checks from three to two.  
> We retained three different checks because we wanted to allow for the 
> case where a path is built and validated without considering status 
> information.  This is explicitly permitted in both RFC 2459 and 3280, 
> and should be covered by SCVP as well.

> Our text follows:

> Excerpt form draft -17, section 3.2.2 Checks


>>    For public key certificates, the following checks are defined:
>>
>>     - id-stc-build-pkc-path: Build a certification path to a trust
>>        anchor;
>>
>>     - id-stc-build-valid-pkc-path: Build a validated certification path
>>        to a trust anchor (revocation checking not required);
>>
>>     - id-stc-build-status-checked-pkc-path: Build a validated
>>        certification path to a trust anchor and perform revocation
>>        status checks on the certification path.

Humm !! humm !!

You say above "reducing the set of checks from three to two.".

If I count correctly I see three choices above.

Would you explain ?

Denis

>>    Conforming SCVP server implementations MUST support the id-stc-build-
>>    pkc-path check.  Conforming SCVP server implementations that support
>>    delegated path validation (DPV) as defined in [RQMTS] MUST support
>>    the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-
>>    path checks.
>>
> 
> Your thoughts?
> 
> Tim






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFgTLm066094; Tue, 15 Feb 2005 07:42:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FFgTM8066093; Tue, 15 Feb 2005 07:42:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFgSB2066087 for <[e-mail]>; Tue, 15 Feb 2005 07:42:28 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1FFfbaP028423; Tue, 15 Feb 2005 10:41:37 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1FFepEY012136; Tue, 15 Feb 2005 10:40:51 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 15 Feb 2005 10:41:52 -0500
To: Denis Pinkas <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: SCVP 16 comments 1-16
Cc: pkix <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Comment 4 was addressed in the new draft.  Your comment that "revocation 
checking without building a validated path does not make sense" was 
accepted, and the client now asserts a single check to request a validated 
path with revocation checking, as in your proposal.

Our resolution was slightly different from your proposal.  You proposed to 
resolve this issue by reducing the set of checks from three to two.  We 
retained three different checks because we wanted to allow for the case 
where a path is built and validated without considering status 
information.  This is explicitly permitted in both RFC 2459 and 3280, and 
should be covered by SCVP as well.

Our text follows:

Excerpt form draft -17, section 3.2.2 Checks
>
>    For public key certificates, the following checks are defined:
>
>     - id-stc-build-pkc-path: Build a certification path to a trust
>        anchor;
>
>     - id-stc-build-valid-pkc-path: Build a validated certification path
>        to a trust anchor (revocation checking not required);
>
>     - id-stc-build-status-checked-pkc-path: Build a validated
>        certification path to a trust anchor and perform revocation
>        status checks on the certification path.
>
>    Conforming SCVP server implementations MUST support the id-stc-build-
>    pkc-path check.  Conforming SCVP server implementations that support
>    delegated path validation (DPV) as defined in [RQMTS] MUST support
>    the id-stc-build-valid-pkc-path and id-stc-build-status-checked-pkc-
>    path checks.
>

Your thoughts?

Tim



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFaJDb065560; Tue, 15 Feb 2005 07:36:19 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FFaJ3d065559; Tue, 15 Feb 2005 07:36:19 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFaIXw065553 for <[e-mail]>; Tue, 15 Feb 2005 07:36:19 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15249; Tue, 15 Feb 2005 10:36:16 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-scvp-17.txt
Date: Tue, 15 Feb 2005 10:36:15 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Simple Certificate Validation Protocol (SCVP)
	Author(s)	: A. Malpani, et al.
	Filename	: draft-ietf-pkix-scvp-17.txt
	Pages		: 76
	Date		: 2005-2-14
	
SCVP allows a client to delegate certificate path construction and 
   certificate path validation to a server.  The path construction or 
   validation (e.g. making sure that none of the certificates in the 
   path are revoked) is performed according to a validation policy, 
   which contains one or more trust anchors.  It allows simplification 
   of client implementations and use of a set of predefined validation 
   policies.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-17.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-scvp-17.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-scvp-17.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-scvp-17.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-scvp-17.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFZu89065506; Tue, 15 Feb 2005 07:35:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FFZuBD065505; Tue, 15 Feb 2005 07:35:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFZt0G065498 for <[e-mail]>; Tue, 15 Feb 2005 07:35:55 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15028; Tue, 15 Feb 2005 10:35:52 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-2797-bis-02.txt
Date: Tue, 15 Feb 2005 10:35:52 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Certificate Management Messages over CMS
	Author(s)	: M. Myers, et al.
	Filename	: draft-ietf-pkix-2797-bis-02.txt
	Pages		: 0
	Date		: 2005-2-14
	
This document defines the base syntax for CMC, a Certificate 
   Management protocol using CMS (Cryptographic Message Syntax).  This 
   protocol addresses two immediate needs within the Internet PKI 
   community: 
    
   1. The need for an interface to public key certification products 
      and services based on CMS and PKCS #10 (Public Key Crytpography 
      Standard), and 
    
   2. The need in S/MIME (Secure MIME) for a certificate enrollment 
      protocol for DSA-signed certificates with Diffie-Hellman public 
      keys.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-2797-bis-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-2797-bis-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-2797-bis-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-2797-bis-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-2797-bis-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFM3Yn064169; Tue, 15 Feb 2005 07:22:03 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FFM38e064168; Tue, 15 Feb 2005 07:22:03 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft5.fr.colt.net (smtp-ft5.fr.colt.net [213.41.78.199]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFM1xi064123 for <[e-mail]>; Tue, 15 Feb 2005 07:22:02 -0800 (PST) (envelope-from [e-mail])
Received: from [10.0.0.51] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft5.fr.colt.net with ESMTP id j1FFLk516073 for <[e-mail]>; Tue, 15 Feb 2005 16:21:51 +0100
Message-ID: <[e-mail]>
Date: Tue, 15 Feb 2005 16:21:46 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; fr-FR; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en, fr, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Question about updating the CA to change its DN encoding
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Masaki SHIMAOKA wrote:

>I have one question about updating the CA to change its DN encoding.
>
>If the old CA and new CA have different keypairs, issue the self-issued
>certificates each other, and have same DN regardless of encoding, should
>both CA share the revocation information between their CRLs?
># I believe that such self-issued certificates are the one called a name
>rollover certificate in RFC 3280.
>
>The reason why I wonder is that revocation information is specified by
>issuer and serial number.  If an application assumes that DNs of such
>old CA and new CA is the same, the application may use to check the CRL
>issued by new CA for a certificate issued by old CA.  
>And if the answer is YES in the case using such applications, it means
>anyone can make the CRL substitution attack easily.
>
>So, I hope the answer is NO and all applications should use to check the
>CRL issued by the signing key of the corresponding certificate issuer.
>  
>
"name rollover" certificates are needed only for client that don't 
support encoding conversions when comparing DN.
Even many clients are in this case, some clients can be correctly 
implementing the comparison and then they will handle the two 
certificates as belonging to the same CA.
If thoses clients also fully implement the CRL checking rules, then they 
should consider a CRLs emitted under either the old or the new key as 
valid for certificates emitted under both keys.

The answer is YES, even if it might be in practice difficult to find 
even one single client that is actually affected.




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFIFmC063811; Tue, 15 Feb 2005 07:18:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FFIFvZ063810; Tue, 15 Feb 2005 07:18:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFIEoH063804 for <[e-mail]>; Tue, 15 Feb 2005 07:18:14 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1FFHaaX022466; Tue, 15 Feb 2005 10:17:39 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1FFHPEY001418; Tue, 15 Feb 2005 10:17:25 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 15 Feb 2005 10:18:27 -0500
To: Denis Pinkas <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: SCVP draft 17 available now! (Was Re: SCVP Draft 17: Summary of changes)
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

I just realized the significance of your comment "since I have not yet seen 
the draft."  The ID announcement does not seem to have been posted, but the 
new draft is available right now from the PKIX WG charter page.

The URL for draft 17 is 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-scvp-17.txt

If I had recognized this situation, I would have included the URL in my 
message with the summary of changes yesterday.

Thanks,

Tim

At 01:33 PM 2/15/2005 +0100, Denis Pinkas wrote:
>Tim (or to the ever optimist)
>
>>Folks,
>
>>A new version of SCVP-17 was posted this afternoon.  IMHO, this version 
>>fully satisfies RFC 3379, and is responsive to the comments submitted on 
>>the WG mailing list.
>
>My comments 46 to 68 have never been responded on the list.
>
>I replied to the disposition of comments for 1-45 stating that several 
>comments were not correctly understood and resolved to my satisfaction, 
>but I got no answer.
>
>Under these conditions, I am rather pessimistic, since I have not yet seen 
>the draft.
>
>Denis
>
>
>>Ever the optimist, I believe this draft is a strong candidate for WG 
>>consensus.
>>Please spend some time reviewing the new draft so we can gauge consensus 
>>and either tweak the document before the ID submission deadline (next 
>>Monday!) or forward it to the ADs.
>>In the interest of an efficient review, here is a summary of the changes:
>>(1) All of the comments submitted to the list before Christmas were 
>>reviewed.  Comments where Trevor had worked out a resolution on the list 
>>are included here and many (but not all) of the remaining comments were 
>>addressed.
>>(2) Inconsistencies between the text and any ASN.1 structures have been 
>>resolved.
>>(3) Draft 16 used the term "signed" to refer to messages protected by 
>>either a digital signature or a (H)MAC.  Draft 17 refers to these 
>>messages as "protected" and reserves the word "signed" for messages 
>>protected by a digital signature.
>>(4) The Diffie-Hellman based authentication method was changed from MUST 
>>to SHOULD implement.
>>(5) The text for validation policies, validation algoriothms and name 
>>validation algorithms has all been revised for clarity.
>>(6) A field has been added to the validation policy response message so 
>>that servers can indicate the type(s) of status information the server is 
>>capable of using, as required in RFC 3379.
>>(7) Validation policies are now required to include default values for 
>>all parameters.  Draft -16 permitted servers to create policies where 
>>clients were forced to supply values for some parameters.
>>(8) A requestor name field was added to the cv request message, so that 
>>clients can include an asserted identity, as required in RFC 3379.
>>Servers may still return an authenticated identity for the client if 
>>available.
>>(9) The key usage and extended key usage specifications have been 
>>enhanced to permit a client to state "no requirements".
>>(10) The SCVP server now uses the ValdiationPolicy ASN.1 data structure 
>>from the scvp request message to indicate its policy (in the scvp 
>>response and policy response messages).
>>(11) The validation error OIDs associated with the basic validation 
>>algorithm and name validation algorithm have been scrubbed.
>>(12) The keyPurposeID in the name validation algorithm was renamed 
>>nameCompAlgId.  While some of the OIDs specified in this document 
>>correspond to extended key usages, that is not a requirement of the 
>>specification.  The important point was that the OID identified the 
>>algorithm used to compare names in the end certificate.
>>(13) The isCA option to support partial path validation was removed from 
>>the validation policy.  To use this feature securely, extensive additions 
>>to the protocol were required to return a set of interim state variables 
>>from an incomplete run of RFC 3280 Section 6.1 path validation.  The 
>>complexity was considered an impediment to completion of the document and 
>>was not a requirement in RFC 3379.  (This feature may be specified in a 
>>separate document in the future, using the SCVP extensions mechanism.)
>>(14) Clients signal whether a cached response is acceptable using the 
>>responseFlags rather than a wantback as in draft -16.
>>(15) When providing a list of certificates in the replyWantbacks in an 
>>scvp response message, servers are now required to order the certificates 
>>beginning with the end certificate.  (This is a requirement stated in RFC 
>>3379.)
>>(16) When performing Diffie-Hellman where the client has an ephemeral key 
>>and the server has a static key, the ephemeral key is conveyed in the 
>>authenticated data wrapper rather than the cv request.  The draft does 
>>not allow ephemeral - ephemeral but does support pre-shared keys.
>>(17) A new failure code was added to reply status to handle the case 
>>where all checks were performed successfully, however one or more of the 
>>wantBacks could not be satisfied.
>>(18) The replychecks for status checking were extended to cover the case 
>>where the server cannot locate a source of status information.  (This 
>>differentiates the failure from one where a source is known but network 
>>or other errors prevented getting the information.)
>>Of the comments which were not incorporated into the document:
>>(A) The editors disagreed with the comment that path validation 
>>algorithms other than that in RFC 3280 should be supported.  This is a 
>>PKIX WG specification, and there is no requirement in RFC 3379 to support 
>>non-PKIX path validation.  Consequently, this change was not made.
>>(B) The descriptions of validation algorithm and validation policy more 
>>clearly delineate the differences, but I am unsure if all of that class 
>>of comments are satisfied.
>>(C) Changes to ASN.1 syntax for elegance alone were not implemented; 
>>beauty is in the eye of the beholder and that debate would never end.
>>ASN.1 changes were only made to enforce restrictions specified in the 
>>text or for consistency with the text (e.g., add a missing item described 
>>elsewhere.)
>>Thanks,
>>Tim Polk
>
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFHMYa063760; Tue, 15 Feb 2005 07:17:22 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FFHMhj063759; Tue, 15 Feb 2005 07:17:22 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFHFpa063727 for <[e-mail]>; Tue, 15 Feb 2005 07:17:17 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA71394; Tue, 15 Feb 2005 16:30:39 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021516170121:315 ; Tue, 15 Feb 2005 16:17:01 +0100 
Message-ID: <[e-mail]>
Date: Tue, 15 Feb 2005 16:17:32 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: pkix <[e-mail]>
Subject: SCVP 16 comments 17-45
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 16:17:01, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 16:17:02, Serialize complete at 15/02/2005 16:17:02
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1FFHMpa063754
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

You said: "I am looking forward to your comments on our disposition of your 
comments".

You already got these ones below which were not responded.

Denis

==========================================================================
Denis,

The editors have been working feverishly to meet the deadlines.  In some 
cases, the disposition of comments are currently chicken scratch on paper. 
They will be submitted to the list as soon as we can document things.

However, you should understand that some comments may not be resolved to 
your satisfaction.  We are looking for *rough consensus* here.  That means 
the WG as a group needs to be satisfied on each issue, but some individuals 
will inevitably be unhappy with the resolution of some particular issues. 
That is just life.

IMHO, issues related to consistency with RFC 3379 are show stoppers - SCVP 
must be responsive to our requirements document!  Issuers related to 
elegance and personal preference are not show stoppers, and should not be 
allowed to prevent this document from moving forward.

Anyway, we will get the disposition of your comments (and others) documented 
and onto the list today or tomorrow.  I'm looking forward to your comments 
on our disposition of your comments.

Thanks,

Tim

-------- Original Message --------
Subject: Re: SCVP 16 comments deadline
Date: Wed, 05 Jan 2005 13:46:18 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
To: Trevor Freeman <[e-mail]>
CC: [e-mail]
References: 
<[e-mail]>


Trevor,

Here are my responses on 17-45. There are still many major points on which
we do not agree. The MAJOR one has still to do with the deletion of the
validation ALGORITHM so that all validation POLICY dependant parameters can
be placed under the validation policy reference.


17. On top of page 7, the relationship between the validation policy and
the basic certification path algorithm is not explained. Then in section
1.4 The concept of validation algorithm is introduced but its relationship
with the validation policy is not explained. This is confusing.

Later on when observing the ASN.1 syntax it may be discovered that two
OIDs are being used:

     - one for the validation policy (ValidationPolRef) and
     - one for the validation algorithm (ValidationAlg).

This is overcomplicated and unnecessary.

[TF] Is there a specific issue with the current draft such as a scenario
which is not addressed ?

[DP] I do not believe that raising this question is a good way to solve my
concern. The “S” from SCVP was supposed to mean “Simple”. The current
description is the description of CCVP ”Complex Certificate Validation
Protocol”. Now, since you asked, CCVP is unable to support the validation
algorithm described in section 6.2 of RFC 3280 (with many trust points, each
one with its set of parameters). Adding more complexity to
solve it would not be the right answer.

A major simplification is obtained if there is an OID to define the
validation policy while there may be or not be additional parameters.

We sould then have:

    valPolByOID::= SEQUENCE {
          valPolId              OBJECT IDENTIFIER,
          parameters            ANY DEFINED BY ValPolId OPTIONAL }

Specifying a path processing compliant with section 6.1 of RFC 3280 would
not be possible in the general case, since the current text from RFC 3280
is too vague/ambiguous to support the case where a CRL is *not* signed
by the CA.

It would be desirable to be able to communicate easily and in a standard
way the parameters that may be set in section 6.1 from RFC 3280. In
addition, key usage should be added to that list.

The document should then define a bundle of all these previous useful
parameters and allow for the addition of other parameters.

It is thus proposed to define an OID for a validation policy compliant
with section 6.1 of RFC 3280 (some differences with section 6 from
3280bis, i.e. adding precision, may be expected). It is thus proposed to
modify the text starting from :

" The inputs to the basic certification path processing algorithm used by
SCVP are defined by [PKIX-1] in section 6.1.1 and comprise" up to the end
of section 1.3 with the following:

"For clients able to specify the parameters of a validation policy, it may
be useful to define a standard data structure (using a bundle) able to
support the parameters of the basic certification path processing
algorithm defined by in section 6.1.1 from [PKIX-1] :

     - a set of Trust Anchors (by value or by reference),
     - the initial Certificate Policy set,
     - initial Certificate Policy mapping setting,
     - initial any-Policy setting,
     - initial explicit Certificate Policy setting.
as well as :
     - the usage of the key contained in the certificate (e.g., key
encipherment, key agreement, signature)

This will be done using a bundle which encapsulates all these parameters.
Other application-specific purposes parameters may be added".

18. Section 1.4 is about a "Validation Algorithm". Given what was said
before, the header of this section should be changed. If we make a
subsection 1.3.1 called "1.3.1. General" for encapsulating the previous
text, then we can introduce a new section 1.3.2 called:
"1.3.2. Validation policy according to section 6.1 of RFC 3280"

[TF] See comment to 17
[DP] See my response above.

Some of the text present in the current section 1.4 has been used to build
the new text that is proposed below:

"1.3.2. Validation policy according to section 6.1 of RFC 3280 SCVP
defines a specific validation policy which implements the certification
path validation algorithm as defined in section 6.1 of [PKIX-1]. This
specific validation policy, called "rfc-3280 basic validation policy" uses
the parameters defined in the bundle mentioned above.

Note that this algorithm does not support in its full generality the
algorithm described in section 6.2 of [PKIX-1] since, when more than one
trust anchor is being defined, all the conditions that are specified apply
to all trust anchors, whereas section 6.2 allows to have different
conditions for every trust anchor.

The rfc-3280 basic validation policy may be the default validation policy
supported by the server, but does not need to".

19. Section 2 "Protocol Overview"
In order to allow for interoperability and testing a common protocol needs
to be supported. It should be defined.

[TF] There is plenty of precedence for this to be in a separate document.
CMS itself just defines the syntax.

[DP] Would you be more explicit ?


20. Section 3 "Validation Request"
The unsigned request form is not explained and there is a confusion for
the signed request which indeed authenticates the client and is thus not
anonymous. The current text is :

"A signed request is used to authenticate the client to the server or to
provide an anonymous client integrity over the request-response pair."
It should be rephrased as:

"An unsigned request provides an anonymous client integrity over the
request since the hash of the request or the full request is incorporated
in the response. A signed request is used to authenticate the client to
the server".

[TF] Since by definition the anonymous client has to sign the request as
well this does not make sense. A server can also return a cached response
in which case there is no hash of the request in the response. How about :
An anonymous client signs the request to provide integrity over the
request. A identifiable signs the request to authenticate itself to the
server.

[DP] This does not make sense. If the response is a live response (not
cached) then including the hash of the request in the response is fine and
the request does not need to be signed. If the response is a cached
response, then the cached response must include “sufficient” information
to make sure for the client that it is not a replay from a too old
response. The only way is to copy all the parameters of the original
request. In either case, signing the request does not help.


21. Page 13. Section 3.1.2 "checks"
The following sentence adds nothing and should be removed:
"A server may still choose to perform revocation status checks when
performing path construction, although this information cannot be returned
to the client."

[TF] I think it reinforces that with some checks, don't require revocation
status checking but a server may still elect to do so.

[DP] I disagree. A server SHALL do what the client asks, no more no less.
Please, delete the sentence.


22. Page 15. Section 3.1.3 "wantBack"
The text states:
- Proof of revocation status for each certificate in the AC issuer
certification path;

It would be important to refer the section of the RFC which explains how
to check the "revocation status for each certificate in the AC issuer
certification path".

[TF] OK, I will add a reference to 3281 section 5.

[DP] RFC 3281 is “An Internet Attribute Certificate Profile for
Authorization ». I do not believe that it is the correct reference. The
basic problem is that there exists no RFC that explains how to check the
"revocation status for each certificate in the AC issuer certification
path". So leaving details to the validation policy is the only solution.


23. Page 15. Section 3.1.3 "wantBack"
The text states:
The client can also request a non-cached response to the
request by including wantback id-swb-non-cached-resp in the request.
The default behavior should be the reverse: fresh information is provided,
unless the client accept cached information. The item should be changed
into: id-swb-cached-resp

[TF] This has been moved to response flags and the default is non-cached.
[DP] Fine, finally one point on which we agree.

24. Page 15. Section 3.1.3 "wantBack"
The text states:
id-swb-pkc-all-valid-cert-paths OBJECT IDENTIFIER ::= { id-swb 13}
It should be mentioned that this item is only possible for DPD.

[TF] Why is this only possible with DPD?
[DP] Because DPV returns only the fist valid path (i.e. a single path)


25. Page 16. Section 3.1.4 validationPolicy
The following sentence is talking of an agreement whereas such agreement
does not exist. Delete the sentence:
"The client and server can optionally agree on a set of parameters which
may fully or partially define a validation policy".
[TF] OK


26. Page 16. Section 3.1.4 validationPolicy
The text states:
"If a partial set of parameters has been agreed upon, then the client
supplies a reference to the policy plus whatever parameters are necessary
to complete the request in this item.

This should be replaced with:
"If the validation policy does not define all parameters necessary for
processing an SCVP request, then the client need to supply these
parameters".

[TF] Thats is not true. The client can omit whatever parameters match the
server default value.

[DP] This would mean that the default validation policy always have a full
set of parameters. In that case the quoted sentence is still incorrect
since it states “ a partial set of parameters”. That sentence still needs
to be corrected. What about:” The client supplies a reference to the
policy plus whatever parameters which are allowed to change the default
parameters".

27. Page 16. Section 3.1.4 validationPolicy
     The syntax of the validationPolicy item is defined as:

     ValidationPolicy ::= SEQUENCE {
        validationPolRef          ValidationPolRef,
        validationAlg         [0] ValidationAlg OPTIONAL,
        userPolicySet         [1] SEQUENCE SIZE (1..MAX) OF OBJECT
                                    IDENTIFIER OPTIONAL,
        inhibitPolicyMapping  [2] BOOLEAN OPTIONAL,
        requireExplicitPolicy [3] BOOLEAN OPTIONAL,
        inhibitAnyPolicy      [4] BOOLEAN OPTIONAL,
        isCA                  [5] BOOLEAN OPTIONAL,
        trustAnchors          [6] TrustAnchors OPTIONAL,
        keyUsages             [7] SEQUENCE SIZE (1..MAX) OF KeyUsage
                                     OPTIONAL,
        extendedKeyUsages     [8] ExtKeyUsageSyntax OPTIONAL}

This structure is quite odd, because it only allows to pass additional
parameters as parameters of the validationAlg. Suppressing the
validationAlg item add adding validationParamExtensions would be a simpler
and cleaner way.

[TF] The only way to include other parameters is because the algorithm
needs them. You cannot introduce new parameters without at the same time
defining there use. Therefore mandating additional parameters be passed
which the corresponding identifier for their is the right thing to do.

[DP] I disagree. I could say: the only way to include other parameters is
to place them as parameters of the validation policy because the
validation policy needs them. Your response is placed too early and does
not consider the proposal made just after. See the proposal hereafter and
please reconsider your position. This is one of the major issues.

Each validation policies uses its own parameters. We should have something
like :

ValPolByOID  ::= SEQUENCE {
          valPolgId             OBJECT IDENTIFIER,
          parameters            ANY DEFINED BY valPolId OPTIONAL }

More details follow.

28. It is highly debatable if URIs should be supported or not to reference
a validation policy. URIs are not stable over time and thus unless there
are dereferenced and a hash value is computed over them, it is insecure to
use them. There is a discussion in the security consideration section, but
no warning and no pointer here. If we keep them, we should warn the user.

[TF] The argument over the stability of URIs is discussed in the security
section - which is the appropriate place. The reality is in many
organizations are stable enough and much more manageable. The issue over
dereferencing and hashing is bogus. Both OID and URI are both opaque
stings for this purpose and rely on you trusting the management doing the
right thing.

[DP] Anyway a reference to the security consideration section is missing.
If you believe that a URI is opaque, it should be said, because
dereferencing is very often announced by some people as being an
advantage. You can place that information in the security considerations
section if you wish and then let the IESG decide.

If the WG should decides that they should be supported (and if the IESG
agrees) on page 17, the ASN.1 description should then be:

ValidationPolicy ::= CHOICE {
        valPolByOID         [0] ValPolByOID,
        valPolByURI         [1] ValPolByURI }

ValPolByOID  ::= SEQUENCE {
          valPolgId             OBJECT IDENTIFIER,
          parameters            ANY DEFINED BY valPolId OPTIONAL }

ValPolByURI ::= SEQUENCE {
        uri            IA5String,
        hashAlgo       OBJECT IDENTIFIER,
        hashValue      OCTET STRING}

29. It is proposed to define the following bundle:
ValidationParamBundle ::= SEQUENCE {
        certificatePolicySet      [0] SEQUENCE SIZE (1..MAX) OF
                                      OBJECT IDENTIFIER OPTIONAL,
        inhibitPolicyMapping      [1] BOOLEAN OPTIONAL,
        requireExplicitPolicy     [2] BOOLEAN OPTIONAL,
        inhibitAnyPolicy          [3] BOOLEAN OPTIONAL,
        isCA                      [4] BOOLEAN OPTIONAL,
        trustAnchors              [5] TrustAnchors OPTIONAL,
        keyUsages                 [6] SEQUENCE SIZE (1..MAX) OF
                                      KeyUsage OPTIONAL,
        extendedKeyUsages         [7] ExtKeyUsageSyntax OPTIONAL,
        extensions                [8] EXPLICIT Extensions OPTIONAL }

Note that userPolicySet" is unclear and has been changed into
"certificatePolicySet".

[TF] The use of userPolicySet aligns with 3280. I don't think the name to
the existing structure is ambiguous or misleading.

[DP] Your response arguments about the note but omits to respond to the
main argument of this comment. So I consider that a response to this
comment is still awaited. BTW, userPolicySet is not a term used in RFC
3280, so you cant’t say it aligns with RFC 3280.

The text would need to be aligned with the new structure and, of course
the parameters of the rfc-3280 basic validation policy will simply include
the bundle above as its parameters. It should also be mentioned somewhere
in the document that the support of the rfc-3280 basic validation policy
is not mandatory for conformance but, if supported then the bundle needs
to be supported.

30. Page 17. Section 3.1.5 validationAlg should be deleted.
[TF] Already done

[DP] Let us see what the next text will look like to know whether this
comment is solved or not. I fear it is not.


31. Page 17. Section 3.1.5.1 Default Validation Algorithm should be
deleted and replaced by a section later on the "rfc-3280 basic validation
policy", which should have its OID defined under the scvp tree for OIDs.

[TF] the basic validation algorithm references the 3280 section 6.

[DP] What you call the basic validation algorithm is one of the many
elements of the rfc-3280 basic validation policy. It is buried within the
validation policy and does not need to be identified independently of the
validation policy. The default Validation Algorithm still needs to be
deleted. This relates to comment 17.


32. Page 17. Section 3.1.5.1. Some text of this section might be re-used
to build a new section on the rfc-3280 basic validation policy. Note that
the last sentence at the bottom of page 17, should be removed. This
sentence is: "The default validation policy MUST use the basic validation
algorithm". Any default validation policy can be used.

[TF] See answer to 31
[DP] See my response above.


33. Page 17. Section 3.1.5.2 validationAlg (same title as 3.1.5 !) should
be as well deleted.
[TF] The duplicate has been deleted


34. Page 20. Section 3.1.5.2.3 Name Validation Algorithm
This goal of this section seems to introduce an additional test to the
basic "rfc-3280 basic validation policy". It would come naturally as an
extension of ValidationParamBundle, rather than as a parameter of the
validationAlgo which has been proposed to be removed. The text should be
modified accordingly.

[TF] See answer 27.
[DP] See my response: your response does not consider the proposal made in
comment 27.


35. Page 21. Section 3.1.5.2.3 Name Validation Algorithm
       NameValidationAlgParms ::= SEQUENCE {
          keyPurposeId      KeyPurposeId,
          validationNames   GeneralNames }

This construct is artificial since KeyPurposeId is about the Extended Key
Usage and has nothing to do with name validation.

[TF] Its simple reuses and existing practice.
[DP] I do not understand the argument about “existing practice”.

It could indeed be interesting to test the Extended Key Usage extension of
a certificate, but this should be supported as an extension of
ValidationParamBundle. The text should be modified accordingly.


36. Page 22. Section 3.1.5.3 userPolicySet
userPolicySet should be changed everywhere into certificatePolicySet.

[TF] userPolicySet aligns with 3280 section 6.
[DP] userPolicySet is not a term used in RFC 3280, so you cant’t say it
aligns with RFC 3280 section 6. You are probably reading a different
document.


37. Page 22. Section 3.1.5.3 userPolicySet
The text has many sentences like:
SCVP clients SHOULD support userPolicySet item in requests, and SCVP
servers MUST support userPolicySet item in requests.

These requirements only apply for the rfc-3280 basic validation policy,
and this should be clearly mentioned.

[TF] Since all validation polices contain userPolicySet, it can be in any
policy.

[DP] I disagree. There may be some validation policies where no parameter
at all can be changed by the client. I would expect that most clients will
use OIDs for validation policies with no parameter at all. A client is not
necessarily allowed to change any parameter of a validation policy. In
some cases clients will be allowed to specify only some parameters (but
not all).


38. Page 22. Section 3.1.5.4 inhibitPolicyMapping
The text states:
      By default the server allows policy mapping as
      part of certification path validation.

For simplicity, this should be the reverse. Replace with:

     "By default the server does not perform policy mapping as
      part of certification path validation. If the client wants
      the server to support policy mapping, allowPolicyMapping must
      be set to TRUE in the request".

[TF] This conflicts with 3280 section 6.
[DP] It does not. Section 6 does not mandate policy mapping.
The default is simplicity: no policy mapping.


39. Page 24. Section 3.1.5.8 trustAnchors
The text states:
    "A certificate reference can be used to identify the
      trust anchor by certificate hash and optionally a
      distinguished  name with serial number".

This is not consistent with the ASN.1 definition of PKCReference
which is:
     PKCReference ::= CHOICE {
        cert                   [0] Certificate,
        pkcRef                 [1] ESSCertID }

Please correct.

[DP] A response is missing.


40. Page 25. Section 3.1.6 responseRefHash

The text states:
     "By default, the server includes a hash
     of the request in the response. If the client wants the server
     to include the full request in the response, responseRefHash
     is set to FALSE."

The server shall always include a hash of the request in the response.

[TF] A server cannot include a hash of the request in a cached response.

[DP] See my new response to comment 20. If the response is a live response
(not cached) then including the hash of the request in the response is
fine. If the response is a cached response, then the cached response must
include “sufficient” information to make sure for the client that it is
not a replay from a too old response. The only way is to copy all the
parameters of the original request.

This is an easy way to allow to test the integrity of the request. Since
the full description of the validation policy may be much longer a flag
should be used to say that the full validation policy is not returned
unless requested.

[TF] There is one, it is responseValidationPolByRef. The response flags
now has a FullRequestInResponse in place of the requestRefHash.

[DP] Let us see what the full new proposal is. If you agree with my
response to comment 20, maybe we are converging.


It is thus proposed to have instead the following:

"3.1.6.1 fullRequestInResponse
The fullRequestInResponse controls if the client wants the server to
include the full request in the response. By default,
fullRequestInResponse is set to FALSE. If the client wants back the full
request then it must set this parameter to TRUE. The main reason a client
would request the server to include the full request in the response is to
archive the request-response exchange in a single object.  That is, the
client wants to archive a single object which includes both request and
response".


41. Page 26. Section 3.1.6.2 responseValidationPolByRef
This item should be renamed: fullValPolInResponse
The text should be changed into:

"The fullValPolInResponse controls whether the response includes the
identifier of the validation policy with all the parameters that have been
used by the server, i.e. all the variable parameters independent from the
fact that there were specified by the client or defaulted if not
specified. By default, fullValPolInResponse is set to FALSE. If the client
wants the full validation policy to be included, then fullValPolInResponse
is set to TRUE. The main reason a client would request the server to
include validation policy to be included by value is to archive the
request-response exchange in a single object. That is, the client wants to
archive the CVResponse and have it include every aspect of the validation
policy."

[TF] I have not changed the name, but the section now reads

The responseValidationPolByRef controls whether the response includes just
a reference to the policy or the reference to the policy plus all the
parameters by value of the policy used to process the request. the
response MUST contain references to the validation policy. If the client
wants the validation policy parameters to be also included by value, then
the responseValidationPolByRef is set to FALSE. The main reason a client
would request the server to include validation policy to be included by
value is to archive the request-response exchange in a single object. That
is, the client wants to archive the CVResponse and have it include every
aspect of the validation policy.

[DP] This new proposed text is still incorrect: “just a reference to the
validation policy” does not help, (unless the validation policy has no
variable parameter). We need to have a mechanism for replay protection
and/or for making sure that the response relates to the right request:
“just a reference to the validation policy” does not provide this
property. However, my proposal provides that property. Please reconsider
my text.

The ResponseFlags should be changed as follows:
     ResponseFlags ::= SEQUENCE {
        fullRequestInResponse      BOOLEAN DEFAULT FALSE,
        fullValPolInResponse       BOOLEAN DEFAULT FALSE,
        signResponse               BOOLEAN DEFAULT TRUE }

42. Page 28. Section 3.1.9 intermediateCerts. Minor.
Change:
     The optional intermediateCerts item helps the SCVP server
     create valid certification paths.
into:
     The optional intermediateCerts item may help the SCVP server
     to create valid certification paths.

[TF] Fixed

43. Page 29. Section 3.1.11. producedAt
Last sentence. Change:
     SCVP server SHOULD support the producedAt values in the
     request.
into:
     SCVP server MAY support the producedAt values in the request.

Reason: cached responses should not need to be implemented in
order to be compliant with the specification.

[TF] Fixed


44. Page 32. Section 3.5 dhPublicKey
The text states:
"For the server to compute the shared secret, it must lean the public
values the client generates, therefore the client MUST include this in the
request if it uses this mechanism to integrity protect the request-
response pair."

Replace:

"to integrity protect the request-response pair"

with :

"to authenticate and integrity protect the first response and authenticate
and integrity protect subsequent request-response pairs".

[TF] draft now read " integrity protect the request and the subsequent
response." The use of DH does not necessarily authenticate the request.


45. Page 32. Section 3.6 SCVP Request Authentication
The text states:

"It is a matter of local policy what validation policy is used by the
server when validating requests".

This sentence could be misinterpreted because the word "validating" is
being used. Change into:

It is a matter of local policy what validation policy is used by the
server when authentication requests".

[TF] Fixed

END OF COMMENTS

Denis






Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFFFnu063586; Tue, 15 Feb 2005 07:15:15 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FFFFts063585; Tue, 15 Feb 2005 07:15:15 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FFFBtG063566 for <[e-mail]>; Tue, 15 Feb 2005 07:15:12 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA16274; Tue, 15 Feb 2005 16:28:33 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021516145458:311 ; Tue, 15 Feb 2005 16:14:54 +0100 
Message-ID: <[e-mail]>
Date: Tue, 15 Feb 2005 16:15:26 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: pkix <[e-mail]>
Subject: SCVP 16 comments 1-16
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 16:14:54, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 16:14:56, Serialize complete at 15/02/2005 16:14:56
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim,

You said: "I am looking forward to your comments on our disposition of your 
comments".

You already got this one below which was not responded.

Denis

==========================================================================
Denis,

The editors have been working feverishly to meet the deadlines.  In some 
cases, the disposition of comments are currently chicken scratch on paper. 
They will be submitted to the list as soon as we can document things.

However, you should understand that some comments may not be resolved to 
your satisfaction.  We are looking for *rough consensus* here.  That means 
the WG as a group needs to be satisfied on each issue, but some individuals 
will inevitably be unhappy with the resolution of some particular issues. 
That is just life.

IMHO, issues related to consistency with RFC 3379 are show stoppers - SCVP 
must be responsive to our requirements document!  Issuers related to 
elegance and personal preference are not show stoppers, and should not be 
allowed to prevent this document from moving forward.

Anyway, we will get the disposition of your comments (and others) documented 
and onto the list today or tomorrow.  I'm looking forward to your comments 
on our disposition of your comments.

Thanks,

Tim

-------- Original Message --------
Subject: Re: SCVP 16 comments deadline
Date: Wed, 08 Dec 2004 17:00:33 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
To: Trevor Freeman <[e-mail]>
CC: [e-mail]
References: 
<[e-mail]>


Trevor,

 > Hi Denis,
 > Below are responses to 1-16. Others will follow later.

I am pleased that you accepted comments 13, 14, 15 and 16.
Among this list, I have a further remark on comment 4.

 > * 4. Page 13. Typo. Section 3.1.2 "checks"
 > * The two following lines are in fact one line:
 > *
 > * Change:
 > *
 > *      - Build a validated certification path to a trust anchor; and
 > *
 > *      - Do revocation status checks on the certification path.
 > *
 > * into:
 > *
 > *      - Build a validated certification path to a trust anchor and
 > *        do revocation status checks on the certification path.
 > *
 > [TF] Since this paragraph is listing the possible checks and building a
 > path is a separate check to revocation checking, I think the current
 > text is more accurate.

I agree that "building a path is a separate check to revocation checking",
but revocation checking without building a validated path does not make sense.

The full text currently is:

      - Build a certification path to a trust anchor;

      - Build a validated certification path to a trust anchor; and

      - Do revocation status checks on the certification path.

The full text should be:

      - Build a certification path to a trust anchor;

      - Build a validated certification path to a trust anchor; and
        do revocation status checks on the certification path.

Denis




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FEqUFK060504; Tue, 15 Feb 2005 06:52:30 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FEqUfw060503; Tue, 15 Feb 2005 06:52:30 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FEqTBR060493 for <[e-mail]>; Tue, 15 Feb 2005 06:52:29 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1FEmaaP015427; Tue, 15 Feb 2005 09:48:37 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1FElgEY019512; Tue, 15 Feb 2005 09:47:42 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 15 Feb 2005 09:48:43 -0500
To: Denis Pinkas <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: SCVP Draft 17: Summary of changes
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

The editors have been working feverishly to meet the deadlines.  In some 
cases, the disposition of comments are currently chicken scratch on 
paper.  They will be submitted to the list as soon as we can document things.

However, you should understand that some comments may not be resolved to 
your satisfaction.  We are looking for *rough consensus* here.  That means 
the WG as a group needs to be satisfied on each issue, but some individuals 
will inevitably be unhappy with the resolution of some particular 
issues.  That is just life.

IMHO, issues related to consistency with RFC 3379 are show stoppers - SCVP 
must be responsive to our requirements document!  Issuers related to 
elegance and personal preference are not show stoppers, and should not be 
allowed to prevent this document from moving forward.

Anyway, we will get the disposition of your comments (and others) 
documented and onto the list today or tomorrow.  I'm looking forward to 
your comments on our disposition of your comments.

Thanks,

Tim

At 01:33 PM 2/15/2005 +0100, Denis Pinkas wrote:
>Tim (or to the ever optimist)
>
>>Folks,
>
>>A new version of SCVP-17 was posted this afternoon.  IMHO, this version 
>>fully satisfies RFC 3379, and is responsive to the comments submitted on 
>>the WG mailing list.
>
>My comments 46 to 68 have never been responded on the list.
>
>I replied to the disposition of comments for 1-45 stating that several 
>comments were not correctly understood and resolved to my satisfaction, 
>but I got no answer.
>
>Under these conditions, I am rather pessimistic, since I have not yet seen 
>the draft.
>
>Denis
>
>
>>Ever the optimist, I believe this draft is a strong candidate for WG 
>>consensus.
>>Please spend some time reviewing the new draft so we can gauge consensus 
>>and either tweak the document before the ID submission deadline (next 
>>Monday!) or forward it to the ADs.
>>In the interest of an efficient review, here is a summary of the changes:
>>(1) All of the comments submitted to the list before Christmas were 
>>reviewed.  Comments where Trevor had worked out a resolution on the list 
>>are included here and many (but not all) of the remaining comments were 
>>addressed.
>>(2) Inconsistencies between the text and any ASN.1 structures have been 
>>resolved.
>>(3) Draft 16 used the term "signed" to refer to messages protected by 
>>either a digital signature or a (H)MAC.  Draft 17 refers to these 
>>messages as "protected" and reserves the word "signed" for messages 
>>protected by a digital signature.
>>(4) The Diffie-Hellman based authentication method was changed from MUST 
>>to SHOULD implement.
>>(5) The text for validation policies, validation algoriothms and name 
>>validation algorithms has all been revised for clarity.
>>(6) A field has been added to the validation policy response message so 
>>that servers can indicate the type(s) of status information the server is 
>>capable of using, as required in RFC 3379.
>>(7) Validation policies are now required to include default values for 
>>all parameters.  Draft -16 permitted servers to create policies where 
>>clients were forced to supply values for some parameters.
>>(8) A requestor name field was added to the cv request message, so that 
>>clients can include an asserted identity, as required in RFC 3379.
>>Servers may still return an authenticated identity for the client if 
>>available.
>>(9) The key usage and extended key usage specifications have been 
>>enhanced to permit a client to state "no requirements".
>>(10) The SCVP server now uses the ValdiationPolicy ASN.1 data structure 
>>from the scvp request message to indicate its policy (in the scvp 
>>response and policy response messages).
>>(11) The validation error OIDs associated with the basic validation 
>>algorithm and name validation algorithm have been scrubbed.
>>(12) The keyPurposeID in the name validation algorithm was renamed 
>>nameCompAlgId.  While some of the OIDs specified in this document 
>>correspond to extended key usages, that is not a requirement of the 
>>specification.  The important point was that the OID identified the 
>>algorithm used to compare names in the end certificate.
>>(13) The isCA option to support partial path validation was removed from 
>>the validation policy.  To use this feature securely, extensive additions 
>>to the protocol were required to return a set of interim state variables 
>>from an incomplete run of RFC 3280 Section 6.1 path validation.  The 
>>complexity was considered an impediment to completion of the document and 
>>was not a requirement in RFC 3379.  (This feature may be specified in a 
>>separate document in the future, using the SCVP extensions mechanism.)
>>(14) Clients signal whether a cached response is acceptable using the 
>>responseFlags rather than a wantback as in draft -16.
>>(15) When providing a list of certificates in the replyWantbacks in an 
>>scvp response message, servers are now required to order the certificates 
>>beginning with the end certificate.  (This is a requirement stated in RFC 
>>3379.)
>>(16) When performing Diffie-Hellman where the client has an ephemeral key 
>>and the server has a static key, the ephemeral key is conveyed in the 
>>authenticated data wrapper rather than the cv request.  The draft does 
>>not allow ephemeral - ephemeral but does support pre-shared keys.
>>(17) A new failure code was added to reply status to handle the case 
>>where all checks were performed successfully, however one or more of the 
>>wantBacks could not be satisfied.
>>(18) The replychecks for status checking were extended to cover the case 
>>where the server cannot locate a source of status information.  (This 
>>differentiates the failure from one where a source is known but network 
>>or other errors prevented getting the information.)
>>Of the comments which were not incorporated into the document:
>>(A) The editors disagreed with the comment that path validation 
>>algorithms other than that in RFC 3280 should be supported.  This is a 
>>PKIX WG specification, and there is no requirement in RFC 3379 to support 
>>non-PKIX path validation.  Consequently, this change was not made.
>>(B) The descriptions of validation algorithm and validation policy more 
>>clearly delineate the differences, but I am unsure if all of that class 
>>of comments are satisfied.
>>(C) Changes to ASN.1 syntax for elegance alone were not implemented; 
>>beauty is in the eye of the beholder and that debate would never end.
>>ASN.1 changes were only made to enforce restrictions specified in the 
>>text or for consistency with the text (e.g., add a missing item described 
>>elsewhere.)
>>Thanks,
>>Tim Polk
>
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FDCqqH035255; Tue, 15 Feb 2005 05:12:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FDCqRC035254; Tue, 15 Feb 2005 05:12:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FDCjHY035165 for <[e-mail]>; Tue, 15 Feb 2005 05:12:48 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA62674; Tue, 15 Feb 2005 14:25:42 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021514120330:230 ; Tue, 15 Feb 2005 14:12:03 +0100 
Message-ID: <[e-mail]>
Date: Tue, 15 Feb 2005 14:12:34 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Russ Housley <[e-mail]>, pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 14:12:03, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 14:12:05, Serialize complete at 15/02/2005 14:12:05
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

> Denis,

> No I don't see that a rewriting of the document is motivated at this
> point.

It is your opinion, but not mine.

> There is nothing in the document that suggests that the specified
> approach is superior in any way. 

What about the following sentences picked from the document:

    Standardized methods of finding the certificate of the CRL issuer are
    currently available either though an accessible directory location or
    through use of the Subject Information Access extension in
    intermediary CA certificates.  These methods are however not
    generally applicable, and they do not provide a generic solution to
    the problem.

This is true only if indirect CRLs are being used, but the wording "indirect 
CRL" is absent from these lines.

> It is an optional mechanism to be used
> by those who whish to use it to find the CRL signer cert.

  ... which is really motivated when indirect CRLs are being used, but 
otherwise is not and the draft does not say it.

> I think the motivation for allowing this extension in CRLs is
> sufficiently stated in the document. 

It is not. In addition, adding an extension does not make sense unless you 
tell how it should be used.

> Nothing you suggest is changing the
> technical outline of the specified solution.

In this case, the processing of this new extension may be explained and this 
is not the case at this time.

> More comments below..
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 11 februari 2005 11:33
>>To: Stefan Santesson
>>Cc: Russ Housley; pkix
>>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
>>
>>
>>Stefan,
>>
>>
>>>Denis,
>>>
>>> Sorry for being unclear, and maybe for not seeing what you try to
>>> say.
> 
>>> What I meant was that the problem should not exist at all for
>>> non-indirect CRLs. Here I totally agree that the CRL and the CA
>>> can't have unrelated chaining. I'm not sure what the standard says about
>>> this but if this is unclear, then it should be made clear.

>>> What I further mean is that the existence of diversified cert and
>>> CRL paths is therefore only an issue for indirect CRLs, AND for indirect
>>> CRLs CDP and IDP matching IS a requirement.

>>> The conclusion I make is: The current text in the crl-aia draft is
>>> correct since diversified CRL and cert paths may exist where the CRL
>>> issuer cert is issued by someone else that the CA that issued the
>>> validated cert.

>> The problem is that neither the abstract nor the introduction of this
>> draft is limiting the scope to indirect CRLs only.

> [Stefan] That is because the scope of AIA in CRLs is not limited to
> indirect CRLs.

   .. but this extension does not add anything, if SIA used.

>> The point is that a relying party cannot know in advance whether
>> indirect CRLs or "direct CRLs" are being used. So the story starts when the
>> relying party gets a "candidate CRL" from the CRL DP and then it can see
>> whether it contains or not an IDP.

> [Stefan] This is incorrect. The data in each DP of the CDP will tell the
> RP whether the DP points to an indirect CRL.

    DistributionPoint ::= SEQUENCE {
         distributionPoint       [0]     DistributionPointName OPTIONAL,
         reasons                 [1]     ReasonFlags OPTIONAL,
         cRLIssuer               [2]     GeneralNames OPTIONAL }

    DistributionPointName ::= CHOICE {
         fullName                [0]     GeneralNames,
         nameRelativeToCRLIssuer [1]     RelativeDistinguishedName }

Which field are you talking about ?

>> The draft should thus address the two scenarios (i.e. an IDP is or is
>> not present) and for direct CRLs there is no "superiority" of the new
>> extension.

> [Stefan] I don't see the point with that. The use of the AIA extension
> in CRL is not different for indirect or direct CRLs.

With direct CRLs, there does not need to be any AIA extension, if the SIA 
extension in CA certificates is present. This is not said and should be said.

Then the processing of the extension should be explained for indirect CRLs.

Denis

>>Would you prepare a revison of the draft along these lines ?

> [Stefan] No, see above.

>> If you agree, I woud propose that we discuss off-line with your
>> co-editor the details of the new draft and come back to the list 
 >> when a new draft is ready.

>>Denis


>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FCXs7r021829; Tue, 15 Feb 2005 04:33:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FCXsIN021828; Tue, 15 Feb 2005 04:33:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FCXgGn021637 for <[e-mail]>; Tue, 15 Feb 2005 04:33:46 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id NAA23592; Tue, 15 Feb 2005 13:46:45 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021513330679:204 ; Tue, 15 Feb 2005 13:33:06 +0100 
Message-ID: <[e-mail]>
Date: Tue, 15 Feb 2005 13:33:38 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: SCVP Draft 17: Summary of changes
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 13:33:06, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 15/02/2005 13:33:13, Serialize complete at 15/02/2005 13:33:13
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim (or to the ever optimist)

> Folks,

> A new version of SCVP-17 was posted this afternoon.  IMHO, this version 
> fully satisfies RFC 3379, and is responsive to the comments submitted on 
> the WG mailing list.  

My comments 46 to 68 have never been responded on the list.

I replied to the disposition of comments for 1-45 stating that several 
comments were not correctly understood and resolved to my satisfaction, but 
I got no answer.

Under these conditions, I am rather pessimistic, since I have not yet seen 
the draft.

Denis


> Ever the optimist, I believe this draft is a 
> strong candidate for WG consensus.
> 
> Please spend some time reviewing the new draft so we can gauge consensus 
> and either tweak the document before the ID submission deadline (next 
> Monday!) or forward it to the ADs.
> 
> In the interest of an efficient review, here is a summary of the changes:
> 
> (1) All of the comments submitted to the list before Christmas were 
> reviewed.  Comments where Trevor had worked out a resolution on the list 
> are included here and many (but not all) of the remaining comments were 
> addressed.
> (2) Inconsistencies between the text and any ASN.1 structures have been 
> resolved.
> (3) Draft 16 used the term "signed" to refer to messages protected by 
> either a digital signature or a (H)MAC.  Draft 17 refers to these 
> messages as "protected" and reserves the word "signed" for messages 
> protected by a digital signature.
> (4) The Diffie-Hellman based authentication method was changed from MUST 
> to SHOULD implement.
> (5) The text for validation policies, validation algoriothms and name 
> validation algorithms has all been revised for clarity.
> (6) A field has been added to the validation policy response message so 
> that servers can indicate the type(s) of status information the server 
> is capable of using, as required in RFC 3379.
> (7) Validation policies are now required to include default values for 
> all parameters.  Draft -16 permitted servers to create policies where 
> clients were forced to supply values for some parameters.
> (8) A requestor name field was added to the cv request message, so that 
> clients can include an asserted identity, as required in RFC 3379.  
> Servers may still return an authenticated identity for the client if 
> available.
> (9) The key usage and extended key usage specifications have been 
> enhanced to permit a client to state "no requirements".
> (10) The SCVP server now uses the ValdiationPolicy ASN.1 data structure 
> from the scvp request message to indicate its policy (in the scvp 
> response and policy response messages).
> (11) The validation error OIDs associated with the basic validation 
> algorithm and name validation algorithm have been scrubbed.
> (12) The keyPurposeID in the name validation algorithm was renamed 
> nameCompAlgId.  While some of the OIDs specified in this document 
> correspond to extended key usages, that is not a requirement of the 
> specification.  The important point was that the OID identified the 
> algorithm used to compare names in the end certificate.
> (13) The isCA option to support partial path validation was removed from 
> the validation policy.  To use this feature securely, extensive 
> additions to the protocol were required to return a set of interim state 
> variables from an incomplete run of RFC 3280 Section 6.1 path 
> validation.  The complexity was considered an impediment to completion 
> of the document and was not a requirement in RFC 3379.  (This feature 
> may be specified in a separate document in the future, using the SCVP 
> extensions mechanism.)
> (14) Clients signal whether a cached response is acceptable using the 
> responseFlags rather than a wantback as in draft -16.
> (15) When providing a list of certificates in the replyWantbacks in an 
> scvp response message, servers are now required to order the 
> certificates beginning with the end certificate.  (This is a requirement 
> stated in RFC 3379.)
> (16) When performing Diffie-Hellman where the client has an ephemeral 
> key and the server has a static key, the ephemeral key is conveyed in 
> the authenticated data wrapper rather than the cv request.  The draft 
> does not allow ephemeral - ephemeral but does support pre-shared keys.
> (17) A new failure code was added to reply status to handle the case 
> where all checks were performed successfully, however one or more of the 
> wantBacks could not be satisfied.
> (18) The replychecks for status checking were extended to cover the case 
> where the server cannot locate a source of status information.  (This 
> differentiates the failure from one where a source is known but network 
> or other errors prevented getting the information.)
> 
> Of the comments which were not incorporated into the document:
> 
> (A) The editors disagreed with the comment that path validation 
> algorithms other than that in RFC 3280 should be supported.  This is a 
> PKIX WG specification, and there is no requirement in RFC 3379 to 
> support non-PKIX path validation.  Consequently, this change was not made.
> (B) The descriptions of validation algorithm and validation policy more 
> clearly delineate the differences, but I am unsure if all of that class 
> of comments are satisfied.
> (C) Changes to ASN.1 syntax for elegance alone were not implemented; 
> beauty is in the eye of the beholder and that debate would never end.  
> ASN.1 changes were only made to enforce restrictions specified in the 
> text or for consistency with the text (e.g., add a missing item 
> described elsewhere.)
> 
> Thanks,
> 
> Tim Polk
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FAd9P5083003; Tue, 15 Feb 2005 02:39:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1FAd9QJ083002; Tue, 15 Feb 2005 02:39:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mx07.ms.so-net.ne.jp (mx07.ms.so-net.ne.jp [202.238.82.7]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1FAcqTw082764 for <[e-mail]>; Tue, 15 Feb 2005 02:39:01 -0800 (PST) (envelope-from [e-mail])
Received: from [127.0.0.1] (p299e62.tkyoac00.ap.so-net.ne.jp [218.41.158.98]) by mx07.ms.so-net.ne.jp  with ESMTP id j1FAcLDK006736 for <[e-mail]>; Tue, 15 Feb 2005 19:38:21 +0900 (JST)
Date: Tue, 15 Feb 2005 19:38:19 +0900
From: Masaki SHIMAOKA <[e-mail]>
To: IETF-PKIX <[e-mail]>
Subject: Question about updating the CA to change its DN encoding
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.12.01 [ja]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,

I have one question about updating the CA to change its DN encoding.

If the old CA and new CA have different keypairs, issue the self-issued
certificates each other, and have same DN regardless of encoding, should
both CA share the revocation information between their CRLs?
# I believe that such self-issued certificates are the one called a name
rollover certificate in RFC 3280.

The reason why I wonder is that revocation information is specified by
issuer and serial number.  If an application assumes that DNs of such
old CA and new CA is the same, the application may use to check the CRL
issued by new CA for a certificate issued by old CA.  
And if the answer is YES in the case using such applications, it means
anyone can make the CRL substitution attack easily.

So, I hope the answer is NO and all applications should use to check the
CRL issued by the signing key of the corresponding certificate issuer.

Is it correct?

-- shima



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1EMwfja060816; Mon, 14 Feb 2005 14:58:41 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1EMwfhf060815; Mon, 14 Feb 2005 14:58:41 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1EMwXAm060808 for <[e-mail]>; Mon, 14 Feb 2005 14:58:33 -0800 (PST) (envelope-from [e-mail])
Received: from postmark.nist.gov (pullyou.nist.gov [129.6.16.93]) by smtp.nist.gov (8.12.10/8.12.10) with ESMTP id j1EMwRj7007339; Mon, 14 Feb 2005 17:58:27 -0500
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id j1EMw7EY011047; Mon, 14 Feb 2005 17:58:07 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 14 Feb 2005 17:59:09 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: SCVP Draft 17: Summary of changes
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-NIST-MailScanner: Found to be clean
X-MailScanner-From: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

A new version of SCVP-17 was posted this afternoon.  IMHO, this version 
fully satisfies RFC 3379, and is responsive to the comments submitted on 
the WG mailing list.  Ever the optimist, I believe this draft is a strong 
candidate for WG consensus.

Please spend some time reviewing the new draft so we can gauge consensus 
and either tweak the document before the ID submission deadline (next 
Monday!) or forward it to the ADs.

In the interest of an efficient review, here is a summary of the changes:

(1) All of the comments submitted to the list before Christmas were 
reviewed.  Comments where Trevor had worked out a resolution on the list 
are included here and many (but not all) of the remaining comments were 
addressed.
(2) Inconsistencies between the text and any ASN.1 structures have been 
resolved.
(3) Draft 16 used the term "signed" to refer to messages protected by 
either a digital signature or a (H)MAC.  Draft 17 refers to these messages 
as "protected" and reserves the word "signed" for messages protected by a 
digital signature.
(4) The Diffie-Hellman based authentication method was changed from MUST to 
SHOULD implement.
(5) The text for validation policies, validation algoriothms and name 
validation algorithms has all been revised for clarity.
(6) A field has been added to the validation policy response message so 
that servers can indicate the type(s) of status information the server is 
capable of using, as required in RFC 3379.
(7) Validation policies are now required to include default values for all 
parameters.  Draft -16 permitted servers to create policies where clients 
were forced to supply values for some parameters.
(8) A requestor name field was added to the cv request message, so that 
clients can include an asserted identity, as required in RFC 3379.  Servers 
may still return an authenticated identity for the client if available.
(9) The key usage and extended key usage specifications have been enhanced 
to permit a client to state "no requirements".
(10) The SCVP server now uses the ValdiationPolicy ASN.1 data structure 
from the scvp request message to indicate its policy (in the scvp response 
and policy response messages).
(11) The validation error OIDs associated with the basic validation 
algorithm and name validation algorithm have been scrubbed.
(12) The keyPurposeID in the name validation algorithm was renamed 
nameCompAlgId.  While some of the OIDs specified in this document 
correspond to extended key usages, that is not a requirement of the 
specification.  The important point was that the OID identified the 
algorithm used to compare names in the end certificate.
(13) The isCA option to support partial path validation was removed from 
the validation policy.  To use this feature securely, extensive additions 
to the protocol were required to return a set of interim state variables 
from an incomplete run of RFC 3280 Section 6.1 path validation.  The 
complexity was considered an impediment to completion of the document and 
was not a requirement in RFC 3379.  (This feature may be specified in a 
separate document in the future, using the SCVP extensions mechanism.)
(14) Clients signal whether a cached response is acceptable using the 
responseFlags rather than a wantback as in draft -16.
(15) When providing a list of certificates in the replyWantbacks in an scvp 
response message, servers are now required to order the certificates 
beginning with the end certificate.  (This is a requirement stated in RFC 
3379.)
(16) When performing Diffie-Hellman where the client has an ephemeral key 
and the server has a static key, the ephemeral key is conveyed in the 
authenticated data wrapper rather than the cv request.  The draft does not 
allow ephemeral - ephemeral but does support pre-shared keys.
(17) A new failure code was added to reply status to handle the case where 
all checks were performed successfully, however one or more of the 
wantBacks could not be satisfied.
(18) The replychecks for status checking were extended to cover the case 
where the server cannot locate a source of status information.  (This 
differentiates the failure from one where a source is known but network or 
other errors prevented getting the information.)

Of the comments which were not incorporated into the document:

(A) The editors disagreed with the comment that path validation algorithms 
other than that in RFC 3280 should be supported.  This is a PKIX WG 
specification, and there is no requirement in RFC 3379 to support non-PKIX 
path validation.  Consequently, this change was not made.
(B) The descriptions of validation algorithm and validation policy more 
clearly delineate the differences, but I am unsure if all of that class of 
comments are satisfied.
(C) Changes to ASN.1 syntax for elegance alone were not implemented; beauty 
is in the eye of the beholder and that debate would never end.  ASN.1 
changes were only made to enforce restrictions specified in the text or for 
consistency with the text (e.g., add a missing item described elsewhere.)

Thanks,

Tim Polk



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1C6dPEB048000; Fri, 11 Feb 2005 22:39:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1C6dPEc047999; Fri, 11 Feb 2005 22:39:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1C6dLOm047901 for <[e-mail]>; Fri, 11 Feb 2005 22:39:24 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Sat, 12 Feb 2005 06:40:53 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Date: Sat, 12 Feb 2005 06:38:59 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
thread-index: AcUQMOftF/wc2le/Tmq4kYTJi9jzgwAmorSg
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 12 Feb 2005 06:40:53.0360 (UTC) FILETIME=[CC677700:01C510CD]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1C6dOOm047991
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

No I don't see that a rewriting of the document is motivated at this
point.

There is nothing in the document that suggests that the specified
approach is superior in any way. It is an optional mechanism to be used
by those who whish to use it to find the CRL signer cert.

I think the motivation for allowing this extension in CRLs is
sufficiently stated in the document. Nothing you suggest is changing the
technical outline of the specified solution.

More comments below..

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Denis Pinkas
> Sent: den 11 februari 2005 11:33
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> 
> Stefan,
> 
> > Denis,
> >
> > Sorry for being unclear, and maybe for not seeing what you try to
say.
> >
> > What I meant was that the problem should not exist at all for
> > non-indirect CRLs. Here I totally agree that the CRL and the CA
can't
> > have unrelated chaining. I'm not sure what the standard says about
this
> > but if this is unclear, then it should be made clear.
> >
> > What I further mean is that the existence of diversified cert and
CRL
> > paths is therefore only an issue for indirect CRLs, AND for indirect
> > CRLs CDP and IDP matching IS a requirement.
> >
> > The conclusion I make is: The current text in the crl-aia draft is
> > correct since diversified CRL and cert paths may exist where the CRL
> > issuer cert is issued by someone else that the CA that issued the
> > validated cert.
> 
> The problem is that neither the abstract nor the introduction of this
> draft
> is limiting the scope to indirect CRLs only.
> 
[Stefan] That is because the scope of AIA in CRLs is not limited to
indirect CRLs.

> The point is that a relying party cannot know in advance whether
indirect
> CRLs or "direct CRLs" are being used. So the story starts when the
relying
> party gets a "candidate CRL" from the CRL DP and then it can see
whether
> it
> contains or not an IDP.
>
[Stefan] This is incorrect. The data in each DP of the CDP will tell the
RP whether the DP points to an indirect CRL.

> The draft should thus address the two scenarios (i.e. an IDP is or is
not
> present) and for direct CRLs there is no "superiority" of the new
> extension.
> 

[Stefan] I don't see the point with that. The use of the AIA extension
in CRL is not different for indirect or direct CRLs.

> Would you prepare a revison of the draft along these lines ?
> 

[Stefan] No, see above.

> If you agree, I woud propose that we discuss off-line with your
co-editor
> the details of the new draft and come back to the list when a new
draft is
> ready.
> 
> Denis
> 
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >
> >>-----Original Message-----
> >>From: [e-mail]
> >
> > [mailto:[e-mail]]
> >
> >>On Behalf Of Denis Pinkas
> >>Sent: den 10 februari 2005 17:44
> >>To: Stefan Santesson
> >>Cc: Russ Housley; pkix
> >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> >>
> >>
> >>Stefan,
> >>
> >>
> >>>Denis it looks like there are some misconceptions here:
> >>
> >>>Your scenario only applies to indirect CRLs.
> >>
> >>In X.509/ 3.3.32 indirect CRL (iCRL): A revocation list that at
least
> >>contains revocation information about certificates issued by
> >
> > authorities
> >
> >>other than that which issued this CRL.
> >>
> >>I already mentioned that this sentence is not crystal clear while
RFC
> >
> > 3280
> >
> >>states:
> >>
> >>    Whenever the CRL issuer is not the CA that issued the
> >
> > certificates,
> >
> >>    the CRL is referred to as an indirect CRL.
> >>
> >>  ... which is worse and would need to be corrected. However, this
is
> >
> > not
> >
> >>the main issue for this thread.
> >>
> >>Don't you mean the reverse ? i.e. you scenario applies to indirect
> >
> > CRLs
> >
> >>while mine does not apply to indirect CRL, but only when the CRL
only
> >>contains revocation information for certificates coming from one
> >
> > single CA
> >
> >>?
> >>
> >>Denis
> >>
> >>
> >>>For indirect CRLs both CDP
> >>>AND IDP MUST be present and at least 1 DP location/URL in CDP MUST
> >>
> > match
> >
> >>>at least one DP location/URL in IDP.
> >>>
> >>>This is already a requirement of both RFC 3280 and X.509.
> >>>
> >>><snip>
> >>>
> >>>>This leads to the following conclusion:
> >>>>
> >>>>  a) if the IDP is not present, then my scenario applies.
> >>>>  b) if the IDP is present, then your scenario applies.
> >>>
> >>>
> >>>Conclusion: a) never apply to this problem space.
> >>>
> >>>
> >>>Stefan Santesson
> >>>Microsoft Security Center of Excellence (SCOE)
> >>>
> >>>
> >>>
> >>>
> >>>>-----Original Message-----
> >>>>From: Denis Pinkas [mailto:[e-mail]]
> >>>>Sent: den 10 februari 2005 17:21
> >>>>To: Stefan Santesson
> >>>>Cc: Russ Housley; pkix
> >>>>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> >>>>
> >>>>Stefan,
> >>>>
> >>>>
> >>>>>I think this question is the key issue:
> >>>>
> >>>>><Snip>
> >>>>
> >>>>>>Can there be another rule which guarantes that there is no
> >>>>>
> >>>ambiguity
> >>>
> >>>
> >>>>>>about he right CRL issuer bearing the name contained in
> >>>>>
> > cRLIssuer
> >
> >>>?
> >>>
> >>>
> >>>>>>The answer is no, ... unless you demonstrate the contrary.
> >>>>>
> >>>>>>Note: remember that the CA cannot know in advanced which trust
> >>>>>>anchor(s) will be placed in the validation policies used by
> >>>>>
> >>>relying
> >>>
> >>>
> >>>>>>parties.
> >>>>>
> >>>>>>Denis
> >>>>>
> >>>>>If a relying party trust a rouge CA, then all bets are off. This
> >>>>
> > is
> >
> >>>>part
> >>>>
> >>>>>of the PKI fundamentals we have to accept. So the issue is to
> >>>>
> >>>prevent
> >>>
> >>>
> >>>>>matching of unrelated certs and CRLs from trusted issuers.
> >>>>
> >>>>>This is only a theoretically realistic threat if the CDP in the
> >>>>
> >>>cert
> >>>
> >>>
> >>>>>doesn't include any pointer/address to the CRL storage location
> >>>>
> >>>(which
> >>>
> >>>
> >>>>>should be considered really BAD practice).
> >>>>
> >>>>At this stage of explanations, the CRL pointer whether present or
> >>>
> >>>absent
> >>>
> >>>
> >>>>does not help. We  all know that it is possible to replace a CRL
by
> >>>>another
> >>>>one since it is never required to secure the protocol to query
CRLs.
> >>>
> >>>So an
> >>>
> >>>
> >>>>attacker having noticed that two CRL issuer names are the same,
> >>>
> > might
> >
> >>>>perform an active attack and exchange CRLs at will.
> >>>>
> >>>> > Storage location addresses
> >>>>
> >>>>>(which have to match between CDP and IDP if present) do have
> >>>>
> >>>sufficient
> >>>
> >>>
> >>>>>uniqueness characteristics to effectively mitigate accidental CA
> >>>>
> >>>name
> >>>
> >>>
> >>>>>collisions. In fact, there are ways to form CDP and IDP to
> >>>>
> >>>completely
> >>>
> >>>
> >>>>>eliminate this threat without imposing your requirement.
> >>>>
> >>>>Interresting. Your proposal would lead to the following:
> >>>>
> >>>>   1) both the CDP and the IDP MUST must be present,
> >>>>   2) then they must match.
> >>>>
> >>>> ... but the proposal would mandate the presence of the IDP.
> >>>>
> >>>>This leads to the following conclusion:
> >>>>
> >>>>  a) if the IDP is not present, then my scenario applies.
> >>>>  b) if the IDP is present, then your scenario applies.
> >>>>
> >>>>Both scenarios would then co-exist.
> >>>>
> >>>>If you can revise the main body of the draft along these lines,
then
> >>>
> >>>we
> >>>
> >>>
> >>>>may
> >>>>be close to an agreement.
> >>>>
> >>>>Then the second implication is : if the CRL issuer is under the
same
> >>>>trust anchor, it will be trusted, otherwise it might not unless
the
> >>>
> >>>other
> >>>
> >>>
> >>>>trust anchor is also present in the validation policy. So the
> >>>>recommandation
> >>>>to use the same trust anchor would be better explained this way in
> >>>
> > the
> >
> >>>>security considerations section.
> >>>>
> >>>>Denis
> >>>>
> >>>>
> >>>>>Yes - an extra level of security would be guaranteed if the rule
> >>>>
> >>>you
> >>>
> >>>
> >>>>>suggest would be imposed, but I think it is too late and too
> >>>>>restrictive. The threat is not material and realistic enough to
> >>>>
> >>>justify
> >>>
> >>>
> >>>>>a restriction that would declare perfectly secure current
> >>>>>implementations non-conformant.
> >>>>>
> >>>>>You are free to seek support for your position, but until you
> >>>>
> > have
> >
> >>>>>obtained rough consensus on your suggested limitation, the
> >>>>
> > crl-aia
> >
> >>>>>drafting process must assume that the limitation you suggest does
> >>>>
> >>>NOT
> >>>
> >>>
> >>>>>exist.
> >>>>>
> >>>>>
> >>>>>
> >>>>>Stefan Santesson
> >>>>>Microsoft Security Center of Excellence (SCOE)
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>>-----Original Message-----
> >>>>>>From: Denis Pinkas [mailto:[e-mail]]
> >>>>>>Sent: den 10 februari 2005 14:31
> >>>>>>To: Stefan Santesson
> >>>>>>Cc: Russ Housley; pkix
> >>>>>>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> >>>>>>
> >>>>>>Stefan,
> >>>>>>
> >>>>>>There is a major security issue here.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>Denis,
> >>>>>>>
> >>>>>>>It is obvious that you base your objections on the assumption
> >>>>>>
> > that
> >
> >>>a
> >>>
> >>>
> >>>>>CRL
> >>>>>
> >>>>>
> >>>>>>>issuer cert MUST be issued by the CA issuing the validated
> >>>>>>
> > subject
> >
> >>>>>cert.
> >>>>>
> >>>>>
> >>>>>>>But you also admit that this is what you think the stand should
> >>>>>>
> >>>say
> >>>
> >>>
> >>>>>but
> >>>>>
> >>>>>
> >>>>>>>do not say (at least not explicitly).
> >>>>>>>
> >>>>>>>Quote from your text: "This is not explicitly stated in RFC
3280
> >>>>>>
> >>>for
> >>>
> >>>
> >>>>>CRL
> >>>>>
> >>>>>
> >>>>>>>issuers, but it is for OCSP responders"
> >>>>>>>
> >>>>>>>I guess it will be useless to get into details before we have
> >>>>>>
> >>>sorted
> >>>
> >>>
> >>>>>out
> >>>>>
> >>>>>
> >>>>>>>this major cause of disagreement. But since even you admit that
> >>>>>>
> >>>>>there is
> >>>>>
> >>>>>
> >>>>>>>no such requirement in RFC 3280 (nor X.509), I'm not sure what
> >>>>>>
> >>>there
> >>>
> >>>
> >>>>>is
> >>>>>
> >>>>>
> >>>>>>>to discuss.
> >>>>>>
> >>>>>>The security considerations section needs to be discussed.
> >>>>>>
> >>>>>>The current text is:
> >>>>>>
> >>>>>>     Implementers should take into account the possible
> >>>>>
> > existence
> >
> >>>of
> >>>
> >>>
> >>>>>>     multiple unrelated CAs and CRL issuers with the same name.
> >>>>>
> >>>As
> >>>
> >>>
> >>>>>>     means of reducing problems and security issues related to
> >>>>>
> >>>issuer
> >>>
> >>>
> >>>>>>     name collisions, CA names SHOULD be formed in a way that
> >>>>>
> >>>reduce
> >>>
> >>>
> >>>>>the
> >>>>>
> >>>>>
> >>>>>>     likelihood of name collisions.
> >>>>>>
> >>>>>>The SHOULD in the previous sentence does not solve the problem,
> >>>>>
> >>>since
> >>>
> >>>
> >>>>>this
> >>>>>
> >>>>>
> >>>>>>cannot be prevented. The text should explain how to have a
secure
> >>>>>
> >>>>>system
> >>>>>
> >>>>>
> >>>>>>even in the case of a name collision, i.e. two CAs pick the same
> >>>>>
> >>>name
> >>>
> >>>
> >>>>>to
> >>>>>
> >>>>>
> >>>>>>designate a CRL issuer but that name now relates to two
different
> >>>>>>entities.
> >>>>>>
> >>>>>>     Implementations validating CRLs
> >>>>>>     MUST ensure that the certification path of the target
> >>>>>
> >>>>>certificate
> >>>>>
> >>>>>
> >>>>>>     and the CRL issuer certification path used to validate the
> >>>>>
> >>>>>target
> >>>>>
> >>>>>
> >>>>>>     certificate, terminate at the same trust anchor.
> >>>>>>
> >>>>>>This sentence does not solve the problem. The only way to solve
> >>>>>
> > the
> >
> >>>>>>problem
> >>>>>>is, for relying parties, to be able to know unambiguously which
> >>>>>
> > CA
> >
> >>>is
> >>>
> >>>
> >>>>>>allowed to certify the CRL issuer name. It cannot be "any CA" in
> >>>>>
> > a
> >
> >>>>>>certification tree.
> >>>>>>
> >>>>>>Since the syntax of the cRLIssuer contained in DistributionPoint
> >>>>>
> >>>does
> >>>
> >>>
> >>>>>not
> >>>>>
> >>>>>
> >>>>>>permit to place any other information than a name, it cannot
> >>>>>
> >>>designate
> >>>
> >>>
> >>>>>the
> >>>>>
> >>>>>
> >>>>>>CA allowed to certify the CRL issuer name, hence there needs to
> >>>>>
> > be
> >
> >>>a
> >>>
> >>>
> >>>>>fixed
> >>>>>
> >>>>>
> >>>>>>rule to be known by all relying parties.
> >>>>>>
> >>>>>>The fixed rule I proposed mimics the conditions of the OCSP
> >>>>>
> >>>responder,
> >>>
> >>>
> >>>>>>i.e.
> >>>>>>
> >>>>>> "The CRL Issuer must have a specially marked certificate issued
> >>>>>>  directly by the CA, indicating that the CRL issuer may issue
> >>>>>
> >>>CRLs".
> >>>
> >>>
> >>>>>>Can there be another rule which guarantes that there is no
> >>>>>
> >>>ambiguity
> >>>
> >>>
> >>>>>about
> >>>>>
> >>>>>
> >>>>>>the right CRL issuer bearing the name contained in cRLIssuer ?
> >>>>>
> > The
> >
> >>>>>answer
> >>>>>
> >>>>>
> >>>>>>is
> >>>>>>no, ... unless you demonstrate the contrary.
> >>>>>>
> >>>>>>Note: remember that the CA cannot know in advanced which trust
> >>>>>
> >>>>>anchor(s)
> >>>>>
> >>>>>
> >>>>>>will be placed in the validation policies used by relying
> >>>>>
> > parties.
> >
> >>>>>>Denis
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>
> >
> >
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1BCS6Ae050090; Fri, 11 Feb 2005 04:28:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1BCS6fA050088; Fri, 11 Feb 2005 04:28:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1BCS243050028 for <[e-mail]>; Fri, 11 Feb 2005 04:28:05 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j1BCRun15533; Fri, 11 Feb 2005 13:27:56 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Fri, 11 Feb 2005 13:27:57 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j1BCRuP01660; Fri, 11 Feb 2005 13:27:56 +0100 (MET)
Date: Fri, 11 Feb 2005 13:27:56 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Cc: [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis, 

It seems not only to me that you are trying to discuss a topic
which is out of scope for this document. 

This document describes how to put a pointer to a repository
at some particular place, not more. 
 
Assuming that you would have made some top
down search through a CA that issued 1000 sub cas etc, you
may end with something that has the required structure to
validate the CRL. It just takes you some more time.

Or, the AIA gives you a hint about what might be best to
test first, not more, not less? It is not really better
or worse than a SIA, or an implicit directory name, or
whatever.

Whether this list of certs that you obtain validates 
according to the same trust anchor is a problem that exists 
independantly of how you obtained the cert (path) that signed a 
crl, you are describing this as

 "it is never required to secure the protocol to query CRLs"

Do you want this in the security section:

   The "pointer" obtained from the AIA extension and the resulting
   certificates do not indicate anything about the validity of the
   CRL. Thus, the same techniques to validate the CRL must
   be applied independantly how the information (i.e. a list
   of potentially validating certs) is obtained.

You MAY say that this URI is not sufficient so a valid CRL cannot be
determined at all by starting at that point and limiting the search
in an inappropriate way. 

I may have overlooked something, in this case TIA for teaching :-)

Peter 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1BC4OCl042524; Fri, 11 Feb 2005 04:04:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1BC4OFT042523; Fri, 11 Feb 2005 04:04:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1BC4MRP042446 for <[e-mail]>; Fri, 11 Feb 2005 04:04:23 -0800 (PST) (envelope-from [e-mail])
Received: from smtp3.tcd.ie (smtp3.tcd.ie [134.226.1.158]) by smtp3.tcd.ie (Postfix) with ESMTP id E4F2514C041 for <[e-mail]>; Fri, 11 Feb 2005 12:04:04 +0000 (GMT)
Received: from smtp3.tcd.ie by localhost.localdomain (VaMailArmor-2.0.1.16) id 09767-5A409AA9; Fri, 11 Feb 2005 12:04:04 +0000
Received: from [134.226.145.79] (mme145079.mme.tcd.ie [134.226.145.79]) by smtp3.tcd.ie (Postfix) with ESMTP id C1ACC14C041 for <[e-mail]>; Fri, 11 Feb 2005 12:04:04 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 12:05:15 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-pkixrep-03.txt
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiVirus: checked by Vexira MailArmor (version: 2.0.1.16; VAE: 6.29.0.7; VDF: 6.29.0.101; host: smtp3.tcd.ie)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

First time I've read this one (mea culpa).

How'd you like to add "_XKMS" as another variant to this? Otherwise
the "_HTTP" option is somewhat ambiguous.

Cheers,
Stephen.

[e-mail] wrote:

> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 	Title		: Internet X.509 Public Key Infrastructure Repository Locator Service
> 	Author(s)	: S. Boeyen, P. Hallam-Baker
> 	Filename	: draft-ietf-pkix-pkixrep-03.txt
> 	Pages		: 4
> 	Date		: 2005-2-10
> 	
> This document defines a PKI repository locator service. The service
> makes use of DNS SRV records defined in accordance with RFC 2782. The
> service enables certificate using systems to locate PKI repositories 
> based on a domain name, identify the protocols that can be used to 
> access the repository, and obtain addresses for the servers that host 
> the repository service.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkixrep-03.txt
> 
> To remove yourself from the I-D Announcement list, send a message to 
> [e-mail] with the word unsubscribe in the body of the message.  
> You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
> to change your subscription settings.
> 
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-pkix-pkixrep-03.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
> 	[e-mail].
> In the body type:
> 	"FILE /internet-drafts/draft-ietf-pkix-pkixrep-03.txt".
> 	
> NOTE:	The mail server at ietf.org can return the document in
> 	MIME-encoded form by using the "mpack" utility.  To use this
> 	feature, insert the command "ENCODING mime" before the "FILE"
> 	command.  To decode the response(s), you will need "munpack" or
> 	a MIME-compliant mail reader.  Different MIME-compliant mail readers
> 	exhibit different behavior, especially when dealing with
> 	"multipart" MIME messages (i.e. documents which have been split
> 	up into multiple messages), so check your local documentation on
> 	how to manipulate these messages.
> 		
> 		
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1BAXe6d010568; Fri, 11 Feb 2005 02:33:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1BAXe0o010567; Fri, 11 Feb 2005 02:33:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1BAXac8010502 for <[e-mail]>; Fri, 11 Feb 2005 02:33:37 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA48986; Fri, 11 Feb 2005 11:46:52 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021111331764:1643 ; Fri, 11 Feb 2005 11:33:17 +0100 
Message-ID: <[e-mail]>
Date: Fri, 11 Feb 2005 11:33:16 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Russ Housley <[e-mail]>, pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/02/2005 11:33:17, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 11/02/2005 11:33:19, Serialize complete at 11/02/2005 11:33:19
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

> Denis,
> 
> Sorry for being unclear, and maybe for not seeing what you try to say.
> 
> What I meant was that the problem should not exist at all for
> non-indirect CRLs. Here I totally agree that the CRL and the CA can't
> have unrelated chaining. I'm not sure what the standard says about this
> but if this is unclear, then it should be made clear.
> 
> What I further mean is that the existence of diversified cert and CRL
> paths is therefore only an issue for indirect CRLs, AND for indirect
> CRLs CDP and IDP matching IS a requirement.
> 
> The conclusion I make is: The current text in the crl-aia draft is
> correct since diversified CRL and cert paths may exist where the CRL
> issuer cert is issued by someone else that the CA that issued the
> validated cert.

The problem is that neither the abstract nor the introduction of this draft 
is limiting the scope to indirect CRLs only.

The point is that a relying party cannot know in advance whether indirect 
CRLs or "direct CRLs" are being used. So the story starts when the relying 
party gets a "candidate CRL" from the CRL DP and then it can see whether it 
contains or not an IDP.

The draft should thus address the two scenarios (i.e. an IDP is or is not 
present) and for direct CRLs there is no "superiority" of the new extension.

Would you prepare a revison of the draft along these lines ?

If you agree, I woud propose that we discuss off-line with your co-editor 
the details of the new draft and come back to the list when a new draft is 
ready.

Denis

> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of Denis Pinkas
>>Sent: den 10 februari 2005 17:44
>>To: Stefan Santesson
>>Cc: Russ Housley; pkix
>>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
>>
>>
>>Stefan,
>>
>>
>>>Denis it looks like there are some misconceptions here:
>>
>>>Your scenario only applies to indirect CRLs.
>>
>>In X.509/ 3.3.32 indirect CRL (iCRL): A revocation list that at least
>>contains revocation information about certificates issued by
> 
> authorities
> 
>>other than that which issued this CRL.
>>
>>I already mentioned that this sentence is not crystal clear while RFC
> 
> 3280
> 
>>states:
>>
>>    Whenever the CRL issuer is not the CA that issued the
> 
> certificates,
> 
>>    the CRL is referred to as an indirect CRL.
>>
>>  ... which is worse and would need to be corrected. However, this is
> 
> not
> 
>>the main issue for this thread.
>>
>>Don't you mean the reverse ? i.e. you scenario applies to indirect
> 
> CRLs
> 
>>while mine does not apply to indirect CRL, but only when the CRL only
>>contains revocation information for certificates coming from one
> 
> single CA
> 
>>?
>>
>>Denis
>>
>>
>>>For indirect CRLs both CDP
>>>AND IDP MUST be present and at least 1 DP location/URL in CDP MUST
>>
> match
> 
>>>at least one DP location/URL in IDP.
>>>
>>>This is already a requirement of both RFC 3280 and X.509.
>>>
>>><snip>
>>>
>>>>This leads to the following conclusion:
>>>>
>>>>  a) if the IDP is not present, then my scenario applies.
>>>>  b) if the IDP is present, then your scenario applies.
>>>
>>>
>>>Conclusion: a) never apply to this problem space.
>>>
>>>
>>>Stefan Santesson
>>>Microsoft Security Center of Excellence (SCOE)
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>Sent: den 10 februari 2005 17:21
>>>>To: Stefan Santesson
>>>>Cc: Russ Housley; pkix
>>>>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
>>>>
>>>>Stefan,
>>>>
>>>>
>>>>>I think this question is the key issue:
>>>>
>>>>><Snip>
>>>>
>>>>>>Can there be another rule which guarantes that there is no
>>>>>
>>>ambiguity
>>>
>>>
>>>>>>about he right CRL issuer bearing the name contained in
>>>>>
> cRLIssuer
> 
>>>?
>>>
>>>
>>>>>>The answer is no, ... unless you demonstrate the contrary.
>>>>>
>>>>>>Note: remember that the CA cannot know in advanced which trust
>>>>>>anchor(s) will be placed in the validation policies used by
>>>>>
>>>relying
>>>
>>>
>>>>>>parties.
>>>>>
>>>>>>Denis
>>>>>
>>>>>If a relying party trust a rouge CA, then all bets are off. This
>>>>
> is
> 
>>>>part
>>>>
>>>>>of the PKI fundamentals we have to accept. So the issue is to
>>>>
>>>prevent
>>>
>>>
>>>>>matching of unrelated certs and CRLs from trusted issuers.
>>>>
>>>>>This is only a theoretically realistic threat if the CDP in the
>>>>
>>>cert
>>>
>>>
>>>>>doesn't include any pointer/address to the CRL storage location
>>>>
>>>(which
>>>
>>>
>>>>>should be considered really BAD practice).
>>>>
>>>>At this stage of explanations, the CRL pointer whether present or
>>>
>>>absent
>>>
>>>
>>>>does not help. We  all know that it is possible to replace a CRL by
>>>>another
>>>>one since it is never required to secure the protocol to query CRLs.
>>>
>>>So an
>>>
>>>
>>>>attacker having noticed that two CRL issuer names are the same,
>>>
> might
> 
>>>>perform an active attack and exchange CRLs at will.
>>>>
>>>> > Storage location addresses
>>>>
>>>>>(which have to match between CDP and IDP if present) do have
>>>>
>>>sufficient
>>>
>>>
>>>>>uniqueness characteristics to effectively mitigate accidental CA
>>>>
>>>name
>>>
>>>
>>>>>collisions. In fact, there are ways to form CDP and IDP to
>>>>
>>>completely
>>>
>>>
>>>>>eliminate this threat without imposing your requirement.
>>>>
>>>>Interresting. Your proposal would lead to the following:
>>>>
>>>>   1) both the CDP and the IDP MUST must be present,
>>>>   2) then they must match.
>>>>
>>>> ... but the proposal would mandate the presence of the IDP.
>>>>
>>>>This leads to the following conclusion:
>>>>
>>>>  a) if the IDP is not present, then my scenario applies.
>>>>  b) if the IDP is present, then your scenario applies.
>>>>
>>>>Both scenarios would then co-exist.
>>>>
>>>>If you can revise the main body of the draft along these lines, then
>>>
>>>we
>>>
>>>
>>>>may
>>>>be close to an agreement.
>>>>
>>>>Then the second implication is : if the CRL issuer is under the same
>>>>trust anchor, it will be trusted, otherwise it might not unless the
>>>
>>>other
>>>
>>>
>>>>trust anchor is also present in the validation policy. So the
>>>>recommandation
>>>>to use the same trust anchor would be better explained this way in
>>>
> the
> 
>>>>security considerations section.
>>>>
>>>>Denis
>>>>
>>>>
>>>>>Yes - an extra level of security would be guaranteed if the rule
>>>>
>>>you
>>>
>>>
>>>>>suggest would be imposed, but I think it is too late and too
>>>>>restrictive. The threat is not material and realistic enough to
>>>>
>>>justify
>>>
>>>
>>>>>a restriction that would declare perfectly secure current
>>>>>implementations non-conformant.
>>>>>
>>>>>You are free to seek support for your position, but until you
>>>>
> have
> 
>>>>>obtained rough consensus on your suggested limitation, the
>>>>
> crl-aia
> 
>>>>>drafting process must assume that the limitation you suggest does
>>>>
>>>NOT
>>>
>>>
>>>>>exist.
>>>>>
>>>>>
>>>>>
>>>>>Stefan Santesson
>>>>>Microsoft Security Center of Excellence (SCOE)
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>>-----Original Message-----
>>>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>>>Sent: den 10 februari 2005 14:31
>>>>>>To: Stefan Santesson
>>>>>>Cc: Russ Housley; pkix
>>>>>>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
>>>>>>
>>>>>>Stefan,
>>>>>>
>>>>>>There is a major security issue here.
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Denis,
>>>>>>>
>>>>>>>It is obvious that you base your objections on the assumption
>>>>>>
> that
> 
>>>a
>>>
>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>>>issuer cert MUST be issued by the CA issuing the validated
>>>>>>
> subject
> 
>>>>>cert.
>>>>>
>>>>>
>>>>>>>But you also admit that this is what you think the stand should
>>>>>>
>>>say
>>>
>>>
>>>>>but
>>>>>
>>>>>
>>>>>>>do not say (at least not explicitly).
>>>>>>>
>>>>>>>Quote from your text: "This is not explicitly stated in RFC 3280
>>>>>>
>>>for
>>>
>>>
>>>>>CRL
>>>>>
>>>>>
>>>>>>>issuers, but it is for OCSP responders"
>>>>>>>
>>>>>>>I guess it will be useless to get into details before we have
>>>>>>
>>>sorted
>>>
>>>
>>>>>out
>>>>>
>>>>>
>>>>>>>this major cause of disagreement. But since even you admit that
>>>>>>
>>>>>there is
>>>>>
>>>>>
>>>>>>>no such requirement in RFC 3280 (nor X.509), I'm not sure what
>>>>>>
>>>there
>>>
>>>
>>>>>is
>>>>>
>>>>>
>>>>>>>to discuss.
>>>>>>
>>>>>>The security considerations section needs to be discussed.
>>>>>>
>>>>>>The current text is:
>>>>>>
>>>>>>     Implementers should take into account the possible
>>>>>
> existence
> 
>>>of
>>>
>>>
>>>>>>     multiple unrelated CAs and CRL issuers with the same name.
>>>>>
>>>As
>>>
>>>
>>>>>>     means of reducing problems and security issues related to
>>>>>
>>>issuer
>>>
>>>
>>>>>>     name collisions, CA names SHOULD be formed in a way that
>>>>>
>>>reduce
>>>
>>>
>>>>>the
>>>>>
>>>>>
>>>>>>     likelihood of name collisions.
>>>>>>
>>>>>>The SHOULD in the previous sentence does not solve the problem,
>>>>>
>>>since
>>>
>>>
>>>>>this
>>>>>
>>>>>
>>>>>>cannot be prevented. The text should explain how to have a secure
>>>>>
>>>>>system
>>>>>
>>>>>
>>>>>>even in the case of a name collision, i.e. two CAs pick the same
>>>>>
>>>name
>>>
>>>
>>>>>to
>>>>>
>>>>>
>>>>>>designate a CRL issuer but that name now relates to two different
>>>>>>entities.
>>>>>>
>>>>>>     Implementations validating CRLs
>>>>>>     MUST ensure that the certification path of the target
>>>>>
>>>>>certificate
>>>>>
>>>>>
>>>>>>     and the CRL issuer certification path used to validate the
>>>>>
>>>>>target
>>>>>
>>>>>
>>>>>>     certificate, terminate at the same trust anchor.
>>>>>>
>>>>>>This sentence does not solve the problem. The only way to solve
>>>>>
> the
> 
>>>>>>problem
>>>>>>is, for relying parties, to be able to know unambiguously which
>>>>>
> CA
> 
>>>is
>>>
>>>
>>>>>>allowed to certify the CRL issuer name. It cannot be "any CA" in
>>>>>
> a
> 
>>>>>>certification tree.
>>>>>>
>>>>>>Since the syntax of the cRLIssuer contained in DistributionPoint
>>>>>
>>>does
>>>
>>>
>>>>>not
>>>>>
>>>>>
>>>>>>permit to place any other information than a name, it cannot
>>>>>
>>>designate
>>>
>>>
>>>>>the
>>>>>
>>>>>
>>>>>>CA allowed to certify the CRL issuer name, hence there needs to
>>>>>
> be
> 
>>>a
>>>
>>>
>>>>>fixed
>>>>>
>>>>>
>>>>>>rule to be known by all relying parties.
>>>>>>
>>>>>>The fixed rule I proposed mimics the conditions of the OCSP
>>>>>
>>>responder,
>>>
>>>
>>>>>>i.e.
>>>>>>
>>>>>> "The CRL Issuer must have a specially marked certificate issued
>>>>>>  directly by the CA, indicating that the CRL issuer may issue
>>>>>
>>>CRLs".
>>>
>>>
>>>>>>Can there be another rule which guarantes that there is no
>>>>>
>>>ambiguity
>>>
>>>
>>>>>about
>>>>>
>>>>>
>>>>>>the right CRL issuer bearing the name contained in cRLIssuer ?
>>>>>
> The
> 
>>>>>answer
>>>>>
>>>>>
>>>>>>is
>>>>>>no, ... unless you demonstrate the contrary.
>>>>>>
>>>>>>Note: remember that the CA cannot know in advanced which trust
>>>>>
>>>>>anchor(s)
>>>>>
>>>>>
>>>>>>will be placed in the validation policies used by relying
>>>>>
> parties.
> 
>>>>>>Denis
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1B9QDsH086112; Fri, 11 Feb 2005 01:26:13 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1B9QDtR086111; Fri, 11 Feb 2005 01:26:13 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1B9Q4WO086055 for <[e-mail]>; Fri, 11 Feb 2005 01:26:08 -0800 (PST) (envelope-from [e-mail])
Received: from romans (unknown [207.202.179.27]) by smtp2.pacifier.net (Postfix) with ESMTP id 6D1E975B29; Fri, 11 Feb 2005 01:25:58 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Sharon Boeyen'" <[e-mail]>
Cc: "'IETF-PKIX'" <[e-mail]>
Subject: RE: Draft-ietf-pkix-rfc2511bis-07
Date: Fri, 11 Feb 2005 01:36:01 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01C50FDA.0CB4F480"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
Thread-Index: AcUOxTYq5CsGRJhUTxivhI5PuudQqwBU8v+g
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_004E_01C50FDA.0CB4F480
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Sharon,
 
My problem on the timing of getting remarks in -- since we haven't started
last call and I have some comments that required an update to the document
anyway.
 
1.  I will define a new OID for this.  My assumption is that the old one
should be obsoleted as this change was made by the original authors of the
draft, I assume in response to interop changes and replaced with the new
UTF8String regInfo item.
 
2.  I would disagree with the statement that since EncryptedValue is used in
existing products it should not be deprecated, however I am willing to be
convinced that we need to keep it.  I deprecated the use of the structure
for the following reasons:
 
a) There is no identification in the structure as to what public key was
used to encrypt the symmetric key.  This means that servers must guess as to
which private key is used in the decryption operation (or try multiple
keys).
 
b) There is no method of changing the structure to be encrypted, but for the
reasons covered at the start of section 4.2.1 I did just that in this
document.  The document does not allow for the encryption of just the
PrivateKeyInfo structure anymore.
 
c) The content within the EncryptedValue structure was context sensitive,
but not tagged as to actual content.  It might be either a certificate or a
private key.
 
d) It is not possible to do encryption with key agreement keys given the
lack of location to place the sender public key or to identify where it came
from.
 
e) It is currently necessary to implement both EncryptedValue and
EnvelopedData to implement the spec.  This would tend to violate the edict
from the chairs that we should avoid, when possible, having two different
ways of accomplishing the same thing.
 
f) The structure valueHint is under defined if it is to be meaningfully
used.
 
The only marginal advantage that I see is that EncryptedValue uses bit
strings rather than octet strings to wrap the data, but as they are almost
always in 8 byte quantities with all of the common algorithms in use this
seems to be of dubious benefit.
 
I am not sure what indendedAlg was actually suppose to be used for.  This
seems to be duplicate information with the algorithm identifier associated
with the public key in the certificate request, although I suppose the first
could be rsa-oaep and the latter rsa-enc.
 
jim



  _____  

From: [e-mail] [mailto:[e-mail]] On
Behalf Of Sharon Boeyen
Sent: Wednesday, February 09, 2005 7:58 AM
To: 'Stephen Kent'; [e-mail]
Cc: IETF-PKIX
Subject: RE: Draft-ietf-pkix-rfc2511bis-07



Jim, sorry for the delay in responding. I have 2 comments: 

1) The new document completely changes the meaning of an Object Identifer
(changing the name as well as the syntax). In the original RFC (see page
11), the OID was defined as follows:


id-regInfo-asciiPairs  OBJECT IDENTIFIER  ::= {id-regInfo 1} --with syntax
OCTET STRING 
(however in Appendix B they call this id-regInfo-utf8Pairs with a syntax of
OCTET STRING, so there was some confusion even back then)


In the new RFC it changes to: 
  
id-regInfo-utf8Pairs  OBJECT IDENTIFIER  ::= {id-regInfo 1} --with syntax
UTF8String (see section 7.1. 
  
OIDs cannot be redefined like this.  I suggest you leave the old OID as is
and define a new one for UTF8 String. 

2) The use of the EncryptedValue structure has been deprecated. This is one
of the two choices for conveying an encrypted key in the archive options
control that would appear in the controls element of the cert request. The
other choice is envelopedData. EncryptedValue is in use in existing products
and therefore should not be deprecated.

Cheers, 
Sharon 

-----Original Message----- 
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent 
Sent: Friday, January 07, 2005 4:04 PM 
To: [e-mail] 
Cc: IETF-PKIX 
Subject: Re: Draft-ietf-pkix-rfc2511bis-07 



Folks, 

Jim sent this message in mid-December and I have seen no response on 
the list, so far.  if nobody responds to Jim, Tim and I will 
interpret this as implicit authorization for Jim to proceed as he see 
fit on this topics. 

Steve 


>As advertized this draft is now under new editorship.  As the new 
>editor there are a number of issues that I fill still need to be 
>resolved before this draft can go to last call.  If there is no help 
>forth coming then I will be making arbitrary decions on these issue. 
> 
>Additionally, if anyone has kept any of the final reports from the 
>interop trials for CMP, I would like to see the sections that relate to 
>CRMF. 
> 
>You can easily find the open issues and questions by searching for [[[ 
>in the document. 
> 
>1.  Section 4.1 - I have a partial answer for this question dealing 
>with non DN style names that are authenticated, but are not actually 
>either subject names (DNs) or subject alt names (General Names).  The 
>only real question at this point is should this rational be documented. 
> 
>2.  Section 4.2 - I am worried about the possiblity of somebody copying 
>an encrypted private key being sent to the CA/RA and then copying it 
>into their own certificate request.  They could then later request a 
>key recovery from the CA/RA and get back somebody elses private key.  
>This is the reason that I am worried about how a POP proof is done 
>here.  One potential answer is to include the authenticated identity 
>along with the private key in the encrypted block. 
> 
>3.  Section 4.2 - We MUST solve the question of what the contents of 
>the encrypted blob look like.  One potential answer is to obsolete 
>thisMessage and reaplace it with an EnvelopedData then all that needs 
>to be covered is the format of the encrypted key plus any POP info 
>required. 
> 
>4.  Section 4.3 - Does the DH section need to be expanded so that any 
>key agreement key pair can be used?  This can be done by adding a MAC 
>alg and value pair to the end of the POPOPrivKey choice (and 
>potentially obsoleting the dhMAC element). 
> 
>5.  Section 4.4 - Two questions regarding guidence for the number of 
>iterations and the amount of salt to be used.  We need a cryptographer 
>to give us some guidelines for these details, or atleast need to set 
>some minimums. 
> 
>6.  Section 6.1 & 6.2 - The content of these controls is not well 
>defined and a couple of questions regarding this are asked.  This may 
>have been addressed in the interop by adding some undocumented 
>restrictions. 
> 
>7.  Section 6.4 - There are a couple of archive questions here.  At 
>this point my inclination is to kill the entire section unless somebody 
>wants to make it acutally work. 
> 
>8.  Section 6.8 - Ditto here. 
> 
>9.  Section 7.1 - Consider the string "Tokens?%30%FA%F3?9%"   The parsing
is 
>difficult (but not impossible) due to the overload of the % token. 
> 
>Jim 


------=_NextPart_000_004E_01C50FDA.0CB4F480
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: Draft-ietf-pkix-rfc2511bis-07</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2604" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005>Sharon,</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005>My problem on the timing of getting remarks =
in -- since=20
we haven't started last call and I have some comments that required an =
update to=20
the document anyway.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005>1.&nbsp; I will define a new OID for =
this.&nbsp; My=20
assumption is that the old one should be obsoleted as this change was =
made by=20
the original authors of the draft, I assume in response to interop =
changes and=20
replaced with the new UTF8String regInfo item.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005>2.&nbsp; I would disagree with the statement =
that since=20
EncryptedValue is used in existing products it should not be deprecated, =
however=20
I am willing to be convinced that we need to keep it.&nbsp; I deprecated =
the use=20
of the structure for the following reasons:</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005>a) There is no identification in the =
structure as to=20
what public key was used to encrypt the symmetric key.&nbsp; This means =
that=20
servers must guess as to which private key is used in the decryption =
operation=20
(or try multiple keys).</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005>b) There is no method of changing the =
structure to be=20
encrypted, but for the reasons covered at the start of section 4.2.1 I =
did just=20
that in this document.&nbsp; The document does not allow for the =
encryption of=20
just the PrivateKeyInfo structure anymore.</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff =
size=3D2><SPAN=20
class=3D666440609-11022005>c) The content within the EncryptedValue =
structure was=20
context sensitive, but not tagged as to actual content.&nbsp; It might =
be either=20
a certificate or a private key.</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><SPAN class=3D666440609-11022005></SPAN><FONT face=3DArial><FONT=20
color=3D#0000ff><FONT size=3D2>d<SPAN class=3D666440609-11022005>) It is =
not possible=20
to do encryption with key agreement keys given the lack of location to =
place the=20
sender public key or to identify where it came=20
from.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D666440609-11022005></SPAN></FONT></FONT></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><FONT color=3D#0000ff><FONT size=3D2><SPAN=20
class=3D666440609-11022005>e) It is currently necessary to implement =
both=20
EncryptedValue and EnvelopedData to implement the spec.&nbsp; This would =
tend to=20
violate the edict from the chairs that we should avoid, when possible, =
having=20
two different ways of accomplishing the same=20
thing.</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D666440609-11022005><FONT face=3DArial color=3D#0000ff =
size=3D2>f) The=20
structure valueHint is under defined if it is to be meaningfully=20
used.</FONT></SPAN></DIV>
<DIV><SPAN class=3D666440609-11022005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D666440609-11022005><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
only marginal advantage that I see is that EncryptedValue uses bit =
strings=20
rather than octet strings to wrap the data, but as they are almost =
always in 8=20
byte quantities with all of the common algorithms in use this seems to =
be of=20
dubious benefit.</FONT></SPAN></DIV>
<DIV><SPAN class=3D666440609-11022005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D666440609-11022005><FONT face=3DArial color=3D#0000ff =
size=3D2>I am=20
not sure what indendedAlg was actually suppose to be used for.&nbsp; =
This seems=20
to be duplicate information with the algorithm identifier associated =
with the=20
public key in the certificate request, although I suppose the first =
could be=20
rsa-oaep and the latter rsa-enc.</FONT></SPAN></DIV>
<DIV><SPAN class=3D666440609-11022005><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D666440609-11022005><FONT face=3DArial color=3D#0000ff =

size=3D2>jim</FONT></SPAN></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT><BR></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> [e-mail] =

  [mailto:[e-mail]] <B>On Behalf Of </B>Sharon=20
  Boeyen<BR><B>Sent:</B> Wednesday, February 09, 2005 7:58 =
AM<BR><B>To:</B>=20
  'Stephen Kent'; [e-mail]<BR><B>Cc:</B> =
IETF-PKIX<BR><B>Subject:</B>=20
  RE: Draft-ietf-pkix-rfc2511bis-07<BR></FONT><BR></DIV>
  <DIV></DIV>
  <P><FONT size=3D2>Jim, sorry for the delay in responding. I have 2=20
  comments:</FONT> </P>
  <P><FONT size=3D2>1) The new document completely changes the meaning =
of an=20
  Object Identifer (changing the name as well as the syntax). In the =
original=20
  RFC (see page 11), the OID was defined as follows:</FONT></P>
  <P><FONT size=3D2></FONT> <BR><FONT =
size=3D2>id-regInfo-asciiPairs&nbsp; OBJECT=20
  IDENTIFIER&nbsp; ::=3D {id-regInfo 1} --with syntax OCTET =
STRING</FONT>=20
  <BR><FONT size=3D2>(however in Appendix B they call this =
id-regInfo-utf8Pairs=20
  with a syntax of OCTET STRING, so there was some confusion even back=20
  then)</FONT></P>
  <P><FONT size=3D2></FONT> <BR><FONT size=3D2>In the new RFC it changes =
to:</FONT>=20
  <BR><FONT size=3D2>&nbsp;</FONT> <BR><FONT =
size=3D2>id-regInfo-utf8Pairs&nbsp;=20
  OBJECT IDENTIFIER&nbsp; ::=3D {id-regInfo 1} --with syntax UTF8String =
(see=20
  section 7.1.</FONT> <BR><FONT size=3D2>&nbsp;</FONT> <BR><FONT =
size=3D2>OIDs=20
  cannot be redefined like this.&nbsp; I suggest you leave the old OID =
as is and=20
  define a new one for UTF8 String. </FONT></P>
  <P><FONT size=3D2>2) The use of the EncryptedValue structure has been=20
  deprecated. This is one of the two choices for conveying an encrypted =
key in=20
  the archive options control that would appear in the controls element =
of the=20
  cert request. The other choice is envelopedData. EncryptedValue is in =
use in=20
  existing products and therefore should not be deprecated.</FONT></P>
  <P><FONT size=3D2>Cheers,</FONT> <BR><FONT size=3D2>Sharon </FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  [e-mail] [<A=20
  =
href=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail.=
imc.org</A>]=20
  On Behalf Of Stephen Kent</FONT> <BR><FONT size=3D2>Sent: Friday, =
January 07,=20
  2005 4:04 PM</FONT> <BR><FONT size=3D2>To: [e-mail]</FONT> =
<BR><FONT=20
  size=3D2>Cc: IETF-PKIX</FONT> <BR><FONT size=3D2>Subject: Re:=20
  Draft-ietf-pkix-rfc2511bis-07</FONT> </P><BR><BR>
  <P><FONT size=3D2>Folks,</FONT> </P>
  <P><FONT size=3D2>Jim sent this message in mid-December and I have =
seen no=20
  response on </FONT><BR><FONT size=3D2>the list, so far.&nbsp; if =
nobody responds=20
  to Jim, Tim and I will </FONT><BR><FONT size=3D2>interpret this as =
implicit=20
  authorization for Jim to proceed as he see </FONT><BR><FONT =
size=3D2>fit on this=20
  topics.</FONT> </P>
  <P><FONT size=3D2>Steve</FONT> </P><BR>
  <P><FONT size=3D2>&gt;As advertized this draft is now under new=20
  editorship.&nbsp; As the new </FONT><BR><FONT size=3D2>&gt;editor =
there are a=20
  number of issues that I fill still need to be </FONT><BR><FONT=20
  size=3D2>&gt;resolved before this draft can go to last call.&nbsp; If =
there is=20
  no help </FONT><BR><FONT size=3D2>&gt;forth coming then I will be =
making=20
  arbitrary decions on these issue.</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
  <BR><FONT size=3D2>&gt;Additionally, if anyone has kept any of the =
final reports=20
  from the </FONT><BR><FONT size=3D2>&gt;interop trials for CMP, I would =
like to=20
  see the sections that relate to </FONT><BR><FONT =
size=3D2>&gt;CRMF.</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;You can easily =
find the open=20
  issues and questions by searching for [[[ </FONT><BR><FONT =
size=3D2>&gt;in the=20
  document.</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;1.&nbsp;=20
  Section 4.1 - I have a partial answer for this question dealing=20
  </FONT><BR><FONT size=3D2>&gt;with non DN style names that are =
authenticated,=20
  but are not actually </FONT><BR><FONT size=3D2>&gt;either subject =
names (DNs) or=20
  subject alt names (General Names).&nbsp; The </FONT><BR><FONT =
size=3D2>&gt;only=20
  real question at this point is should this rational be =
documented.</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;2.&nbsp; Section =
4.2 - I am=20
  worried about the possiblity of somebody copying </FONT><BR><FONT=20
  size=3D2>&gt;an encrypted private key being sent to the CA/RA and then =
copying=20
  it </FONT><BR><FONT size=3D2>&gt;into their own certificate =
request.&nbsp; They=20
  could then later request a </FONT><BR><FONT size=3D2>&gt;key recovery =
from the=20
  CA/RA and get back somebody elses private key.&nbsp; </FONT><BR><FONT=20
  size=3D2>&gt;This is the reason that I am worried about how a POP =
proof is done=20
  </FONT><BR><FONT size=3D2>&gt;here.&nbsp; One potential answer is to =
include the=20
  authenticated identity </FONT><BR><FONT size=3D2>&gt;along with the =
private key=20
  in the encrypted block.</FONT> <BR><FONT size=3D2>&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt;3.&nbsp; Section 4.2 - We MUST solve the question of what =
the=20
  contents of </FONT><BR><FONT size=3D2>&gt;the encrypted blob look =
like.&nbsp;=20
  One potential answer is to obsolete </FONT><BR><FONT =
size=3D2>&gt;thisMessage=20
  and reaplace it with an EnvelopedData then all that needs =
</FONT><BR><FONT=20
  size=3D2>&gt;to be covered is the format of the encrypted key plus any =
POP info=20
  </FONT><BR><FONT size=3D2>&gt;required.</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
  <BR><FONT size=3D2>&gt;4.&nbsp; Section 4.3 - Does the DH section need =
to be=20
  expanded so that any </FONT><BR><FONT size=3D2>&gt;key agreement key =
pair can be=20
  used?&nbsp; This can be done by adding a MAC </FONT><BR><FONT =
size=3D2>&gt;alg=20
  and value pair to the end of the POPOPrivKey choice (and =
</FONT><BR><FONT=20
  size=3D2>&gt;potentially obsoleting the dhMAC element).</FONT> =
<BR><FONT=20
  size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;5.&nbsp; Section 4.4 - Two =
questions=20
  regarding guidence for the number of </FONT><BR><FONT =
size=3D2>&gt;iterations=20
  and the amount of salt to be used.&nbsp; We need a cryptographer=20
  </FONT><BR><FONT size=3D2>&gt;to give us some guidelines for these =
details, or=20
  atleast need to set </FONT><BR><FONT size=3D2>&gt;some =
minimums.</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;6.&nbsp; Section =
6.1 &amp;=20
  6.2 - The content of these controls is not well </FONT><BR><FONT=20
  size=3D2>&gt;defined and a couple of questions regarding this are =
asked.&nbsp;=20
  This may </FONT><BR><FONT size=3D2>&gt;have been addressed in the =
interop by=20
  adding some undocumented </FONT><BR><FONT =
size=3D2>&gt;restrictions.</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;7.&nbsp; Section =
6.4 - There=20
  are a couple of archive questions here.&nbsp; At </FONT><BR><FONT=20
  size=3D2>&gt;this point my inclination is to kill the entire section =
unless=20
  somebody </FONT><BR><FONT size=3D2>&gt;wants to make it acutally =
work.</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> <BR><FONT size=3D2>&gt;8.&nbsp; Section =
6.8 - Ditto=20
  here.</FONT> <BR><FONT size=3D2>&gt;</FONT> <BR><FONT =
size=3D2>&gt;9.&nbsp;=20
  Section 7.1 - Consider the string "Tokens?%30%FA%F3?9%"&nbsp;&nbsp; =
The=20
  parsing is</FONT> <BR><FONT size=3D2>&gt;difficult (but not =
impossible) due to=20
  the overload of the % token.</FONT> <BR><FONT size=3D2>&gt;</FONT> =
<BR><FONT=20
  size=3D2>&gt;Jim</FONT> </P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_004E_01C50FDA.0CB4F480--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AKqQuQ077350; Thu, 10 Feb 2005 12:52:26 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1AKqQLe077349; Thu, 10 Feb 2005 12:52:26 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AKqOLB077322 for <[e-mail]>; Thu, 10 Feb 2005 12:52:24 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06315; Thu, 10 Feb 2005 15:52:21 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-pkixrep-03.txt
Date: Thu, 10 Feb 2005 15:52:21 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Internet X.509 Public Key Infrastructure Repository Locator Service
	Author(s)	: S. Boeyen, P. Hallam-Baker
	Filename	: draft-ietf-pkix-pkixrep-03.txt
	Pages		: 4
	Date		: 2005-2-10
	
This document defines a PKI repository locator service. The service
makes use of DNS SRV records defined in accordance with RFC 2782. The
service enables certificate using systems to locate PKI repositories 
based on a domain name, identify the protocols that can be used to 
access the repository, and obtain addresses for the servers that host 
the repository service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkixrep-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-pkixrep-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-pkixrep-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-pkixrep-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-pkixrep-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AIh2Wp069561; Thu, 10 Feb 2005 10:43:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1AIh2Xd069560; Thu, 10 Feb 2005 10:43:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AIh1xZ069504 for <[e-mail]>; Thu, 10 Feb 2005 10:43:01 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 10 Feb 2005 18:42:55 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Date: Thu, 10 Feb 2005 18:42:48 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
thread-index: AcUPmKAwrnmlti8ETFecoy8pvA8e7gABWVMA
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 10 Feb 2005 18:42:55.0663 (UTC) FILETIME=[55AECBF0:01C50FA0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1AIh2xZ069554
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Sorry for being unclear, and maybe for not seeing what you try to say.

What I meant was that the problem should not exist at all for
non-indirect CRLs. Here I totally agree that the CRL and the CA can't
have unrelated chaining. I'm not sure what the standard says about this
but if this is unclear, then it should be made clear.

What I further mean is that the existence of diversified cert and CRL
paths is therefore only an issue for indirect CRLs, AND for indirect
CRLs CDP and IDP matching IS a requirement.

The conclusion I make is: The current text in the crl-aia draft is
correct since diversified CRL and cert paths may exist where the CRL
issuer cert is issued by someone else that the CA that issued the
validated cert.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Denis Pinkas
> Sent: den 10 februari 2005 17:44
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> 
> Stefan,
> 
> > Denis it looks like there are some misconceptions here:
> 
> > Your scenario only applies to indirect CRLs.
> 
> In X.509/ 3.3.32 indirect CRL (iCRL): A revocation list that at least
> contains revocation information about certificates issued by
authorities
> other than that which issued this CRL.
> 
> I already mentioned that this sentence is not crystal clear while RFC
3280
> states:
> 
>     Whenever the CRL issuer is not the CA that issued the
certificates,
>     the CRL is referred to as an indirect CRL.
> 
>   ... which is worse and would need to be corrected. However, this is
not
> the main issue for this thread.
> 
> Don't you mean the reverse ? i.e. you scenario applies to indirect
CRLs
> while mine does not apply to indirect CRL, but only when the CRL only
> contains revocation information for certificates coming from one
single CA
> ?
> 
> Denis
> 
> > For indirect CRLs both CDP
> > AND IDP MUST be present and at least 1 DP location/URL in CDP MUST
match
> > at least one DP location/URL in IDP.
> >
> > This is already a requirement of both RFC 3280 and X.509.
> >
> > <snip>
> >
> >>This leads to the following conclusion:
> >>
> >>   a) if the IDP is not present, then my scenario applies.
> >>   b) if the IDP is present, then your scenario applies.
> >
> >
> > Conclusion: a) never apply to this problem space.
> >
> >
> > Stefan Santesson
> > Microsoft Security Center of Excellence (SCOE)
> >
> >
> >
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[e-mail]]
> >>Sent: den 10 februari 2005 17:21
> >>To: Stefan Santesson
> >>Cc: Russ Housley; pkix
> >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> >>
> >>Stefan,
> >>
> >> > I think this question is the key issue:
> >>
> >> > <Snip>
> >>
> >> >> Can there be another rule which guarantes that there is no
> >
> > ambiguity
> >
> >> >> about he right CRL issuer bearing the name contained in
cRLIssuer
> >
> > ?
> >
> >> >> The answer is no, ... unless you demonstrate the contrary.
> >>
> >> >> Note: remember that the CA cannot know in advanced which trust
> >> >> anchor(s) will be placed in the validation policies used by
> >
> > relying
> >
> >> >> parties.
> >>
> >> >>Denis
> >>
> >> > If a relying party trust a rouge CA, then all bets are off. This
is
> >>part
> >> > of the PKI fundamentals we have to accept. So the issue is to
> >
> > prevent
> >
> >> > matching of unrelated certs and CRLs from trusted issuers.
> >>
> >> > This is only a theoretically realistic threat if the CDP in the
> >
> > cert
> >
> >> > doesn't include any pointer/address to the CRL storage location
> >
> > (which
> >
> >> > should be considered really BAD practice).
> >>
> >>At this stage of explanations, the CRL pointer whether present or
> >
> > absent
> >
> >>does not help. We  all know that it is possible to replace a CRL by
> >>another
> >>one since it is never required to secure the protocol to query CRLs.
> >
> > So an
> >
> >>attacker having noticed that two CRL issuer names are the same,
might
> >>perform an active attack and exchange CRLs at will.
> >>
> >>  > Storage location addresses
> >> > (which have to match between CDP and IDP if present) do have
> >
> > sufficient
> >
> >> > uniqueness characteristics to effectively mitigate accidental CA
> >
> > name
> >
> >> > collisions. In fact, there are ways to form CDP and IDP to
> >
> > completely
> >
> >> > eliminate this threat without imposing your requirement.
> >>
> >>Interresting. Your proposal would lead to the following:
> >>
> >>    1) both the CDP and the IDP MUST must be present,
> >>    2) then they must match.
> >>
> >>  ... but the proposal would mandate the presence of the IDP.
> >>
> >>This leads to the following conclusion:
> >>
> >>   a) if the IDP is not present, then my scenario applies.
> >>   b) if the IDP is present, then your scenario applies.
> >>
> >>Both scenarios would then co-exist.
> >>
> >>If you can revise the main body of the draft along these lines, then
> >
> > we
> >
> >>may
> >>be close to an agreement.
> >>
> >>Then the second implication is : if the CRL issuer is under the same
> >>trust anchor, it will be trusted, otherwise it might not unless the
> >
> > other
> >
> >>trust anchor is also present in the validation policy. So the
> >>recommandation
> >>to use the same trust anchor would be better explained this way in
the
> >>security considerations section.
> >>
> >>Denis
> >>
> >> > Yes - an extra level of security would be guaranteed if the rule
> >
> > you
> >
> >> > suggest would be imposed, but I think it is too late and too
> >> > restrictive. The threat is not material and realistic enough to
> >
> > justify
> >
> >> > a restriction that would declare perfectly secure current
> >> > implementations non-conformant.
> >> >
> >> > You are free to seek support for your position, but until you
have
> >> > obtained rough consensus on your suggested limitation, the
crl-aia
> >> > drafting process must assume that the limitation you suggest does
> >
> > NOT
> >
> >> > exist.
> >> >
> >> >
> >> >
> >> > Stefan Santesson
> >> > Microsoft Security Center of Excellence (SCOE)
> >> >
> >> >
> >> >
> >> >>-----Original Message-----
> >> >>From: Denis Pinkas [mailto:[e-mail]]
> >> >>Sent: den 10 februari 2005 14:31
> >> >>To: Stefan Santesson
> >> >>Cc: Russ Housley; pkix
> >> >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> >> >>
> >> >>Stefan,
> >> >>
> >> >>There is a major security issue here.
> >> >>
> >> >>
> >> >>>Denis,
> >> >>>
> >> >>>It is obvious that you base your objections on the assumption
that
> >
> > a
> >
> >> >>
> >> > CRL
> >> >
> >> >>>issuer cert MUST be issued by the CA issuing the validated
subject
> >> >>
> >> > cert.
> >> >
> >> >>>But you also admit that this is what you think the stand should
> >
> > say
> >
> >> >>
> >> > but
> >> >
> >> >>>do not say (at least not explicitly).
> >> >>>
> >> >>>Quote from your text: "This is not explicitly stated in RFC 3280
> >
> > for
> >
> >> >>
> >> > CRL
> >> >
> >> >>>issuers, but it is for OCSP responders"
> >> >>>
> >> >>>I guess it will be useless to get into details before we have
> >
> > sorted
> >
> >> >>
> >> > out
> >> >
> >> >>>this major cause of disagreement. But since even you admit that
> >> >>
> >> > there is
> >> >
> >> >>>no such requirement in RFC 3280 (nor X.509), I'm not sure what
> >
> > there
> >
> >> >>
> >> > is
> >> >
> >> >>>to discuss.
> >> >>
> >> >>The security considerations section needs to be discussed.
> >> >>
> >> >>The current text is:
> >> >>
> >> >>      Implementers should take into account the possible
existence
> >
> > of
> >
> >> >>      multiple unrelated CAs and CRL issuers with the same name.
> >
> > As
> >
> >> >>      means of reducing problems and security issues related to
> >
> > issuer
> >
> >> >>      name collisions, CA names SHOULD be formed in a way that
> >
> > reduce
> >
> >> >
> >> > the
> >> >
> >> >>      likelihood of name collisions.
> >> >>
> >> >>The SHOULD in the previous sentence does not solve the problem,
> >
> > since
> >
> >> >
> >> > this
> >> >
> >> >>cannot be prevented. The text should explain how to have a secure
> >> >
> >> > system
> >> >
> >> >>even in the case of a name collision, i.e. two CAs pick the same
> >
> > name
> >
> >> >
> >> > to
> >> >
> >> >>designate a CRL issuer but that name now relates to two different
> >> >>entities.
> >> >>
> >> >>      Implementations validating CRLs
> >> >>      MUST ensure that the certification path of the target
> >> >
> >> > certificate
> >> >
> >> >>      and the CRL issuer certification path used to validate the
> >> >
> >> > target
> >> >
> >> >>      certificate, terminate at the same trust anchor.
> >> >>
> >> >>This sentence does not solve the problem. The only way to solve
the
> >> >>problem
> >> >>is, for relying parties, to be able to know unambiguously which
CA
> >
> > is
> >
> >> >>allowed to certify the CRL issuer name. It cannot be "any CA" in
a
> >> >>certification tree.
> >> >>
> >> >>Since the syntax of the cRLIssuer contained in DistributionPoint
> >
> > does
> >
> >> >
> >> > not
> >> >
> >> >>permit to place any other information than a name, it cannot
> >
> > designate
> >
> >> >
> >> > the
> >> >
> >> >>CA allowed to certify the CRL issuer name, hence there needs to
be
> >
> > a
> >
> >> >
> >> > fixed
> >> >
> >> >>rule to be known by all relying parties.
> >> >>
> >> >>The fixed rule I proposed mimics the conditions of the OCSP
> >
> > responder,
> >
> >> >>i.e.
> >> >>
> >> >>  "The CRL Issuer must have a specially marked certificate issued
> >> >>   directly by the CA, indicating that the CRL issuer may issue
> >
> > CRLs".
> >
> >> >>
> >> >>Can there be another rule which guarantes that there is no
> >
> > ambiguity
> >
> >> >
> >> > about
> >> >
> >> >>the right CRL issuer bearing the name contained in cRLIssuer ?
The
> >> >
> >> > answer
> >> >
> >> >>is
> >> >>no, ... unless you demonstrate the contrary.
> >> >>
> >> >>Note: remember that the CA cannot know in advanced which trust
> >> >
> >> > anchor(s)
> >> >
> >> >>will be placed in the validation policies used by relying
parties.
> >> >>
> >> >>Denis
> >> >>
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AH6edG064063; Thu, 10 Feb 2005 09:06:40 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1AH6e3J064062; Thu, 10 Feb 2005 09:06:40 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AH6dWj064053 for <[e-mail]>; Thu, 10 Feb 2005 09:06:39 -0800 (PST) (envelope-from [e-mail])
Received: from uranus.cry.pto (cryptolog.net4.nerim.net [62.212.120.81]) by mallaury.noc.nerim.net (Postfix) with ESMTP id E7AC562DB8; Thu, 10 Feb 2005 18:06:29 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by uranus.cry.pto (Postfix) with ESMTP id A43C444102; Thu, 10 Feb 2005 18:07:54 +0100 (CET)
Received: from uranus.cry.pto ([127.0.0.1]) by localhost (uranus [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30447-09; Thu, 10 Feb 2005 18:07:50 +0100 (CET)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by uranus.cry.pto (Postfix) with SMTP id A4D2E440E6; Thu, 10 Feb 2005 18:07:50 +0100 (CET)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Thu, 10 Feb 2005 18:06:27 +0100
From: "Julien Stern" <[e-mail]>
Date: Thu, 10 Feb 2005 18:06:27 +0100
To: Stefan Santesson <[e-mail]>
Cc: Denis Pinkas <[e-mail]>, Russ Housley <[e-mail]>, pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Message-ID: <[e-mail]>
Mail-Followup-To: Julien Stern <[e-mail]>, Stefan Santesson <[e-mail]>, Denis Pinkas <[e-mail]>, Russ Housley <[e-mail]>, pkix <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.6+20040907i
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Feb 10, 2005 at 03:17:37PM -0000, Stefan Santesson wrote:
> 
> I think this question is the key issue:
> 
> <Snip>
> > Can there be another rule which guarantes that there is no ambiguity
> about
> > the right CRL issuer bearing the name contained in cRLIssuer ? The
> answer
> > is
> > no, ... unless you demonstrate the contrary.
> > 
> > Note: remember that the CA cannot know in advanced which trust
> anchor(s)
> > will be placed in the validation policies used by relying parties.
> > 
> > Denis
> >
> 
> If a relying party trust a rouge CA, then all bets are off. This is part
> of the PKI fundamentals we have to accept. So the issue is to prevent
> matching of unrelated certs and CRLs from trusted issuers.  

I do not want to (re)start some heated discussions about this topic,
but I'm still curious about the above assumption. Is there a consensus
on it from all the list members ?

Usually, when a security assumption is broken, there are consequences,
but the often used "all bets are off" sentence is a fairly vague
consequence. So what does this "all bets are off" mean ?

- That the rogue CA can do anything it wants under its hierarchy ?
- That the rogue CA can do anything it wants above its hierarchy ?
- That the rogue CA can do anything it wants in any other hierarchy ?
- That the earth will suddently spin the other way round ? :)
- Something else ?

(Quite arguably, my consequences still remain quite vague,
but hopefully clarify my point).

I mean, let's take Microsoft certificate store. And let's assume
that some low-level CA far down in the hierarchy of some trust anchor
gets corrupted. Do we really want it to be able to impact the security
of the system as a whole, and in particular of all the other trust
anchor hierarchies ?

If this is the case, no system will be usable with two trust anchors
with different security clearances.

An other way to state the problem would be: is there a solution that
would allow to limit the scope of a CA compromise to something much
lower than "all bets are off" and if so, how practical would it be,
and do we want to implement it somehow ?

My (humble) position on the general topic would be directly inferred 
by an answer on the previous assumption.

Regards,

--
Julien Stern
R&D director
Cryptolog International SAS
16-18, rue Vulpian
75013 Paris
Tel [phone]



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AGiu4h062714; Thu, 10 Feb 2005 08:44:56 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1AGiuVQ062713; Thu, 10 Feb 2005 08:44:56 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AGitLa062695 for <[e-mail]>; Thu, 10 Feb 2005 08:44:55 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA28762; Thu, 10 Feb 2005 17:58:16 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021017444175:1405 ; Thu, 10 Feb 2005 17:44:41 +0100 
Message-ID: <[e-mail]>
Date: Thu, 10 Feb 2005 17:43:32 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Russ Housley <[e-mail]>, pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/02/2005 17:44:41, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/02/2005 17:44:43, Serialize complete at 10/02/2005 17:44:43
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

> Denis it looks like there are some misconceptions here:

> Your scenario only applies to indirect CRLs. 

In X.509/ 3.3.32 indirect CRL (iCRL): A revocation list that at least 
contains revocation information about certificates issued by authorities 
other than that which issued this CRL.

I already mentioned that this sentence is not crystal clear while RFC 3280 
states:

    Whenever the CRL issuer is not the CA that issued the certificates,
    the CRL is referred to as an indirect CRL.

  ... which is worse and would need to be corrected. However, this is not 
the main issue for this thread.

Don't you mean the reverse ? i.e. you scenario applies to indirect CRLs 
while mine does not apply to indirect CRL, but only when the CRL only 
contains revocation information for certificates coming from one single CA ?

Denis

> For indirect CRLs both CDP
> AND IDP MUST be present and at least 1 DP location/URL in CDP MUST match
> at least one DP location/URL in IDP.
> 
> This is already a requirement of both RFC 3280 and X.509.
> 
> <snip>
> 
>>This leads to the following conclusion:
>>
>>   a) if the IDP is not present, then my scenario applies.
>>   b) if the IDP is present, then your scenario applies.
> 
> 
> Conclusion: a) never apply to this problem space.
> 
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: den 10 februari 2005 17:21
>>To: Stefan Santesson
>>Cc: Russ Housley; pkix
>>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
>>
>>Stefan,
>>
>> > I think this question is the key issue:
>>
>> > <Snip>
>>
>> >> Can there be another rule which guarantes that there is no
> 
> ambiguity
> 
>> >> about he right CRL issuer bearing the name contained in cRLIssuer
> 
> ?
> 
>> >> The answer is no, ... unless you demonstrate the contrary.
>>
>> >> Note: remember that the CA cannot know in advanced which trust
>> >> anchor(s) will be placed in the validation policies used by
> 
> relying
> 
>> >> parties.
>>
>> >>Denis
>>
>> > If a relying party trust a rouge CA, then all bets are off. This is
>>part
>> > of the PKI fundamentals we have to accept. So the issue is to
> 
> prevent
> 
>> > matching of unrelated certs and CRLs from trusted issuers.
>>
>> > This is only a theoretically realistic threat if the CDP in the
> 
> cert
> 
>> > doesn't include any pointer/address to the CRL storage location
> 
> (which
> 
>> > should be considered really BAD practice).
>>
>>At this stage of explanations, the CRL pointer whether present or
> 
> absent
> 
>>does not help. We  all know that it is possible to replace a CRL by
>>another
>>one since it is never required to secure the protocol to query CRLs.
> 
> So an
> 
>>attacker having noticed that two CRL issuer names are the same, might
>>perform an active attack and exchange CRLs at will.
>>
>>  > Storage location addresses
>> > (which have to match between CDP and IDP if present) do have
> 
> sufficient
> 
>> > uniqueness characteristics to effectively mitigate accidental CA
> 
> name
> 
>> > collisions. In fact, there are ways to form CDP and IDP to
> 
> completely
> 
>> > eliminate this threat without imposing your requirement.
>>
>>Interresting. Your proposal would lead to the following:
>>
>>    1) both the CDP and the IDP MUST must be present,
>>    2) then they must match.
>>
>>  ... but the proposal would mandate the presence of the IDP.
>>
>>This leads to the following conclusion:
>>
>>   a) if the IDP is not present, then my scenario applies.
>>   b) if the IDP is present, then your scenario applies.
>>
>>Both scenarios would then co-exist.
>>
>>If you can revise the main body of the draft along these lines, then
> 
> we
> 
>>may
>>be close to an agreement.
>>
>>Then the second implication is : if the CRL issuer is under the same
>>trust anchor, it will be trusted, otherwise it might not unless the
> 
> other
> 
>>trust anchor is also present in the validation policy. So the
>>recommandation
>>to use the same trust anchor would be better explained this way in the
>>security considerations section.
>>
>>Denis
>>
>> > Yes - an extra level of security would be guaranteed if the rule
> 
> you
> 
>> > suggest would be imposed, but I think it is too late and too
>> > restrictive. The threat is not material and realistic enough to
> 
> justify
> 
>> > a restriction that would declare perfectly secure current
>> > implementations non-conformant.
>> >
>> > You are free to seek support for your position, but until you have
>> > obtained rough consensus on your suggested limitation, the crl-aia
>> > drafting process must assume that the limitation you suggest does
> 
> NOT
> 
>> > exist.
>> >
>> >
>> >
>> > Stefan Santesson
>> > Microsoft Security Center of Excellence (SCOE)
>> >
>> >
>> >
>> >>-----Original Message-----
>> >>From: Denis Pinkas [mailto:[e-mail]]
>> >>Sent: den 10 februari 2005 14:31
>> >>To: Stefan Santesson
>> >>Cc: Russ Housley; pkix
>> >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
>> >>
>> >>Stefan,
>> >>
>> >>There is a major security issue here.
>> >>
>> >>
>> >>>Denis,
>> >>>
>> >>>It is obvious that you base your objections on the assumption that
> 
> a
> 
>> >>
>> > CRL
>> >
>> >>>issuer cert MUST be issued by the CA issuing the validated subject
>> >>
>> > cert.
>> >
>> >>>But you also admit that this is what you think the stand should
> 
> say
> 
>> >>
>> > but
>> >
>> >>>do not say (at least not explicitly).
>> >>>
>> >>>Quote from your text: "This is not explicitly stated in RFC 3280
> 
> for
> 
>> >>
>> > CRL
>> >
>> >>>issuers, but it is for OCSP responders"
>> >>>
>> >>>I guess it will be useless to get into details before we have
> 
> sorted
> 
>> >>
>> > out
>> >
>> >>>this major cause of disagreement. But since even you admit that
>> >>
>> > there is
>> >
>> >>>no such requirement in RFC 3280 (nor X.509), I'm not sure what
> 
> there
> 
>> >>
>> > is
>> >
>> >>>to discuss.
>> >>
>> >>The security considerations section needs to be discussed.
>> >>
>> >>The current text is:
>> >>
>> >>      Implementers should take into account the possible existence
> 
> of
> 
>> >>      multiple unrelated CAs and CRL issuers with the same name.
> 
> As
> 
>> >>      means of reducing problems and security issues related to
> 
> issuer
> 
>> >>      name collisions, CA names SHOULD be formed in a way that
> 
> reduce
> 
>> >
>> > the
>> >
>> >>      likelihood of name collisions.
>> >>
>> >>The SHOULD in the previous sentence does not solve the problem,
> 
> since
> 
>> >
>> > this
>> >
>> >>cannot be prevented. The text should explain how to have a secure
>> >
>> > system
>> >
>> >>even in the case of a name collision, i.e. two CAs pick the same
> 
> name
> 
>> >
>> > to
>> >
>> >>designate a CRL issuer but that name now relates to two different
>> >>entities.
>> >>
>> >>      Implementations validating CRLs
>> >>      MUST ensure that the certification path of the target
>> >
>> > certificate
>> >
>> >>      and the CRL issuer certification path used to validate the
>> >
>> > target
>> >
>> >>      certificate, terminate at the same trust anchor.
>> >>
>> >>This sentence does not solve the problem. The only way to solve the
>> >>problem
>> >>is, for relying parties, to be able to know unambiguously which CA
> 
> is
> 
>> >>allowed to certify the CRL issuer name. It cannot be "any CA" in a
>> >>certification tree.
>> >>
>> >>Since the syntax of the cRLIssuer contained in DistributionPoint
> 
> does
> 
>> >
>> > not
>> >
>> >>permit to place any other information than a name, it cannot
> 
> designate
> 
>> >
>> > the
>> >
>> >>CA allowed to certify the CRL issuer name, hence there needs to be
> 
> a
> 
>> >
>> > fixed
>> >
>> >>rule to be known by all relying parties.
>> >>
>> >>The fixed rule I proposed mimics the conditions of the OCSP
> 
> responder,
> 
>> >>i.e.
>> >>
>> >>  "The CRL Issuer must have a specially marked certificate issued
>> >>   directly by the CA, indicating that the CRL issuer may issue
> 
> CRLs".
> 
>> >>
>> >>Can there be another rule which guarantes that there is no
> 
> ambiguity
> 
>> >
>> > about
>> >
>> >>the right CRL issuer bearing the name contained in cRLIssuer ? The
>> >
>> > answer
>> >
>> >>is
>> >>no, ... unless you demonstrate the contrary.
>> >>
>> >>Note: remember that the CA cannot know in advanced which trust
>> >
>> > anchor(s)
>> >
>> >>will be placed in the validation policies used by relying parties.
>> >>
>> >>Denis
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AGXVaX061548; Thu, 10 Feb 2005 08:33:31 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1AGXVO7061547; Thu, 10 Feb 2005 08:33:31 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AGXTli061536 for <[e-mail]>; Thu, 10 Feb 2005 08:33:29 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Feb 2005 16:33:05 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Date: Thu, 10 Feb 2005 16:33:08 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
thread-index: AcUPjLMPSzx4weWMRlyCmIrOqmON1gAAHmfA
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 10 Feb 2005 16:33:05.0134 (UTC) FILETIME=[322A68E0:01C50F8E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1AGXUli061541
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis it looks like there are some misconceptions here:

Your scenario only applies to indirect CRLs. For indirect CRLs both CDP
AND IDP MUST be present and at least 1 DP location/URL in CDP MUST match
at least one DP location/URL in IDP.

This is already a requirement of both RFC 3280 and X.509.

<snip>
> This leads to the following conclusion:
> 
>    a) if the IDP is not present, then my scenario applies.
>    b) if the IDP is present, then your scenario applies.

Conclusion: a) never apply to this problem space.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 10 februari 2005 17:21
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> Stefan,
> 
>  > I think this question is the key issue:
> 
>  > <Snip>
> 
>  >> Can there be another rule which guarantes that there is no
ambiguity
>  >> about he right CRL issuer bearing the name contained in cRLIssuer
?
>  >> The answer is no, ... unless you demonstrate the contrary.
> 
>  >> Note: remember that the CA cannot know in advanced which trust
>  >> anchor(s) will be placed in the validation policies used by
relying
>  >> parties.
> 
>  >>Denis
> 
>  > If a relying party trust a rouge CA, then all bets are off. This is
> part
>  > of the PKI fundamentals we have to accept. So the issue is to
prevent
>  > matching of unrelated certs and CRLs from trusted issuers.
> 
>  > This is only a theoretically realistic threat if the CDP in the
cert
>  > doesn't include any pointer/address to the CRL storage location
(which
>  > should be considered really BAD practice).
> 
> At this stage of explanations, the CRL pointer whether present or
absent
> does not help. We  all know that it is possible to replace a CRL by
> another
> one since it is never required to secure the protocol to query CRLs.
So an
> attacker having noticed that two CRL issuer names are the same, might
> perform an active attack and exchange CRLs at will.
> 
>   > Storage location addresses
>  > (which have to match between CDP and IDP if present) do have
sufficient
>  > uniqueness characteristics to effectively mitigate accidental CA
name
>  > collisions. In fact, there are ways to form CDP and IDP to
completely
>  > eliminate this threat without imposing your requirement.
> 
> Interresting. Your proposal would lead to the following:
> 
>     1) both the CDP and the IDP MUST must be present,
>     2) then they must match.
> 
>   ... but the proposal would mandate the presence of the IDP.
> 
> This leads to the following conclusion:
> 
>    a) if the IDP is not present, then my scenario applies.
>    b) if the IDP is present, then your scenario applies.
> 
> Both scenarios would then co-exist.
> 
> If you can revise the main body of the draft along these lines, then
we
> may
> be close to an agreement.
> 
> Then the second implication is : if the CRL issuer is under the same
> trust anchor, it will be trusted, otherwise it might not unless the
other
> trust anchor is also present in the validation policy. So the
> recommandation
> to use the same trust anchor would be better explained this way in the
> security considerations section.
> 
> Denis
> 
>  > Yes - an extra level of security would be guaranteed if the rule
you
>  > suggest would be imposed, but I think it is too late and too
>  > restrictive. The threat is not material and realistic enough to
justify
>  > a restriction that would declare perfectly secure current
>  > implementations non-conformant.
>  >
>  > You are free to seek support for your position, but until you have
>  > obtained rough consensus on your suggested limitation, the crl-aia
>  > drafting process must assume that the limitation you suggest does
NOT
>  > exist.
>  >
>  >
>  >
>  > Stefan Santesson
>  > Microsoft Security Center of Excellence (SCOE)
>  >
>  >
>  >
>  >>-----Original Message-----
>  >>From: Denis Pinkas [mailto:[e-mail]]
>  >>Sent: den 10 februari 2005 14:31
>  >>To: Stefan Santesson
>  >>Cc: Russ Housley; pkix
>  >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
>  >>
>  >>Stefan,
>  >>
>  >>There is a major security issue here.
>  >>
>  >>
>  >>>Denis,
>  >>>
>  >>>It is obvious that you base your objections on the assumption that
a
>  >>
>  > CRL
>  >
>  >>>issuer cert MUST be issued by the CA issuing the validated subject
>  >>
>  > cert.
>  >
>  >>>But you also admit that this is what you think the stand should
say
>  >>
>  > but
>  >
>  >>>do not say (at least not explicitly).
>  >>>
>  >>>Quote from your text: "This is not explicitly stated in RFC 3280
for
>  >>
>  > CRL
>  >
>  >>>issuers, but it is for OCSP responders"
>  >>>
>  >>>I guess it will be useless to get into details before we have
sorted
>  >>
>  > out
>  >
>  >>>this major cause of disagreement. But since even you admit that
>  >>
>  > there is
>  >
>  >>>no such requirement in RFC 3280 (nor X.509), I'm not sure what
there
>  >>
>  > is
>  >
>  >>>to discuss.
>  >>
>  >>The security considerations section needs to be discussed.
>  >>
>  >>The current text is:
>  >>
>  >>      Implementers should take into account the possible existence
of
>  >>      multiple unrelated CAs and CRL issuers with the same name.
As
>  >>      means of reducing problems and security issues related to
issuer
>  >>      name collisions, CA names SHOULD be formed in a way that
reduce
>  >
>  > the
>  >
>  >>      likelihood of name collisions.
>  >>
>  >>The SHOULD in the previous sentence does not solve the problem,
since
>  >
>  > this
>  >
>  >>cannot be prevented. The text should explain how to have a secure
>  >
>  > system
>  >
>  >>even in the case of a name collision, i.e. two CAs pick the same
name
>  >
>  > to
>  >
>  >>designate a CRL issuer but that name now relates to two different
>  >>entities.
>  >>
>  >>      Implementations validating CRLs
>  >>      MUST ensure that the certification path of the target
>  >
>  > certificate
>  >
>  >>      and the CRL issuer certification path used to validate the
>  >
>  > target
>  >
>  >>      certificate, terminate at the same trust anchor.
>  >>
>  >>This sentence does not solve the problem. The only way to solve the
>  >>problem
>  >>is, for relying parties, to be able to know unambiguously which CA
is
>  >>allowed to certify the CRL issuer name. It cannot be "any CA" in a
>  >>certification tree.
>  >>
>  >>Since the syntax of the cRLIssuer contained in DistributionPoint
does
>  >
>  > not
>  >
>  >>permit to place any other information than a name, it cannot
designate
>  >
>  > the
>  >
>  >>CA allowed to certify the CRL issuer name, hence there needs to be
a
>  >
>  > fixed
>  >
>  >>rule to be known by all relying parties.
>  >>
>  >>The fixed rule I proposed mimics the conditions of the OCSP
responder,
>  >>i.e.
>  >>
>  >>  "The CRL Issuer must have a specially marked certificate issued
>  >>   directly by the CA, indicating that the CRL issuer may issue
CRLs".
>  >>
>  >>Can there be another rule which guarantes that there is no
ambiguity
>  >
>  > about
>  >
>  >>the right CRL issuer bearing the name contained in cRLIssuer ? The
>  >
>  > answer
>  >
>  >>is
>  >>no, ... unless you demonstrate the contrary.
>  >>
>  >>Note: remember that the CA cannot know in advanced which trust
>  >
>  > anchor(s)
>  >
>  >>will be placed in the validation policies used by relying parties.
>  >>
>  >>Denis
>  >>
>  >>
>  >>
>  >
>  >
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AGM6V4060801; Thu, 10 Feb 2005 08:22:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1AGM6vi060800; Thu, 10 Feb 2005 08:22:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AGM4Zu060790 for <[e-mail]>; Thu, 10 Feb 2005 08:22:05 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA28968; Thu, 10 Feb 2005 17:35:26 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021017215234:1387 ; Thu, 10 Feb 2005 17:21:52 +0100 
Message-ID: <[e-mail]>
Date: Thu, 10 Feb 2005 17:20:44 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Russ Housley <[e-mail]>, pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/02/2005 17:21:52, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/02/2005 17:21:53, Serialize complete at 10/02/2005 17:21:53
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

 > I think this question is the key issue:

 > <Snip>

 >> Can there be another rule which guarantes that there is no ambiguity
 >> about he right CRL issuer bearing the name contained in cRLIssuer ?
 >> The answer is no, ... unless you demonstrate the contrary.

 >> Note: remember that the CA cannot know in advanced which trust
 >> anchor(s) will be placed in the validation policies used by relying
 >> parties.

 >>Denis

 > If a relying party trust a rouge CA, then all bets are off. This is part
 > of the PKI fundamentals we have to accept. So the issue is to prevent
 > matching of unrelated certs and CRLs from trusted issuers.

 > This is only a theoretically realistic threat if the CDP in the cert
 > doesn't include any pointer/address to the CRL storage location (which
 > should be considered really BAD practice).

At this stage of explanations, the CRL pointer whether present or absent 
does not help. We  all know that it is possible to replace a CRL by another 
one since it is never required to secure the protocol to query CRLs. So an 
attacker having noticed that two CRL issuer names are the same, might 
perform an active attack and exchange CRLs at will.

  > Storage location addresses
 > (which have to match between CDP and IDP if present) do have sufficient
 > uniqueness characteristics to effectively mitigate accidental CA name
 > collisions. In fact, there are ways to form CDP and IDP to completely
 > eliminate this threat without imposing your requirement.

Interresting. Your proposal would lead to the following:

    1) both the CDP and the IDP MUST must be present,
    2) then they must match.

  ... but the proposal would mandate the presence of the IDP.

This leads to the following conclusion:

   a) if the IDP is not present, then my scenario applies.
   b) if the IDP is present, then your scenario applies.

Both scenarios would then co-exist.

If you can revise the main body of the draft along these lines, then we may 
be close to an agreement.

Then the second implication is : if the CRL issuer is under the same
trust anchor, it will be trusted, otherwise it might not unless the other
trust anchor is also present in the validation policy. So the recommandation
to use the same trust anchor would be better explained this way in the 
security considerations section.

Denis

 > Yes - an extra level of security would be guaranteed if the rule you
 > suggest would be imposed, but I think it is too late and too
 > restrictive. The threat is not material and realistic enough to justify
 > a restriction that would declare perfectly secure current
 > implementations non-conformant.
 >
 > You are free to seek support for your position, but until you have
 > obtained rough consensus on your suggested limitation, the crl-aia
 > drafting process must assume that the limitation you suggest does NOT
 > exist.
 >
 >
 >
 > Stefan Santesson
 > Microsoft Security Center of Excellence (SCOE)
 >
 >
 >
 >>-----Original Message-----
 >>From: Denis Pinkas [mailto:[e-mail]]
 >>Sent: den 10 februari 2005 14:31
 >>To: Stefan Santesson
 >>Cc: Russ Housley; pkix
 >>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
 >>
 >>Stefan,
 >>
 >>There is a major security issue here.
 >>
 >>
 >>>Denis,
 >>>
 >>>It is obvious that you base your objections on the assumption that a
 >>
 > CRL
 >
 >>>issuer cert MUST be issued by the CA issuing the validated subject
 >>
 > cert.
 >
 >>>But you also admit that this is what you think the stand should say
 >>
 > but
 >
 >>>do not say (at least not explicitly).
 >>>
 >>>Quote from your text: "This is not explicitly stated in RFC 3280 for
 >>
 > CRL
 >
 >>>issuers, but it is for OCSP responders"
 >>>
 >>>I guess it will be useless to get into details before we have sorted
 >>
 > out
 >
 >>>this major cause of disagreement. But since even you admit that
 >>
 > there is
 >
 >>>no such requirement in RFC 3280 (nor X.509), I'm not sure what there
 >>
 > is
 >
 >>>to discuss.
 >>
 >>The security considerations section needs to be discussed.
 >>
 >>The current text is:
 >>
 >>      Implementers should take into account the possible existence of
 >>      multiple unrelated CAs and CRL issuers with the same name.  As
 >>      means of reducing problems and security issues related to issuer
 >>      name collisions, CA names SHOULD be formed in a way that reduce
 >
 > the
 >
 >>      likelihood of name collisions.
 >>
 >>The SHOULD in the previous sentence does not solve the problem, since
 >
 > this
 >
 >>cannot be prevented. The text should explain how to have a secure
 >
 > system
 >
 >>even in the case of a name collision, i.e. two CAs pick the same name
 >
 > to
 >
 >>designate a CRL issuer but that name now relates to two different
 >>entities.
 >>
 >>      Implementations validating CRLs
 >>      MUST ensure that the certification path of the target
 >
 > certificate
 >
 >>      and the CRL issuer certification path used to validate the
 >
 > target
 >
 >>      certificate, terminate at the same trust anchor.
 >>
 >>This sentence does not solve the problem. The only way to solve the
 >>problem
 >>is, for relying parties, to be able to know unambiguously which CA is
 >>allowed to certify the CRL issuer name. It cannot be "any CA" in a
 >>certification tree.
 >>
 >>Since the syntax of the cRLIssuer contained in DistributionPoint does
 >
 > not
 >
 >>permit to place any other information than a name, it cannot designate
 >
 > the
 >
 >>CA allowed to certify the CRL issuer name, hence there needs to be a
 >
 > fixed
 >
 >>rule to be known by all relying parties.
 >>
 >>The fixed rule I proposed mimics the conditions of the OCSP responder,
 >>i.e.
 >>
 >>  "The CRL Issuer must have a specially marked certificate issued
 >>   directly by the CA, indicating that the CRL issuer may issue CRLs".
 >>
 >>Can there be another rule which guarantes that there is no ambiguity
 >
 > about
 >
 >>the right CRL issuer bearing the name contained in cRLIssuer ? The
 >
 > answer
 >
 >>is
 >>no, ... unless you demonstrate the contrary.
 >>
 >>Note: remember that the CA cannot know in advanced which trust
 >
 > anchor(s)
 >
 >>will be placed in the validation policies used by relying parties.
 >>
 >>Denis
 >>
 >>
 >>
 >
 >





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AFHx6w056896; Thu, 10 Feb 2005 07:17:59 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1AFHxPV056895; Thu, 10 Feb 2005 07:17:59 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1AFHwAs056889 for <[e-mail]>; Thu, 10 Feb 2005 07:17:58 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 10 Feb 2005 15:17:52 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Date: Thu, 10 Feb 2005 15:17:37 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
thread-index: AcUPdLAVBMQ3Y0WJSQCZVxRoCXh2FgABad/Q
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "pkix" <[e-mail]>
X-OriginalArrivalTime: 10 Feb 2005 15:17:52.0664 (UTC) FILETIME=[B0862180:01C50F83]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1AFHxAs056890
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think this question is the key issue:

<Snip>
> Can there be another rule which guarantes that there is no ambiguity
about
> the right CRL issuer bearing the name contained in cRLIssuer ? The
answer
> is
> no, ... unless you demonstrate the contrary.
> 
> Note: remember that the CA cannot know in advanced which trust
anchor(s)
> will be placed in the validation policies used by relying parties.
> 
> Denis
>

If a relying party trust a rouge CA, then all bets are off. This is part
of the PKI fundamentals we have to accept. So the issue is to prevent
matching of unrelated certs and CRLs from trusted issuers.  

This is only a theoretically realistic threat if the CDP in the cert
doesn't include any pointer/address to the CRL storage location (which
should be considered really BAD practice). Storage location addresses
(which have to match between CDP and IDP if present) do have sufficient
uniqueness characteristics to effectively mitigate accidental CA name
collisions. In fact, there are ways to form CDP and IDP to completely
eliminate this threat without imposing your requirement.


Yes - an extra level of security would be guaranteed if the rule you
suggest would be imposed, but I think it is too late and too
restrictive. The threat is not material and realistic enough to justify
a restriction that would declare perfectly secure current
implementations non-conformant.

You are free to seek support for your position, but until you have
obtained rough consensus on your suggested limitation, the crl-aia
drafting process must assume that the limitation you suggest does NOT
exist.



Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 10 februari 2005 14:31
> To: Stefan Santesson
> Cc: Russ Housley; pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> Stefan,
> 
> There is a major security issue here.
> 
> > Denis,
> >
> > It is obvious that you base your objections on the assumption that a
CRL
> > issuer cert MUST be issued by the CA issuing the validated subject
cert.
> >
> > But you also admit that this is what you think the stand should say
but
> > do not say (at least not explicitly).
> >
> > Quote from your text: "This is not explicitly stated in RFC 3280 for
CRL
> > issuers, but it is for OCSP responders"
> >
> > I guess it will be useless to get into details before we have sorted
out
> > this major cause of disagreement. But since even you admit that
there is
> > no such requirement in RFC 3280 (nor X.509), I'm not sure what there
is
> > to discuss.
> 
> The security considerations section needs to be discussed.
> 
> The current text is:
> 
>       Implementers should take into account the possible existence of
>       multiple unrelated CAs and CRL issuers with the same name.  As
>       means of reducing problems and security issues related to issuer
>       name collisions, CA names SHOULD be formed in a way that reduce
the
>       likelihood of name collisions.
> 
> The SHOULD in the previous sentence does not solve the problem, since
this
> cannot be prevented. The text should explain how to have a secure
system
> even in the case of a name collision, i.e. two CAs pick the same name
to
> designate a CRL issuer but that name now relates to two different
> entities.
> 
>       Implementations validating CRLs
>       MUST ensure that the certification path of the target
certificate
>       and the CRL issuer certification path used to validate the
target
>       certificate, terminate at the same trust anchor.
> 
> This sentence does not solve the problem. The only way to solve the
> problem
> is, for relying parties, to be able to know unambiguously which CA is
> allowed to certify the CRL issuer name. It cannot be "any CA" in a
> certification tree.
> 
> Since the syntax of the cRLIssuer contained in DistributionPoint does
not
> permit to place any other information than a name, it cannot designate
the
> CA allowed to certify the CRL issuer name, hence there needs to be a
fixed
> rule to be known by all relying parties.
> 
> The fixed rule I proposed mimics the conditions of the OCSP responder,
> i.e.
> 
>   "The CRL Issuer must have a specially marked certificate issued
>    directly by the CA, indicating that the CRL issuer may issue CRLs".
> 
> Can there be another rule which guarantes that there is no ambiguity
about
> the right CRL issuer bearing the name contained in cRLIssuer ? The
answer
> is
> no, ... unless you demonstrate the contrary.
> 
> Note: remember that the CA cannot know in advanced which trust
anchor(s)
> will be placed in the validation policies used by relying parties.
> 
> Denis
> 
> 
> 



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1ADUP8p050972; Thu, 10 Feb 2005 05:30:25 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1ADUPHj050971; Thu, 10 Feb 2005 05:30:25 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1ADUL4S050949 for <[e-mail]>; Thu, 10 Feb 2005 05:30:23 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA09966; Thu, 10 Feb 2005 14:43:34 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005021014300006:1260 ; Thu, 10 Feb 2005 14:30:00 +0100 
Message-ID: <[e-mail]>
Date: Thu, 10 Feb 2005 14:30:31 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: Russ Housley <[e-mail]>, pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/02/2005 14:30:00, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 10/02/2005 14:30:03, Serialize complete at 10/02/2005 14:30:03
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=us-ascii; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan,

There is a major security issue here.

> Denis,
> 
> It is obvious that you base your objections on the assumption that a CRL
> issuer cert MUST be issued by the CA issuing the validated subject cert.
> 
> But you also admit that this is what you think the stand should say but
> do not say (at least not explicitly).
> 
> Quote from your text: "This is not explicitly stated in RFC 3280 for CRL
> issuers, but it is for OCSP responders"
> 
> I guess it will be useless to get into details before we have sorted out
> this major cause of disagreement. But since even you admit that there is
> no such requirement in RFC 3280 (nor X.509), I'm not sure what there is
> to discuss.

The security considerations section needs to be discussed.

The current text is:

      Implementers should take into account the possible existence of
      multiple unrelated CAs and CRL issuers with the same name.  As
      means of reducing problems and security issues related to issuer
      name collisions, CA names SHOULD be formed in a way that reduce the
      likelihood of name collisions.

The SHOULD in the previous sentence does not solve the problem, since this 
cannot be prevented. The text should explain how to have a secure system 
even in the case of a name collision, i.e. two CAs pick the same name to 
designate a CRL issuer but that name now relates to two different entities.

      Implementations validating CRLs
      MUST ensure that the certification path of the target certificate
      and the CRL issuer certification path used to validate the target
      certificate, terminate at the same trust anchor.

This sentence does not solve the problem. The only way to solve the problem 
is, for relying parties, to be able to know unambiguously which CA is 
allowed to certify the CRL issuer name. It cannot be "any CA" in a 
certification tree.

Since the syntax of the cRLIssuer contained in DistributionPoint does not 
permit to place any other information than a name, it cannot designate the 
CA allowed to certify the CRL issuer name, hence there needs to be a fixed 
rule to be known by all relying parties.

The fixed rule I proposed mimics the conditions of the OCSP responder, i.e.

  "The CRL Issuer must have a specially marked certificate issued
   directly by the CA, indicating that the CRL issuer may issue CRLs".

Can there be another rule which guarantes that there is no ambiguity about 
the right CRL issuer bearing the name contained in cRLIssuer ? The answer is 
no, ... unless you demonstrate the contrary.

Note: remember that the CA cannot know in advanced which trust anchor(s) 
will be placed in the validation policies used by relying parties.

Denis



> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
>  
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: den 7 februari 2005 06:19
>>To: Stefan Santesson; Russ Housley
>>Cc: pkix
>>Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
>>
>>Comments on <draft-ietf-pkix-crlaia-00.txt>
>>
>>1. The title and the scope of the document are not in accordance with
> 
> the
> 
>>content of the document. The document is not simply defining a new
>>extension
>>that may help to find out a CRL, but is defining a new way to verify
> 
> that
> 
>>a
>>CRL is correct.
>>
>>
>>2. The new way to verify that a CRL is correct is not aligned with the
>>current documents.
>>
>>According to RFC 3280, page 7, a CRL issuer is an "optional system to
>>which
>>a CA delegates the publication of certificate revocation lists".
>>
>>This means that the CA is responsible of the CRL issuance but may
> 
> delegate
> 
>>the publication to another entity, while being still legally
> 
> responsible
> 
>>of
>>the issuance of the CRLs.
>>
>>The CRL distribution points extension, defined in section 4.2.1.14 of
> 
> RFC
> 
>>3280, is the means for the CA to designate the appropriate CRL Issuer.
>>When
>>the CA is not the CRL issuer, then the cRLIssuer field MUST be present
> 
> and
> 
>>contain the Name of the CRL issuer. This field has the syntax
>>GeneralNames.
>>
>>GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
>>
>>GeneralName ::= CHOICE {
>>      otherName                       [0]     AnotherName,
>>      rfc822Name                      [1]     IA5String,
>>      dNSName                         [2]     IA5String,
>>      x400Address                     [3]     ORAddress,
>>      directoryName                   [4]     Name,
>>      ediPartyName                    [5]     EDIPartyName,
>>      uniformResourceIdentifier       [6]     IA5String,
>>      iPAddress                       [7]     OCTET STRING,
>>      registeredID                    [8]     OBJECT IDENTIFIER }
>>
>>Since a name is only unambiguous when certified by a CA (two CAs can
>>certify
>>two different entities but might use the same name for each of them),
> 
> the
> 
>>straightforward rule to make sure that the name is unambiguous is to
> 
> use a
> 
>>certificate for that name that has been issued by the CA which has
>>designated the CRL Issuer.
>>
>>This is not explicitly stated in RFC 3280 for CRL issuers, but it is
> 
> for
> 
>>OCSP responderx which play a similar function. In page 3 of RFC 2560
> 
> we
> 
>>have:
>>
>>All definitive response messages SHALL be digitally signed. The key
>>    used to sign the response MUST belong to one of the following:
>>
>>    -- (...)
>>    -- (...)
>>    -- a CA Designated Responder (Authorized Responder) who holds a
>>       *specially marked certificate issued directly by the CA*,
>>indicating
>>       that the responder may issue OCSP responses for that CA.
>>
>>This means that the CRL Issuer must have a *specially marked
> 
> certificate
> 
>>issued directly by the CA*, indicating that the CRL isssuer may issue
> 
> CRLs
> 
>>for that CA.
>>
>>Having said this, many portions of the text are not acceptable. Only a
> 
> few
> 
>>examples will be given hereafter.
>>
>>
>>3. The abstract is misleading. The text states:
>>"The CRL extension provides a means of discovering and retrieving CRL
>>issuer
>>certificates." It should say :"The CRL extension provides an
> 
> additional
> 
>>means of discovering and retrieving CRL issuer certificates."
>>
>>
>>4. The introduction is misleading. The text states:
>>
>>" CRL validation is also specified in RFC 3280, which involves the
>>constructions of a valid certification path for the CRL issuer".
>>
>>There is no concept of "construction of valid certification path for
> 
> the
> 
>>CRL
>>issuer". There is however the concept of a certification path which is
> 
> a
> 
>>chain of certificates from a "certificate-to-be-tested" up to one of
> 
> the
> 
>>root keys trusted under the validation policy. For each certificate of
> 
> the
> 
>>certification path, it must be tested that it is not revoked. As said
>>above,
>>the CRL issuer is designated by the CA and thus there is the need to
>>locate,
>>get and verify the CRL issuer certificate that has been issued by the
> 
> CA.
> 
>>For each certificate of the certification path, there may be the need
> 
> to
> 
>>capture just ONE CRL issuer certificate and no more.
>>
>>The next sentences are inappropriate as well and should be deleted.
>>
>>
>>5. The introduction states:
>>
>>    "Standardized methods of finding the certificate of the CRL issuer
> 
> are
> 
>>    currently available either though an accessible directory location
> 
> or
> 
>>    through use of the Subject Information Access extension in
>>    intermediary CA certificates.  These methods are however not
>>    generally applicable, and they do not provide a generic solution
> 
> to
> 
>>    the problem."
>>
>>This text is biased and is incorrect. SIA is equally applicable and
> 
> also
> 
>>provides a generic solution to the problem. It has simply to do with
> 
> using
> 
>>an extension which points downwards or upwards.
>>
>>The key point is that the certification path (as described in RFC
> 
> 3280)
> 
>>needs first to be build. Once it is built, and only once this is done,
> 
> the
> 
>>question is whether or not all certificates of the path are not
> 
> revoked.
> 
>>This means that it is possible to look up in every certificate of the
>>certification path and find out the extensions which are present.
> 
> There is
> 
>>no superiority to the new proposed extension, if SIA is populated.
>>
>>
>>6. The introduction states:
>>
>>    This document provides a straightforward and generic solution to
> 
> the
> 
>>    CRL issuer certification path building problem by permitting use
> 
> of
> 
>>    the Authority Information Access extension in CRLs, enabling a CRL
>>    checking application to use the same access method
> 
> (id-ad-caIssuers)
> 
>>    to locate the certificate of the CRL issuer and, if necessary,
>>    complete the CRL issuer certification path building to an
> 
> appropriate
> 
>>    trust anchor.
>>
>>Based on the previous arguments, this text is incorrect as well since
>>there
>>is no "CRL issuer certification path building problem".
>>
>>Major changes to this document are required to go any further. Until
> 
> an
> 
>>agreement can be reached on the previous issues, it does not make
> 
> sense to
> 
>>discuss the remaining of the document.
>>
>>Denis
>>
>>
>>
>>>A New Internet-Draft is available from the on-line Internet-Drafts
>>
>>directories.
>>
>>>This draft is a work item of the Public-Key Infrastructure (X.509)
>>
>>Working Group of the IETF.
>>
>>>	Title		: Internet X.509 Public Key
>>
>>Infrastructure Authority
>>
>>>			  Information Access CRL Extension
>>>	Author(s)	: S. Santesson, R. Housley
>>>	Filename	: draft-ietf-pkix-crlaia-00.txt
>>>	Pages		: 7
>>>	Date		: 2005-1-26
>>>
>>>This document updates RFC 3280 by defining the Authority Information
>>>   Access Certificate Revocation Lists (CRL) extension.  RFC 3280
>>>   defines the Authority Information Access certificate extension
>>
> using
> 
>>>   the same syntax.  The CRL extension provides a means of
>>
> discovering
> 
>>>   and retrieving CRL issuer certificates.
>>>
>>>A URL for this Internet-Draft is:
>>>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt
>>
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1ADCAZv049911; Thu, 10 Feb 2005 05:12:10 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j1ADCAtH049910; Thu, 10 Feb 2005 05:12:10 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j1ADC4sD049893 for <[e-mail]>; Thu, 10 Feb 2005 05:12:04 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Thu, 10 Feb 2005 13:11:58 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
Date: Thu, 10 Feb 2005 13:11:51 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-crlaia-00.txt comments
thread-index: AcUODdTzr6d8YJ+YShK0qLy6m4+QfQAACXaQAAEnVSAABGswMABSqK6Q
From: "Stefan Santesson" <[e-mail]>
To: "Matt Cooper" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 10 Feb 2005 13:11:58.0481 (UTC) FILETIME=[19E14810:01C50F72]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j1ADC5sD049903
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So, how about this:

When the HTTP scheme is specified, the URI MUST specify the location of
a certificate containing file. The file MUST contain either a single
binary DER encoded certificate (indicated by the .cer file extension) or
one or more certificates encapsulated in a CMS certs-only (PKCS#7)
message [ref] (indicated by the .p7c file extension).

HTTP server implementations accessed via the URI SHOULD use the
appropriate MIME [ref] content-type for the certificate containing file.
Specifically, the HTTP server SHOULD use the content-type
application/pkix-cert [ref] for a single DER encoded certificate and
application/pkcs7-mime [ref] for CMS certs-only (PKCS#7).  Consuming
clients may use the MIME type and file extension as a hint to the file
content, but should not depend solely on the presence of the correct
MIME type or file extension in the server response.

---------


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Matt Cooper
> Sent: den 9 februari 2005 02:32
> To: Stefan Santesson; 'Russ Housley'
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> 
> 
> Hi Stefan,
> 
> One nit with regard to the wording - The way you have used
"certificate
> file" makes it seem like a new term when I read it. Is this used in
other
> docs to collectively describe multiple file types containing
certificates?
> If no, I think you may want to find a different way to say this so it
> doesn't sound like new terminology, or, if not, should it be defined
> explicitly?  Fairly minor point in any event.
> 
> You can decide what to do with the above comment; I stuck with that
> terminology below. I was thinking something along these lines:
> 
> -------
> When the HTTP scheme is specified, the URI MUST specify the location
of a
> certificate file. The certificate file MUST be either a single binary
DER
> encoded certificate (indicated by the .cer file extension) file or a
> single
> binary DER encoded certs-only PKCS#7 [ref] file (indicated by the .p7c
> file
> extension) containing one or more certificates.
> 
> HTTP server implementations accessed via the URI SHOULD use the
> appropriate
> MIME [ref] content-type for the certificate file.  Specifically, the
HTTP
> server SHOULD use the content-type application/pkix-cert [ref] for a
> single
> DER encoded certificate and application/pkcs7-mime [ref] for a
certs-only
> PKCS#7.  Consuming clients may use the MIME type and file extension as
a
> hint to the file content, but should not depend solely on the presence
of
> the correct MIME type or file extension in the server response.
> -------
> 
> Best Regards,
> 
> Matt Cooper
> Orion Security Solutions
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> (Mob) 703.981.2269
> (Off) 703.917.0060 x. 30
> (Fax) 703.917.0260
> Visit our website!
> http://www.orionsec.com
> 
> 
> 
> 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On
> Behalf Of Stefan Santesson
> Sent: Tuesday, February 08, 2005 2:17 PM
> To: Matt Cooper; Russ Housley
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> 
> 
> Matt,
> 
> Do you have any proposed wording?
> Feel free to make a suggestion.
> 
> Stefan Santesson
> Microsoft Security Center of Excellence (SCOE)
> 
> 
> > -----Original Message-----
> > From: Matt Cooper [mailto:[e-mail]]
> > Sent: den 8 februari 2005 19:50
> > To: 'Russ Housley'; Stefan Santesson
> > Cc: [e-mail]
> > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> >
> > I knew we would get to the same page eventually. :)
> >
> > I'm glad to hear the answer is negative. I, and several others I
have
> > spoken to, took the text in the draft to indicate this extra MIME
> > encoding
> was
> > the
> > proposed requirement. So, I think we simply need to reword that
> section to
> > be very clear on this point.
> >
> > Best Regards,
> >
> > Matt Cooper
> > Orion Security Solutions
> > 1489 Chain Bridge Road, Suite 300
> > McLean, Virginia 22101
> > (Mob) 703.981.2269
> > (Off) 703.917.0060 x. 30
> > (Fax) 703.917.0260
> > Visit our website!
> > http://www.orionsec.com
> >
> >
> > -----Original Message-----
> > From: Russ Housley [mailto:[e-mail]]
> > Sent: Tuesday, February 08, 2005 1:41 PM
> > To: Matt Cooper; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> >
> > Matt:
> >
> > Now I understand the issue.  Sorry it took so long for me to
> understand
> > the
> > comment.
> >
> > FALSE.
> >
> > I expect the server to store a binary .cer and .p7c file.  The only
> MIME
> > encoding will be applied by the transport protocol.  HTTP will MIME
> > encode.
> > FTP will not.
> >
> > Russ
> >
> > At 12:27 PM 2/7/2005, Matt Cooper wrote:
> > >Russ,
> > >
> > >TRUE|FALSE: On the server, you intend for the certificate file
> (stored
> > >TRUE|on
> > >the server's hard disk) to be MIME encoded.
> > >
> > >The question has nothing to do with HTTP. It could be FTP or NFS
for
> > >all it matters. What the draft says (to me at least) is that you
are
> > >supposed to MIME encode the data *BEFORE* the protocol encoding
ever
> > enters
> > the picture.
> > >This results in the client receiving a MIME encoded file regardless
> of
> > >transport protocol.
> > >
> > >Best Regards,
> > >
> > >Matt Cooper
> > >Orion Security Solutions
> > >1489 Chain Bridge Road, Suite 300
> > >McLean, Virginia 22101
> > >(Mob) 703.981.2269
> > >(Off) 703.917.0060 x. 30
> > >(Fax) 703.917.0260
> > >Visit our website!
> > >http://www.orionsec.com
> > >
> > >
> > >-----Original Message-----
> > >From: Russ Housley [mailto:[e-mail]]
> > >Sent: Friday, February 04, 2005 8:21 AM
> > >To: Matt Cooper; [e-mail]
> > >Cc: [e-mail]
> > >Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> > >
> > >Matt:
> > >
> > >MIME supports many encoding types, including binary and base64.  I
> > >think that binary will be used in this case, but base64 and other
> > >encodings are not prohibited.
> > >
> > >We should probably say that binary encoding MUST be supported.
> > >
> > >Russ
> > >
> > >At 06:29 PM 2/3/2005, Matt Cooper wrote:
> > >
> > > >Perhaps I was not clear either.  I didn't think you were
attempting
> > > >to eliminate the HTTP MIME encoding.  And believe me, I'm the
first
> > > >one to cheer having a naming convention for this purpose!
> > > >
> > > >Are you saying that your intent was only to apply the MIME
encoding
> > > >to how the HTTP server should be serving up the files to the
> client?
> > > >Not trying to be difficult, I just want to be sure we're on the
> same
> > > >page as the text reads quite differently to me.
> > > >
> > > >It reads (to me) that you intend for the hosted file to be MIME
> > > >encoded rather than binary.  Specifically, as [A MIME encoded
> > > >application/pkcs7-mime "certs-only" file  as specified in RFC
2797
> > > >[CMC]"].  When I read this it indicated to me that I am supposed
to
> > > >MIME encode the PKCS#7 and name the resultant MIME text file with
a
> > > >.p7c extension.  E.g., place the following file content on my web
> > server:
> > > >
> > > >MIME-Version: 1.0
> > > >Content-Type: application/pkcs7-mime;
> > > >         smime-type="certs-only";
> > > >         name="cacerts.p7c"
> > > >Content-Transfer-Encoding: base64
> > > >Content-Disposition: attachment;
> > > >         filename="cacerts.p7c"
> > > >
> > >
> >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEg
> > > >g/
> > > >+Q29u
> > >
> >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X
> > > >05
> > > >leHRQ
> > > >...
> > > >BhcnA===
> > > >
> > > >
> > > >Matt Cooper
> > > >Orion Security Solutions
> > > >1489 Chain Bridge Road, Suite 300
> > > >McLean, Virginia 22101
> > > >(Mob) 703.981.2269
> > > >(Off) 703.917.0060 x. 30
> > > >(Fax) 703.917.0260
> > > >Visit our website!
> > > >http://www.orionsec.com
> > > >
> > > >
> > > >________________________________
> > > >
> > > >From: Russ Housley [mailto:[e-mail]]
> > > >Sent: Thursday, February 03, 2005 3:39 PM
> > > >To: Matt Cooper; [e-mail]
> > > >Cc: [e-mail]
> > > >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
> > > >
> > > >
> > > >Matt:
> > > >
> > > >We were not clear.  We did not intend to eliminate the MIME
> encoding
> > > >which is normally present with HTTP.  The MIME types are
specified
> in
> > > >the referenced documents, I believe.  Rather, we were also
stating
> a
> > > >naming convention for the files that are obtained.
> > > >
> > > >Russ
> > > >
> > > >At 03:15 PM 2/3/2005, Matt Cooper wrote:
> > > >
> > > >
> > > >         First, I'd like to say I'm happy to see this come out,
> this
> > > >is a needed addition for CRLs.
> > > >
> > > >         All my comments refer to the following snippet extracted
> > > >from the draft
> > > >         (
> > > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt
> > >
><http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt>
> ):
> > > >
> > > >         ===begin===
> > > >            When the http scheme is specified, the URI MUST point
> to a
> > > >            certificate file.  The certificate file MUST contain
> > > >either a single
> > > >            DER encoded certificate (indicated by the .cer file
> > > >extension)
> > >or
> > > >            contain a certification path (indicated by the .p7c
> file
> > > >extension):
> > > >
> > > >               .cer   A single DER encoded certificate as
specified
> in
> > > >                      RFC 2585 [PKIX-CERT].
> > > >
> > > >               .p7c   A MIME encoded application/pkcs7-mime
"certs-
> > only"
> > >file
> > > >                      as specified in RFC 2797 [CMC].
> > > >         ===end===
> > > >
> > > >         Unless this has been required in another document that I
> am
> > > >unaware of, we should use not use "MIME encoded" for this purpose
> for
> > > >the following
> > > >reasons:
> > > >         1. It creates burden on the client.  Why should the
client
> > > >need a MIME decoder to verify a CRL?
> > > >         2. It creates burden for CA's and CA operators.  They
may
> > > >have to learn how to manually encode a PKCS#7 in a MIME structure
> if
> > > >their CA does not output this for them. This is error prone and
may
> > > >lead to
> > >problems.
> > > >         3. Clients must handle one case as binary and the other
> case
> > > > as
> > >text
> > > >         4. Web servers already return MIME types for data;
another
> > > >MIME layer is not needed
> > > >
> > > >         It is not too much to expect that the relying party
> software
> > > >can distinguish between a binary cert and a binary p7c file. (For
> > > >example, MS CAPI already does this for AIA)  However, to make
life
> > > >easier for the client, could we throw in appropriate use of MIME
> > > >types on
> > >the web server?
> > > >Perhaps something like this:
> > > >
> > > >         "HTTP server implementations accessed via the URI SHOULD
> use
> > > >the appropriate MIME content-type for the certificate file.
> > > >Specifically, the HTTP server SHOULD return the content-type
> > > >application/pkix-cert for a single DER encoded certificate and
> > > >application/pkcs7-mime for a certs-only PKCS#7.  Consuming
clients
> > > >SHOULD use the MIME type as a hint, but should not depend solely
on
> > > >the presence of the correct MIME type in the server response."
> > > >
> > > >         Calling for the contents of the p7c to be "a
certification
> > > >path" is too restrictive in my mind.  It would be better to leave
> > > >this wide open and say something like "contain one or more
> > > >certificates that may be helpful to the relying party."  This
> leaves
> > > >it up to the implementer to put in any certificates that may be
> > > >useful for path construction regardless of whether we have common
> > > >trusted roots.  (They may also wish to not include the entire
path,
> > > >but instead only the CRL signer cert, which then has another AIA
in
> > > >it.)
> > > >
> > > >         Suggest rewording the text something like this :
> > > >
> > > >         When the HTTP scheme is specified, the URI MUST point to
a
> > > >certificate file. The certificate file MUST be either a single
> binary
> > > >DER encoded certificate (indicated by the .cer file extension) or
a
> > > >single binary DER encoded certs-only PKCS#7 file (indicated by
the
> > > >.p7c file
> > > >extension) containing one or more certificates that may be
helpful
> to
> > > >the relying party.
> > > >
> > > >
> > > >         Matt Cooper
> > > >         Orion Security Solutions
> > > >         1489 Chain Bridge Road, Suite 300
> > > >         McLean, Virginia 22101
> > > >         (Mob) 703.981.2269
> > > >         (Off) 703.917.0060 x. 30
> > > >         (Fax) 703.917.0260
> > > >         Visit our website!
> > > >         http://www.orionsec.com <http://www.orionsec.com/>
> > > >
> > > >
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19Fw51b041742; Wed, 9 Feb 2005 07:58:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19Fw5Tn041741; Wed, 9 Feb 2005 07:58:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sottmxsecs3.entrust.com (sottmxsecs3.entrust.com [216.191.252.14]) by above.proper.com (8.12.11/8.12.9) with SMTP id j19FvxYr041729 for <[e-mail]>; Wed, 9 Feb 2005 07:57:59 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 3629 invoked from network); 9 Feb 2005 15:57:11 -0000
Received: from [e-mail] by sottmxsecs3.entrust.com with EntrustECS-Server-7.2.5;09 Feb 2005 15:57:11 -0000
Received: from unknown (HELO sottmxs00.entrust.com) (10.4.61.22) by sottmxsecs3.entrust.com with SMTP; 9 Feb 2005 15:57:11 -0000
Received: by sottmxs00.entrust.com with Internet Mail Service (5.5.2657.72) id <DMZ9J53K>; Wed, 9 Feb 2005 10:57:51 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, [e-mail]
Cc: IETF-PKIX <[e-mail]>
Subject: RE: Draft-ietf-pkix-rfc2511bis-07
Date: Wed, 9 Feb 2005 10:57:45 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50EC0.1877C9EC"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C50EC0.1877C9EC
Content-Type: text/plain

Jim, sorry for the delay in responding. I have 2 comments:

1) The new document completely changes the meaning of an Object Identifer
(changing the name as well as the syntax). In the original RFC (see page
11), the OID was defined as follows:
 
id-regInfo-asciiPairs  OBJECT IDENTIFIER  ::= {id-regInfo 1} --with syntax
OCTET STRING
(however in Appendix B they call this id-regInfo-utf8Pairs with a syntax of
OCTET STRING, so there was some confusion even back then)
 
In the new RFC it changes to:
 
id-regInfo-utf8Pairs  OBJECT IDENTIFIER  ::= {id-regInfo 1} --with syntax
UTF8String (see section 7.1.
 
OIDs cannot be redefined like this.  I suggest you leave the old OID as is
and define a new one for UTF8 String. 

2) The use of the EncryptedValue structure has been deprecated. This is one
of the two choices for conveying an encrypted key in the archive options
control that would appear in the controls element of the cert request. The
other choice is envelopedData. EncryptedValue is in use in existing products
and therefore should not be deprecated.

Cheers,
Sharon 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Friday, January 07, 2005 4:04 PM
To: [e-mail]
Cc: IETF-PKIX
Subject: Re: Draft-ietf-pkix-rfc2511bis-07



Folks,

Jim sent this message in mid-December and I have seen no response on 
the list, so far.  if nobody responds to Jim, Tim and I will 
interpret this as implicit authorization for Jim to proceed as he see 
fit on this topics.

Steve


>As advertized this draft is now under new editorship.  As the new 
>editor there are a number of issues that I fill still need to be 
>resolved before this draft can go to last call.  If there is no help 
>forth coming then I will be making arbitrary decions on these issue.
>
>Additionally, if anyone has kept any of the final reports from the 
>interop trials for CMP, I would like to see the sections that relate to 
>CRMF.
>
>You can easily find the open issues and questions by searching for [[[ 
>in the document.
>
>1.  Section 4.1 - I have a partial answer for this question dealing 
>with non DN style names that are authenticated, but are not actually 
>either subject names (DNs) or subject alt names (General Names).  The 
>only real question at this point is should this rational be documented.
>
>2.  Section 4.2 - I am worried about the possiblity of somebody copying 
>an encrypted private key being sent to the CA/RA and then copying it 
>into their own certificate request.  They could then later request a 
>key recovery from the CA/RA and get back somebody elses private key.  
>This is the reason that I am worried about how a POP proof is done 
>here.  One potential answer is to include the authenticated identity 
>along with the private key in the encrypted block.
>
>3.  Section 4.2 - We MUST solve the question of what the contents of 
>the encrypted blob look like.  One potential answer is to obsolete 
>thisMessage and reaplace it with an EnvelopedData then all that needs 
>to be covered is the format of the encrypted key plus any POP info 
>required.
>
>4.  Section 4.3 - Does the DH section need to be expanded so that any 
>key agreement key pair can be used?  This can be done by adding a MAC 
>alg and value pair to the end of the POPOPrivKey choice (and 
>potentially obsoleting the dhMAC element).
>
>5.  Section 4.4 - Two questions regarding guidence for the number of 
>iterations and the amount of salt to be used.  We need a cryptographer 
>to give us some guidelines for these details, or atleast need to set 
>some minimums.
>
>6.  Section 6.1 & 6.2 - The content of these controls is not well 
>defined and a couple of questions regarding this are asked.  This may 
>have been addressed in the interop by adding some undocumented 
>restrictions.
>
>7.  Section 6.4 - There are a couple of archive questions here.  At 
>this point my inclination is to kill the entire section unless somebody 
>wants to make it acutally work.
>
>8.  Section 6.8 - Ditto here.
>
>9.  Section 7.1 - Consider the string "Tokens?%30%FA%F3?9%"   The parsing
is
>difficult (but not impossible) due to the overload of the % token.
>
>Jim

------_=_NextPart_001_01C50EC0.1877C9EC
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: Draft-ietf-pkix-rfc2511bis-07</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Jim, sorry for the delay in responding. I have 2 =
comments:</FONT>
</P>

<P><FONT SIZE=3D2>1) The new document completely changes the meaning of =
an Object Identifer (changing the name as well as the syntax). In the =
original RFC (see page 11), the OID was defined as follows:</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>id-regInfo-asciiPairs&nbsp; OBJECT IDENTIFIER&nbsp; =
::=3D {id-regInfo 1} --with syntax OCTET STRING</FONT>
<BR><FONT SIZE=3D2>(however in Appendix B they call this =
id-regInfo-utf8Pairs with a syntax of OCTET STRING, so there was some =
confusion even back then)</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>In the new RFC it changes to:</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>id-regInfo-utf8Pairs&nbsp; OBJECT IDENTIFIER&nbsp; =
::=3D {id-regInfo 1} --with syntax UTF8String (see section 7.1.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>OIDs cannot be redefined like this.&nbsp; I suggest =
you leave the old OID as is and define a new one for UTF8 String. =
</FONT>
</P>

<P><FONT SIZE=3D2>2) The use of the EncryptedValue structure has been =
deprecated. This is one of the two choices for conveying an encrypted =
key in the archive options control that would appear in the controls =
element of the cert request. The other choice is envelopedData. =
EncryptedValue is in use in existing products and therefore should not =
be deprecated.</FONT></P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Sharon </FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: [e-mail] [<A =
HREF=3D"mailto:[e-mail]">mailto:owner-ietf-pkix@mail=
.imc.org</A>] On Behalf Of Stephen Kent</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, January 07, 2005 4:04 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: IETF-PKIX</FONT>
<BR><FONT SIZE=3D2>Subject: Re: Draft-ietf-pkix-rfc2511bis-07</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Folks,</FONT>
</P>

<P><FONT SIZE=3D2>Jim sent this message in mid-December and I have seen =
no response on </FONT>
<BR><FONT SIZE=3D2>the list, so far.&nbsp; if nobody responds to Jim, =
Tim and I will </FONT>
<BR><FONT SIZE=3D2>interpret this as implicit authorization for Jim to =
proceed as he see </FONT>
<BR><FONT SIZE=3D2>fit on this topics.</FONT>
</P>

<P><FONT SIZE=3D2>Steve</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;As advertized this draft is now under new =
editorship.&nbsp; As the new </FONT>
<BR><FONT SIZE=3D2>&gt;editor there are a number of issues that I fill =
still need to be </FONT>
<BR><FONT SIZE=3D2>&gt;resolved before this draft can go to last =
call.&nbsp; If there is no help </FONT>
<BR><FONT SIZE=3D2>&gt;forth coming then I will be making arbitrary =
decions on these issue.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Additionally, if anyone has kept any of the =
final reports from the </FONT>
<BR><FONT SIZE=3D2>&gt;interop trials for CMP, I would like to see the =
sections that relate to </FONT>
<BR><FONT SIZE=3D2>&gt;CRMF.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;You can easily find the open issues and =
questions by searching for [[[ </FONT>
<BR><FONT SIZE=3D2>&gt;in the document.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;1.&nbsp; Section 4.1 - I have a partial answer =
for this question dealing </FONT>
<BR><FONT SIZE=3D2>&gt;with non DN style names that are authenticated, =
but are not actually </FONT>
<BR><FONT SIZE=3D2>&gt;either subject names (DNs) or subject alt names =
(General Names).&nbsp; The </FONT>
<BR><FONT SIZE=3D2>&gt;only real question at this point is should this =
rational be documented.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;2.&nbsp; Section 4.2 - I am worried about the =
possiblity of somebody copying </FONT>
<BR><FONT SIZE=3D2>&gt;an encrypted private key being sent to the CA/RA =
and then copying it </FONT>
<BR><FONT SIZE=3D2>&gt;into their own certificate request.&nbsp; They =
could then later request a </FONT>
<BR><FONT SIZE=3D2>&gt;key recovery from the CA/RA and get back =
somebody elses private key.&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt;This is the reason that I am worried about how a =
POP proof is done </FONT>
<BR><FONT SIZE=3D2>&gt;here.&nbsp; One potential answer is to include =
the authenticated identity </FONT>
<BR><FONT SIZE=3D2>&gt;along with the private key in the encrypted =
block.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;3.&nbsp; Section 4.2 - We MUST solve the =
question of what the contents of </FONT>
<BR><FONT SIZE=3D2>&gt;the encrypted blob look like.&nbsp; One =
potential answer is to obsolete </FONT>
<BR><FONT SIZE=3D2>&gt;thisMessage and reaplace it with an =
EnvelopedData then all that needs </FONT>
<BR><FONT SIZE=3D2>&gt;to be covered is the format of the encrypted key =
plus any POP info </FONT>
<BR><FONT SIZE=3D2>&gt;required.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;4.&nbsp; Section 4.3 - Does the DH section need =
to be expanded so that any </FONT>
<BR><FONT SIZE=3D2>&gt;key agreement key pair can be used?&nbsp; This =
can be done by adding a MAC </FONT>
<BR><FONT SIZE=3D2>&gt;alg and value pair to the end of the POPOPrivKey =
choice (and </FONT>
<BR><FONT SIZE=3D2>&gt;potentially obsoleting the dhMAC =
element).</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;5.&nbsp; Section 4.4 - Two questions regarding =
guidence for the number of </FONT>
<BR><FONT SIZE=3D2>&gt;iterations and the amount of salt to be =
used.&nbsp; We need a cryptographer </FONT>
<BR><FONT SIZE=3D2>&gt;to give us some guidelines for these details, or =
atleast need to set </FONT>
<BR><FONT SIZE=3D2>&gt;some minimums.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;6.&nbsp; Section 6.1 &amp; 6.2 - The content of =
these controls is not well </FONT>
<BR><FONT SIZE=3D2>&gt;defined and a couple of questions regarding this =
are asked.&nbsp; This may </FONT>
<BR><FONT SIZE=3D2>&gt;have been addressed in the interop by adding =
some undocumented </FONT>
<BR><FONT SIZE=3D2>&gt;restrictions.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;7.&nbsp; Section 6.4 - There are a couple of =
archive questions here.&nbsp; At </FONT>
<BR><FONT SIZE=3D2>&gt;this point my inclination is to kill the entire =
section unless somebody </FONT>
<BR><FONT SIZE=3D2>&gt;wants to make it acutally work.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;8.&nbsp; Section 6.8 - Ditto here.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;9.&nbsp; Section 7.1 - Consider the string =
&quot;Tokens?%30%FA%F3?9%&quot;&nbsp;&nbsp; The parsing is</FONT>
<BR><FONT SIZE=3D2>&gt;difficult (but not impossible) due to the =
overload of the % token.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;Jim</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C50EC0.1877C9EC--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19BTc8M095219; Wed, 9 Feb 2005 03:29:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j19BTcRG095218; Wed, 9 Feb 2005 03:29:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j19BTbS4095182 for <[e-mail]>; Wed, 9 Feb 2005 03:29:37 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j19BTXn02396; Wed, 9 Feb 2005 12:29:33 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Wed, 9 Feb 2005 12:29:33 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j19BTXi23307; Wed, 9 Feb 2005 12:29:33 +0100 (MET)
Date: Wed, 9 Feb 2005 12:29:33 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stefan, thanks for the answer,

basically I see that there were no conceptual differences, and
only some misunderstandings caused by the wordings.
 
> [Stefan] AIA in Certificates and in CRLs share the same ASN.1 syntax
> even if we choose to populate the extension with different data. I think
> that is perfectly fine and true for many extensions. I.e. when you use
> an extension to serve purpose A you may fill that extension with
> different parameters and data than if the extension serve purpose B. Yet
> the same extension OID is maintained for both cases and the same syntax
> is used.

It seems that with the clarification concerning the MIME encoding, my
remarks does not have no longer a good ground. 

Nevertheless, I think that it important that when the same accessMethod 
oid is used, then the retrieval and presentation(encoding) of the data pointed 
to by the URI should be the same independantly of whether the access method 
is used in an AIA or a SIA of a certificate or a CRL or whather else beast.  

> > - The id-ad-caIssuers definition in 3280 defines the usage of ftp,
> http,
> >   ldap (but fails together with operationl protocols to completely
> >   define the data formats for http and ftp.
> > 
> 
> [Stefan] This is the initial suggestion but it is debatable. We started
> with the minimum set to see whether there was a strong need for anything
> else that was not included in version 0. Do you see a strong reason to
> expand the proposed set of schemas? If yes, then why?

This issue is not orthogonal:

- The operational protocols are not complete, only single certs can be
  retrieved with http and ftp, since there is no other spec., only some
  undocumented practice.

- I am not sure whether FTP is really a necessary goal, in any case, the
  protocol is difficult to implement or to be profiled, etc. 
  

I suggest that either in 3280 or in operational protocols one should clarify
the data format with multiple certificates, define the mime types etc.
(In the mean time you can put an appendix in the AIA text to remind this,
 this was done with the SIA in 3161 at some time).

In a normative way one should reference operational protocols, and, maybe
profile it, i.e. saying the ftp is not recommended, in whatever way
you want it. Or, clients SHOULD support ldap AND http, and MUST support 
one of them at least? ..

> >   I am not sure that p7c in the current text is really intended to
> have
> >   another mime encapsulation (as mentioned by D.C.), but if so, what
> >   would this be good for?
> 
> [Stefan] Hopefully this has been sorted out in recent exchange on the
> topic. 

Yes. 

> > - Shouldn't the data format be met into an updated operational
> >   protocols? This would also allow to say a little bit more
> >   about what an http client is supposed to implement as a minimal
> >   profile for http.
> > 
> 
> [Stefan] What we ant to do is to describe what is already widely
> deployed for AIA. This is what the text tries to capture. If the text
> fails to do that, then we are more than happy to receive suggested
> improvements to the text.

I'd say, not for AIA, but for whatever 'accessMethod' to uris that have certs
or lists of certs. 

You are not exactly responding to the question: There is something in
between TCP and the data. One can just name this thingy 'http', but still 
there are many options to mention, should a 'lightweight' client be able 
to follow redirections etc. A discussion similar to the SAML/SOAP to http
binding seems useful as an update for the operational protocols. 
example: What returns should be permitted, etc, redirects allowed, 
chunked encoding?, ... ==> all this should be in the operationl protocols. 

> > - It doesn't seem extremely useful to me to have several different
> >   formats to access to certificat list via http, on for certificats
> >   in general (done by Peter Gutmann's text) and another in this
> >   text.
> 
> [Stefan] This is the fine balance. We want to limit the set as much as
> possible but still support current deployments that have been deployed
> in conformity with RFC 3280 in good faith. There is simply too much use
> of the .p7c file format to ignore it and declare it non-conformant.

I don't want to declar the p7c non conformant, on the contrary, it is
simple to implement in the server, and in cas of CMS implementations on
the client side, the parsing comes for free, whilst with ...

> There is also the aspect of efficiency, where the p7c format may reveal
> a complete chain.
The certs are a SET, I don't see exactly what you mean, but since
we are not in disagreement about the usefulness of the 'type' ...

> 
> > 
> > - Using a suffix .cer or .p7c to determine the content type behind
> >   an http uri seems not ok to me, for this AFAIK, http uses mime
> types.
> 
> [Stefan] I think/hope this one has been sorted out.

Yes. but needs to be corrected in the text. 

> 
> > 
> > - Yes, I know, we might end with a debate whether a list of certs
> >   can be provided best as:
> > 
> >   - SEQUENCE OF Certificate
> >   - a p7c cert only PKCS7/CMS file
> >   - a mime multipart containing several individual certificats
> >   - same result as with ldap...
> > 
> >   Well, so be it, ==> 'n' mime types (defined with their file suffix)
> >   a an http client can set a list of acceptable mime types, and the
> server
> >   must return the data in that way. Using undefined length encoding,
> >   the first and the second simply mean to encode a fixed prefix and
> > suffix,
> >   the third is a bit more complicated, etc.
> > 
> 
> [Stefan] We all agree that the information is stored in raw format and
> that MIME encoding is an issue for the transport protocol. Is there
> anything more to say about this?

Since I think that this is an isseu for the operational protocols ... :-)



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j199wlPZ061644; Wed, 9 Feb 2005 01:58:47 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j199wlpE061642; Wed, 9 Feb 2005 01:58:47 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (d5-175.dip.isp-service.de [83.121.5.175]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j199wfIF061487 for <[e-mail]>; Wed, 9 Feb 2005 01:58:46 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id A48E6E075A; Wed,  9 Feb 2005 10:58:15 +0100 (CET)
Received: from nb2.stroeder.com ([127.0.0.1]) by localhost (nb2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08767-04; Wed,  9 Feb 2005 10:58:14 +0100 (CET)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 1F3F5E059F; Wed,  9 Feb 2005 10:58:14 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 09 Feb 2005 10:58:13 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
Cc: Matt Cooper <[e-mail]>, [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by amavisd-new at stroeder.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley wrote:
 >
> I expect the server to store a binary .cer and .p7c file. The only 
> MIME encoding will be applied by the transport protocol. HTTP will
> MIME encode. FTP will not.

This should be made more clear in the text.
I also interpreted it like Matt did.

Ciao, Michael.

--
Michael Ströder
http://www.stroeder.com



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j191X2Gf052285; Tue, 8 Feb 2005 17:33:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j191X2wp052284; Tue, 8 Feb 2005 17:33:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j191X1Jv052269 for <[e-mail]>; Tue, 8 Feb 2005 17:33:01 -0800 (PST) (envelope-from [e-mail])
Received: from wmcooper (pcp09268965pcs.arlngt01.va.comcast.net [69.143.119.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id j191WnmX026094; Tue, 8 Feb 2005 20:32:50 -0500
Message-Id: <[e-mail]>
From: "Matt Cooper" <[e-mail]>
To: "'Stefan Santesson'" <[e-mail]>, "'Russ Housley'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
Date: Tue, 8 Feb 2005 20:32:02 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcUODdTzr6d8YJ+YShK0qLy6m4+QfQAACXaQAAEnVSAABGswMA==
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Stefan,

One nit with regard to the wording - The way you have used "certificate
file" makes it seem like a new term when I read it. Is this used in other
docs to collectively describe multiple file types containing certificates?
If no, I think you may want to find a different way to say this so it
doesn't sound like new terminology, or, if not, should it be defined
explicitly?  Fairly minor point in any event.

You can decide what to do with the above comment; I stuck with that
terminology below. I was thinking something along these lines:

-------
When the HTTP scheme is specified, the URI MUST specify the location of a
certificate file. The certificate file MUST be either a single binary DER
encoded certificate (indicated by the .cer file extension) file or a single
binary DER encoded certs-only PKCS#7 [ref] file (indicated by the .p7c file
extension) containing one or more certificates.

HTTP server implementations accessed via the URI SHOULD use the appropriate
MIME [ref] content-type for the certificate file.  Specifically, the HTTP
server SHOULD use the content-type application/pkix-cert [ref] for a single
DER encoded certificate and application/pkcs7-mime [ref] for a certs-only
PKCS#7.  Consuming clients may use the MIME type and file extension as a
hint to the file content, but should not depend solely on the presence of
the correct MIME type or file extension in the server response.
-------

Best Regards,

Matt Cooper
Orion Security Solutions
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101
(Mob) 703.981.2269
(Off) 703.917.0060 x. 30
(Fax) 703.917.0260
Visit our website!
http://www.orionsec.com
 



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stefan Santesson
Sent: Tuesday, February 08, 2005 2:17 PM
To: Matt Cooper; Russ Housley
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments


Matt,

Do you have any proposed wording?
Feel free to make a suggestion.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Matt Cooper [mailto:[e-mail]]
> Sent: den 8 februari 2005 19:50
> To: 'Russ Housley'; Stefan Santesson
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> 
> I knew we would get to the same page eventually. :)
> 
> I'm glad to hear the answer is negative. I, and several others I have 
> spoken to, took the text in the draft to indicate this extra MIME 
> encoding
was
> the
> proposed requirement. So, I think we simply need to reword that
section to
> be very clear on this point.
> 
> Best Regards,
> 
> Matt Cooper
> Orion Security Solutions
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> (Mob) 703.981.2269
> (Off) 703.917.0060 x. 30
> (Fax) 703.917.0260
> Visit our website!
> http://www.orionsec.com
> 
> 
> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Tuesday, February 08, 2005 1:41 PM
> To: Matt Cooper; [e-mail]
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> 
> Matt:
> 
> Now I understand the issue.  Sorry it took so long for me to
understand
> the
> comment.
> 
> FALSE.
> 
> I expect the server to store a binary .cer and .p7c file.  The only
MIME
> encoding will be applied by the transport protocol.  HTTP will MIME 
> encode.
> FTP will not.
> 
> Russ
> 
> At 12:27 PM 2/7/2005, Matt Cooper wrote:
> >Russ,
> >
> >TRUE|FALSE: On the server, you intend for the certificate file
(stored
> >TRUE|on
> >the server's hard disk) to be MIME encoded.
> >
> >The question has nothing to do with HTTP. It could be FTP or NFS for 
> >all it matters. What the draft says (to me at least) is that you are 
> >supposed to MIME encode the data *BEFORE* the protocol encoding ever
> enters
> the picture.
> >This results in the client receiving a MIME encoded file regardless
of
> >transport protocol.
> >
> >Best Regards,
> >
> >Matt Cooper
> >Orion Security Solutions
> >1489 Chain Bridge Road, Suite 300
> >McLean, Virginia 22101
> >(Mob) 703.981.2269
> >(Off) 703.917.0060 x. 30
> >(Fax) 703.917.0260
> >Visit our website!
> >http://www.orionsec.com
> >
> >
> >-----Original Message-----
> >From: Russ Housley [mailto:[e-mail]]
> >Sent: Friday, February 04, 2005 8:21 AM
> >To: Matt Cooper; [e-mail]
> >Cc: [e-mail]
> >Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> >
> >Matt:
> >
> >MIME supports many encoding types, including binary and base64.  I 
> >think that binary will be used in this case, but base64 and other 
> >encodings are not prohibited.
> >
> >We should probably say that binary encoding MUST be supported.
> >
> >Russ
> >
> >At 06:29 PM 2/3/2005, Matt Cooper wrote:
> >
> > >Perhaps I was not clear either.  I didn't think you were attempting 
> > >to eliminate the HTTP MIME encoding.  And believe me, I'm the first 
> > >one to cheer having a naming convention for this purpose!
> > >
> > >Are you saying that your intent was only to apply the MIME encoding 
> > >to how the HTTP server should be serving up the files to the
client?
> > >Not trying to be difficult, I just want to be sure we're on the
same
> > >page as the text reads quite differently to me.
> > >
> > >It reads (to me) that you intend for the hosted file to be MIME 
> > >encoded rather than binary.  Specifically, as [A MIME encoded 
> > >application/pkcs7-mime "certs-only" file  as specified in RFC 2797 
> > >[CMC]"].  When I read this it indicated to me that I am supposed to 
> > >MIME encode the PKCS#7 and name the resultant MIME text file with a 
> > >.p7c extension.  E.g., place the following file content on my web
> server:
> > >
> > >MIME-Version: 1.0
> > >Content-Type: application/pkcs7-mime;
> > >         smime-type="certs-only";
> > >         name="cacerts.p7c"
> > >Content-Transfer-Encoding: base64
> > >Content-Disposition: attachment;
> > >         filename="cacerts.p7c"
> > >
> >
>MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEg
> > >g/
> > >+Q29u
> >
>dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X
> > >05
> > >leHRQ
> > >...
> > >BhcnA===
> > >
> > >
> > >Matt Cooper
> > >Orion Security Solutions
> > >1489 Chain Bridge Road, Suite 300
> > >McLean, Virginia 22101
> > >(Mob) 703.981.2269
> > >(Off) 703.917.0060 x. 30
> > >(Fax) 703.917.0260
> > >Visit our website!
> > >http://www.orionsec.com
> > >
> > >
> > >________________________________
> > >
> > >From: Russ Housley [mailto:[e-mail]]
> > >Sent: Thursday, February 03, 2005 3:39 PM
> > >To: Matt Cooper; [e-mail]
> > >Cc: [e-mail]
> > >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
> > >
> > >
> > >Matt:
> > >
> > >We were not clear.  We did not intend to eliminate the MIME
encoding
> > >which is normally present with HTTP.  The MIME types are specified
in
> > >the referenced documents, I believe.  Rather, we were also stating
a
> > >naming convention for the files that are obtained.
> > >
> > >Russ
> > >
> > >At 03:15 PM 2/3/2005, Matt Cooper wrote:
> > >
> > >
> > >         First, I'd like to say I'm happy to see this come out,
this
> > >is a needed addition for CRLs.
> > >
> > >         All my comments refer to the following snippet extracted 
> > >from the draft
> > >         (
> > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt
> > ><http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt>
):
> > >
> > >         ===begin===
> > >            When the http scheme is specified, the URI MUST point
to a
> > >            certificate file.  The certificate file MUST contain 
> > >either a single
> > >            DER encoded certificate (indicated by the .cer file
> > >extension)
> >or
> > >            contain a certification path (indicated by the .p7c
file
> > >extension):
> > >
> > >               .cer   A single DER encoded certificate as specified
in
> > >                      RFC 2585 [PKIX-CERT].
> > >
> > >               .p7c   A MIME encoded application/pkcs7-mime "certs-
> only"
> >file
> > >                      as specified in RFC 2797 [CMC].
> > >         ===end===
> > >
> > >         Unless this has been required in another document that I
am
> > >unaware of, we should use not use "MIME encoded" for this purpose
for
> > >the following
> > >reasons:
> > >         1. It creates burden on the client.  Why should the client 
> > >need a MIME decoder to verify a CRL?
> > >         2. It creates burden for CA's and CA operators.  They may 
> > >have to learn how to manually encode a PKCS#7 in a MIME structure
if
> > >their CA does not output this for them. This is error prone and may 
> > >lead to
> >problems.
> > >         3. Clients must handle one case as binary and the other
case
> > > as
> >text
> > >         4. Web servers already return MIME types for data; another 
> > >MIME layer is not needed
> > >
> > >         It is not too much to expect that the relying party
software
> > >can distinguish between a binary cert and a binary p7c file. (For 
> > >example, MS CAPI already does this for AIA)  However, to make life 
> > >easier for the client, could we throw in appropriate use of MIME 
> > >types on
> >the web server?
> > >Perhaps something like this:
> > >
> > >         "HTTP server implementations accessed via the URI SHOULD
use
> > >the appropriate MIME content-type for the certificate file.
> > >Specifically, the HTTP server SHOULD return the content-type 
> > >application/pkix-cert for a single DER encoded certificate and 
> > >application/pkcs7-mime for a certs-only PKCS#7.  Consuming clients 
> > >SHOULD use the MIME type as a hint, but should not depend solely on 
> > >the presence of the correct MIME type in the server response."
> > >
> > >         Calling for the contents of the p7c to be "a certification 
> > >path" is too restrictive in my mind.  It would be better to leave 
> > >this wide open and say something like "contain one or more 
> > >certificates that may be helpful to the relying party."  This
leaves
> > >it up to the implementer to put in any certificates that may be 
> > >useful for path construction regardless of whether we have common 
> > >trusted roots.  (They may also wish to not include the entire path, 
> > >but instead only the CRL signer cert, which then has another AIA in
> > >it.)
> > >
> > >         Suggest rewording the text something like this :
> > >
> > >         When the HTTP scheme is specified, the URI MUST point to a 
> > >certificate file. The certificate file MUST be either a single
binary
> > >DER encoded certificate (indicated by the .cer file extension) or a 
> > >single binary DER encoded certs-only PKCS#7 file (indicated by the 
> > >.p7c file
> > >extension) containing one or more certificates that may be helpful
to
> > >the relying party.
> > >
> > >
> > >         Matt Cooper
> > >         Orion Security Solutions
> > >         1489 Chain Bridge Road, Suite 300
> > >         McLean, Virginia 22101
> > >         (Mob) 703.981.2269
> > >         (Off) 703.917.0060 x. 30
> > >         (Fax) 703.917.0260
> > >         Visit our website!
> > >         http://www.orionsec.com <http://www.orionsec.com/>
> > >
> > >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18KdcZh036520; Tue, 8 Feb 2005 12:39:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18Kdcg4036519; Tue, 8 Feb 2005 12:39:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Kdb2n036511 for <[e-mail]>; Tue, 8 Feb 2005 12:39:38 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15200; Tue, 8 Feb 2005 15:39:35 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-gost-cppk-02.txt
Date: Tue, 08 Feb 2005 15:39:35 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: Using the GOST R 34.10-94, GOST R 34.10-2001 and GOST 
			  R 34.11-94 algorithms with the Internet X.509 Public Key 
			  Infrastructure Certificate and CRL Profile.
	Author(s)	: S. Leontiev, D. Shefanovskij
	Filename	: draft-ietf-pkix-gost-cppk-02.txt
	Pages		: 19
	Date		: 2005-2-8
	
This document describes identifiers and appropriate parameters for
   the algorithms GOST R 34.10-94, GOST R 34.10-2001, GOST R 34.11-94,
   and also ASN.1 encoding scheme for digital signatures and public
   keys, used in Internet X.509 Public Key Infrastructure (PKI).  This
   specification extends [RFC3279], 'Algorithms and Identifiers for the
   Internet X.509 Public Key Infrastructure Certificate and Certificate
   Revocation List (CRL) Profile' and, correspondingly, [RFC3280],
   'Internet X.509 Public Key Infrastructure: Certificate and
   Certificate Revocation List (CRL) Profile'. All implementations of
   this specification MUST also satisfy the requirements of [RFC3280].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-gost-cppk-02.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-gost-cppk-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-gost-cppk-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-gost-cppk-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-gost-cppk-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Jg9ff032196; Tue, 8 Feb 2005 11:42:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18Jg9lb032195; Tue, 8 Feb 2005 11:42:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail.exchange.microsoft.com (mail.exchange.microsoft.com [131.107.76.151]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Jg8aP032176 for <[e-mail]>; Tue, 8 Feb 2005 11:42:08 -0800 (PST) (envelope-from [e-mail])
Received: from df-edge-01.exchange.corp.microsoft.com ([157.54.8.149]) by mail.exchange.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 11:41:55 -0800
Received: from df-hub-02.exchange.corp.microsoft.com (157.54.8.23) by df-edge-01.exchange.corp.microsoft.com (157.54.8.149) with Microsoft SMTP Server id 8.0.00218.8; Tue, 8 Feb 2005 11:41:45 -0800
Received: from df-fido-msg.exchange.corp.microsoft.com ([157.54.6.241]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 11:41:52 -0800
Received: from df-courage-msg.exchange.corp.microsoft.com ([157.54.4.14]) by df-fido-msg.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 11:41:57 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Class: urn:content-classes:message
X-MimeOLE: Produced By Microsoft Exchange V6.5.7408.0
X-OriginalArrivalTime: 08 Feb 2005 19:41:57.0922 (UTC) FILETIME=[40352020:01C50E16]
Subject: FW: SCVP 16 comments
Date: Tue, 8 Feb 2005 11:41:54 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP 16 comments
Thread-Index: AcTpahOp8ttidUfRQ0GpWe4rjEFaeAkqId9wAADlVaA=
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j18Jg8aP032190
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

* -----Original Message-----
* From: Trevor Freeman
* Sent: Tuesday, February 08, 2005 11:36 AM
* To: 'Wen-Cheng Wang'
* Subject: RE: SCVP 16 comments
* 
* 
* Hi Wen-Cheng,
* Thanks for these comments. SCVP 17 should be shortly posted
* See below for answers
* Trevor
* * -----Original Message-----
* * From: Wen-Cheng Wang [mailto:[e-mail]]
* * Sent: Thursday, December 23, 2004 7:40 PM
* * To: Trevor Freeman
* * Subject: Fw: SCVP 16 comments
* *
* * Trevor,
* *
* * I would like to remind you that you have not yet responded
* * to my comments on SCVP ID 16.
* *
* * Wen-Cheng Wang
* *
* * ----- Original Message -----
* * From: "Wen-Cheng Wang" <[e-mail]>
* * To: <[e-mail]>
* * Sent: Thursday, December 16, 2004 1:13 AM
* * Subject: SCVP 16 comments
* *
* *
* * >
* * > Here are my comments on SCVP ID 16.
* * >
* * > 1. Page 11:
* * >
* * > The responseRefHash, responseValidationPolByRef, and
* * > signResponse items are now grouped into the the
* * > responseFlags item.
* * >
* * > Therefore, the sentence:
* * >
* * > " A query
* * >   MUST contain a sequence of one or more queriedCerts items as
well
* * >   as one checks, one wantBack and one validationPolicy item; and a
* * >   query MAY also contain responseRefHash,
responseValidationPolByRef,
* * >   signResponse, serverContextInfo, validationTime,
intermediateCerts,
* * >   revInfos, producedAt, and queryExtensions items."
* * >
* * > should be changed to:
* * >
* * > " A query
* * >   MUST contain a sequence of one or more queriedCerts items as
well
* * >   as one checks, one wantBack and one validationPolicy item; and a
* * >   query MAY also contain responseFlags, serverContextInfo,
* * >   validationTime, intermediateCerts, revInfos, producedAt, and
* * >   queryExtensions items."
* [TF] Fixed
* * >
* * > 2. Page 12:
* * >
* * > For the same reason, the sentence:
* * >
* * > " The requestRefHash, responseValidationPolByRef
* * >   and signResponse items allow the client to request optional
* * >   features for the response."
* * >
* * > should be changed to:
* * >
* * > " The responseFlags item allows the client to request optional
* * >   features for the response."
* [TF] Fixed
* * >
* * > 3. Page 13:
* * >
* * > When a client want to build/validate/do revocation check on the
* * > certification path for the AC issuer, it is not clear that whether
* * > the reference to the AC itself or the AC issuer's PKC need to be
* * > send to the server?
* * >
* * > Also, there are no OIDs defined for
* * >
* * >   - Build a certification path to a trust anchor;
* * >   - Build a certification path to a trust anchor for the AC
* * >     issuer
* [TF] the following OID are already defined
* id-stc-build-pkc-path: Build a certification path to a trust anchor;
* id-stc-build-status-checked-aa-path: Build a validated certification
path
* to a trust anchor for the AC issuer and perform
* * >
* * > And I think the following statement is not correct.
* * >
* * >   "Also, building a validated certification path does
* * >    not imply revocation status checks."
* * >
* * > If the server does not perform revocation status checks,
* * > how does it know the certification path is valid or not?
* * >
* * > 4. Page 17:
* * > The following paragraph should not appear in section 3.1.4.1:
* * >
* * > " SCVP servers SHOULD support serverContextInfo.  SCVP clients MAY
* * >   support serverContextInfo"
* [TF] Fixed
* * >
* * > 5. Page 18:
* * >
* * > The following paragraph should be moved to section 3.1.4.1:
* * >
* * > " Neither the clients nor server MUST dereference the URI during
SCVP
* * >   request processing.  The URI is simply used as a reference for
the
* * >   validation policy.  Clients and server MAY dereference the URI
as
* * >   part of configuration."
* [TF] Fixed
* * >
* * > 6. Page 19, 20, 21, 22:
* * > OID names are not consistent. The following substutions are
* * > recommended:
* * >
* * > id-bvae-notYetValid -> id-bvae-not-yet-valid
* * >
* * > id-bvae-wrong-Anchor -> id-bvae-wrong-anchor
* * >
* * > id-bvae-invalid-Key-Usage -> id-bvae-invalid-key-usage
* * >
* * > id-bvae-invalid-Purpose -> id-bvae-invalid-purpose
* * >
* * > id-bvae-invalid-Policy -> id-bvae-invalid-cert-policy
* * >
* * > id-bvae-invalid-Name -> id-bvae-invalid-name
* * >
* * > id-bvae-invalid-Entity -> id-bvae-invalid-entity
* * >
* * > id-bvae-invalid-Depth -> id-bvae-invalid-path-length
* * >
* * > id-bvae-invalidPurpose -> id-bvae-invalid-purpose
* * >
* * > id-bvae-invalidCertPolicy -> id-bvae-invalid-cert-policy
* * >
* * > id-bvae-invalidName -> id-bvae-invalid-name
* * >
* * > id-bvae-invalidEntity -> id-bvae-invalid-entity
* * >
* * > id-bvae-invalidPathDepth -> id-bvae-invalid-path-length
* * >
* * > id-nvae-unknown-pupose -> id-nvae-unknown-purpose
* * >
* * > id-nvae-nameMismatch -> id-nvae-name-mismatch
* * >
* * > id-nvae-noCertName -> id-nvae-no-name
* * >
* * > id-nvae-unknownPupose -> id-nvae-unknown-purpose
* * >
* * > id-nvae-badName -> id-nvae-bad-name
* * >
* * > id-nvae-badNameType -> id-nvae-bad-name-type
* * >
* * > id-nvae-mixedNames -> id-nvae-mixed-names
* [TF] Fixed
* * >
* * > 7. Page 22:
* * >
* * > The following paragraph should not appear in section 3.1.5.2.4:
* * >
* * > " The userPolicySet item specifies a list of policy identifiers
that
* * >   the SCVP server MUST use when forming and validating a
certificate
* * >   If certPolicies is not specified, then any-policy MUST be used."
* [TF] Fixed
* * >
* * > 8. Page 64:
* * >
* * > In the last paragraph of page 64:
* * >
* * > "serverContextInformation" should be "serverContextInfo".
* [TF] Fixed
* * >
* * >
* * > Wen-Cheng Wang
* * >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Jcmqs031961; Tue, 8 Feb 2005 11:38:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18JcmFM031960; Tue, 8 Feb 2005 11:38:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Jclac031949 for <[e-mail]>; Tue, 8 Feb 2005 11:38:47 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Tue, 8 Feb 2005 19:38:39 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Date: Tue, 8 Feb 2005 19:38:50 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
thread-index: AcUODLjPSAmJJorSQ2mbUWsc2kofggABiRpA
From: "Stefan Santesson" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 08 Feb 2005 19:38:39.0542 (UTC) FILETIME=[C9F6BD60:01C50E15]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j18Jcmac031955
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

Thanks for the comments.

Comments in-line;

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Peter Sylvester [mailto:[e-mail]]
> Sent: den 8 februari 2005 19:33
> To: [e-mail]; Stefan Santesson
> Cc: [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> 
> - The abstract says that the defined extension has the same syntax
>   as for certificats.
>   This seems slightly misleading for me since the texts also defines
>   data formats, and does not reuse the existing id-ad-caIssuers.
> 

[Stefan] AIA in Certificates and in CRLs share the same ASN.1 syntax
even if we choose to populate the extension with different data. I think
that is perfectly fine and true for many extensions. I.e. when you use
an extension to serve purpose A you may fill that extension with
different parameters and data than if the extension serve purpose B. Yet
the same extension OID is maintained for both cases and the same syntax
is used.


> - The id-ad-caIssuers definition in 3280 defines the usage of ftp,
http,
>   ldap (but fails together with operationl protocols to completely
>   define the data formats for http and ftp.
> 

[Stefan] This is the initial suggestion but it is debatable. We started
with the minimum set to see whether there was a strong need for anything
else that was not included in version 0. Do you see a strong reason to
expand the proposed set of schemas? If yes, then why?

>   I am not sure that p7c in the current text is really intended to
have
>   another mime encapsulation (as mentioned by D.C.), but if so, what
>   would this be good for?

[Stefan] Hopefully this has been sorted out in recent exchange on the
topic. 

> 
> - Shouldn't the data format be met into an updated operational
>   protocols? This would also allow to say a little bit more
>   about what an http client is supposed to implement as a minimal
>   profile for http.
> 

[Stefan] What we ant to do is to describe what is already widely
deployed for AIA. This is what the text tries to capture. If the text
fails to do that, then we are more than happy to receive suggested
improvements to the text.

> - It doesn't seem extremely useful to me to have several different
>   formats to access to certificat list via http, on for certificats
>   in general (done by Peter Gutmann's text) and another in this
>   text.

[Stefan] This is the fine balance. We want to limit the set as much as
possible but still support current deployments that have been deployed
in conformity with RFC 3280 in good faith. There is simply too much use
of the .p7c file format to ignore it and declare it non-conformant.
There is also the aspect of efficiency, where the p7c format may reveal
a complete chain.

> 
> - Using a suffix .cer or .p7c to determine the content type behind
>   an http uri seems not ok to me, for this AFAIK, http uses mime
types.

[Stefan] I think/hope this one has been sorted out.

> 
> - Yes, I know, we might end with a debate whether a list of certs
>   can be provided best as:
> 
>   - SEQUENCE OF Certificate
>   - a p7c cert only PKCS7/CMS file
>   - a mime multipart containing several individual certificats
>   - same result as with ldap...
> 
>   Well, so be it, ==> 'n' mime types (defined with their file suffix)
>   a an http client can set a list of acceptable mime types, and the
server
>   must return the data in that way. Using undefined length encoding,
>   the first and the second simply mean to encode a fixed prefix and
> suffix,
>   the third is a bit more complicated, etc.
> 

[Stefan] We all agree that the information is stored in raw format and
that MIME encoding is an issue for the transport protocol. Is there
anything more to say about this?

> Peter
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18JHWs4030410; Tue, 8 Feb 2005 11:17:32 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18JHWQn030409; Tue, 8 Feb 2005 11:17:32 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18JHV8G030397 for <[e-mail]>; Tue, 8 Feb 2005 11:17:31 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Feb 2005 19:17:26 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
Date: Tue, 8 Feb 2005 19:17:20 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-crlaia-00.txt comments
thread-index: AcUODdTzr6d8YJ+YShK0qLy6m4+QfQAACXaQAAEnVSA=
From: "Stefan Santesson" <[e-mail]>
To: "Matt Cooper" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 08 Feb 2005 19:17:26.0084 (UTC) FILETIME=[D2EC7840:01C50E12]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j18JHV8G030404
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Matt,

Do you have any proposed wording?
Feel free to make a suggestion.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Matt Cooper [mailto:[e-mail]]
> Sent: den 8 februari 2005 19:50
> To: 'Russ Housley'; Stefan Santesson
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> 
> I knew we would get to the same page eventually. :)
> 
> I'm glad to hear the answer is negative. I, and several others I have
> spoken
> to, took the text in the draft to indicate this extra MIME encoding
was
> the
> proposed requirement. So, I think we simply need to reword that
section to
> be very clear on this point.
> 
> Best Regards,
> 
> Matt Cooper
> Orion Security Solutions
> 1489 Chain Bridge Road, Suite 300
> McLean, Virginia 22101
> (Mob) 703.981.2269
> (Off) 703.917.0060 x. 30
> (Fax) 703.917.0260
> Visit our website!
> http://www.orionsec.com
> 
> 
> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Tuesday, February 08, 2005 1:41 PM
> To: Matt Cooper; [e-mail]
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> 
> Matt:
> 
> Now I understand the issue.  Sorry it took so long for me to
understand
> the
> comment.
> 
> FALSE.
> 
> I expect the server to store a binary .cer and .p7c file.  The only
MIME
> encoding will be applied by the transport protocol.  HTTP will MIME
> encode.
> FTP will not.
> 
> Russ
> 
> At 12:27 PM 2/7/2005, Matt Cooper wrote:
> >Russ,
> >
> >TRUE|FALSE: On the server, you intend for the certificate file
(stored
> >TRUE|on
> >the server's hard disk) to be MIME encoded.
> >
> >The question has nothing to do with HTTP. It could be FTP or NFS for
> >all it matters. What the draft says (to me at least) is that you are
> >supposed to MIME encode the data *BEFORE* the protocol encoding ever
> enters
> the picture.
> >This results in the client receiving a MIME encoded file regardless
of
> >transport protocol.
> >
> >Best Regards,
> >
> >Matt Cooper
> >Orion Security Solutions
> >1489 Chain Bridge Road, Suite 300
> >McLean, Virginia 22101
> >(Mob) 703.981.2269
> >(Off) 703.917.0060 x. 30
> >(Fax) 703.917.0260
> >Visit our website!
> >http://www.orionsec.com
> >
> >
> >-----Original Message-----
> >From: Russ Housley [mailto:[e-mail]]
> >Sent: Friday, February 04, 2005 8:21 AM
> >To: Matt Cooper; [e-mail]
> >Cc: [e-mail]
> >Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> >
> >Matt:
> >
> >MIME supports many encoding types, including binary and base64.  I
> >think that binary will be used in this case, but base64 and other
> >encodings are not prohibited.
> >
> >We should probably say that binary encoding MUST be supported.
> >
> >Russ
> >
> >At 06:29 PM 2/3/2005, Matt Cooper wrote:
> >
> > >Perhaps I was not clear either.  I didn't think you were attempting
> > >to eliminate the HTTP MIME encoding.  And believe me, I'm the first
> > >one to cheer having a naming convention for this purpose!
> > >
> > >Are you saying that your intent was only to apply the MIME encoding
> > >to how the HTTP server should be serving up the files to the
client?
> > >Not trying to be difficult, I just want to be sure we're on the
same
> > >page as the text reads quite differently to me.
> > >
> > >It reads (to me) that you intend for the hosted file to be MIME
> > >encoded rather than binary.  Specifically, as [A MIME encoded
> > >application/pkcs7-mime "certs-only" file  as specified in RFC 2797
> > >[CMC]"].  When I read this it indicated to me that I am supposed to
> > >MIME encode the PKCS#7 and name the resultant MIME text file with a
> > >.p7c extension.  E.g., place the following file content on my web
> server:
> > >
> > >MIME-Version: 1.0
> > >Content-Type: application/pkcs7-mime;
> > >         smime-type="certs-only";
> > >         name="cacerts.p7c"
> > >Content-Transfer-Encoding: base64
> > >Content-Disposition: attachment;
> > >         filename="cacerts.p7c"
> > >
> >
>MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEg
> > >g/
> > >+Q29u
> >
>dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X
> > >05
> > >leHRQ
> > >...
> > >BhcnA===
> > >
> > >
> > >Matt Cooper
> > >Orion Security Solutions
> > >1489 Chain Bridge Road, Suite 300
> > >McLean, Virginia 22101
> > >(Mob) 703.981.2269
> > >(Off) 703.917.0060 x. 30
> > >(Fax) 703.917.0260
> > >Visit our website!
> > >http://www.orionsec.com
> > >
> > >
> > >________________________________
> > >
> > >From: Russ Housley [mailto:[e-mail]]
> > >Sent: Thursday, February 03, 2005 3:39 PM
> > >To: Matt Cooper; [e-mail]
> > >Cc: [e-mail]
> > >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
> > >
> > >
> > >Matt:
> > >
> > >We were not clear.  We did not intend to eliminate the MIME
encoding
> > >which is normally present with HTTP.  The MIME types are specified
in
> > >the referenced documents, I believe.  Rather, we were also stating
a
> > >naming convention for the files that are obtained.
> > >
> > >Russ
> > >
> > >At 03:15 PM 2/3/2005, Matt Cooper wrote:
> > >
> > >
> > >         First, I'd like to say I'm happy to see this come out,
this
> > >is a needed addition for CRLs.
> > >
> > >         All my comments refer to the following snippet extracted
> > >from the draft
> > >         (
> > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt
> > ><http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt>
):
> > >
> > >         ===begin===
> > >            When the http scheme is specified, the URI MUST point
to a
> > >            certificate file.  The certificate file MUST contain
> > >either a single
> > >            DER encoded certificate (indicated by the .cer file
> > >extension)
> >or
> > >            contain a certification path (indicated by the .p7c
file
> > >extension):
> > >
> > >               .cer   A single DER encoded certificate as specified
in
> > >                      RFC 2585 [PKIX-CERT].
> > >
> > >               .p7c   A MIME encoded application/pkcs7-mime "certs-
> only"
> >file
> > >                      as specified in RFC 2797 [CMC].
> > >         ===end===
> > >
> > >         Unless this has been required in another document that I
am
> > >unaware of, we should use not use "MIME encoded" for this purpose
for
> > >the following
> > >reasons:
> > >         1. It creates burden on the client.  Why should the client
> > >need a MIME decoder to verify a CRL?
> > >         2. It creates burden for CA's and CA operators.  They may
> > >have to learn how to manually encode a PKCS#7 in a MIME structure
if
> > >their CA does not output this for them. This is error prone and may
> > >lead to
> >problems.
> > >         3. Clients must handle one case as binary and the other
case
> > > as
> >text
> > >         4. Web servers already return MIME types for data; another
> > >MIME layer is not needed
> > >
> > >         It is not too much to expect that the relying party
software
> > >can distinguish between a binary cert and a binary p7c file. (For
> > >example, MS CAPI already does this for AIA)  However, to make life
> > >easier for the client, could we throw in appropriate use of MIME
> > >types on
> >the web server?
> > >Perhaps something like this:
> > >
> > >         "HTTP server implementations accessed via the URI SHOULD
use
> > >the appropriate MIME content-type for the certificate file.
> > >Specifically, the HTTP server SHOULD return the content-type
> > >application/pkix-cert for a single DER encoded certificate and
> > >application/pkcs7-mime for a certs-only PKCS#7.  Consuming clients
> > >SHOULD use the MIME type as a hint, but should not depend solely on
> > >the presence of the correct MIME type in the server response."
> > >
> > >         Calling for the contents of the p7c to be "a certification
> > >path" is too restrictive in my mind.  It would be better to leave
> > >this wide open and say something like "contain one or more
> > >certificates that may be helpful to the relying party."  This
leaves
> > >it up to the implementer to put in any certificates that may be
> > >useful for path construction regardless of whether we have common
> > >trusted roots.  (They may also wish to not include the entire path,
> > >but instead only the CRL signer cert, which then has another AIA in
> > >it.)
> > >
> > >         Suggest rewording the text something like this :
> > >
> > >         When the HTTP scheme is specified, the URI MUST point to a
> > >certificate file. The certificate file MUST be either a single
binary
> > >DER encoded certificate (indicated by the .cer file extension) or a
> > >single binary DER encoded certs-only PKCS#7 file (indicated by the
> > >.p7c file
> > >extension) containing one or more certificates that may be helpful
to
> > >the relying party.
> > >
> > >
> > >         Matt Cooper
> > >         Orion Security Solutions
> > >         1489 Chain Bridge Road, Suite 300
> > >         McLean, Virginia 22101
> > >         (Mob) 703.981.2269
> > >         (Off) 703.917.0060 x. 30
> > >         (Fax) 703.917.0260
> > >         Visit our website!
> > >         http://www.orionsec.com <http://www.orionsec.com/>
> > >
> > >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IoOLe028509; Tue, 8 Feb 2005 10:50:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18IoOAr028508; Tue, 8 Feb 2005 10:50:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IoNeN028498 for <[e-mail]>; Tue, 8 Feb 2005 10:50:23 -0800 (PST) (envelope-from [e-mail])
Received: from wmcooper (pcp09268965pcs.arlngt01.va.comcast.net [69.143.119.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id j18IoJmX016108; Tue, 8 Feb 2005 13:50:19 -0500
Message-Id: <[e-mail]>
From: "Matt Cooper" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
Date: Tue, 8 Feb 2005 13:49:32 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
In-Reply-To: <[e-mail]>
Thread-Index: AcUODdTzr6d8YJ+YShK0qLy6m4+QfQAACXaQ
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I knew we would get to the same page eventually. :)

I'm glad to hear the answer is negative. I, and several others I have spoken
to, took the text in the draft to indicate this extra MIME encoding was the
proposed requirement. So, I think we simply need to reword that section to
be very clear on this point.

Best Regards,

Matt Cooper
Orion Security Solutions
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101
(Mob) 703.981.2269
(Off) 703.917.0060 x. 30
(Fax) 703.917.0260
Visit our website!
http://www.orionsec.com
 

-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Tuesday, February 08, 2005 1:41 PM
To: Matt Cooper; [e-mail]
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments

Matt:

Now I understand the issue.  Sorry it took so long for me to understand the
comment.

FALSE.

I expect the server to store a binary .cer and .p7c file.  The only MIME
encoding will be applied by the transport protocol.  HTTP will MIME encode.
FTP will not.

Russ

At 12:27 PM 2/7/2005, Matt Cooper wrote:
>Russ,
>
>TRUE|FALSE: On the server, you intend for the certificate file (stored 
>TRUE|on
>the server's hard disk) to be MIME encoded.
>
>The question has nothing to do with HTTP. It could be FTP or NFS for 
>all it matters. What the draft says (to me at least) is that you are 
>supposed to MIME encode the data *BEFORE* the protocol encoding ever enters
the picture.
>This results in the client receiving a MIME encoded file regardless of 
>transport protocol.
>
>Best Regards,
>
>Matt Cooper
>Orion Security Solutions
>1489 Chain Bridge Road, Suite 300
>McLean, Virginia 22101
>(Mob) 703.981.2269
>(Off) 703.917.0060 x. 30
>(Fax) 703.917.0260
>Visit our website!
>http://www.orionsec.com
>
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Friday, February 04, 2005 8:21 AM
>To: Matt Cooper; [e-mail]
>Cc: [e-mail]
>Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
>
>Matt:
>
>MIME supports many encoding types, including binary and base64.  I 
>think that binary will be used in this case, but base64 and other 
>encodings are not prohibited.
>
>We should probably say that binary encoding MUST be supported.
>
>Russ
>
>At 06:29 PM 2/3/2005, Matt Cooper wrote:
>
> >Perhaps I was not clear either.  I didn't think you were attempting 
> >to eliminate the HTTP MIME encoding.  And believe me, I'm the first 
> >one to cheer having a naming convention for this purpose!
> >
> >Are you saying that your intent was only to apply the MIME encoding 
> >to how the HTTP server should be serving up the files to the client?  
> >Not trying to be difficult, I just want to be sure we're on the same 
> >page as the text reads quite differently to me.
> >
> >It reads (to me) that you intend for the hosted file to be MIME 
> >encoded rather than binary.  Specifically, as [A MIME encoded 
> >application/pkcs7-mime "certs-only" file  as specified in RFC 2797 
> >[CMC]"].  When I read this it indicated to me that I am supposed to 
> >MIME encode the PKCS#7 and name the resultant MIME text file with a 
> >.p7c extension.  E.g., place the following file content on my web server:
> >
> >MIME-Version: 1.0
> >Content-Type: application/pkcs7-mime;
> >         smime-type="certs-only";
> >         name="cacerts.p7c"
> >Content-Transfer-Encoding: base64
> >Content-Disposition: attachment;
> >         filename="cacerts.p7c"
> >
> >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEg
> >g/
> >+Q29u
> >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X
> >05
> >leHRQ
> >...
> >BhcnA===
> >
> >
> >Matt Cooper
> >Orion Security Solutions
> >1489 Chain Bridge Road, Suite 300
> >McLean, Virginia 22101
> >(Mob) 703.981.2269
> >(Off) 703.917.0060 x. 30
> >(Fax) 703.917.0260
> >Visit our website!
> >http://www.orionsec.com
> >
> >
> >________________________________
> >
> >From: Russ Housley [mailto:[e-mail]]
> >Sent: Thursday, February 03, 2005 3:39 PM
> >To: Matt Cooper; [e-mail]
> >Cc: [e-mail]
> >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
> >
> >
> >Matt:
> >
> >We were not clear.  We did not intend to eliminate the MIME encoding 
> >which is normally present with HTTP.  The MIME types are specified in 
> >the referenced documents, I believe.  Rather, we were also stating a 
> >naming convention for the files that are obtained.
> >
> >Russ
> >
> >At 03:15 PM 2/3/2005, Matt Cooper wrote:
> >
> >
> >         First, I'd like to say I'm happy to see this come out, this 
> >is a needed addition for CRLs.
> >
> >         All my comments refer to the following snippet extracted 
> >from the draft
> >         (
> >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt
> ><http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt>  ):
> >
> >         ===begin===
> >            When the http scheme is specified, the URI MUST point to a
> >            certificate file.  The certificate file MUST contain 
> >either a single
> >            DER encoded certificate (indicated by the .cer file 
> >extension)
>or
> >            contain a certification path (indicated by the .p7c file
> >extension):
> >
> >               .cer   A single DER encoded certificate as specified in
> >                      RFC 2585 [PKIX-CERT].
> >
> >               .p7c   A MIME encoded application/pkcs7-mime "certs-only"
>file
> >                      as specified in RFC 2797 [CMC].
> >         ===end===
> >
> >         Unless this has been required in another document that I am 
> >unaware of, we should use not use "MIME encoded" for this purpose for 
> >the following
> >reasons:
> >         1. It creates burden on the client.  Why should the client 
> >need a MIME decoder to verify a CRL?
> >         2. It creates burden for CA's and CA operators.  They may 
> >have to learn how to manually encode a PKCS#7 in a MIME structure if 
> >their CA does not output this for them. This is error prone and may 
> >lead to
>problems.
> >         3. Clients must handle one case as binary and the other case 
> > as
>text
> >         4. Web servers already return MIME types for data; another 
> >MIME layer is not needed
> >
> >         It is not too much to expect that the relying party software 
> >can distinguish between a binary cert and a binary p7c file. (For 
> >example, MS CAPI already does this for AIA)  However, to make life 
> >easier for the client, could we throw in appropriate use of MIME 
> >types on
>the web server?
> >Perhaps something like this:
> >
> >         "HTTP server implementations accessed via the URI SHOULD use 
> >the appropriate MIME content-type for the certificate file.
> >Specifically, the HTTP server SHOULD return the content-type 
> >application/pkix-cert for a single DER encoded certificate and 
> >application/pkcs7-mime for a certs-only PKCS#7.  Consuming clients 
> >SHOULD use the MIME type as a hint, but should not depend solely on 
> >the presence of the correct MIME type in the server response."
> >
> >         Calling for the contents of the p7c to be "a certification 
> >path" is too restrictive in my mind.  It would be better to leave 
> >this wide open and say something like "contain one or more 
> >certificates that may be helpful to the relying party."  This leaves 
> >it up to the implementer to put in any certificates that may be 
> >useful for path construction regardless of whether we have common 
> >trusted roots.  (They may also wish to not include the entire path, 
> >but instead only the CRL signer cert, which then has another AIA in
> >it.)
> >
> >         Suggest rewording the text something like this :
> >
> >         When the HTTP scheme is specified, the URI MUST point to a 
> >certificate file. The certificate file MUST be either a single binary 
> >DER encoded certificate (indicated by the .cer file extension) or a 
> >single binary DER encoded certs-only PKCS#7 file (indicated by the 
> >.p7c file
> >extension) containing one or more certificates that may be helpful to 
> >the relying party.
> >
> >
> >         Matt Cooper
> >         Orion Security Solutions
> >         1489 Chain Bridge Road, Suite 300
> >         McLean, Virginia 22101
> >         (Mob) 703.981.2269
> >         (Off) 703.917.0060 x. 30
> >         (Fax) 703.917.0260
> >         Visit our website!
> >         http://www.orionsec.com <http://www.orionsec.com/>
> >
> >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18Ifmob028053; Tue, 8 Feb 2005 10:41:48 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18IfmVn028052; Tue, 8 Feb 2005 10:41:48 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j18IflDa028040 for <[e-mail]>; Tue, 8 Feb 2005 10:41:47 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 9173 invoked by uid 0); 8 Feb 2005 18:41:36 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.128.119) by woodstock.binhost.com with SMTP; 8 Feb 2005 18:41:36 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Tue, 08 Feb 2005 13:41:22 -0500
To: "Matt Cooper" <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Matt:

Now I understand the issue.  Sorry it took so long for me to understand the 
comment.

FALSE.

I expect the server to store a binary .cer and .p7c file.  The only MIME 
encoding will be applied by the transport protocol.  HTTP will MIME 
encode.  FTP will not.

Russ

At 12:27 PM 2/7/2005, Matt Cooper wrote:
>Russ,
>
>TRUE|FALSE: On the server, you intend for the certificate file (stored on
>the server's hard disk) to be MIME encoded.
>
>The question has nothing to do with HTTP. It could be FTP or NFS for all it
>matters. What the draft says (to me at least) is that you are supposed to
>MIME encode the data *BEFORE* the protocol encoding ever enters the picture.
>This results in the client receiving a MIME encoded file regardless of
>transport protocol.
>
>Best Regards,
>
>Matt Cooper
>Orion Security Solutions
>1489 Chain Bridge Road, Suite 300
>McLean, Virginia 22101
>(Mob) 703.981.2269
>(Off) 703.917.0060 x. 30
>(Fax) 703.917.0260
>Visit our website!
>http://www.orionsec.com
>
>
>-----Original Message-----
>From: Russ Housley [mailto:[e-mail]]
>Sent: Friday, February 04, 2005 8:21 AM
>To: Matt Cooper; [e-mail]
>Cc: [e-mail]
>Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
>
>Matt:
>
>MIME supports many encoding types, including binary and base64.  I think
>that binary will be used in this case, but base64 and other encodings are
>not prohibited.
>
>We should probably say that binary encoding MUST be supported.
>
>Russ
>
>At 06:29 PM 2/3/2005, Matt Cooper wrote:
>
> >Perhaps I was not clear either.  I didn't think you were attempting to
> >eliminate the HTTP MIME encoding.  And believe me, I'm the first one to
> >cheer having a naming convention for this purpose!
> >
> >Are you saying that your intent was only to apply the MIME encoding to
> >how the HTTP server should be serving up the files to the client?  Not
> >trying to be difficult, I just want to be sure we're on the same page
> >as the text reads quite differently to me.
> >
> >It reads (to me) that you intend for the hosted file to be MIME encoded
> >rather than binary.  Specifically, as [A MIME encoded
> >application/pkcs7-mime "certs-only" file  as specified in RFC 2797
> >[CMC]"].  When I read this it indicated to me that I am supposed to
> >MIME encode the PKCS#7 and name the resultant MIME text file with a
> >.p7c extension.  E.g., place the following file content on my web server:
> >
> >MIME-Version: 1.0
> >Content-Type: application/pkcs7-mime;
> >         smime-type="certs-only";
> >         name="cacerts.p7c"
> >Content-Transfer-Encoding: base64
> >Content-Disposition: attachment;
> >         filename="cacerts.p7c"
> >
> >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/
> >+Q29u
> >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05
> >leHRQ
> >...
> >BhcnA===
> >
> >
> >Matt Cooper
> >Orion Security Solutions
> >1489 Chain Bridge Road, Suite 300
> >McLean, Virginia 22101
> >(Mob) 703.981.2269
> >(Off) 703.917.0060 x. 30
> >(Fax) 703.917.0260
> >Visit our website!
> >http://www.orionsec.com
> >
> >
> >________________________________
> >
> >From: Russ Housley [mailto:[e-mail]]
> >Sent: Thursday, February 03, 2005 3:39 PM
> >To: Matt Cooper; [e-mail]
> >Cc: [e-mail]
> >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
> >
> >
> >Matt:
> >
> >We were not clear.  We did not intend to eliminate the MIME encoding
> >which is normally present with HTTP.  The MIME types are specified in
> >the referenced documents, I believe.  Rather, we were also stating a
> >naming convention for the files that are obtained.
> >
> >Russ
> >
> >At 03:15 PM 2/3/2005, Matt Cooper wrote:
> >
> >
> >         First, I'd like to say I'm happy to see this come out, this is
> >a needed addition for CRLs.
> >
> >         All my comments refer to the following snippet extracted from
> >the draft
> >         (
> >http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt
> ><http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt>  ):
> >
> >         ===begin===
> >            When the http scheme is specified, the URI MUST point to a
> >            certificate file.  The certificate file MUST contain either
> >a single
> >            DER encoded certificate (indicated by the .cer file extension)
>or
> >            contain a certification path (indicated by the .p7c file
> >extension):
> >
> >               .cer   A single DER encoded certificate as specified in
> >                      RFC 2585 [PKIX-CERT].
> >
> >               .p7c   A MIME encoded application/pkcs7-mime "certs-only"
>file
> >                      as specified in RFC 2797 [CMC].
> >         ===end===
> >
> >         Unless this has been required in another document that I am
> >unaware of, we should use not use "MIME encoded" for this purpose for
> >the following
> >reasons:
> >         1. It creates burden on the client.  Why should the client
> >need a MIME decoder to verify a CRL?
> >         2. It creates burden for CA's and CA operators.  They may have
> >to learn how to manually encode a PKCS#7 in a MIME structure if their
> >CA does not output this for them. This is error prone and may lead to
>problems.
> >         3. Clients must handle one case as binary and the other case as
>text
> >         4. Web servers already return MIME types for data; another
> >MIME layer is not needed
> >
> >         It is not too much to expect that the relying party software
> >can distinguish between a binary cert and a binary p7c file. (For
> >example, MS CAPI already does this for AIA)  However, to make life
> >easier for the client, could we throw in appropriate use of MIME types on
>the web server?
> >Perhaps something like this:
> >
> >         "HTTP server implementations accessed via the URI SHOULD use
> >the appropriate MIME content-type for the certificate file.
> >Specifically, the HTTP server SHOULD return the content-type
> >application/pkix-cert for a single DER encoded certificate and
> >application/pkcs7-mime for a certs-only PKCS#7.  Consuming clients
> >SHOULD use the MIME type as a hint, but should not depend solely on the
> >presence of the correct MIME type in the server response."
> >
> >         Calling for the contents of the p7c to be "a certification
> >path" is too restrictive in my mind.  It would be better to leave this
> >wide open and say something like "contain one or more certificates that
> >may be helpful to the relying party."  This leaves it up to the
> >implementer to put in any certificates that may be useful for path
> >construction regardless of whether we have common trusted roots.  (They
> >may also wish to not include the entire path, but instead only the CRL
> >signer cert, which then has another AIA in
> >it.)
> >
> >         Suggest rewording the text something like this :
> >
> >         When the HTTP scheme is specified, the URI MUST point to a
> >certificate file. The certificate file MUST be either a single binary
> >DER encoded certificate (indicated by the .cer file extension) or a
> >single binary DER encoded certs-only PKCS#7 file (indicated by the .p7c
> >file
> >extension) containing one or more certificates that may be helpful to
> >the relying party.
> >
> >
> >         Matt Cooper
> >         Orion Security Solutions
> >         1489 Chain Bridge Road, Suite 300
> >         McLean, Virginia 22101
> >         (Mob) 703.981.2269
> >         (Off) 703.917.0060 x. 30
> >         (Fax) 703.917.0260
> >         Visit our website!
> >         http://www.orionsec.com <http://www.orionsec.com/>
> >
> >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IXOrU027608; Tue, 8 Feb 2005 10:33:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j18IXOl6027607; Tue, 8 Feb 2005 10:33:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j18IXKLP027595 for <[e-mail]>; Tue, 8 Feb 2005 10:33:23 -0800 (PST) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id j18IXDn18446; Tue, 8 Feb 2005 19:33:13 +0100 (MET)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.8); Tue, 8 Feb 2005 19:33:13 +0100 (MET)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7p1+Sun/8.11.7) id j18IXCn20472; Tue, 8 Feb 2005 19:33:12 +0100 (MET)
Date: Tue, 8 Feb 2005 19:33:12 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

- The abstract says that the defined extension has the same syntax
  as for certificats.
  This seems slightly misleading for me since the texts also defines
  data formats, and does not reuse the existing id-ad-caIssuers.
  
- The id-ad-caIssuers definition in 3280 defines the usage of ftp, http,
  ldap (but fails together with operationl protocols to completely
  define the data formats for http and ftp. 

  I am not sure that p7c in the current text is really intended to have
  another mime encapsulation (as mentioned by D.C.), but if so, what
  would this be good for?

- Shouldn't the data format be met into an updated operational
  protocols? This would also allow to say a little bit more
  about what an http client is supposed to implement as a minimal
  profile for http. 

- It doesn't seem extremely useful to me to have several different
  formats to access to certificat list via http, on for certificats
  in general (done by Peter Gutmann's text) and another in this
  text.

- Using a suffix .cer or .p7c to determine the content type behind
  an http uri seems not ok to me, for this AFAIK, http uses mime types.

- Yes, I know, we might end with a debate whether a list of certs
  can be provided best as:
 
  - SEQUENCE OF Certificate
  - a p7c cert only PKCS7/CMS file
  - a mime multipart containing several individual certificats
  - same result as with ldap...

  Well, so be it, ==> 'n' mime types (defined with their file suffix)
  a an http client can set a list of acceptable mime types, and the server
  must return the data in that way. Using undefined length encoding, 
  the first and the second simply mean to encode a fixed prefix and suffix,
  the third is a bit more complicated, etc. 

Peter






 
    


   



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IREZ6046171; Mon, 7 Feb 2005 10:27:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17IREBk046170; Mon, 7 Feb 2005 10:27:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nb2.stroeder.com (d4-238.dip.isp-service.de [83.121.4.238]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17IR05F046049 for <[e-mail]>; Mon, 7 Feb 2005 10:27:05 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id 1264E77059; Mon,  7 Feb 2005 18:26:26 +0100 (CET)
Received: from nb2.stroeder.com ([127.0.0.1]) by localhost (nb2 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08069-06; Mon,  7 Feb 2005 18:26:21 +0100 (CET)
Received: from [127.0.0.1] (localhost [127.0.0.1]) by nb2.stroeder.com (Postfix) with ESMTP id F35F67706C; Mon,  7 Feb 2005 18:26:18 +0100 (CET)
Message-ID: <[e-mail]>
Date: Mon, 07 Feb 2005 18:26:18 +0100
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217
X-Accept-Language: de-de, de, en-us, en
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
Cc: Matt Cooper <[e-mail]>, [e-mail]
Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.89.6.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new at stroeder.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ Housley wrote:
> 
> At 06:29 PM 2/3/2005, Matt Cooper wrote:
> 
>> When I read this it
>> indicated to me that I am supposed to MIME encode the PKCS#7 and name the
>> resultant MIME text file with a .p7c extension.  E.g., place the 
>> following
>> file content on my web server:
>>
>> MIME-Version: 1.0
>> Content-Type: application/pkcs7-mime;
>>         smime-type="certs-only";
>>         name="cacerts.p7c"
>> Content-Transfer-Encoding: base64
>> Content-Disposition: attachment;
>>         filename="cacerts.p7c"
>>
>> MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/+Q29u 
>> dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05leHRQ 
>> ...
>> BhcnA===
>
> MIME supports many encoding types, including binary and base64.  I think 
> that binary will be used in this case, but base64 and other encodings 
> are not prohibited.
> 
> We should probably say that binary encoding MUST be supported.

Russ, it's still not clear to me whether you and Matt are talking about
the same thing:

I think Matt is talking about the file containing yet another
encapsulated MIME part. As I understand the example he gave the header
lines would *not* be the HTTP header lines. These would be the header of
an additional MIME part stored in the certificate file.

Ciao, Michael.



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HSORN039376; Mon, 7 Feb 2005 09:28:24 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17HSOtI039375; Mon, 7 Feb 2005 09:28:24 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17HSNVh039364 for <[e-mail]>; Mon, 7 Feb 2005 09:28:23 -0800 (PST) (envelope-from [e-mail])
Received: from wmcooper (pcp09268965pcs.arlngt01.va.comcast.net [69.143.119.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id j17HSBmY026352; Mon, 7 Feb 2005 12:28:18 -0500
Message-Id: <[e-mail]>
From: "Matt Cooper" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
Date: Mon, 7 Feb 2005 12:27:18 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcUKvGEmY2Yqj9F1Rg+JCl0qj9UeigABqH2A
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

TRUE|FALSE: On the server, you intend for the certificate file (stored on
the server's hard disk) to be MIME encoded.

The question has nothing to do with HTTP. It could be FTP or NFS for all it
matters. What the draft says (to me at least) is that you are supposed to
MIME encode the data *BEFORE* the protocol encoding ever enters the picture.
This results in the client receiving a MIME encoded file regardless of
transport protocol.

Best Regards,
 
Matt Cooper
Orion Security Solutions
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101
(Mob) 703.981.2269
(Off) 703.917.0060 x. 30
(Fax) 703.917.0260
Visit our website!
http://www.orionsec.com


-----Original Message-----
From: Russ Housley [mailto:[e-mail]] 
Sent: Friday, February 04, 2005 8:21 AM
To: Matt Cooper; [e-mail]
Cc: [e-mail]
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments

Matt:

MIME supports many encoding types, including binary and base64.  I think
that binary will be used in this case, but base64 and other encodings are
not prohibited.

We should probably say that binary encoding MUST be supported.

Russ

At 06:29 PM 2/3/2005, Matt Cooper wrote:

>Perhaps I was not clear either.  I didn't think you were attempting to 
>eliminate the HTTP MIME encoding.  And believe me, I'm the first one to 
>cheer having a naming convention for this purpose!
>
>Are you saying that your intent was only to apply the MIME encoding to 
>how the HTTP server should be serving up the files to the client?  Not 
>trying to be difficult, I just want to be sure we're on the same page 
>as the text reads quite differently to me.
>
>It reads (to me) that you intend for the hosted file to be MIME encoded 
>rather than binary.  Specifically, as [A MIME encoded 
>application/pkcs7-mime "certs-only" file  as specified in RFC 2797 
>[CMC]"].  When I read this it indicated to me that I am supposed to 
>MIME encode the PKCS#7 and name the resultant MIME text file with a 
>.p7c extension.  E.g., place the following file content on my web server:
>
>MIME-Version: 1.0
>Content-Type: application/pkcs7-mime;
>         smime-type="certs-only";
>         name="cacerts.p7c"
>Content-Transfer-Encoding: base64
>Content-Disposition: attachment;
>         filename="cacerts.p7c"
>
>MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/
>+Q29u 
>dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05
>leHRQ
>...
>BhcnA===
>
>
>Matt Cooper
>Orion Security Solutions
>1489 Chain Bridge Road, Suite 300
>McLean, Virginia 22101
>(Mob) 703.981.2269
>(Off) 703.917.0060 x. 30
>(Fax) 703.917.0260
>Visit our website!
>http://www.orionsec.com
>
>
>________________________________
>
>From: Russ Housley [mailto:[e-mail]]
>Sent: Thursday, February 03, 2005 3:39 PM
>To: Matt Cooper; [e-mail]
>Cc: [e-mail]
>Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
>
>
>Matt:
>
>We were not clear.  We did not intend to eliminate the MIME encoding 
>which is normally present with HTTP.  The MIME types are specified in 
>the referenced documents, I believe.  Rather, we were also stating a 
>naming convention for the files that are obtained.
>
>Russ
>
>At 03:15 PM 2/3/2005, Matt Cooper wrote:
>
>
>         First, I'd like to say I'm happy to see this come out, this is 
>a needed addition for CRLs.
>
>         All my comments refer to the following snippet extracted from 
>the draft
>         ( 
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt
><http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt>  ):
>
>         ===begin===
>            When the http scheme is specified, the URI MUST point to a
>            certificate file.  The certificate file MUST contain either 
>a single
>            DER encoded certificate (indicated by the .cer file extension)
or
>            contain a certification path (indicated by the .p7c file
>extension):
>
>               .cer   A single DER encoded certificate as specified in
>                      RFC 2585 [PKIX-CERT].
>
>               .p7c   A MIME encoded application/pkcs7-mime "certs-only"
file
>                      as specified in RFC 2797 [CMC].
>         ===end===
>
>         Unless this has been required in another document that I am 
>unaware of, we should use not use "MIME encoded" for this purpose for 
>the following
>reasons:
>         1. It creates burden on the client.  Why should the client 
>need a MIME decoder to verify a CRL?
>         2. It creates burden for CA's and CA operators.  They may have 
>to learn how to manually encode a PKCS#7 in a MIME structure if their 
>CA does not output this for them. This is error prone and may lead to
problems.
>         3. Clients must handle one case as binary and the other case as
text
>         4. Web servers already return MIME types for data; another 
>MIME layer is not needed
>
>         It is not too much to expect that the relying party software 
>can distinguish between a binary cert and a binary p7c file. (For 
>example, MS CAPI already does this for AIA)  However, to make life 
>easier for the client, could we throw in appropriate use of MIME types on
the web server?
>Perhaps something like this:
>
>         "HTTP server implementations accessed via the URI SHOULD use 
>the appropriate MIME content-type for the certificate file.  
>Specifically, the HTTP server SHOULD return the content-type 
>application/pkix-cert for a single DER encoded certificate and 
>application/pkcs7-mime for a certs-only PKCS#7.  Consuming clients 
>SHOULD use the MIME type as a hint, but should not depend solely on the 
>presence of the correct MIME type in the server response."
>
>         Calling for the contents of the p7c to be "a certification 
>path" is too restrictive in my mind.  It would be better to leave this 
>wide open and say something like "contain one or more certificates that 
>may be helpful to the relying party."  This leaves it up to the 
>implementer to put in any certificates that may be useful for path 
>construction regardless of whether we have common trusted roots.  (They 
>may also wish to not include the entire path, but instead only the CRL 
>signer cert, which then has another AIA in
>it.)
>
>         Suggest rewording the text something like this :
>
>         When the HTTP scheme is specified, the URI MUST point to a 
>certificate file. The certificate file MUST be either a single binary 
>DER encoded certificate (indicated by the .cer file extension) or a 
>single binary DER encoded certs-only PKCS#7 file (indicated by the .p7c 
>file
>extension) containing one or more certificates that may be helpful to 
>the relying party.
>
>
>         Matt Cooper
>         Orion Security Solutions
>         1489 Chain Bridge Road, Suite 300
>         McLean, Virginia 22101
>         (Mob) 703.981.2269
>         (Off) 703.917.0060 x. 30
>         (Fax) 703.917.0260
>         Visit our website!
>         http://www.orionsec.com <http://www.orionsec.com/>
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17Euqtb022900; Mon, 7 Feb 2005 06:56:52 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17EuqQZ022899; Mon, 7 Feb 2005 06:56:52 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur1.microsoft.com (mail-eur1.microsoft.com [213.199.128.139]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17EuoC1022872 for <[e-mail]>; Mon, 7 Feb 2005 06:56:51 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Mon, 7 Feb 2005 14:56:40 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
Date: Mon, 7 Feb 2005 14:56:27 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
thread-index: AcUNIA6T5J+BNWCSRIeIrLrA/s3ttAAA/xlw
From: "Stefan Santesson" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Russ Housley" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 07 Feb 2005 14:56:40.0834 (UTC) FILETIME=[3B370620:01C50D25]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j17EupC1022894
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

It is obvious that you base your objections on the assumption that a CRL
issuer cert MUST be issued by the CA issuing the validated subject cert.

But you also admit that this is what you think the stand should say but
do not say (at least not explicitly).

Quote from your text: "This is not explicitly stated in RFC 3280 for CRL
issuers, but it is for OCSP responders"

I guess it will be useless to get into details before we have sorted out
this major cause of disagreement. But since even you admit that there is
no such requirement in RFC 3280 (nor X.509), I'm not sure what there is
to discuss.


Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: den 7 februari 2005 06:19
> To: Stefan Santesson; Russ Housley
> Cc: pkix
> Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
> 
> Comments on <draft-ietf-pkix-crlaia-00.txt>
> 
> 1. The title and the scope of the document are not in accordance with
the
> content of the document. The document is not simply defining a new
> extension
> that may help to find out a CRL, but is defining a new way to verify
that
> a
> CRL is correct.
> 
> 
> 2. The new way to verify that a CRL is correct is not aligned with the
> current documents.
> 
> According to RFC 3280, page 7, a CRL issuer is an "optional system to
> which
> a CA delegates the publication of certificate revocation lists".
> 
> This means that the CA is responsible of the CRL issuance but may
delegate
> the publication to another entity, while being still legally
responsible
> of
> the issuance of the CRLs.
> 
> The CRL distribution points extension, defined in section 4.2.1.14 of
RFC
> 3280, is the means for the CA to designate the appropriate CRL Issuer.
> When
> the CA is not the CRL issuer, then the cRLIssuer field MUST be present
and
> contain the Name of the CRL issuer. This field has the syntax
> GeneralNames.
> 
> GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName
> 
> GeneralName ::= CHOICE {
>       otherName                       [0]     AnotherName,
>       rfc822Name                      [1]     IA5String,
>       dNSName                         [2]     IA5String,
>       x400Address                     [3]     ORAddress,
>       directoryName                   [4]     Name,
>       ediPartyName                    [5]     EDIPartyName,
>       uniformResourceIdentifier       [6]     IA5String,
>       iPAddress                       [7]     OCTET STRING,
>       registeredID                    [8]     OBJECT IDENTIFIER }
> 
> Since a name is only unambiguous when certified by a CA (two CAs can
> certify
> two different entities but might use the same name for each of them),
the
> straightforward rule to make sure that the name is unambiguous is to
use a
> certificate for that name that has been issued by the CA which has
> designated the CRL Issuer.
> 
> This is not explicitly stated in RFC 3280 for CRL issuers, but it is
for
> OCSP responderx which play a similar function. In page 3 of RFC 2560
we
> have:
> 
> All definitive response messages SHALL be digitally signed. The key
>     used to sign the response MUST belong to one of the following:
> 
>     -- (...)
>     -- (...)
>     -- a CA Designated Responder (Authorized Responder) who holds a
>        *specially marked certificate issued directly by the CA*,
> indicating
>        that the responder may issue OCSP responses for that CA.
> 
> This means that the CRL Issuer must have a *specially marked
certificate
> issued directly by the CA*, indicating that the CRL isssuer may issue
CRLs
> for that CA.
> 
> Having said this, many portions of the text are not acceptable. Only a
few
> examples will be given hereafter.
> 
> 
> 3. The abstract is misleading. The text states:
> "The CRL extension provides a means of discovering and retrieving CRL
> issuer
> certificates." It should say :"The CRL extension provides an
additional
> means of discovering and retrieving CRL issuer certificates."
> 
> 
> 4. The introduction is misleading. The text states:
> 
> " CRL validation is also specified in RFC 3280, which involves the
> constructions of a valid certification path for the CRL issuer".
> 
> There is no concept of "construction of valid certification path for
the
> CRL
> issuer". There is however the concept of a certification path which is
a
> chain of certificates from a "certificate-to-be-tested" up to one of
the
> root keys trusted under the validation policy. For each certificate of
the
> certification path, it must be tested that it is not revoked. As said
> above,
> the CRL issuer is designated by the CA and thus there is the need to
> locate,
> get and verify the CRL issuer certificate that has been issued by the
CA.
> 
> For each certificate of the certification path, there may be the need
to
> capture just ONE CRL issuer certificate and no more.
> 
> The next sentences are inappropriate as well and should be deleted.
> 
> 
> 5. The introduction states:
> 
>     "Standardized methods of finding the certificate of the CRL issuer
are
>     currently available either though an accessible directory location
or
>     through use of the Subject Information Access extension in
>     intermediary CA certificates.  These methods are however not
>     generally applicable, and they do not provide a generic solution
to
>     the problem."
> 
> This text is biased and is incorrect. SIA is equally applicable and
also
> provides a generic solution to the problem. It has simply to do with
using
> an extension which points downwards or upwards.
> 
> The key point is that the certification path (as described in RFC
3280)
> needs first to be build. Once it is built, and only once this is done,
the
> question is whether or not all certificates of the path are not
revoked.
> This means that it is possible to look up in every certificate of the
> certification path and find out the extensions which are present.
There is
> no superiority to the new proposed extension, if SIA is populated.
> 
> 
> 6. The introduction states:
> 
>     This document provides a straightforward and generic solution to
the
>     CRL issuer certification path building problem by permitting use
of
>     the Authority Information Access extension in CRLs, enabling a CRL
>     checking application to use the same access method
(id-ad-caIssuers)
>     to locate the certificate of the CRL issuer and, if necessary,
>     complete the CRL issuer certification path building to an
appropriate
>     trust anchor.
> 
> Based on the previous arguments, this text is incorrect as well since
> there
> is no "CRL issuer certification path building problem".
> 
> Major changes to this document are required to go any further. Until
an
> agreement can be reached on the previous issues, it does not make
sense to
> discuss the remaining of the document.
> 
> Denis
> 
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509)
> Working Group of the IETF.
> >
> > 	Title		: Internet X.509 Public Key
> Infrastructure Authority
> > 			  Information Access CRL Extension
> > 	Author(s)	: S. Santesson, R. Housley
> > 	Filename	: draft-ietf-pkix-crlaia-00.txt
> > 	Pages		: 7
> > 	Date		: 2005-1-26
> >
> > This document updates RFC 3280 by defining the Authority Information
> >    Access Certificate Revocation Lists (CRL) extension.  RFC 3280
> >    defines the Authority Information Access certificate extension
using
> >    the same syntax.  The CRL extension provides a means of
discovering
> >    and retrieving CRL issuer certificates.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt
> 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17EJTmX019068; Mon, 7 Feb 2005 06:19:29 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j17EJTH9019067; Mon, 7 Feb 2005 06:19:29 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j17EJOBv019047 for <[e-mail]>; Mon, 7 Feb 2005 06:19:26 -0800 (PST) (envelope-from [e-mail])
Received: from cln-m001.frcl.bull.fr (cln-m001.frcl.bull.fr [129.182.91.40]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA51292; Mon, 7 Feb 2005 15:32:27 +0100
Received: from bull.net ([129.182.108.120]) by cln-m001.frcl.bull.fr (Lotus Domino Release 5.0.10) with ESMTP id 2005020715185603:2318 ; Mon, 7 Feb 2005 15:18:56 +0100 
Message-ID: <[e-mail]>
Date: Mon, 07 Feb 2005 15:19:25 +0100
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>, Russ Housley <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-crlaia-00.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 07/02/2005 15:18:56, Serialize by Router on CLN-M001/FR/BULL(Release 5.0.10 |March 22, 2002) at 07/02/2005 15:18:59, Serialize complete at 07/02/2005 15:18:59
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j17EJTBv019062
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Comments on <draft-ietf-pkix-crlaia-00.txt>

1. The title and the scope of the document are not in accordance with the 
content of the document. The document is not simply defining a new extension 
that may help to find out a CRL, but is defining a new way to verify that a 
CRL is correct.


2. The new way to verify that a CRL is correct is not aligned with the 
current documents.

According to RFC 3280, page 7, a CRL issuer is an “optional system to which 
a CA delegates the publication of certificate revocation lists”.

This means that the CA is responsible of the CRL issuance but may delegate 
the publication to another entity, while being still legally responsible of 
the issuance of the CRLs.

The CRL distribution points extension, defined in section 4.2.1.14 of RFC 
3280, is the means for the CA to designate the appropriate CRL Issuer. When 
the CA is not the CRL issuer, then the cRLIssuer field MUST be present and 
contain the Name of the CRL issuer. This field has the syntax GeneralNames.

GeneralNames ::= SEQUENCE SIZE (1..MAX) OF GeneralName

GeneralName ::= CHOICE {
      otherName                       [0]     AnotherName,
      rfc822Name                      [1]     IA5String,
      dNSName                         [2]     IA5String,
      x400Address                     [3]     ORAddress,
      directoryName                   [4]     Name,
      ediPartyName                    [5]     EDIPartyName,
      uniformResourceIdentifier       [6]     IA5String,
      iPAddress                       [7]     OCTET STRING,
      registeredID                    [8]     OBJECT IDENTIFIER }

Since a name is only unambiguous when certified by a CA (two CAs can certify 
two different entities but might use the same name for each of them), the 
straightforward rule to make sure that the name is unambiguous is to use a 
certificate for that name that has been issued by the CA which has 
designated the CRL Issuer.

This is not explicitly stated in RFC 3280 for CRL issuers, but it is for 
OCSP responderx which play a similar function. In page 3 of RFC 2560 we have:

All definitive response messages SHALL be digitally signed. The key
    used to sign the response MUST belong to one of the following:

    -- (...)
    -- (...)
    -- a CA Designated Responder (Authorized Responder) who holds a
       *specially marked certificate issued directly by the CA*, indicating
       that the responder may issue OCSP responses for that CA.

This means that the CRL Issuer must have a *specially marked certificate 
issued directly by the CA*, indicating that the CRL isssuer may issue CRLs 
for that CA.

Having said this, many portions of the text are not acceptable. Only a few 
examples will be given hereafter.


3. The abstract is misleading. The text states:
“The CRL extension provides a means of discovering and retrieving CRL issuer 
certificates.” It should say :“The CRL extension provides an additional 
means of discovering and retrieving CRL issuer certificates.”


4. The introduction is misleading. The text states:

“ CRL validation is also specified in RFC 3280, which involves the 
constructions of a valid certification path for the CRL issuer”.

There is no concept of “construction of valid certification path for the CRL 
issuer”. There is however the concept of a certification path which is a 
chain of certificates from a “certificate-to—be-tested” up to one of the 
root keys trusted under the validation policy. For each certificate of the 
certification path, it must be tested that it is not revoked. As said above, 
the CRL issuer is designated by the CA and thus there is the need to locate, 
get and verify the CRL issuer certificate that has been issued by the CA.

For each certificate of the certification path, there may be the need to 
capture just ONE CRL issuer certificate and no more.

The next sentences are inappropriate as well and should be deleted.


5. The introduction states:

    “Standardized methods of finding the certificate of the CRL issuer are
    currently available either though an accessible directory location or
    through use of the Subject Information Access extension in
    intermediary CA certificates.  These methods are however not
    generally applicable, and they do not provide a generic solution to
    the problem.”

This text is biased and is incorrect. SIA is equally applicable and also 
provides a generic solution to the problem. It has simply to do with using 
an extension which points downwards or upwards.

The key point is that the certification path (as described in RFC 3280) 
needs first to be build. Once it is built, and only once this is done, the 
question is whether or not all certificates of the path are not revoked. 
This means that it is possible to look up in every certificate of the 
certification path and find out the extensions which are present. There is 
no superiority to the new proposed extension, if SIA is populated.


6. The introduction states:

    This document provides a straightforward and generic solution to the
    CRL issuer certification path building problem by permitting use of
    the Authority Information Access extension in CRLs, enabling a CRL
    checking application to use the same access method (id-ad-caIssuers)
    to locate the certificate of the CRL issuer and, if necessary,
    complete the CRL issuer certification path building to an appropriate
    trust anchor.

Based on the previous arguments, this text is incorrect as well since there 
is no “CRL issuer certification path building problem”.

Major changes to this document are required to go any further. Until an 
agreement can be reached on the previous issues, it does not make sense to 
discuss the remaining of the document.

Denis


> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
> 	Title		: Internet X.509 Public Key Infrastructure Authority 
> 			  Information Access CRL Extension
> 	Author(s)	: S. Santesson, R. Housley
> 	Filename	: draft-ietf-pkix-crlaia-00.txt
> 	Pages		: 7
> 	Date		: 2005-1-26
> 	
> This document updates RFC 3280 by defining the Authority Information
>    Access Certificate Revocation Lists (CRL) extension.  RFC 3280
>    defines the Authority Information Access certificate extension using
>    the same syntax.  The CRL extension provides a means of discovering
>    and retrieving CRL issuer certificates.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt





Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LtLvl000592; Fri, 4 Feb 2005 13:55:21 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14LtLgH000591; Fri, 4 Feb 2005 13:55:21 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14LtKiY000585 for <[e-mail]>; Fri, 4 Feb 2005 13:55:21 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 24365 invoked by uid 0); 4 Feb 2005 21:55:12 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.44.43) by woodstock.binhost.com with SMTP; 4 Feb 2005 21:55:12 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Fri, 04 Feb 2005 16:54:57 -0500
To: "Stefan Santesson" <[e-mail]>, "Matt Cooper" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
Cc: <[e-mail]>
In-Reply-To: <[e-mail] .corp.microsoft.com>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have no problem including certificate that may be useful in path 
construction in the .p7c.

Russ

At 04:35 PM 2/4/2005, Stefan Santesson wrote:
>Yes, we just want to express that which is the current practice.
>
>I guess that limits to binary and base64 encoded .cer file and binary
>.p7c
>
>Except from this I agree to Matt that it would be nice to loosen up the
>requirement on what certificates that is included in a .p7c file. Maybe
>"certificate path" is too restrictive. I have no problem with Matt's
>suggested change here.
>
>Stefan Santesson
>Microsoft Security Center of Excellence (SCOE)
>
> > -----Original Message-----
> > From: [e-mail]
>[mailto:[e-mail]]
> > On Behalf Of Russ Housley
> > Sent: den 4 februari 2005 05:21
> > To: Matt Cooper; Stefan Santesson
> > Cc: [e-mail]
> > Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> >
> >
> > Matt:
> >
> > MIME supports many encoding types, including binary and base64.  I
>think
> > that binary will be used in this case, but base64 and other encodings
>are
> > not prohibited.
> >
> > We should probably say that binary encoding MUST be supported.
> >
> > Russ
> >
> > At 06:29 PM 2/3/2005, Matt Cooper wrote:
> >
> > >Perhaps I was not clear either.  I didn't think you were attempting
>to
> > >eliminate the HTTP MIME encoding.  And believe me, I'm the first one
>to
> > >cheer having a naming convention for this purpose!
> > >
> > >Are you saying that your intent was only to apply the MIME encoding
>to
> > how
> > >the HTTP server should be serving up the files to the client?  Not
>trying
> > to
> > >be difficult, I just want to be sure we're on the same page as the
>text
> > >reads quite differently to me.
> > >
> > >It reads (to me) that you intend for the hosted file to be MIME
>encoded
> > >rather than binary.  Specifically, as [A MIME encoded
>application/pkcs7-
> > mime
> > >"certs-only" file  as specified in RFC 2797 [CMC]"].  When I read
>this it
> > >indicated to me that I am supposed to MIME encode the PKCS#7 and name
>the
> > >resultant MIME text file with a .p7c extension.  E.g., place the
> > following
> > >file content on my web server:
> > >
> > >MIME-Version: 1.0
> > >Content-Type: application/pkcs7-mime;
> > >         smime-type="certs-only";
> > >         name="cacerts.p7c"
> > >Content-Transfer-Encoding: base64
> > >Content-Disposition: attachment;
> > >         filename="cacerts.p7c"
> > >
> >
> >MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/
>+Q
> > 29u
> >
> >dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05
>le
> > HRQ
> > >...
> > >BhcnA===
> > >
> > >
> > >Matt Cooper
> > >Orion Security Solutions
> > >1489 Chain Bridge Road, Suite 300
> > >McLean, Virginia 22101
> > >(Mob) 703.981.2269
> > >(Off) 703.917.0060 x. 30
> > >(Fax) 703.917.0260
> > >Visit our website!
> > >http://www.orionsec.com
> > >
> > >
> > >________________________________
> > >
> > >From: Russ Housley [mailto:[e-mail]]
> > >Sent: Thursday, February 03, 2005 3:39 PM
> > >To: Matt Cooper; [e-mail]
> > >Cc: [e-mail]
> > >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
> > >
> > >
> > >Matt:
> > >
> > >We were not clear.  We did not intend to eliminate the MIME encoding
> > which
> > >is normally present with HTTP.  The MIME types are specified in the
> > >referenced documents, I believe.  Rather, we were also stating a
>naming
> > >convention for the files that are obtained.
> > >
> > >Russ
> > >
> > >At 03:15 PM 2/3/2005, Matt Cooper wrote:
> > >
> > >
> > >         First, I'd like to say I'm happy to see this come out, this
>is a
> > >needed addition for CRLs.
> > >
> > >         All my comments refer to the following snippet extracted
>from
> > the
> > >draft
> > >         (
>http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-
> > 00.txt
> > ><http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt>
>):
> > >
> > >         ===begin===
> > >            When the http scheme is specified, the URI MUST point to
>a
> > >            certificate file.  The certificate file MUST contain
>either a
> > >single
> > >            DER encoded certificate (indicated by the .cer file
> > extension) or
> > >            contain a certification path (indicated by the .p7c file
> > >extension):
> > >
> > >               .cer   A single DER encoded certificate as specified
>in
> > >                      RFC 2585 [PKIX-CERT].
> > >
> > >               .p7c   A MIME encoded application/pkcs7-mime
>"certs-only"
> > file
> > >                      as specified in RFC 2797 [CMC].
> > >         ===end===
> > >
> > >         Unless this has been required in another document that I am
> > unaware
> > >of, we should use not use "MIME encoded" for this purpose for the
> > following
> > >reasons:
> > >         1. It creates burden on the client.  Why should the client
>need
> > a
> > >MIME decoder to verify a CRL?
> > >         2. It creates burden for CA's and CA operators.  They may
>have
> > to
> > >learn how to manually encode a PKCS#7 in a MIME structure if their CA
> > does
> > >not output this for them. This is error prone and may lead to
>problems.
> > >         3. Clients must handle one case as binary and the other case
>as
> > text
> > >         4. Web servers already return MIME types for data; another
>MIME
> > >layer is not needed
> > >
> > >         It is not too much to expect that the relying party software
>can
> > >distinguish between a binary cert and a binary p7c file. (For
>example, MS
> > >CAPI already does this for AIA)  However, to make life easier for the
> > >client, could we throw in appropriate use of MIME types on the web
> > server?
> > >Perhaps something like this:
> > >
> > >         "HTTP server implementations accessed via the URI SHOULD use
>the
> > >appropriate MIME content-type for the certificate file.
>Specifically,
> > the
> > >HTTP server SHOULD return the content-type application/pkix-cert for
>a
> > >single DER encoded certificate and application/pkcs7-mime for a
>certs-
> > only
> > >PKCS#7.  Consuming clients SHOULD use the MIME type as a hint, but
>should
> > >not depend solely on the presence of the correct MIME type in the
>server
> > >response."
> > >
> > >         Calling for the contents of the p7c to be "a certification
>path"
> > is
> > >too restrictive in my mind.  It would be better to leave this wide
>open
> > and
> > >say something like "contain one or more certificates that may be
>helpful
> > to
> > >the relying party."  This leaves it up to the implementer to put in
>any
> > >certificates that may be useful for path construction regardless of
> > whether
> > >we have common trusted roots.  (They may also wish to not include the
> > entire
> > >path, but instead only the CRL signer cert, which then has another
>AIA in
> > >it.)
> > >
> > >         Suggest rewording the text something like this :
> > >
> > >         When the HTTP scheme is specified, the URI MUST point to a
> > >certificate file. The certificate file MUST be either a single binary
>DER
> > >encoded certificate (indicated by the .cer file extension) or a
>single
> > >binary DER encoded certs-only PKCS#7 file (indicated by the .p7c file
> > >extension) containing one or more certificates that may be helpful to
>the
> > >relying party.
> > >
> > >
> > >         Matt Cooper
> > >         Orion Security Solutions
> > >         1489 Chain Bridge Road, Suite 300
> > >         McLean, Virginia 22101
> > >         (Mob) 703.981.2269
> > >         (Off) 703.917.0060 x. 30
> > >         (Fax) 703.917.0260
> > >         Visit our website!
> > >         http://www.orionsec.com <http://www.orionsec.com/>
> > >
> > >



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LZcBN099269; Fri, 4 Feb 2005 13:35:38 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14LZc02099268; Fri, 4 Feb 2005 13:35:38 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail-eur.microsoft.com (mail-eur.microsoft.com [213.199.128.145]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14LZbOq099248 for <[e-mail]>; Fri, 4 Feb 2005 13:35:37 -0800 (PST) (envelope-from [e-mail])
Received: from EUR-MSG-03.europe.corp.microsoft.com ([65.53.192.44]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 4 Feb 2005 21:36:58 +0000
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
Date: Fri, 4 Feb 2005 21:35:00 -0000
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: draft-ietf-pkix-crlaia-00.txt comments
thread-index: AcUKz4KgFsFUT136QGK2avMXYo/tzwAMTy7w
From: "Stefan Santesson" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Matt Cooper" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 04 Feb 2005 21:36:58.0687 (UTC) FILETIME=[A7BB4CF0:01C50B01]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id j14LZbOq099263
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes, we just want to express that which is the current practice. 

I guess that limits to binary and base64 encoded .cer file and binary
.p7c

Except from this I agree to Matt that it would be nice to loosen up the
requirement on what certificates that is included in a .p7c file. Maybe
"certificate path" is too restrictive. I have no problem with Matt's
suggested change here.

Stefan Santesson
Microsoft Security Center of Excellence (SCOE)
 
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Russ Housley
> Sent: den 4 februari 2005 05:21
> To: Matt Cooper; Stefan Santesson
> Cc: [e-mail]
> Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
> 
> 
> Matt:
> 
> MIME supports many encoding types, including binary and base64.  I
think
> that binary will be used in this case, but base64 and other encodings
are
> not prohibited.
> 
> We should probably say that binary encoding MUST be supported.
> 
> Russ
> 
> At 06:29 PM 2/3/2005, Matt Cooper wrote:
> 
> >Perhaps I was not clear either.  I didn't think you were attempting
to
> >eliminate the HTTP MIME encoding.  And believe me, I'm the first one
to
> >cheer having a naming convention for this purpose!
> >
> >Are you saying that your intent was only to apply the MIME encoding
to
> how
> >the HTTP server should be serving up the files to the client?  Not
trying
> to
> >be difficult, I just want to be sure we're on the same page as the
text
> >reads quite differently to me.
> >
> >It reads (to me) that you intend for the hosted file to be MIME
encoded
> >rather than binary.  Specifically, as [A MIME encoded
application/pkcs7-
> mime
> >"certs-only" file  as specified in RFC 2797 [CMC]"].  When I read
this it
> >indicated to me that I am supposed to MIME encode the PKCS#7 and name
the
> >resultant MIME text file with a .p7c extension.  E.g., place the
> following
> >file content on my web server:
> >
> >MIME-Version: 1.0
> >Content-Type: application/pkcs7-mime;
> >         smime-type="certs-only";
> >         name="cacerts.p7c"
> >Content-Transfer-Encoding: base64
> >Content-Disposition: attachment;
> >         filename="cacerts.p7c"
> >
>
>MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/
+Q
> 29u
>
>dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05
le
> HRQ
> >...
> >BhcnA===
> >
> >
> >Matt Cooper
> >Orion Security Solutions
> >1489 Chain Bridge Road, Suite 300
> >McLean, Virginia 22101
> >(Mob) 703.981.2269
> >(Off) 703.917.0060 x. 30
> >(Fax) 703.917.0260
> >Visit our website!
> >http://www.orionsec.com
> >
> >
> >________________________________
> >
> >From: Russ Housley [mailto:[e-mail]]
> >Sent: Thursday, February 03, 2005 3:39 PM
> >To: Matt Cooper; [e-mail]
> >Cc: [e-mail]
> >Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
> >
> >
> >Matt:
> >
> >We were not clear.  We did not intend to eliminate the MIME encoding
> which
> >is normally present with HTTP.  The MIME types are specified in the
> >referenced documents, I believe.  Rather, we were also stating a
naming
> >convention for the files that are obtained.
> >
> >Russ
> >
> >At 03:15 PM 2/3/2005, Matt Cooper wrote:
> >
> >
> >         First, I'd like to say I'm happy to see this come out, this
is a
> >needed addition for CRLs.
> >
> >         All my comments refer to the following snippet extracted
from
> the
> >draft
> >         (
http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-
> 00.txt
> ><http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt>
):
> >
> >         ===begin===
> >            When the http scheme is specified, the URI MUST point to
a
> >            certificate file.  The certificate file MUST contain
either a
> >single
> >            DER encoded certificate (indicated by the .cer file
> extension) or
> >            contain a certification path (indicated by the .p7c file
> >extension):
> >
> >               .cer   A single DER encoded certificate as specified
in
> >                      RFC 2585 [PKIX-CERT].
> >
> >               .p7c   A MIME encoded application/pkcs7-mime
"certs-only"
> file
> >                      as specified in RFC 2797 [CMC].
> >         ===end===
> >
> >         Unless this has been required in another document that I am
> unaware
> >of, we should use not use "MIME encoded" for this purpose for the
> following
> >reasons:
> >         1. It creates burden on the client.  Why should the client
need
> a
> >MIME decoder to verify a CRL?
> >         2. It creates burden for CA's and CA operators.  They may
have
> to
> >learn how to manually encode a PKCS#7 in a MIME structure if their CA
> does
> >not output this for them. This is error prone and may lead to
problems.
> >         3. Clients must handle one case as binary and the other case
as
> text
> >         4. Web servers already return MIME types for data; another
MIME
> >layer is not needed
> >
> >         It is not too much to expect that the relying party software
can
> >distinguish between a binary cert and a binary p7c file. (For
example, MS
> >CAPI already does this for AIA)  However, to make life easier for the
> >client, could we throw in appropriate use of MIME types on the web
> server?
> >Perhaps something like this:
> >
> >         "HTTP server implementations accessed via the URI SHOULD use
the
> >appropriate MIME content-type for the certificate file.
Specifically,
> the
> >HTTP server SHOULD return the content-type application/pkix-cert for
a
> >single DER encoded certificate and application/pkcs7-mime for a
certs-
> only
> >PKCS#7.  Consuming clients SHOULD use the MIME type as a hint, but
should
> >not depend solely on the presence of the correct MIME type in the
server
> >response."
> >
> >         Calling for the contents of the p7c to be "a certification
path"
> is
> >too restrictive in my mind.  It would be better to leave this wide
open
> and
> >say something like "contain one or more certificates that may be
helpful
> to
> >the relying party."  This leaves it up to the implementer to put in
any
> >certificates that may be useful for path construction regardless of
> whether
> >we have common trusted roots.  (They may also wish to not include the
> entire
> >path, but instead only the CRL signer cert, which then has another
AIA in
> >it.)
> >
> >         Suggest rewording the text something like this :
> >
> >         When the HTTP scheme is specified, the URI MUST point to a
> >certificate file. The certificate file MUST be either a single binary
DER
> >encoded certificate (indicated by the .cer file extension) or a
single
> >binary DER encoded certs-only PKCS#7 file (indicated by the .p7c file
> >extension) containing one or more certificates that may be helpful to
the
> >relying party.
> >
> >
> >         Matt Cooper
> >         Orion Security Solutions
> >         1489 Chain Bridge Road, Suite 300
> >         McLean, Virginia 22101
> >         (Mob) 703.981.2269
> >         (Off) 703.917.0060 x. 30
> >         (Fax) 703.917.0260
> >         Visit our website!
> >         http://www.orionsec.com <http://www.orionsec.com/>
> >
> >




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Ji6iq090358; Fri, 4 Feb 2005 11:44:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Ji6FF090357; Fri, 4 Feb 2005 11:44:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14JhvXn090299 for <[e-mail]>; Fri, 4 Feb 2005 11:44:01 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 6898 invoked by uid 0); 4 Feb 2005 19:43:24 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.44.43) by woodstock.binhost.com with SMTP; 4 Feb 2005 19:43:24 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Fri, 04 Feb 2005 14:41:42 -0500
To: Juergen Brauckmann <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: AIA and draft-ietf-pkix-crlaia-00.txt 
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Juergen:

The Authority Information Access Extension provides information about the 
issuer of the certificate that contains the extension.

Russ

At 09:38 AM 2/4/2005, Juergen Brauckmann wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>
>Hi.
>
>In Chapter 1 you are saying:
>    RFC 3280 [PKIX1] has provided for bottom-up discovery of
>    certification paths through the Authority Information Access
>    extension, where the id-ad-caIssuers access method may specify one or
>    more accessLocation fields that contain references to CA certificates
>    superior to the certificate containing this extension.
>
>That is, the intention of id-ad-caIssuers is to provide a link to the
>direct issuer of the certificate containing the extension, and to CA
>certificates that are further up the chain.
>
>But chapter 4.2.1.1 in RFC 3280 says (4th paragraph):
>   The id-ad-caIssuers OID is used when the additional information lists
>   CAs that have issued certificates superior to the CA that issued the
>   certificate containing this extension.
>
>If I'm reading this sentence, I understand that you should only provide
>a link to the *issuer* of the CA of the certificate containing the
>extension, one level higher up in the hierarchy.
>=> Is my interpretation of the sentence wrong?
>
>Please correct me... .
>
>Regards,
>   Juergen
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.2.4 (GNU/Linux)
>Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
>iQEVAwUBQgOI5tbYU3wuWc8tAQE3Jgf+K+4rBYoYZ157ZtKVhdVBBzxqecV8wTeO
>o2lnTF+PrgdxrLErSykC7IelS9qDv9tV382ZiX2jRSTEqe3rwr1gWILRby6n3lup
>QkhU8w3LzsN8lhcTpo9RhsWaZJ+4ReTSFPN4rIGQBd9qiOB3FNw/Jug84pzI/hV3
>FFNH4B/dSkmsSoY8SvcqRxa2GZrWOQKjPPEFtZIaIVYR1g6h6+PBkj5WyMwyE4Rw
>h0+mO2/gRfL5YRTbfKMFjW03PCXuAr/C6RalQJJuzoObE7fiHE//DqpIK6lV7EKX
>QmGrf3GzvwIv+mBZqzhhW6sMGtZstUIwm2l9QrNL0U4j+kfbt+Js8A==
>=WC/B
>-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Ed2Pb062691; Fri, 4 Feb 2005 06:39:02 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14Ed2k5062690; Fri, 4 Feb 2005 06:39:02 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from sam.dfn-cert.de (sam.dfn-cert.de [193.174.13.103]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14Ed1g2062683 for <[e-mail]>; Fri, 4 Feb 2005 06:39:02 -0800 (PST) (envelope-from [e-mail])
Message-ID: <[e-mail]>
Date: Fri, 04 Feb 2005 15:38:30 +0100
From: Juergen Brauckmann <[e-mail]>
Organization: DFN-CERT Services GmbH
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040913
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: AIA and draft-ietf-pkix-crlaia-00.txt 
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.86.1.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

-----BEGIN PGP SIGNED MESSAGE-----

Hi.

In Chapter 1 you are saying:
   RFC 3280 [PKIX1] has provided for bottom-up discovery of
   certification paths through the Authority Information Access
   extension, where the id-ad-caIssuers access method may specify one or
   more accessLocation fields that contain references to CA certificates
   superior to the certificate containing this extension.

That is, the intention of id-ad-caIssuers is to provide a link to the
direct issuer of the certificate containing the extension, and to CA
certificates that are further up the chain.

But chapter 4.2.1.1 in RFC 3280 says (4th paragraph):
  The id-ad-caIssuers OID is used when the additional information lists
  CAs that have issued certificates superior to the CA that issued the
  certificate containing this extension.

If I'm reading this sentence, I understand that you should only provide
a link to the *issuer* of the CA of the certificate containing the
extension, one level higher up in the hierarchy.
=> Is my interpretation of the sentence wrong?

Please correct me... .

Regards,
  Juergen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBQgOI5tbYU3wuWc8tAQE3Jgf+K+4rBYoYZ157ZtKVhdVBBzxqecV8wTeO
o2lnTF+PrgdxrLErSykC7IelS9qDv9tV382ZiX2jRSTEqe3rwr1gWILRby6n3lup
QkhU8w3LzsN8lhcTpo9RhsWaZJ+4ReTSFPN4rIGQBd9qiOB3FNw/Jug84pzI/hV3
FFNH4B/dSkmsSoY8SvcqRxa2GZrWOQKjPPEFtZIaIVYR1g6h6+PBkj5WyMwyE4Rw
h0+mO2/gRfL5YRTbfKMFjW03PCXuAr/C6RalQJJuzoObE7fiHE//DqpIK6lV7EKX
QmGrf3GzvwIv+mBZqzhhW6sMGtZstUIwm2l9QrNL0U4j+kfbt+Js8A==
=WC/B
-----END PGP SIGNATURE-----



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j14DL6Cu048679; Fri, 4 Feb 2005 05:21:06 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j14DL6ds048678; Fri, 4 Feb 2005 05:21:06 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j14DL5Us048665 for <[e-mail]>; Fri, 4 Feb 2005 05:21:06 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 25593 invoked by uid 0); 4 Feb 2005 13:21:03 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.33.237) by woodstock.binhost.com with SMTP; 4 Feb 2005 13:21:03 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Fri, 04 Feb 2005 08:21:01 -0500
To: "Matt Cooper" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Matt:

MIME supports many encoding types, including binary and base64.  I think 
that binary will be used in this case, but base64 and other encodings are 
not prohibited.

We should probably say that binary encoding MUST be supported.

Russ

At 06:29 PM 2/3/2005, Matt Cooper wrote:

>Perhaps I was not clear either.  I didn't think you were attempting to
>eliminate the HTTP MIME encoding.  And believe me, I'm the first one to
>cheer having a naming convention for this purpose!
>
>Are you saying that your intent was only to apply the MIME encoding to how
>the HTTP server should be serving up the files to the client?  Not trying to
>be difficult, I just want to be sure we're on the same page as the text
>reads quite differently to me.
>
>It reads (to me) that you intend for the hosted file to be MIME encoded
>rather than binary.  Specifically, as [A MIME encoded application/pkcs7-mime
>"certs-only" file  as specified in RFC 2797 [CMC]"].  When I read this it
>indicated to me that I am supposed to MIME encode the PKCS#7 and name the
>resultant MIME text file with a .p7c extension.  E.g., place the following
>file content on my web server:
>
>MIME-Version: 1.0
>Content-Type: application/pkcs7-mime;
>         smime-type="certs-only";
>         name="cacerts.p7c"
>Content-Transfer-Encoding: base64
>Content-Disposition: attachment;
>         filename="cacerts.p7c"
>
>MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/+Q29u
>dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05leHRQ
>...
>BhcnA===
>
>
>Matt Cooper
>Orion Security Solutions
>1489 Chain Bridge Road, Suite 300
>McLean, Virginia 22101
>(Mob) 703.981.2269
>(Off) 703.917.0060 x. 30
>(Fax) 703.917.0260
>Visit our website!
>http://www.orionsec.com
>
>
>________________________________
>
>From: Russ Housley [mailto:[e-mail]]
>Sent: Thursday, February 03, 2005 3:39 PM
>To: Matt Cooper; [e-mail]
>Cc: [e-mail]
>Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
>
>
>Matt:
>
>We were not clear.  We did not intend to eliminate the MIME encoding which
>is normally present with HTTP.  The MIME types are specified in the
>referenced documents, I believe.  Rather, we were also stating a naming
>convention for the files that are obtained.
>
>Russ
>
>At 03:15 PM 2/3/2005, Matt Cooper wrote:
>
>
>         First, I'd like to say I'm happy to see this come out, this is a
>needed addition for CRLs.
>
>         All my comments refer to the following snippet extracted from the
>draft
>         ( http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt
><http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt>  ):
>
>         ===begin===
>            When the http scheme is specified, the URI MUST point to a
>            certificate file.  The certificate file MUST contain either a
>single
>            DER encoded certificate (indicated by the .cer file extension) or
>            contain a certification path (indicated by the .p7c file
>extension):
>
>               .cer   A single DER encoded certificate as specified in
>                      RFC 2585 [PKIX-CERT].
>
>               .p7c   A MIME encoded application/pkcs7-mime "certs-only" file
>                      as specified in RFC 2797 [CMC].
>         ===end===
>
>         Unless this has been required in another document that I am unaware
>of, we should use not use "MIME encoded" for this purpose for the following
>reasons:
>         1. It creates burden on the client.  Why should the client need a
>MIME decoder to verify a CRL?
>         2. It creates burden for CA's and CA operators.  They may have to
>learn how to manually encode a PKCS#7 in a MIME structure if their CA does
>not output this for them. This is error prone and may lead to problems.
>         3. Clients must handle one case as binary and the other case as text
>         4. Web servers already return MIME types for data; another MIME
>layer is not needed
>
>         It is not too much to expect that the relying party software can
>distinguish between a binary cert and a binary p7c file. (For example, MS
>CAPI already does this for AIA)  However, to make life easier for the
>client, could we throw in appropriate use of MIME types on the web server?
>Perhaps something like this:
>
>         "HTTP server implementations accessed via the URI SHOULD use the
>appropriate MIME content-type for the certificate file.  Specifically, the
>HTTP server SHOULD return the content-type application/pkix-cert for a
>single DER encoded certificate and application/pkcs7-mime for a certs-only
>PKCS#7.  Consuming clients SHOULD use the MIME type as a hint, but should
>not depend solely on the presence of the correct MIME type in the server
>response."
>
>         Calling for the contents of the p7c to be "a certification path" is
>too restrictive in my mind.  It would be better to leave this wide open and
>say something like "contain one or more certificates that may be helpful to
>the relying party."  This leaves it up to the implementer to put in any
>certificates that may be useful for path construction regardless of whether
>we have common trusted roots.  (They may also wish to not include the entire
>path, but instead only the CRL signer cert, which then has another AIA in
>it.)
>
>         Suggest rewording the text something like this :
>
>         When the HTTP scheme is specified, the URI MUST point to a
>certificate file. The certificate file MUST be either a single binary DER
>encoded certificate (indicated by the .cer file extension) or a single
>binary DER encoded certs-only PKCS#7 file (indicated by the .p7c file
>extension) containing one or more certificates that may be helpful to the
>relying party.
>
>
>         Matt Cooper
>         Orion Security Solutions
>         1489 Chain Bridge Road, Suite 300
>         McLean, Virginia 22101
>         (Mob) 703.981.2269
>         (Off) 703.917.0060 x. 30
>         (Fax) 703.917.0260
>         Visit our website!
>         http://www.orionsec.com <http://www.orionsec.com/>
>
>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13NU9qM064341; Thu, 3 Feb 2005 15:30:09 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13NU9vH064340; Thu, 3 Feb 2005 15:30:09 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13NU3Br064329 for <[e-mail]>; Thu, 3 Feb 2005 15:30:04 -0800 (PST) (envelope-from [e-mail])
Received: from wmcooper (pcp09268965pcs.arlngt01.va.comcast.net [69.143.119.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id j13NTvRX022430; Thu, 3 Feb 2005 18:29:59 -0500
Message-Id: <[e-mail]>
From: "Matt Cooper" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: draft-ietf-pkix-crlaia-00.txt comments
Date: Thu, 3 Feb 2005 18:29:20 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <[e-mail]>
Thread-Index: AcUKMLMiKTc97gy5Q12zIO3eWeictQACZjbA
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Perhaps I was not clear either.  I didn't think you were attempting to
eliminate the HTTP MIME encoding.  And believe me, I'm the first one to
cheer having a naming convention for this purpose!

Are you saying that your intent was only to apply the MIME encoding to how
the HTTP server should be serving up the files to the client?  Not trying to
be difficult, I just want to be sure we're on the same page as the text
reads quite differently to me.

It reads (to me) that you intend for the hosted file to be MIME encoded
rather than binary.  Specifically, as [A MIME encoded application/pkcs7-mime
"certs-only" file  as specified in RFC 2797 [CMC]"].  When I read this it
indicated to me that I am supposed to MIME encode the PKCS#7 and name the
resultant MIME text file with a .p7c extension.  E.g., place the following
file content on my web server:

MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
	smime-type="certs-only";
	name="cacerts.p7c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="cacerts.p7c"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgg/+Q29u
dGVudC1UeXBlOiBtdWx0aXBhcnQvYWx0ZXJuYXRpdmU7DQoJYm91bmRhcnk9Ii0tLS09X05leHRQ
...
BhcnA===


Matt Cooper
Orion Security Solutions
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101
(Mob) 703.981.2269
(Off) 703.917.0060 x. 30
(Fax) 703.917.0260
Visit our website!
http://www.orionsec.com
 

________________________________

From: Russ Housley [mailto:[e-mail]] 
Sent: Thursday, February 03, 2005 3:39 PM
To: Matt Cooper; [e-mail]
Cc: [e-mail]
Subject: Re: draft-ietf-pkix-crlaia-00.txt comments


Matt:

We were not clear.  We did not intend to eliminate the MIME encoding which
is normally present with HTTP.  The MIME types are specified in the
referenced documents, I believe.  Rather, we were also stating a naming
convention for the files that are obtained.

Russ

At 03:15 PM 2/3/2005, Matt Cooper wrote:


	First, I'd like to say I'm happy to see this come out, this is a
needed addition for CRLs.
	 
	All my comments refer to the following snippet extracted from the
draft 
	( http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt
<http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt>  ):
	 
	===begin===
	   When the http scheme is specified, the URI MUST point to a
	   certificate file.  The certificate file MUST contain either a
single
	   DER encoded certificate (indicated by the .cer file extension) or
	   contain a certification path (indicated by the .p7c file
extension):
	
	      .cer   A single DER encoded certificate as specified in
	             RFC 2585 [PKIX-CERT].
	
	      .p7c   A MIME encoded application/pkcs7-mime "certs-only" file
	             as specified in RFC 2797 [CMC].
	===end===
	 
	Unless this has been required in another document that I am unaware
of, we should use not use "MIME encoded" for this purpose for the following
reasons:
	1. It creates burden on the client.  Why should the client need a
MIME decoder to verify a CRL?
	2. It creates burden for CA's and CA operators.  They may have to
learn how to manually encode a PKCS#7 in a MIME structure if their CA does
not output this for them. This is error prone and may lead to problems.
	3. Clients must handle one case as binary and the other case as text
	4. Web servers already return MIME types for data; another MIME
layer is not needed
	 
	It is not too much to expect that the relying party software can
distinguish between a binary cert and a binary p7c file. (For example, MS
CAPI already does this for AIA)  However, to make life easier for the
client, could we throw in appropriate use of MIME types on the web server?
Perhaps something like this:
	 
	"HTTP server implementations accessed via the URI SHOULD use the
appropriate MIME content-type for the certificate file.  Specifically, the
HTTP server SHOULD return the content-type application/pkix-cert for a
single DER encoded certificate and application/pkcs7-mime for a certs-only
PKCS#7.  Consuming clients SHOULD use the MIME type as a hint, but should
not depend solely on the presence of the correct MIME type in the server
response."
	 
	Calling for the contents of the p7c to be "a certification path" is
too restrictive in my mind.  It would be better to leave this wide open and
say something like "contain one or more certificates that may be helpful to
the relying party."  This leaves it up to the implementer to put in any
certificates that may be useful for path construction regardless of whether
we have common trusted roots.  (They may also wish to not include the entire
path, but instead only the CRL signer cert, which then has another AIA in
it.)
	 
	Suggest rewording the text something like this :
	 
	When the HTTP scheme is specified, the URI MUST point to a
certificate file. The certificate file MUST be either a single binary DER
encoded certificate (indicated by the .cer file extension) or a single
binary DER encoded certs-only PKCS#7 file (indicated by the .p7c file
extension) containing one or more certificates that may be helpful to the
relying party.
	 
	 
	Matt Cooper
	Orion Security Solutions
	1489 Chain Bridge Road, Suite 300 
	McLean, Virginia 22101
	(Mob) 703.981.2269
	(Off) 703.917.0060 x. 30
	(Fax) 703.917.0260
	Visit our website!
	http://www.orionsec.com <http://www.orionsec.com/> 
	 
	 




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13KfEVB048991; Thu, 3 Feb 2005 12:41:14 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13KfE2M048990; Thu, 3 Feb 2005 12:41:14 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j13KfDfb048982 for <[e-mail]>; Thu, 3 Feb 2005 12:41:13 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 9023 invoked by uid 0); 3 Feb 2005 20:41:06 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.143.32) by woodstock.binhost.com with SMTP; 3 Feb 2005 20:41:06 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Thu, 03 Feb 2005 15:38:46 -0500
To: "Matt Cooper" <[e-mail]>, <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: draft-ietf-pkix-crlaia-00.txt comments
Cc: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<html>
<body>
Matt:<br><br>
We were not clear.&nbsp; We did not intend to eliminate the MIME encoding
which is normally present with HTTP.&nbsp; The MIME types are specified
in the referenced documents, I believe.&nbsp; Rather, we were also
stating a naming convention for the files that are obtained.<br><br>
Russ<br><br>
At 03:15 PM 2/3/2005, Matt Cooper wrote:<br>
<blockquote type=cite class=cite cite=""><font face="arial">First, I'd
like to say I'm happy to see this come out, this is a needed addition for
CRLs.<br>
&nbsp;<br>
All my comments refer to the following snippet extracted from the draft
<br>
(<a href="http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt">
http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt</a>
):<br>
&nbsp;<br>
===begin===<br>
&nbsp;&nbsp; When the http scheme is specified, the URI MUST point to
a<br>
&nbsp;&nbsp; certificate file.&nbsp; The certificate file MUST contain
either a single<br>
&nbsp;&nbsp; DER encoded certificate (indicated by the .cer file
extension) or<br>
&nbsp;&nbsp; contain a certification path (indicated by the .p7c file
extension):<br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .cer&nbsp;&nbsp; A single DER encoded
certificate as specified in<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
RFC 2585 [PKIX-CERT].<br><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; .p7c&nbsp;&nbsp; A MIME encoded
application/pkcs7-mime &quot;certs-only&quot; file<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
as specified in RFC 2797 [CMC].<br>
===end===<br>
&nbsp;<br>
Unless this has been required in another document that I am unaware of,
we should use not use &quot;MIME encoded&quot; for this purpose for the
following reasons:<br>
1. It creates burden on the client.&nbsp; Why should the client need a
MIME decoder to verify a CRL?<br>
2. It creates burden for CA's and CA operators.&nbsp; They may have to
learn how to manually encode a PKCS#7 in a MIME structure if their CA
does not output this for them. This is error prone and may lead to
problems.<br>
3. Clients must handle one case as binary and the other case as text<br>
4. Web servers already return MIME types for data; another MIME layer is
not needed<br>
&nbsp;<br>
It is not too much to expect that the relying party software can
distinguish between a binary cert and a binary p7c file. (For example, MS
CAPI already does this for AIA)&nbsp; However, to make life easier for
the client, could we throw in appropriate use of MIME types on the web
server? Perhaps something like this:<br>
&nbsp;<br>
&quot;HTTP server implementations accessed via the URI SHOULD use the
appropriate MIME content-type for the certificate file.&nbsp;
Specifically, the HTTP server SHOULD return the content-type
application/pkix-cert for a single DER encoded certificate and
application/pkcs7-mime for a certs-only PKCS#7.&nbsp; Consuming clients
SHOULD use the MIME type as a hint, but should not depend solely on the
presence of the correct MIME type in the server response.&quot;<br>
&nbsp;<br>
Calling for the contents of the p7c to be &quot;a certification
path&quot; is too restrictive in my mind.&nbsp; It would be better to
leave this wide open and say something like &quot;contain one or more
certificates that may be helpful to the relying party.&quot;&nbsp; This
leaves it up to the implementer to put in any certificates that may be
useful for path construction regardless of whether we have common trusted
roots.&nbsp; (They may also wish to not include the entire path, but
instead only the CRL signer cert, which then has another AIA in it.)<br>
&nbsp;<br>
Suggest rewording the text something like this :<br>
&nbsp;<br>
When the HTTP scheme is specified, the URI MUST point to a certificate
file. The certificate file MUST be either a single binary DER encoded
certificate (indicated by the .cer file extension) or a single binary DER
encoded certs-only PKCS#7 file (indicated by the .p7c file extension)
containing one or more certificates that may be helpful to the relying
party.<br>
&nbsp;<br>
</font>&nbsp;<br>
<font face="arial">Matt Cooper<br>
Orion Security Solutions<br>
1489 Chain Bridge Road, Suite 300 <br>
McLean, Virginia 22101<br>
(Mob) 703.981.2269<br>
(Off) 703.917.0060 x. 30<br>
(Fax) 703.917.0260</font><br>
<font face="arial">Visit our website!<br>
<a href="http://www.orionsec.com/">http://www.orionsec.com</a><br>
</font>&nbsp;<br>
&nbsp;</blockquote></body>
</html>



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13KFgor046509; Thu, 3 Feb 2005 12:15:42 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13KFg3c046508; Thu, 3 Feb 2005 12:15:42 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13KFfnZ046500 for <[e-mail]>; Thu, 3 Feb 2005 12:15:42 -0800 (PST) (envelope-from [e-mail])
Received: from wmcooper (pcp09268965pcs.arlngt01.va.comcast.net [69.143.119.115]) by host13.websitesource.com (8.12.10/8.12.10) with ESMTP id j13KFeRW014485; Thu, 3 Feb 2005 15:15:40 -0500
Message-Id: <[e-mail]>
From: "Matt Cooper" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: draft-ietf-pkix-crlaia-00.txt comments
Date: Thu, 3 Feb 2005 15:15:04 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A2_01C50A03.264D7FC0"
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
Thread-Index: AcUKLQl3j9ejZ5CaRAyGNTfn2tmAkg==
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_00A2_01C50A03.264D7FC0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

First, I'd like to say I'm happy to see this come out, this is a needed
addition for CRLs.
 
All my comments refer to the following snippet extracted from the draft 
(http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt):
 
===begin===
   When the http scheme is specified, the URI MUST point to a
   certificate file.  The certificate file MUST contain either a single
   DER encoded certificate (indicated by the .cer file extension) or
   contain a certification path (indicated by the .p7c file extension):

      .cer   A single DER encoded certificate as specified in
             RFC 2585 [PKIX-CERT].

      .p7c   A MIME encoded application/pkcs7-mime "certs-only" file
             as specified in RFC 2797 [CMC].
===end===
 
Unless this has been required in another document that I am unaware of, we
should use not use "MIME encoded" for this purpose for the following
reasons:
1. It creates burden on the client.  Why should the client need a MIME
decoder to verify a CRL?
2. It creates burden for CA's and CA operators.  They may have to learn how
to manually encode a PKCS#7 in a MIME structure if their CA does not output
this for them. This is error prone and may lead to problems.
3. Clients must handle one case as binary and the other case as text
4. Web servers already return MIME types for data; another MIME layer is not
needed
 
It is not too much to expect that the relying party software can distinguish
between a binary cert and a binary p7c file. (For example, MS CAPI already
does this for AIA)  However, to make life easier for the client, could we
throw in appropriate use of MIME types on the web server? Perhaps something
like this:
 
"HTTP server implementations accessed via the URI SHOULD use the appropriate
MIME content-type for the certificate file.  Specifically, the HTTP server
SHOULD return the content-type application/pkix-cert for a single DER
encoded certificate and application/pkcs7-mime for a certs-only PKCS#7.
Consuming clients SHOULD use the MIME type as a hint, but should not depend
solely on the presence of the correct MIME type in the server response."
 
Calling for the contents of the p7c to be "a certification path" is too
restrictive in my mind.  It would be better to leave this wide open and say
something like "contain one or more certificates that may be helpful to the
relying party."  This leaves it up to the implementer to put in any
certificates that may be useful for path construction regardless of whether
we have common trusted roots.  (They may also wish to not include the entire
path, but instead only the CRL signer cert, which then has another AIA in
it.)
 
Suggest rewording the text something like this :
 
When the HTTP scheme is specified, the URI MUST point to a certificate file.
The certificate file MUST be either a single binary DER encoded certificate
(indicated by the .cer file extension) or a single binary DER encoded
certs-only PKCS#7 file (indicated by the .p7c file extension) containing one
or more certificates that may be helpful to the relying party.
 
 
Matt Cooper
Orion Security Solutions
1489 Chain Bridge Road, Suite 300 
McLean, Virginia 22101
(Mob) 703.981.2269
(Off) 703.917.0060 x. 30
(Fax) 703.917.0260
Visit our website!
 <http://www.orionsec.com/> http://www.orionsec.com
 
 

------=_NextPart_000_00A2_01C50A03.264D7FC0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2523" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D851173020-02022005><FONT face=3DArial>
<DIV><SPAN class=3D851173020-02022005><FONT face=3DArial>First, I'd like =
to say I'm=20
happy to see this come out, this is a needed addition for=20
CRLs.</FONT></SPAN></DIV>
<DIV><SPAN class=3D851173020-02022005><FONT =
face=3DArial></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851173020-02022005><FONT face=3DArial>All my comments =
refer to=20
the following snippet extracted from the draft </FONT></SPAN></DIV>
<DIV><SPAN class=3D851173020-02022005><FONT face=3DArial>(<A=20
title=3Dhttp://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt=
=20
href=3D"http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt=
">http://www.ietf.org/internet-drafts/draft-ietf-pkix-crlaia-00.txt</A>):=
</FONT></SPAN></DIV>
<DIV><SPAN class=3D851173020-02022005><FONT =
face=3DArial></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851173020-02022005><FONT=20
face=3DArial>=3D=3D=3Dbegin=3D=3D=3D</FONT></SPAN></DIV>
<DIV><FONT face=3DArial>&nbsp;&nbsp; When the http scheme is specified, =
the URI=20
MUST point to a<BR>&nbsp;&nbsp; certificate file.&nbsp; The certificate =
file=20
MUST contain either a single<BR>&nbsp;&nbsp; DER encoded certificate =
(indicated=20
by the .cer file extension) or<BR>&nbsp;&nbsp; contain a certification =
path=20
(indicated by the .p7c file =
extension):<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
.cer&nbsp;&nbsp; A single DER encoded certificate as specified=20
in<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
RFC 2585 [PKIX-CERT].<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
.p7c&nbsp;&nbsp; A=20
MIME encoded application/pkcs7-mime "certs-only"=20
file<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;=20
as specified in RFC 2797 [CMC].</FONT><FONT face=3DArial><BR><SPAN=20
class=3D851173020-02022005>=3D=3D=3Dend=3D=3D=3D</SPAN></FONT></DIV>
<DIV><FONT face=3DArial><SPAN =
class=3D851173020-02022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><SPAN class=3D851173020-02022005>Unless this has =
been=20
required in another document that I am unaware of, we should use not use =
"MIME=20
encoded" for this purpose for the following reasons:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial><SPAN class=3D851173020-02022005>1. It creates =
burden on the=20
client.&nbsp; Why should the client need a MIME decoder to verify a=20
CRL?</SPAN></FONT></DIV>
<DIV><FONT face=3DArial><SPAN class=3D851173020-02022005>2. It creates =
burden for=20
CA's and CA operators.&nbsp; They may have to learn how to manually=20
encode&nbsp;a&nbsp;PKCS#7&nbsp;in a MIME structure if their CA does not =
output=20
this for them.&nbsp;This is error prone and may lead to=20
problems.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial><SPAN class=3D851173020-02022005>3. =
Clients&nbsp;must handle=20
one case as binary and the other case as text</SPAN></FONT></DIV>
<DIV><FONT face=3DArial><SPAN class=3D851173020-02022005><SPAN=20
class=3D256543022-02022005>4. Web servers already return MIME types for =
data;=20
another MIME&nbsp;layer is not needed</SPAN></SPAN></FONT></DIV>
<DIV><FONT face=3DArial><SPAN =
class=3D851173020-02022005></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial><SPAN class=3D851173020-02022005>It&nbsp;is not =
too much to=20
expect that the relying party software can distinguish between a binary =
cert and=20
a binary&nbsp;p7c file. (For example, MS CAPI already does this for =
AIA)&nbsp;=20
However, to make life easier for the client, could we throw in =
appropriate use=20
of MIME types on the web server?&nbsp;Perhaps something like=20
this:</SPAN></FONT></DIV>
<DIV><FONT face=3DArial><SPAN =
class=3D851173020-02022005></SPAN></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D851173020-02022005>
<DIV><SPAN class=3D851173020-02022005><FONT face=3DArial>"HTTP server=20
implementations&nbsp;accessed via the URI&nbsp;SHOULD use the =
appropriate MIME=20
content-type for the certificate file.&nbsp; Specifically, the HTTP =
server=20
SHOULD return&nbsp;<SPAN class=3D256543022-02022005>the =
</SPAN>content-type=20
application/pkix-cert for a single DER encoded certificate and=20
application/pkcs7-mime for a certs-only PKCS#7.&nbsp; Consuming clients =
SHOULD=20
use the MIME type as a hint, but should not depend solely on the =
presence of the=20
correct MIME type in the server response."</FONT></SPAN></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV></SPAN></DIV>
<DIV><SPAN class=3D851173020-02022005><FONT face=3DArial>Calling for the =
contents of=20
the p7c to be "a certification path" is too restrictive in my =
mind.&nbsp; It=20
would be better to leave this wide open and say something like "contain =
one or=20
more certificates that may be helpful to the relying party."&nbsp; This =
leaves=20
it up to the&nbsp;implementer&nbsp;to put in any certificates that may =
be useful=20
for path construction regardless of whether we have common trusted =
roots.&nbsp;=20
(They may also wish to not include the entire path, but instead only the =
CRL=20
signer&nbsp;cert, which then has another AIA in it.)</FONT></SPAN></DIV>
<DIV><SPAN class=3D851173020-02022005><FONT =
face=3DArial></FONT></SPAN><SPAN=20
class=3D851173020-02022005><FONT face=3DArial></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851173020-02022005><FONT face=3DArial>Suggest =
rewording the text=20
something like this :</FONT></SPAN></DIV>
<DIV><SPAN class=3D851173020-02022005><FONT =
face=3DArial></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D851173020-02022005><FONT face=3DArial>When the HTTP =
scheme is=20
specified, the URI MUST point to a certificate file.&nbsp;The =
certificate file=20
MUST&nbsp;be either a single&nbsp;binary DER encoded certificate =
(indicated by=20
the .cer file extension) or&nbsp;a single binary DER=20
encoded&nbsp;certs-only&nbsp;PKCS#7 file (indicated by the .p7c file =
extension)=20
containing one or more certificates that may be helpful to the relying=20
party.</FONT></SPAN></DIV>
<DIV><SPAN =
class=3D851173020-02022005></SPAN>&nbsp;</DIV></FONT></SPAN><FONT=20
face=3DArial></FONT></DIV>
<DIV align=3Dleft>
<DIV align=3Dleft><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV align=3Dleft><FONT face=3DArial>Matt Cooper<BR>Orion Security =
Solutions<BR>1489=20
Chain Bridge Road, Suite 300 <BR>McLean, Virginia 22101<BR>(Mob)=20
703.981.2269<BR>(Off) 703.917.0060 x. 30<BR>(Fax) =
703.917.0260</FONT><BR><FONT=20
face=3DArial>Visit our website!<BR></FONT><A =
href=3D"http://www.orionsec.com/"><FONT=20
face=3DArial>http://www.orionsec.com</FONT></A></DIV>
<DIV align=3Dleft><FONT face=3DArial></FONT>&nbsp;</DIV></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_00A2_01C50A03.264D7FC0--



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13IeHXA038913; Thu, 3 Feb 2005 10:40:17 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13IeH9C038912; Thu, 3 Feb 2005 10:40:17 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j13IeGcr038906 for <[e-mail]>; Thu, 3 Feb 2005 10:40:17 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 23647 invoked by uid 0); 3 Feb 2005 18:40:11 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.143.32) by woodstock.binhost.com with SMTP; 3 Feb 2005 18:40:11 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Thu, 03 Feb 2005 13:40:13 -0500
To: [e-mail], [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Question about RFC3379
In-Reply-To: <49863.192.168.1.254.1107447105.squirrel@192.168.1.254>
References: <49863.192.168.1.254.1107447105.squirrel@192.168.1.254>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

RFC 3379 specifies protocol requirements, not a protocol.

SCVP is the protocol that is intended to satisfy the protocol requirements.

Russ

At 11:11 AM 2/3/2005, [e-mail] wrote:

>Hello,
>
>a small question about in the RFC3379, Why there is not definition in
>ASN.1 format for request and the response to the client and server DPV and
>DPD, as one can see it in the RFC2560. It is a deliberated choice?
>
>Thanks.
>Yannick Quenec'hdu



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13GC58x016666; Thu, 3 Feb 2005 08:12:05 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j13GC5WK016665; Thu, 3 Feb 2005 08:12:05 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from whisky.linagora.com (whisky.linagora.com [62.23.27.55]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j13GC29c016647 for <[e-mail]>; Thu, 3 Feb 2005 08:12:03 -0800 (PST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by whisky.linagora.com (Postfix) with ESMTP id 0A01F9DDC1 for <[e-mail]>; Thu,  3 Feb 2005 17:11:44 +0100 (CET)
Received: from whisky.linagora.com ([127.0.0.1]) by localhost (whisky [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09428-10 for <[e-mail]>; Thu,  3 Feb 2005 17:11:32 +0100 (CET)
Received: from tomate.linagora.lan (sgi2.linagora.com [195.68.36.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by whisky.linagora.com (Postfix) with ESMTP id AC4AA9DDC7 for <[e-mail]>; Thu,  3 Feb 2005 17:11:28 +0100 (CET)
Received: from 192.168.1.254 (proxying for 145.242.3.30) (SquirrelMail authenticated user [e-mail]); by tomate.linagora.lan with HTTP; Thu, 3 Feb 2005 17:11:45 +0100 (CET)
Message-ID: <49863.192.168.1.254.1107447105.squirrel@192.168.1.254>
Date: Thu, 3 Feb 2005 17:11:45 +0100 (CET)
Subject: Question about RFC3379
From: [e-mail]
To: [e-mail]
User-Agent: SquirrelMail/1.4.3a
X-Mailer: SquirrelMail/1.4.3a
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: by amavisd-new at linagora.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

a small question about in the RFC3379, Why there is not definition in
ASN.1 format for request and the response to the client and server DPV and
DPD, as one can see it in the RFC2560. It is a deliberated choice?

Thanks.
Yannick Quenec'hdu




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12Kwtdb005766; Wed, 2 Feb 2005 12:58:55 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12Kwt0Q005765; Wed, 2 Feb 2005 12:58:55 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12KwsB9005757 for <[e-mail]>; Wed, 2 Feb 2005 12:58:54 -0800 (PST) (envelope-from [e-mail])
Received: from romans (ip165.131.du.eli.iinet.com [67.136.131.165]) by smtp3.pacifier.net (Postfix) with ESMTP id 811276E460 for <[e-mail]>; Wed,  2 Feb 2005 12:58:52 -0800 (PST)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-cmc-archive-01.txt
Date: Wed, 2 Feb 2005 13:08:56 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527
Thread-Index: AcUIpe5E5YtpFX8QQQaTgqoYNEf3UwAxKzYA
In-Reply-To: <[e-mail]>
Message-Id: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I assume somewhere along the line the rest of the CMC drafts should appear.
They have been submitted for release.

The archive draft was published so that I could get some feedback.  There is
a big QUESTION in the middle of the document that I would like people to
look at.  It basically deals with the best way to return multiple private
keys in a single message.  Whether they should be masked in a single
encrypted blob, or seperated into multiple encrypted blobs and if a single
encrypted blob whether we should extend the structure defined in the CRMF
draft (thus requiring a fast update to it) or not.


Jim




Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j12DHsnR066183; Wed, 2 Feb 2005 05:17:54 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j12DHsJO066182; Wed, 2 Feb 2005 05:17:54 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.243.4]) by above.proper.com (8.12.11/8.12.9) with SMTP id j12DHrOT066165 for <[e-mail]>; Wed, 2 Feb 2005 05:17:53 -0800 (PST) (envelope-from [e-mail])
Received: (qmail 12089 invoked by uid 0); 2 Feb 2005 13:17:50 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.17.29) by woodstock.binhost.com with SMTP; 2 Feb 2005 13:17:50 -0000
Message-Id: <[e-mail]>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14
Date: Wed, 02 Feb 2005 08:17:47 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Fwd: I-D ACTION:draft-housley-pkix-ecc-pkalgs-ecdsa-00.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This group may be interested in this Internet-Draft.

Russ


>To: [e-mail]
>From: [e-mail]
>Date: Tue, 01 Feb 2005 15:48:49 -0500
>Subject: I-D ACTION:draft-housley-pkix-ecc-pkalgs-ecdsa-00.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>
>         Title           : Additional Algorithms and Identifiers for use of
>                           Elliptic Curve Cryptography with PKIX (Explicit
>                           Identification of One-Way Hash Functions)
>         Author(s)       : R. Housley
>         Filename        : draft-housley-pkix-ecc-pkalgs-ecdsa-00.txt
>         Pages           : 6
>         Date            : 2005-2-1
>
>Dan Brown from Certicom has submitted a specification for Additional
>    Algorithms and Identifiers for use of Elliptic Curve Cryptography
>    with PKIX.  This document proposes a different approach for
>    identifying the one-way hash function used with the ECDSA signature
>    algorithm.
>
>A URL for this Internet-Draft is:
>http://www.ietf.org/internet-drafts/draft-housley-pkix-ecc-pkalgs-ecdsa-00.txt



Received: from above.proper.com (localhost.vpnc.org [127.0.0.1]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Ko1L0054911; Tue, 1 Feb 2005 12:50:01 -0800 (PST) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.11/8.12.9/Submit) id j11Ko14k054910; Tue, 1 Feb 2005 12:50:01 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.11/8.12.9) with ESMTP id j11Knx2Q054901 for <[e-mail]>; Tue, 1 Feb 2005 12:50:00 -0800 (PST) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA18287; Tue, 1 Feb 2005 15:49:56 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-cmc-archive-01.txt
Date: Tue, 01 Feb 2005 15:49:56 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.

	Title		: CMC Extensions: Server Side Key Generation and Key Escrow
	Author(s)	: J. Schaad
	Filename	: draft-ietf-pkix-cmc-archive-01.txt
	Pages		: 24
	Date		: 2005-2-1
	
This document defines a set of extensions to the CMC (Certificate
   Management over CMS) protocol that address the desire for having two
   additional services:  1) Server side generation of keys, 2)
   server-side escrow and subsequent recovery of key material.  These
   services are provided by the definition of additional control
   statements within the CMC architecture.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmc-archive-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[e-mail] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.


Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-pkix-cmc-archive-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-cmc-archive-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-cmc-archive-01.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmc-archive-01.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--