RE: Meaning of Non-repudiation

["Housley, Russ" <[e-mail]>]

Steve & Tony:

>>To my view of things, the "existence" of NR=1 in a certificate is no more 
>>than a statement, by the issuing CA, that "they will not stand in the way 
>>of this certificate being used as a component in some form of NR scheme 
>>(and will happily accept your Visa or Mastercard, thank you.)
>>
>>If one limits the presence of an NR bit to this weak assertion, it 
>>becomes clear that the NR bit "means almost nothing."  Thus there is 
>>little left to debate about it on the list.
>>
>>(As I recall, Tom Ginden's "Technical Non-Repudiation" document was about 
>>as far as one could reasonably take application of the NR bit. It was 
>>time for everyone else to put-up or shut-up, and everyone shut-up.)
>>
>>____tony____
>
>Tony,
>
>I think the PKIX list discussion ended with the observation that there 
>might be more benefit to the NR bit in the other direction, i.e., when it 
>is NOT asserted. In that case the interpretation is that the CA is 
>signalling that the cert was not issued for use in transactions requiring 
>NR. Thus one would normally set the NR bit to 0 in certs to be used for 
>signing authentication data exchanges, vs. binding documents, etc.  When 
>the bit is asserted, it is best viewed as a necessary, but not sufficient, 
>condition for NR.
>
>Steve


Son-of-2459 says:

       Further distinctions between the digitalSignature and
       nonRepudiation bits may be provided in specific certificate
       policies.

This allows the CA to state what additional meaning is associated with the 
nonRepudiation bit.

Russ



Received: by above.proper.com (8.11.6/8.11.3) id g410gYZ22871 for ietf-pkix-bks; Tue, 30 Apr 2002 17:42:34 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g410gXa22867 for <[e-mail]>; Tue, 30 Apr 2002 17:42:33 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 May 2002 00:41:11 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id UAA10023; Tue, 30 Apr 2002 20:40:45 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g410gR207256; Tue, 30 Apr 2002 20:42:27 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1ZV7P>; Tue, 30 Apr 2002 20:39:52 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.134]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1ZV7L; Tue, 30 Apr 2002 20:39:49 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 30 Apr 2002 15:49:39 -0400
Subject: RE: Meaning of Non-repudiation
In-Reply-To: <p05100303b8ef7d15f2c9@[128.89.88.34]>
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>

Steve & Tony:

>>To my view of things, the "existence" of NR=1 in a certificate is no more 
>>than a statement, by the issuing CA, that "they will not stand in the way 
>>of this certificate being used as a component in some form of NR scheme 
>>(and will happily accept your Visa or Mastercard, thank you.)
>>
>>If one limits the presence of an NR bit to this weak assertion, it 
>>becomes clear that the NR bit "means almost nothing."  Thus there is 
>>little left to debate about it on the list.
>>
>>(As I recall, Tom Ginden's "Technical Non-Repudiation" document was about 
>>as far as one could reasonably take application of the NR bit. It was 
>>time for everyone else to put-up or shut-up, and everyone shut-up.)
>>
>>____tony____
>
>Tony,
>
>I think the PKIX list discussion ended with the observation that there 
>might be more benefit to the NR bit in the other direction, i.e., when it 
>is NOT asserted. In that case the interpretation is that the CA is 
>signalling that the cert was not issued for use in transactions requiring 
>NR. Thus one would normally set the NR bit to 0 in certs to be used for 
>signing authentication data exchanges, vs. binding documents, etc.  When 
>the bit is asserted, it is best viewed as a necessary, but not sufficient, 
>condition for NR.
>
>Steve


Son-of-2459 says:

       Further distinctions between the digitalSignature and
       nonRepudiation bits may be provided in specific certificate
       policies.

This allows the CA to state what additional meaning is associated with the 
nonRepudiation bit.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UF7IR10200 for ietf-pkix-bks; Tue, 30 Apr 2002 08:07:18 -0700 (PDT)
Received: from mailgate5.cinetic.de (mailgate5.cinetic.de [217.72.192.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UF7Ga10195 for <[e-mail]>; Tue, 30 Apr 2002 08:07:16 -0700 (PDT)
Received: from web.de (fmomail02.dlan.cinetic.de [172.20.1.46]) by mailgate5.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id g3UF71X20056 for [e-mail]; Tue, 30 Apr 2002 17:07:01 +0200
Date: Tue, 30 Apr 2002 17:07:01 +0200
Message-Id: <[e-mail]>
MIME-Version: 1.0
Organization: http://freemail.web.de/
From: <[e-mail]>
To: [e-mail]
Subject: ASN.1 Compiler for Java
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3UF7Ha10196
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 PKIXers,

Does anybody have some experience with an ASN.1 Compiler/Toolkit for Java?
It should be different from Snacc4j. This one I have already checked it
out and I m not satisfied with the licensing situation.

Thx
____________________________________________________
Berufsunfähigskeitversicherung von Mamax bei WEB.DE. 
Jetzt informieren! http://bu.web.de



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3UCxja04826 for ietf-pkix-bks; Tue, 30 Apr 2002 05:59:45 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UCxha04822 for <[e-mail]>; Tue, 30 Apr 2002 05:59:43 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA15768 for <[e-mail]>; Tue, 30 Apr 2002 15:02:33 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002043014590662:569 ; Tue, 30 Apr 2002 14:59:06 +0200 
Message-ID: <[e-mail]>
Date: Tue, 30 Apr 2002 14:59:05 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 30/04/2002 14:59:06, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 30/04/2002 14:59:38, Serialize complete at 30/04/2002 14:59:38
Content-Transfer-Encoding: 7bit
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>

Comments on the Warranty certificate extension

Before looking at the technical details of the warranty, it is important to
make sure that practical cases can be solved. Since a warranty is mentioned,
legal considerations cannot be left aside.

The current proposal states that "the certificate warranty provides an
extended monetary coverage for the legal liability of the CA, in favor of
the *subscriber*".

The problem is that the warranty should also apply in favor of one or more
*relying parties*. Are the relaying parties going to complain to the
subscriber only and will then the subscriber makes arrangement with the CA
only ? 

For the extreme cases where there are, let us say, 10.000 plaintiffs each
one claiming for a damage of 1.000 $ and when the upper limit of the
warranty will be altogether, for example, 100.000 $ (called "aggregated
damage" in the draft). What would be the criteria to reimburse the
plaintiffs ? Since the total damage is 10.000.000 $, are only 10 % of the
first plaintiffs to be reimbursed ? or will a random choice will be done
among the 10.000 plaintiffs ? Since the warranty is for the subscriber and
not for the plaintiffs, will the subscriber deal with the 10.000 plaintiffs
directly ?

The second point is that no conditions to get advantage of the warranty are
mentioned. Should a relying party only check the revocation status of the
certificate ? Should the relying party check the certificate against a
validation policy ? What kind of proof of its checking should the relying
party present to the CA;  or to the subscriber ? An OSCP response? A DPV
response ? Should the details of the transaction involved be provided ?

For all these reasons, the difficulty of use of such an extension is very
questionable.

Now, it should be noticed that such a similar extension has already been
defined in ETSI TS 101 862. This extension takes advantage of the
qcStatement defined in RFC 3039 and specifies a statement regarding limits
on the value of transactions.

This optional statement contains:

- an identifier of this statement (represented by an OID);
- a monetary value expressing the limit on the value of transactions.

This statement is a statement by the issuer which impose a limitation on the
value of transaction for which this certificate can be used to the specified
amount (MonetaryValue), according to the Directive 1999/93/EC of the
European Parliament and of the Council of 13 December 1999 on a Community
framework for electronic signatures, as implemented in the law of the
country specified in the issuer field of this certificate.

In fact the Directive is requiring (in Annex I) a field to specify "limits
on the value of transactions for which the certificate can be used, if
applicable". The reason for that field is specified in the Directive in
these terms:

"The certification-service-provider shall not be liable for damage arising
from use of a qualified certificate which exceeds the limitations placed on
it".

The text does *not* say: "The certification-service-provider *shall be*
liable for damage arising from use of a qualified certificate which *meets*
the limitations placed on it".

So it is more a *disclaimer of warranty* rather than a warranty. If the
proposal was for a warranty disclaimer extension, then it would be more
appropriate. In such a case it would not be necessary to indicate the
conditions to meet to get the warranty since there would be no warranty.

It is doubtful that an off-line indication in a certificate will be the
right answer to a problem that is commonly solved using an on-line protocol
(e.g. money withdrawal on an ATM).

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           : Warranty Certificate Extension
>         Author(s)       : D. Linsenbardt, S. Pontius
>         Filename        : draft-ietf-pkix-warranty-extn-00.txt
>         Pages           : 7
>         Date            : 18-Apr-02
> 
> This document describes a certificate extension to explicitly state
> the warranty offered by a Certificate Authority (CA) for a the
> certificate containing the extension.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-warranty-extn-00.txt


Received: by above.proper.com (8.11.6/8.11.3) id g3UAYD625868 for ietf-pkix-bks; Tue, 30 Apr 2002 03:34:13 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3UAYCa25860 for <[e-mail]>; Tue, 30 Apr 2002 03:34:12 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA22260; Tue, 30 Apr 2002 12:37:04 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002043012333743:529 ; Tue, 30 Apr 2002 12:33:37 +0200 
Message-ID: <[e-mail]>
Date: Tue, 30 Apr 2002 12:33:36 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 30/04/2002 12:33:37, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 30/04/2002 12:34:09, Serialize complete at 30/04/2002 12:34:09
Content-Transfer-Encoding: 7bit
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>

Peter,

> > " When the request is authenticated, the requestor SHOULD be able, upon
> > request, to indicate an identifier to be included in the response.
> > How this identifier is matched with the authenticated identity depends
> > on local server conditions and/or the validation policy. The server
> > MAY choose to refuse to include an identifier in the response, or MAY
> > refuse to create a response."
> >
> > I do not see that there is a need to add "claimed" in it.
> >
> 
> Ok.
> 
> The text 'requestor SHOULD be able' is not good as I said in a
> previous message. 'the protocol MUST provide a means to optionally
> allow ..'

Granted.

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3U384H10942 for ietf-pkix-bks; Mon, 29 Apr 2002 20:08:04 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3U382a10937 for <[e-mail]>; Mon, 29 Apr 2002 20:08:02 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3U37xui026906; Mon, 29 Apr 2002 20:08:00 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Multiple paths in DPD
Date: Mon, 29 Apr 2002 20:05:07 -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]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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 as well.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Housley, Russ
> Sent: Monday, April 29, 2002 4:10 PM
>
> All:
>
> I am comfortable with the approach that Steve suggests.
>
> Russ
>
> At 12:31 PM 4/29/2002 +0100, Stephen Farrell wrote:
>
> >Mike, Russ,
> >
> >Firstly, I also like the "cookie" approach to
> >handling multiple paths so add me to the list
> >of those who'd like the requirements document
> >not to preclude this (I hadn't spotted that
> > it did so).
> >
> >I would though agree with Russ that the requirements
> >document must not require that protocols take this
> >approach. So, basically, the text "Therefore the
> >client MUST be able to indicate the maximum number
> >of certification paths to be returned (provided
> >that they can be found)." is another example of the
> >requirements being overly prescriptive and the usual
> >fix can be applied.
> >
> >Second, I did manage to find a message [1] about
> >this in a relevant thread [2]. I wouldn't say that
> >messaage represents concensus, but OTOH I didn't
> >find anything about what's currently in the
> >requirements draft (though it may be there of course).
> >
> >Third, in looking for those, I noticed that my
> >earliest on-list mail on this topic was Paul Hoffman's
> >of May 23rd 2000 [3], so we can mark the 2nd
> >anniversary of this discussion soon,
> >
> >Sigh,
> >Stephen.
> >
> >[1] http://www.imc.org/ietf-pkix/old-archive-00/msg02286.html
> >[2] http://www.imc.org/ietf-pkix/old-archive-00/msg02220.html
> >[3] http://www.imc.org/ietf-pkix/old-archive-00/msg00840.html
> >
> >Michael Myers wrote:
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]On Behalf Of
> > > > Housley, Russ
> > > > Sent: Friday, April 26, 2002 8:04 AM
> > > >
> > > > Mike:
> > > >
> > > > I am strongly opposed to an approach that would
> > > > require the server to maintain state.  Unless other
> > > > people are willing to speak up and support such an
> > > > approach, I am not willing to make changes in this
> > > > area.  In my view, the current consensus is for
> > > > a stateless server.
> > > >
> > > > Russ
> > >
> > > Russ,
> > >
> > > I'm probably just digging me a deeper hole but I
> thought to
> > > entertain myself in determining precisely where
> consensus was
> > > reached in the WG regarding stateless servers.
> > >
> > > It turns out that I can't find one.  I looked at
> two sources:
> > > the list back for this full year (2002) and the
> minutes of the
> > > meetings as recorded on the IETF web site.  I searched for
> > > "state", "stateless" and "stateful".
> > >
> > > I found nothing in the 2002 minutes with respect
> to these search
> > > targets.  It's only in Minneapolis, 14 March 2001
> where the
> > > minutes record a briefing by Denis:
> > >
> > >     "DPD/DPV - Denis Pinkas (Bull)
> > >     . . .
> > >     Finally, argues for stateless servers, i.e.,
> > >     no retry facility in DPD. (slides)"
> > >
> > > On the list, there's only two hits on "stateful",
> both in a
> > > single message from me querying Tim on an issue
> regarding relay.
> > > A search for "stateless" for this entire calendar
> year only
> > > found the message of today asserting consensus on
> the stateless
> > > approach.  Of the 328 hits for "state" in the
> list for 2002 most
> > > relate either to discussions of response states, the state
> > > machine design model on the server, or expository
> use of the
> > > word.  With respect to anything that might be construed as
> > > consensus on stateless servers, Peter Sylvester
> made a comment
> > > and Denis Pinas responded:
> > >
> > >     [Answer 9] This would create the maintenance of state
> > >     information which should be avoided. . . .
> > >
> > > So I think at best we have consensus by silent
> affirmation.
> > >
> > > Mike
> >
> >--
> >____________________________________________________________
> >Stephen Farrell
> >Baltimore Technologies,   tel: (direct line) [phone]
> >39 Parkgate Street,                     fax: [phone]
> >Dublin 8.                mailto:[e-mail]
> >Ireland                             http://www.baltimore.com
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3TNBip02366 for ietf-pkix-bks; Mon, 29 Apr 2002 16:11:44 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3TNBfa02357 for <[e-mail]>; Mon, 29 Apr 2002 16:11:42 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Apr 2002 23:10:20 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id TAA29913 for <[e-mail]>; Mon, 29 Apr 2002 19:10:05 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3TNBmp29073 for <[e-mail]>; Mon, 29 Apr 2002 19:11:48 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1ZF6C>; Mon, 29 Apr 2002 19:09:14 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1ZF6A; Mon, 29 Apr 2002 19:09:10 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 29 Apr 2002 19:10:23 -0400
Subject: Re: Multiple paths in DPD
In-Reply-To: <[e-mail]>
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>

All:

I am comfortable with the approach that Steve suggests.

Russ

At 12:31 PM 4/29/2002 +0100, Stephen Farrell wrote:

>Mike, Russ,
>
>Firstly, I also like the "cookie" approach to handling multiple
>paths so add me to the list of those who'd like the requirements
>document not to preclude this (I hadn't spotted that it did so).
>I would though agree with Russ that the requirements document must
>not require that protocols take this approach. So, basically, the
>text "Therefore the client MUST be able to indicate the maximum
>number of certification paths to be returned (provided that
>they can be found)." is another example of the requirements
>being overly prescriptive and the usual fix can be applied.
>
>Second, I did manage to find a message [1] about this in a
>relevant thread [2]. I wouldn't say that messaage represents
>concensus, but OTOH I didn't find anything about what's currently
>in the requirements draft (though it may be there of course).
>
>Third, in looking for those, I noticed that my earliest on-list
>mail on this topic was Paul Hoffman's of May 23rd 2000 [3], so we
>can mark the 2nd anniversary of this discussion soon,
>
>Sigh,
>Stephen.
>
>[1] http://www.imc.org/ietf-pkix/old-archive-00/msg02286.html
>[2] http://www.imc.org/ietf-pkix/old-archive-00/msg02220.html
>[3] http://www.imc.org/ietf-pkix/old-archive-00/msg00840.html
>
>Michael Myers wrote:
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]On Behalf Of
> > > Housley, Russ
> > > Sent: Friday, April 26, 2002 8:04 AM
> > >
> > > Mike:
> > >
> > > I am strongly opposed to an approach that would
> > > require the server to maintain state.  Unless other
> > > people are willing to speak up and support such an
> > > approach, I am not willing to make changes in this
> > > area.  In my view, the current consensus is for
> > > a stateless server.
> > >
> > > Russ
> >
> > Russ,
> >
> > I'm probably just digging me a deeper hole but I thought to
> > entertain myself in determining precisely where consensus was
> > reached in the WG regarding stateless servers.
> >
> > It turns out that I can't find one.  I looked at two sources:
> > the list back for this full year (2002) and the minutes of the
> > meetings as recorded on the IETF web site.  I searched for
> > "state", "stateless" and "stateful".
> >
> > I found nothing in the 2002 minutes with respect to these search
> > targets.  It's only in Minneapolis, 14 March 2001 where the
> > minutes record a briefing by Denis:
> >
> >     "DPD/DPV - Denis Pinkas (Bull)
> >     . . .
> >     Finally, argues for stateless servers, i.e.,
> >     no retry facility in DPD. (slides)"
> >
> > On the list, there's only two hits on "stateful", both in a
> > single message from me querying Tim on an issue regarding relay.
> > A search for "stateless" for this entire calendar year only
> > found the message of today asserting consensus on the stateless
> > approach.  Of the 328 hits for "state" in the list for 2002 most
> > relate either to discussions of response states, the state
> > machine design model on the server, or expository use of the
> > word.  With respect to anything that might be construed as
> > consensus on stateless servers, Peter Sylvester made a comment
> > and Denis Pinas responded:
> >
> >     [Answer 9] This would create the maintenance of state
> >     information which should be avoided. . . .
> >
> > So I think at best we have consensus by silent affirmation.
> >
> > Mike
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>39 Parkgate Street,                     fax: [phone]
>Dublin 8.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3TN95N02229 for ietf-pkix-bks; Mon, 29 Apr 2002 16:09:05 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3TN8wa02225 for <[e-mail]>; Mon, 29 Apr 2002 16:08:58 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 29 Apr 2002 23:07:37 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id TAA29782 for <[e-mail]>; Mon, 29 Apr 2002 19:07:22 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3TN95j28909 for <[e-mail]>; Mon, 29 Apr 2002 19:09:05 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1ZF51>; Mon, 29 Apr 2002 19:06:31 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.45]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1ZF5C; Mon, 29 Apr 2002 19:06:26 -0400
From: "Housley, Russ" <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 29 Apr 2002 19:08:52 -0400
Subject: RE: Multiple paths in DPD
In-Reply-To: <[e-mail]>
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>

Mike:

No.  We have a document in Working Group Last Call, and a section in the 
document that has not had any significant change since the initial draft.

You have raised your point, and now we will see if there is support for 
such a change.

Russ

At 12:59 PM 4/26/2002 -0700, Michael Myers wrote:
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of
> > Housley, Russ
> > Sent: Friday, April 26, 2002 8:04 AM
> >
> > Mike:
> >
> > I am strongly opposed to an approach that would
> > require the server to maintain state.  Unless other
> > people are willing to speak up and support such an
> > approach, I am not willing to make changes in this
> > area.  In my view, the current consensus is for
> > a stateless server.
> >
> > Russ
>
>
>Russ,
>
>I'm probably just digging me a deeper hole but I thought to
>entertain myself in determining precisely where consensus was
>reached in the WG regarding stateless servers.
>
>It turns out that I can't find one.  I looked at two sources:
>the list back for this full year (2002) and the minutes of the
>meetings as recorded on the IETF web site.  I searched for
>"state", "stateless" and "stateful".
>
>I found nothing in the 2002 minutes with respect to these search
>targets.  It's only in Minneapolis, 14 March 2001 where the
>minutes record a briefing by Denis:
>
>     "DPD/DPV - Denis Pinkas (Bull)
>     . . .
>     Finally, argues for stateless servers, i.e.,
>     no retry facility in DPD. (slides)"
>
>On the list, there's only two hits on "stateful", both in a
>single message from me querying Tim on an issue regarding relay.
>A search for "stateless" for this entire calendar year only
>found the message of today asserting consensus on the stateless
>approach.  Of the 328 hits for "state" in the list for 2002 most
>relate either to discussions of response states, the state
>machine design model on the server, or expository use of the
>word.  With respect to anything that might be construed as
>consensus on stateless servers, Peter Sylvester made a comment
>and Denis Pinas responded:
>
>     [Answer 9] This would create the maintenance of state
>     information which should be avoided. . . .
>
>So I think at best we have consensus by silent affirmation.
>
>Mike


Received: by above.proper.com (8.11.6/8.11.3) id g3TLTo700168 for ietf-pkix-bks; Mon, 29 Apr 2002 14:29:50 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TLTla00163 for <[e-mail]>; Mon, 29 Apr 2002 14:29:48 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3TLTTui026955; Mon, 29 Apr 2002 14:29:29 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Hal Lockhart" <[e-mail]>, "'Peter Sylvester'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Multiple paths in DPD
Date: Mon, 29 Apr 2002 14:26:36 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
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>

> -----Original Message-----
> From: Hal Lockhart [mailto:[e-mail]]
> Sent: Monday, April 29, 2002 2:00 PM
> To: 'Michael Myers'; Hal Lockhart; 'Peter Sylvester';
[e-mail]
> Cc: [e-mail]
> Subject: RE: Multiple paths in DPD
>
>
> > > I was not talking about the client providing different
> > > inputs, but the fact that server's based of information
> > > will be updated from time to reflect revocations,
> > > expirations, new authorities, etc. I assume this service
> > > will be in continuous operation.
> > >
> >
> > I understand your point better now.  But would not the
effects
> > of these dynamics apply equally well in both the enumerated
and
> > iterated approaches?  I don't yet see how it is a
discriminator
> > between the two.

> My understanding of the other approach is that the set
> of paths is generated afresh each time. (although only
> the first N may be sent) Therefore each response is
> inherently consistent with itself and independant of
> any other response.  BTW, I hold no brief for stateful
> or stateless. I am just trying to help clarify for the
> list, the tradeoffs involved.
>
> Hal

Hal,

Interesting.  My assumption was that in either case there exists
between 1 and N paths defined by the initial context of the
client's query.

Mike



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3TL3Po26068 for ietf-pkix-bks; Mon, 29 Apr 2002 14:03:25 -0700 (PDT)
Received: from dymwsm05.mailwatch.com (dymwsm05.mailwatch.com [204.253.83.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TL3Na26061 for <[e-mail]>; Mon, 29 Apr 2002 14:03:23 -0700 (PDT)
Received: from mwsc0214.mw4.mailwatch.com (mwsc0214.mw4.mailwatch.com [204.253.83.253]) by dymwsm05.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3TL3FA11786 for <[e-mail]>; Mon, 29 Apr 2002 17:03:15 -0400
Received: from mail pickup service by mwsc0214.mw4.mailwatch.com with Microsoft SMTPSVC; Mon, 29 Apr 2002 17:03:15 -0400
Received: from 204.253.83.39 ([204.253.83.39]) by MWSC0214 with SMTP id 0002000e3a22514d-d3a9-40bd-9308-281bb63bb660;	 Mon, 29 Apr 2002 17:03:15 -0500
Received: from bigbird.entegrity.com (bigbird.gradient.com [192.92.110.50])	by dymwsm15.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3TL3Fd13204;	Mon, 29 Apr 2002 17:03:15 -0400
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10)	id <JC4CDFDX>; Mon, 29 Apr 2002 16:59:39 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, Hal Lockhart	 <[e-mail]>, "'Peter Sylvester'"	 <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Multiple paths in DPD
Date: Mon, 29 Apr 2002 16:59:39 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: multipart/alternative;	boundary="----_=_NextPart_001_01C1EFC0.C6FB8EFE"
HOP-COUNT: 1
X-MAILWATCH-INSTANCEID: 0102000e3a22514d-d3a9-40bd-9308-281bb63bb660
X-OriginalArrivalTime: 29 Apr 2002 21:03:15.0639 (UTC) FILETIME=[47DBAC70:01C1EFC1]
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_01C1EFC0.C6FB8EFE
Content-Type: text/plain;
	charset="ISO-8859-1"

 > > I was not talking about the client providing different
> > inputs, but the fact that server's based of information
> > will be updated from time to reflect revocations,
> > expirations, new authorities, etc. I assume this service
> > will be in continuous operation.
> >

> 
> I understand your point better now.  But would not the effects
> of these dynamics apply equally well in both the enumerated and
> iterated approaches?  I don't yet see how it is a discriminator
> between the two.

My understanding of the other approach is that the set of paths is generated
afresh each time. (although only the first N may be sent) Therefore each
response is inherently consistent with itself and independant of any other
response.

BTW, I hold no brief for stateful or stateless. I am just trying to help
clarify for the list, the tradeoffs involved.

Hal

------_=_NextPart_001_01C1EFC0.C6FB8EFE
Content-Type: text/html;
	charset="ISO-8859-1"
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=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Multiple paths in DPD</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&nbsp;&gt; &gt; I was not talking about the client =
providing different</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; inputs, but the fact that server's based =
of information</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; will be updated from time to reflect =
revocations,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; expirations, new authorities, etc. I =
assume this service</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; will be in continuous operation.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I understand your point better now.&nbsp; But =
would not the effects</FONT>
<BR><FONT SIZE=3D2>&gt; of these dynamics apply equally well in both =
the enumerated and</FONT>
<BR><FONT SIZE=3D2>&gt; iterated approaches?&nbsp; I don't yet see how =
it is a discriminator</FONT>
<BR><FONT SIZE=3D2>&gt; between the two.</FONT>
</P>

<P><FONT SIZE=3D2>My understanding of the other approach is that the =
set of paths is generated afresh each time. (although only the first N =
may be sent) Therefore each response is inherently consistent with =
itself and independant of any other response.</FONT></P>

<P><FONT SIZE=3D2>BTW, I hold no brief for stateful or stateless. I am =
just trying to help clarify for the list, the tradeoffs =
involved.</FONT>
</P>

<P><FONT SIZE=3D2>Hal</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1EFC0.C6FB8EFE--


Received: by above.proper.com (8.11.6/8.11.3) id g3TJhRu18346 for ietf-pkix-bks; Mon, 29 Apr 2002 12:43:27 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TJhPa18340 for <[e-mail]>; Mon, 29 Apr 2002 12:43:25 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3TJhCui016836; Mon, 29 Apr 2002 12:43:12 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Hal Lockhart" <[e-mail]>, "'Peter Sylvester'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Multiple paths in DPD
Date: Mon, 29 Apr 2002 12:40:18 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <[e-mail]>
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>

> -----Original Message-----
> From: [e-mail]
>       [mailto:[e-mail]]On Behalf Of
>       Hal Lockhart
> Sent: Monday, April 29, 2002 7:44 AM
> To: 'Michael Myers'; 'Peter Sylvester';
[e-mail]
> Cc: [e-mail]
> Subject: RE: Multiple paths in DPD


> > > Handling this protocol when the information used to
> > > construct the paths changes between requests seems
> > > particularly challenging to me.
> >
> > No.  One of the underlying assumptions is that no
> > paramters change from the client.  The client is
> > seeking a path compliant to a given set of parameters.
> > As it may turn out, the server may have several
> > such that qualify.  The iterative approach enables
> > a client to acquire these in serial query fashion
> > until it either finds the precise record/path
> > it's looking for or the server runs out of data.

> I was not talking about the client providing different
> inputs, but the fact that server's based of information
> will be updated from time to reflect revocations,
> expirations, new authorities, etc. I assume this service
> will be in continuous operation.
>
> Hal

Hal,

I understand your point better now.  But would not the effects
of these dynamics apply equally well in both the enumerated and
iterated approaches?  I don't yet see how it is a discriminator
between the two.

Mike



Received: by above.proper.com (8.11.6/8.11.3) id g3TFUur08388 for ietf-pkix-bks; Mon, 29 Apr 2002 08:30:56 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TFUsa08382 for <[e-mail]>; Mon, 29 Apr 2002 08:30:54 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA04438; Mon, 29 Apr 2002 17:30:52 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Mon, 29 Apr 2002 17:30:52 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA18516; Mon, 29 Apr 2002 17:30:51 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA13804; Mon, 29 Apr 2002 17:30:51 +0200 (MET DST)
Date: Mon, 29 Apr 2002 17:30:51 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
Cc: [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>

> > 
> > Are you asking for a requirement to be included in the
> > text that indicates:
> > 
> > " A protocol that implements the requirements of this document
> >   MUST NOT, never ever, implement other features, even optional ones. "
> 
> I do not think that we need any sentence. Now, if we really needed one, here
> is a proposal:
> 
> The basic protocol SHOULD NOT support any additional requirement besides the
> requirements listed in this document. Any additional feature not listed
> SHOULD only be supported using extension fields.
>

At least you start accepting that other features MAY be implemented by a protocol.
We are therefore a little bit further than:

   > No. We would not make the effort of writing these requirements if we were
   > going to allow a protocol that supports many other features that are *not*
   > required.

Nevertheless, I consider your proposition as overspecification and unjustified.

- You make the assumption that there is something like an extensions mechanism. 
- You restrict ALL features to that extension mechanism without leaving 
  the possibility of 'devine inspiration' that leads to an obvious feature of a
  protocol implemented in an obvious way immediately.

I would agree that additional features that are supported by a protocol need
to have consensus since they may create additional development effort and
interoperability problems. 

Peter





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3TF6eL07174 for ietf-pkix-bks; Mon, 29 Apr 2002 08:06:40 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TF6ca07169 for <[e-mail]>; Mon, 29 Apr 2002 08:06:38 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA04310; Mon, 29 Apr 2002 17:06:27 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Mon, 29 Apr 2002 17:06:27 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA18426; Mon, 29 Apr 2002 17:06:26 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA13799; Mon, 29 Apr 2002 17:06:26 +0200 (MET DST)
Date: Mon, 29 Apr 2002 17:06:26 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
Cc: [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>

> 
> " When the request is authenticated, the requestor SHOULD be able, upon
> request, to indicate an identifier to be included in the response. 
> How this identifier is matched with the authenticated identity depends 
> on local server conditions and/or the validation policy. The server 
> MAY choose to refuse to include an identifier in the response, or MAY 
> refuse to create a response." 
> 
> I do not see that there is a need to add "claimed" in it.
> 

Ok.

The text 'requestor SHOULD be able' is not good as I said in a
previous message. 'the protocol MUST provide a means to optionally
allow ..' 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3TEm7J04525 for ietf-pkix-bks; Mon, 29 Apr 2002 07:48:07 -0700 (PDT)
Received: from dymwsm17.mailwatch.com (dymwsm17.mailwatch.com [204.253.83.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TEm6a04519 for <[e-mail]>; Mon, 29 Apr 2002 07:48:06 -0700 (PDT)
Received: from MWSC0215.mw4.mailwatch.com (mwsc0215.mw4.mailwatch.com [204.253.83.251]) by dymwsm17.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3TElxB32411 for <[e-mail]>; Mon, 29 Apr 2002 10:48:01 -0400
Received: from mail pickup service by MWSC0215.mw4.mailwatch.com with Microsoft SMTPSVC; Mon, 29 Apr 2002 10:47:59 -0400
Received: from 204.253.83.34 ([204.253.83.34]) by MWSC0215 with SMTP id 000200021a1e0b7f-356a-4eb0-883b-9c533143c5ed;	 Mon, 29 Apr 2002 10:47:58 -0500
Received: from bigbird.entegrity.com (bigbird.gradient.com [192.92.110.50])	by dymwsm12.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3TElwL24113;	Mon, 29 Apr 2002 10:47:58 -0400
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10)	id <JC4CD11B>; Mon, 29 Apr 2002 10:44:23 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, "'Peter Sylvester'"	 <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: Multiple paths in DPD
Date: Mon, 29 Apr 2002 10:44:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: multipart/alternative;	boundary="----_=_NextPart_001_01C1EF8C.5A36EDF6"
HOP-COUNT: 1
X-MAILWATCH-INSTANCEID: 010200021a1e0b7f-356a-4eb0-883b-9c533143c5ed
X-OriginalArrivalTime: 29 Apr 2002 14:47:59.0251 (UTC) FILETIME=[DB0B8630:01C1EF8C]
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_01C1EF8C.5A36EDF6
Content-Type: text/plain;
	charset="ISO-8859-1"

> > Handling this protocol when the information used to
> > construct the paths changes between requests seems
> > particularly challenging to me.
> 
> No.  One of the underlying assumptions is that no
> paramters change from the client.  The client is
> seeking a path compliant to a given set of parameters.
> As it may turn out, the server may have several
> such that qualify.  The iterative approach enables
> a client to acquire these in serial query fashion
> until it either finds the precise record/path
> it's looking for or the server runs out of data.

I was not talking about the client providing different inputs, but the fact
that server's based of information will be updated from time to reflect
revocations, expirations, new authorities, etc. I assume this service will
be in continuous operation. 

Hal

------_=_NextPart_001_01C1EF8C.5A36EDF6
Content-Type: text/html;
	charset="ISO-8859-1"
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=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Multiple paths in DPD</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; &gt; Handling this protocol when the information =
used to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; construct the paths changes between =
requests seems</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; particularly challenging to me.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; No.&nbsp; One of the underlying assumptions is =
that no</FONT>
<BR><FONT SIZE=3D2>&gt; paramters change from the client.&nbsp; The =
client is</FONT>
<BR><FONT SIZE=3D2>&gt; seeking a path compliant to a given set of =
parameters.</FONT>
<BR><FONT SIZE=3D2>&gt; As it may turn out, the server may have =
several</FONT>
<BR><FONT SIZE=3D2>&gt; such that qualify.&nbsp; The iterative approach =
enables</FONT>
<BR><FONT SIZE=3D2>&gt; a client to acquire these in serial query =
fashion</FONT>
<BR><FONT SIZE=3D2>&gt; until it either finds the precise =
record/path</FONT>
<BR><FONT SIZE=3D2>&gt; it's looking for or the server runs out of =
data.</FONT>
</P>

<P><FONT SIZE=3D2>I was not talking about the client providing =
different inputs, but the fact that server's based of information will =
be updated from time to reflect revocations, expirations, new =
authorities, etc. I assume this service will be in continuous =
operation. </FONT></P>

<P><FONT SIZE=3D2>Hal</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1EF8C.5A36EDF6--


Received: by above.proper.com (8.11.6/8.11.3) id g3TEk3G04053 for ietf-pkix-bks; Mon, 29 Apr 2002 07:46:03 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TEk1a04045 for <[e-mail]>; Mon, 29 Apr 2002 07:46:01 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA17134; Mon, 29 Apr 2002 16:48:54 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042916452953:445 ; Mon, 29 Apr 2002 16:45:29 +0200 
Message-ID: <[e-mail]>
Date: Mon, 29 Apr 2002 16:45:34 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 29/04/2002 16:45:29, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 29/04/2002 16:46:00, Serialize complete at 29/04/2002 16:46:00
Content-Transfer-Encoding: 7bit
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>

Peter,

> Tim Gindin reminded me that I didn't respond to his mail
> from April 16 where he suggested to add the word 'claimed'
> to create "requester's claimed identity" allowing the
> a server to honour or not the information before returning
> it.
 
> I would accept this way to formulate the requirement.

The text fix that has been proposed is as follows:

" When the request is authenticated, the requestor SHOULD be able, upon
request, to indicate an identifier to be included in the response. 
How this identifier is matched with the authenticated identity depends 
on local server conditions and/or the validation policy. The server 
MAY choose to refuse to include an identifier in the response, or MAY 
refuse to create a response." 

I do not see that there is a need to add "claimed" in it.

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3TEeVE02843 for ietf-pkix-bks; Mon, 29 Apr 2002 07:40:31 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TEeTa02834 for <[e-mail]>; Mon, 29 Apr 2002 07:40:29 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA04166 for <[e-mail]>; Mon, 29 Apr 2002 16:40:30 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Mon, 29 Apr 2002 16:40:30 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA18297 for <[e-mail]>; Mon, 29 Apr 2002 16:40:29 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA13790 for [e-mail]; Mon, 29 Apr 2002 16:40:28 +0200 (MET DST)
Date: Mon, 29 Apr 2002 16:40:28 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3161bis-00.txt
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 text contains a changement that fixes some text concerning a MUST
requirement of the TSA policy to be returned, by changing some
SHOULD to a 'should'. 

I would like to know whether this text corresponds to group
consensus. 

As far as I remember there are some group members that
say that the MUST should be a SHOULD.  

I think the conflict can be summarizes with two paragraphs:

Actual: 

   The policy field MUST indicate the TSA's policy under which the
   response was produced.  If a similar field was present in the
   TimeStampReq, then it MUST have the same value, otherwise an error
   (unacceptedPolicy) MUST be returned. 

Proposed:

   The 'policy' field MUST indicate the TSA's policy under which the
   response was produced.  If the field 'reqPolicy' was present in the
   TimeStampReq, then 'policy' SHOULD have the same value, or an
   error (unacceptedPolicy) SHOULD be returned. 

Unfortunately it seems difficult to get a common opinion between
those who specify and those who implement. 

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

I think that the following text 

      " In that case, at any
       future time, the tokens signed with the corresponding key will be
       considered as invalid, but tokens generated before the revocation
       time will remain valid. "

should be accompagnied by something like:

   It is difficult for a user to claim validity of a token that have a date
   inferior to the revocation date without additional means, e.g. 
   cooperation of the TSA. It is necessary to provide evidence that the
   time stamp had been created before revocation BY THE TSA.  

 





Received: by above.proper.com (8.11.6/8.11.3) id g3TEdXT02639 for ietf-pkix-bks; Mon, 29 Apr 2002 07:39:33 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TEdVa02630 for <[e-mail]>; Mon, 29 Apr 2002 07:39:32 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA12864; Mon, 29 Apr 2002 16:42:25 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042916391802:441 ; Mon, 29 Apr 2002 16:39:18 +0200 
Message-ID: <[e-mail]>
Date: Mon, 29 Apr 2002 16:39:22 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 29/04/2002 16:39:18, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 29/04/2002 16:39:31, Serialize complete at 29/04/2002 16:39:31
Content-Transfer-Encoding: 7bit
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>

Peter,

> Denis,
> 
> Are you asking for a requirement to be included in the
> text that indicates:
> 
> " A protocol that implements the requirements of this document
>   MUST NOT, never ever, implement other features, even optional ones. "

I do not think that we need any sentence. Now, if we really needed one, here
is a proposal:

The basic protocol SHOULD NOT support any additional requirement besides the
requirements listed in this document. Any additional feature not listed
SHOULD only be supported using extension fields.

Denis

> > > The list of potential useful additional feature is as endless as the
> > > list of useless features.
> >
> > No. We would not make the effort of writing these requirements if we were
> > going to allow a protocol that supports many other features that are *not*
> > required.
> >


Received: by above.proper.com (8.11.6/8.11.3) id g3TEQL600920 for ietf-pkix-bks; Mon, 29 Apr 2002 07:26:21 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TEQKa00916 for <[e-mail]>; Mon, 29 Apr 2002 07:26:20 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA23830; Mon, 29 Apr 2002 16:29:12 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042916254888:436 ; Mon, 29 Apr 2002 16:25:48 +0200 
Message-ID: <[e-mail]>
Date: Mon, 29 Apr 2002 16:25:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 29/04/2002 16:25:49, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 29/04/2002 16:26:18, Serialize complete at 29/04/2002 16:26:18
Content-Transfer-Encoding: 7bit
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>

Peter,

> > > The list of potential useful additional feature is as endless as the
> > > list of useless features.
> >
> > No. We would not make the effort of writing these requirements if we were
> > going to allow a protocol that supports many other features that are *not*
> > required.
> >
> > Denis
> 
> Steve Kent said a few days ago:
> 
> " We agreed
>   to allow competing protocol submissions which would be evaluated
>   against the requirements. "
 
> This does not mean IMO, that it is forbidden to have more features
> than those specified in the requirement doc.

The two statements you quote are simply unrelated. 
So this is not a demonstration of your claim.

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3TEGis00553 for ietf-pkix-bks; Mon, 29 Apr 2002 07:16:44 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TEGga00549 for <[e-mail]>; Mon, 29 Apr 2002 07:16:42 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA17146; Mon, 29 Apr 2002 16:19:34 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042916160886:435 ; Mon, 29 Apr 2002 16:16:08 +0200 
Message-ID: <[e-mail]>
Date: Mon, 29 Apr 2002 16:16:14 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: roadmap
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 29/04/2002 16:16:08, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 29/04/2002 16:16:41, Serialize complete at 29/04/2002 16:16:41
Content-Transfer-Encoding: 7bit
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>

Peter,

I believe that we fixed the wording of the roadmap. So the original goal of
this thread is met.

On the other topic whereas OCSP could be extended to support DPV
requirements, we have different views.

Let wait until the DPV requirement document is finished and come back to
that topic later on, if needed.

Denis


> > > - A "trusted" OCSP responder which is not a CA or an authorized responder
> > >   can also issue status information based on his own local policy not
> > >   established by a CA, it can have its own 'revocation service' based
> > >   on the needs of the relying party.

> > So a trusted OCSP responder provides the revocation status information of a
> > *single* certificate and has nothing to do with a DPV server that does much
> > more on a *chain* of certificates.

> The point was that the structure of OCSP trust delegations, i.e., the modes
> of CA, authorized responder and trusted responder provide sufficient possibilities
> so that trust among a DPV client and services can be establish in a same way.
 
> A potential addition to the OCSP protocol you turn a server which was is trusted
> by the client using one of the existing OCSP trust mechanism into a service that
> is implmenting the DPV requirements, i.e. into a DPV server that youses an enhanced
> OCSP protocol.

> > > - An 'authorised' CA DPV responder can create status information about

> > An " 'authorised' CA DPV responder" is not a correct wording: either it is a
> > CA or a DPV responder.

> I am talking about an extended OCSP protocol implementing the DPV
> requirements operated by an authorized OCSP responder.
 

> > >   its immediately subordinate certs, i;e. the single OCSP response that you
> > >   mention, and at the same time include some DPV response that validate
> > >   the path from the intermediate CA to the trusted root, either
> > >   as an entity extension or as a global extension.

> > > - An OCSP server can also be any entity, and not just an authorised
> > >   CA responder. An OCSP responder can respond to whatever the service
> > >   provider likes to provide to its clients or what they need. OCSP is
> > >   not a 'A CS service'.

> > An OCSP server basically provides the revocation status of a certificate and
> > may support extensions in addition to that basic response. Up to now, such
> > extensions have not been defined.

> Obviously not, since we are not at the point of defining a protocol. As far
> as I have understood, Mike is waiting until the DPV reqs get settled.
 
> > Since a DPV response is far richer than a DPV response, it would be quite
> > strange to use the content of the extension and to discard the main
> > response.

> Who has proposed to discard something?
 
> > Picky-backing the DPV structure in an extension of the OCSP structure would
> > also lead to a strange behaviour. You could get a "valid OCSP answer" with
> > an "invalid DPV answer" (e.g. because a certificate from the chain is
> > revoked). These two statuses do not match together.

> Why do you think that the DPV server should indicate that the
> certificate is good. Again, I am not advocating OCSPv2 which some people
> may consider as repaied/enhanced by technique to similar as for
> the Hubble telescope.


Received: by above.proper.com (8.11.6/8.11.3) id g3TDCGi26633 for ietf-pkix-bks; Mon, 29 Apr 2002 06:12:16 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TDCEa26629 for <[e-mail]>; Mon, 29 Apr 2002 06:12:14 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA03747; Mon, 29 Apr 2002 15:12:11 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Mon, 29 Apr 2002 15:12:12 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA17932; Mon, 29 Apr 2002 15:12:10 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA13765; Mon, 29 Apr 2002 15:12:10 +0200 (MET DST)
Date: Mon, 29 Apr 2002 15:12:10 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
Cc: [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>

Tim Gindin reminded me that I didn't respond to his mail
from April 16 where he suggested to add the word 'claimed'
to create "requester's claimed identity" allowing the
a server to honour or not the information before returning
it. 

I would accept this way to formulate the requirement. 


Received: by above.proper.com (8.11.6/8.11.3) id g3TBrWs24384 for ietf-pkix-bks; Mon, 29 Apr 2002 04:53:32 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TBrVa24379 for <[e-mail]>; Mon, 29 Apr 2002 04:53:31 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25116; Mon, 29 Apr 2002 07:53:29 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc3161bis-00.txt
Date: Mon, 29 Apr 2002 07:53:27 -0400
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 Time-Stamp 
                          Protocol (TSP)
	Author(s)	: C. Adams, P. Cain, D. Pinkas, R. Zuccherato
	Filename	: draft-ietf-pkix-rfc3161bis-00.txt
	Pages		: 26
	Date		: 26-Apr-02
	
This document describes the format of a request sent to a Time
Stamping Authority (TSA) and of the response that is returned. It
also establishes several security-relevant requirements for TSA
operation, with regards to processing requests to generate responses.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-rfc3161bis-00.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-rfc3161bis-00.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-rfc3161bis-00.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3TBVRi23911 for ietf-pkix-bks; Mon, 29 Apr 2002 04:31:27 -0700 (PDT)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3TBVOa23907 for <[e-mail]>; Mon, 29 Apr 2002 04:31:25 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3TBVOb19777 for <[e-mail]>; Mon, 29 Apr 2002 12:31:24 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Mon, 29 Apr 2002 12:25:48 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA14157; Mon, 29 Apr 2002 12:31:17 +0100
Message-ID: <[e-mail]>
Date: Mon, 29 Apr 2002 12:31:17 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>, "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: Multiple paths in DPD
References: <[e-mail]>
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>

Mike, Russ,

Firstly, I also like the "cookie" approach to handling multiple
paths so add me to the list of those who'd like the requirements
document not to preclude this (I hadn't spotted that it did so).
I would though agree with Russ that the requirements document must 
not require that protocols take this approach. So, basically, the
text "Therefore the client MUST be able to indicate the maximum 
number of certification paths to be returned (provided that 
they can be found)." is another example of the requirements 
being overly prescriptive and the usual fix can be applied.

Second, I did manage to find a message [1] about this in a 
relevant thread [2]. I wouldn't say that messaage represents 
concensus, but OTOH I didn't find anything about what's currently 
in the requirements draft (though it may be there of course).

Third, in looking for those, I noticed that my earliest on-list
mail on this topic was Paul Hoffman's of May 23rd 2000 [3], so we 
can mark the 2nd anniversary of this discussion soon,

Sigh,
Stephen.

[1] http://www.imc.org/ietf-pkix/old-archive-00/msg02286.html
[2] http://www.imc.org/ietf-pkix/old-archive-00/msg02220.html
[3] http://www.imc.org/ietf-pkix/old-archive-00/msg00840.html

Michael Myers wrote:
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of
> > Housley, Russ
> > Sent: Friday, April 26, 2002 8:04 AM
> >
> > Mike:
> >
> > I am strongly opposed to an approach that would
> > require the server to maintain state.  Unless other
> > people are willing to speak up and support such an
> > approach, I am not willing to make changes in this
> > area.  In my view, the current consensus is for
> > a stateless server.
> >
> > Russ
> 
> Russ,
> 
> I'm probably just digging me a deeper hole but I thought to
> entertain myself in determining precisely where consensus was
> reached in the WG regarding stateless servers.
> 
> It turns out that I can't find one.  I looked at two sources:
> the list back for this full year (2002) and the minutes of the
> meetings as recorded on the IETF web site.  I searched for
> "state", "stateless" and "stateful".
> 
> I found nothing in the 2002 minutes with respect to these search
> targets.  It's only in Minneapolis, 14 March 2001 where the
> minutes record a briefing by Denis:
> 
>     "DPD/DPV - Denis Pinkas (Bull)
>     . . .
>     Finally, argues for stateless servers, i.e.,
>     no retry facility in DPD. (slides)"
> 
> On the list, there's only two hits on "stateful", both in a
> single message from me querying Tim on an issue regarding relay.
> A search for "stateless" for this entire calendar year only
> found the message of today asserting consensus on the stateless
> approach.  Of the 328 hits for "state" in the list for 2002 most
> relate either to discussions of response states, the state
> machine design model on the server, or expository use of the
> word.  With respect to anything that might be construed as
> consensus on stateless servers, Peter Sylvester made a comment
> and Denis Pinas responded:
> 
>     [Answer 9] This would create the maintenance of state
>     information which should be avoided. . . .
> 
> So I think at best we have consensus by silent affirmation.
> 
> Mike

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: by above.proper.com (8.11.6/8.11.3) id g3T9hDh14048 for ietf-pkix-bks; Mon, 29 Apr 2002 02:43:13 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3T9hAa14044 for <[e-mail]>; Mon, 29 Apr 2002 02:43:10 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA03127; Mon, 29 Apr 2002 11:43:08 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Mon, 29 Apr 2002 11:43:08 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id LAA17295; Mon, 29 Apr 2002 11:43:07 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA13719; Mon, 29 Apr 2002 11:43:07 +0200 (MET DST)
Date: Mon, 29 Apr 2002 11:43:07 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
Cc: [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, 

Are you asking for a requirement to be included in the
text that indicates:

" A protocol that implements the requirements of this document
  MUST NOT, never ever, implement other features, even optional ones. "


> > 
> > The list of potential useful additional feature is as endless as the
> > list of useless features. 
> 
> No. We would not make the effort of writing these requirements if we were
> going to allow a protocol that supports many other features that are *not*
> required.
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3RKnVq18165 for ietf-pkix-bks; Sat, 27 Apr 2002 13:49:31 -0700 (PDT)
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3RKnTa18159 for <[e-mail]>; Sat, 27 Apr 2002 13:49:29 -0700 (PDT)
Received: from tsg1 ([12.81.70.70]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020427204926.HFEC18857.mtiwmhc24.worldnet.att.net@tsg1>; Sat, 27 Apr 2002 20:49:26 +0000
Message-ID: <020c01c1ee2c$ca06a790$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "PKIX-IETF" <[e-mail]>, "LISTS - IETF-IESG" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Open issue: requester identifier in DPV response
Date: Sat, 27 Apr 2002 13:46:23 -0700
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 5.50.4522.1200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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>

Stephen - I think that it is very likely that ANY involvement by a WG Chair
in ANY protocol at any level is a conflict of interest and actionable as
such. It shows a predudicial predisposition towards that protocol and favors
it over all others. This is why I am demanding the rewriting of the WG's
charter as well as the approriate sections of RFC2026 et al..

What this means is that you,a WG Chiar CANNOT make any agreements as what
you will and wont allow in the WG. In fact what it really means is that a WG
Chair cannot make any arbitrary decsions regarding one protocol over
another, and it further mandates a uniform process for all. That means
definging the term "vetting" for this WG and how many participants have to
be involved and whether they have to represent separate interests or not...

So the IETF is shooting 0% on keeping the playing field level IMHO...


Todd



----- Original Message -----
From: "Peter Sylvester" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, April 26, 2002 10:40 AM
Subject: Re: Open issue: requester identifier in DPV response


>
> > >
> > > The list of potential useful additional feature is as endless as the
> > > list of useless features.
> >
> > No. We would not make the effort of writing these requirements if we
were
> > going to allow a protocol that supports many other features that are
*not*
> > required.
> >
> > Denis
>
>
> Steve Kent said a few days ago:
>
> " We agreed
>   to allow competing protocol submissions which would be evaluated
>   against the requirements. "
>
> This does not mean IMO, that it is forbidden to have more features
> than those specified in the requirement doc.
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3RKaaV18045 for ietf-pkix-bks; Sat, 27 Apr 2002 13:36:36 -0700 (PDT)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3RKaYa18041 for <[e-mail]>; Sat, 27 Apr 2002 13:36:34 -0700 (PDT)
Received: from tsg1 ([12.81.70.186]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020427203629.GVXA2855.mtiwmhc25.worldnet.att.net@tsg1>; Sat, 27 Apr 2002 20:36:29 +0000
Message-ID: <01ec01c1ee2a$fac02ca0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Hal Lockhart" <[e-mail]>, "PKIX-IETF" <[e-mail]>, <[e-mail]>, "Tim Polk" <[e-mail]>
References: <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Date: Sat, 27 Apr 2002 13:34:46 -0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E9_01C1EDF0.4BED4760"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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_01E9_01C1EDF0.4BED4760
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

RE: Meaning of Non-repudiationHal -
  ----- Original Message -----=20
  From: Hal Lockhart=20
  To: 'Tony Bartoletti' ; Aisenberg, Michael ; =
'[e-mail]' ; '[e-mail]'=20
  Cc: '[e-mail]'=20
  Sent: Friday, April 26, 2002 11:24 AM
  Subject: RE: Meaning of Non-repudiation


  I believe the terms non-repudiation and signature date back to a time =
(1980's) when nobody was talking about this stuff except a few =
mathematicians.=20



You mean as far as Computer Scientists and researchers are concerned?  =
because Banking and other Trust-impinged computer operations have had =
these concepts operating as self-proofing feature for considerably =
longer that the last 20 years.  NR here was implemented as an external =
process. But when you look at them from a logic model stanpoint the NR =
is the same.

What is amusing here is that the PKI world thinks it invented NR. =
Personally what I think  that this is more grist for the mill 'that the =
commercial processes require commercial inputs'.=20



  They probably realized they were using analogies to name mathematical =
concepts, which did have precise meanings in that limited scope. It is =
now recognized that neither analogy holds up to close scrutiny.

  Unfortunately, the terminology got picked up and used very loosely by =
the rest of the world. I have gotten used to hearing marketing types =
using "non-repudiation" to mean any use of digital signatures. (Don't =
get me started on "Trust." ;-)=20

  I just point them at Tom's document. I agree with Tony. What else can =
we do?=20

  Hal=20

  > -----Original Message-----=20
  > From: Tony Bartoletti [mailto:[e-mail]]=20
  > Sent: Friday, April 26, 2002 2:50 PM=20
  > To: Aisenberg, Michael; '[e-mail]';=20
  > '[e-mail]'=20
  > Cc: '[e-mail]'=20
  > Subject: RE: Meaning of Non-repudiation=20
  >=20
  >=20
  >=20
  >=20
  > At the risk of incurring PKIX list-wrath ...=20
  >=20
  > To my view of things, the "existence" of NR=3D1 in a=20
  > certificate is no more=20
  > than a statement, by the issuing CA, that "they will not=20
  > stand in the way=20
  > of this certificate being used as a component in some form of=20
  > NR scheme=20
  > (and will happily accept your Visa or Mastercard, thank you.)=20
  >=20
  > If one limits the presence of an NR bit to this weak=20
  > assertion, it becomes=20
  > clear that the NR bit "means almost nothing."  Thus there is=20
  > little left to=20
  > debate about it on the list.=20
  >=20
  > (As I recall, Tom Ginden's "Technical Non-Repudiation"=20
  > document was about=20
  > as far as one could reasonably take application of the NR=20
  > bit.  It was time=20
  > for everyone else to put-up or shut-up, and everyone shut-up.)=20
  >=20
  >=20
  > ____tony____=20
  >=20
  > Tony Bartoletti 925-422-3881 <[e-mail]>=20
  > Information Operations, Warfare and Assurance Center=20
  > Lawrence Livermore National Laboratory=20
  > Livermore, CA 94551-9900=20
  >=20
  >=20
  >=20
  >=20


------=_NextPart_000_01E9_01C1EDF0.4BED4760
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: Meaning of Non-repudiation</TITLE>
<META content=3D"text/html; charset=3DISO-8859-1" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.3315.2870" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Hal -</FONT></DIV>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
  <DIV=20
  style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
  <A href=3D"mailto:[e-mail]"=20
  title=[e-mail]>Hal Lockhart</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>To:</B> <A =
href=3D"mailto:[e-mail]"=20
  title=[e-mail]>'Tony Bartoletti'</A> ; <A=20
  href=3D"mailto:[e-mail]" =
title=[e-mail]>Aisenberg,=20
  Michael</A> ; <A href=3D"mailto:'[e-mail]'"=20
  =
title=[e-mail]>'[e-mail]'</A>=
 ; <A=20
  href=3D"mailto:'[e-mail]'"=20
  title=[e-mail]>'[e-mail]'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Cc:</B> <A =
href=3D"mailto:'[e-mail]'"=20
  title=[e-mail]>'[e-mail]'</A> </DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Friday, April 26, 2002 =
11:24=20
  AM</DIV>
  <DIV style=3D"FONT: 10pt arial"><B>Subject:</B> RE: Meaning of=20
  Non-repudiation</DIV>
  <DIV><BR></DIV>
  <P><FONT size=3D2>I believe the terms non-repudiation and signature =
date back to=20
  a time (1980's) when nobody was talking about this stuff except a few=20
  mathematicians. </FONT></P>
  <P><FONT size=3D2></FONT>&nbsp;</P></BLOCKQUOTE>
<P><FONT face=3DArial size=3D2>You mean as far as Computer Scientists =
and=20
researchers are concerned?&nbsp; because Banking and other =
Trust-impinged=20
computer operations have had these concepts operating as self-proofing =
feature=20
for&nbsp;considerably longer that the last 20 years.&nbsp; NR here was=20
implemented as an external process. But when you look at them from a =
logic model=20
stanpoint the NR is the same.</FONT></P>
<P><FONT face=3DArial size=3D2>What is amusing here is that the PKI =
world thinks it=20
invented NR. Personally what I think&nbsp; that this is more grist for =
the mill=20
'that&nbsp;the commercial processes require commercial =
inputs</FONT><FONT=20
face=3DArial size=3D2>'. </FONT></P>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #000000 2px solid; MARGIN-LEFT: 5px; MARGIN-RIGHT: =
0px; PADDING-LEFT: 5px; PADDING-RIGHT: 0px">
  <P><FONT size=3D2></FONT>&nbsp;</P>
  <P><FONT size=3D2>They probably realized they were using analogies to =
name=20
  mathematical concepts, which did have precise meanings in that limited =
scope.=20
  It is now recognized that neither analogy holds up to close=20
  scrutiny.</FONT></P>
  <P><FONT size=3D2>Unfortunately, the terminology got picked up and =
used very=20
  loosely by the rest of the world. I have gotten used to hearing =
marketing=20
  types using "non-repudiation" to mean any use of digital signatures. =
(Don't=20
  get me started on "Trust." ;-) </FONT></P>
  <P><FONT size=3D2>I just point them at Tom's document. I agree with =
Tony. What=20
  else can we do?</FONT> </P>
  <P><FONT size=3D2>Hal</FONT> </P>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Tony Bartoletti [<A=20
  href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> <BR><FONT =

  size=3D2>&gt; Sent: Friday, April 26, 2002 2:50 PM</FONT> <BR><FONT =
size=3D2>&gt;=20
  To: Aisenberg, Michael; '[e-mail]';</FONT> =
<BR><FONT=20
  size=3D2>&gt; '[e-mail]'</FONT> <BR><FONT size=3D2>&gt; Cc:=20
  '[e-mail]'</FONT> <BR><FONT size=3D2>&gt; Subject: RE: =
Meaning of=20
  Non-repudiation</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; At the risk of incurring PKIX list-wrath ...</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; To my view of things, the =
"existence"=20
  of NR=3D1 in a </FONT><BR><FONT size=3D2>&gt; certificate is no more=20
  </FONT><BR><FONT size=3D2>&gt; than a statement, by the issuing CA, =
that "they=20
  will not </FONT><BR><FONT size=3D2>&gt; stand in the way =
</FONT><BR><FONT=20
  size=3D2>&gt; of this certificate being used as a component in some =
form of=20
  </FONT><BR><FONT size=3D2>&gt; NR scheme </FONT><BR><FONT =
size=3D2>&gt; (and will=20
  happily accept your Visa or Mastercard, thank you.)</FONT> <BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; If one limits the =
presence of an NR=20
  bit to this weak </FONT><BR><FONT size=3D2>&gt; assertion, it becomes=20
  </FONT><BR><FONT size=3D2>&gt; clear that the NR bit "means almost=20
  nothing."&nbsp; Thus there is </FONT><BR><FONT size=3D2>&gt; little =
left to=20
  </FONT><BR><FONT size=3D2>&gt; debate about it on the list.</FONT> =
<BR><FONT=20
  size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; (As I recall, Tom =
Ginden's "Technical=20
  Non-Repudiation" </FONT><BR><FONT size=3D2>&gt; document was about=20
  </FONT><BR><FONT size=3D2>&gt; as far as one could reasonably take =
application=20
  of the NR </FONT><BR><FONT size=3D2>&gt; bit.&nbsp; It was time =
</FONT><BR><FONT=20
  size=3D2>&gt; for everyone else to put-up or shut-up, and everyone=20
  shut-up.)</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; ____tony____</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Tony Bartoletti 925-422-3881=20
  &lt;[e-mail]&gt;</FONT> <BR><FONT size=3D2>&gt; Information =
Operations,=20
  Warfare and Assurance Center</FONT> <BR><FONT size=3D2>&gt; Lawrence =
Livermore=20
  National Laboratory</FONT> <BR><FONT size=3D2>&gt; Livermore, CA=20
  94551-9900</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt;=20
</FONT></P></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_01E9_01C1EDF0.4BED4760--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3RI32f15780 for ietf-pkix-bks; Sat, 27 Apr 2002 11:03:02 -0700 (PDT)
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3RI30a15776 for <[e-mail]>; Sat, 27 Apr 2002 11:03:00 -0700 (PDT)
Received: from tsg1 ([12.81.70.186]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020427180256.DRST18857.mtiwmhc24.worldnet.att.net@tsg1>; Sat, 27 Apr 2002 18:02:56 +0000
Message-ID: <013f01c1ee15$87ee4d70$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "PKIX" <[e-mail]>, "Aram Perez" <[e-mail]>
Cc: "Hoyt L. Kesterson II" <[e-mail]>
References: <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Date: Sat, 27 Apr 2002 10:58:33 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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>

Aram - yes you are rignt in your commentary regarding the analog and needing
a metric to measure the verying state of NR with.What I would suggest is
that these are states that are based in "grade of reliability" and that
these are technologies that that need to be codified in concert with the
audit community since they will really be the source of the metric.

What this will allow to occur is that stateful information as to the
integrity of the surrounding system can be made part ofthe trust negotiation
process (one of those Mythical "Transaction Service Models" that Stephen is
so fond of hammering me for)...

The end point of this is that it brings to light something critical and that
is the concept that Audit and Audit Process (or state data) needs to be
included inside of the PKI process so that total machine processing of PKI
enhanced transactions can take place. This is another argument for all of
the concepts that I proposed:

    1)    Adding a need for a use model to all I-D/RFC/Standards Drafts

    2)    Building bridges between us and the other standards groups
affected by PKI... especially to the auditors.

    3)    And finally the realization that it is the Audit Process and its
model that determines the end makeup of the PKI product - Not us.


Todd

----- Original Message -----
From: "Aram Perez" <[e-mail]>
To: "PKIX" <[e-mail]>
Cc: "Hoyt L. Kesterson II" <[e-mail]>
Sent: Friday, April 26, 2002 11:37 AM
Subject: Re: Meaning of Non-repudiation



Maybe Hoyt can comment. If I understood him correctly, he mentioned to
me that he had talked to a few people during the RSA Conference and that
there was a consensus to have the NR bit renamed at the X.509 level.

Regards,
Aram Perez


On Friday, April 26, 2002, at 09:37  AM, Aisenberg, Michael wrote:

> As an under-initiated tech-wanabe lawyer who has observed the
> 'non-repudiation'
> debate for several years, it occurs to me that, not only do I concur in
> Todd's observation
> regarding the use of NR {as a technical bit-descriptor being problematic
> vis-à-vis
> his described more 'comprehensive' view of  NR as a 'condition' achieved
> through the
> deployment of an IA environment}, but would further suggest that even
> THAT interpretation requires
> calibration against the generally accepted legal concept of
> non-repudiation
> inherent in the construct and case law around UCC secs. 2-609/2-610.
>
> Todd's analysis suggests a non-statutory analog --based on a description
> of a
> complex of conditions existing simultaneously-- that provides a
> technology-grounded basis for asserting
> the same absolute of  'undeniability of existence' that the
> legal/statutory phrase implies (but, lawyers would never
> assert with the same absolutism as, say, a law of physics, unless a
> court of last resort had
> ruled!)--but it is of course still different from, and therefore capable
> of being confused with the
> bit descriptor.  All of which is a long-winded way of stating the
> obvious--that the importation
> of 'terms of art' from one discipline to another is risky--absent
> precise equality of
> definition, intent and usage--which we obviously don't have here......
>
>
> Michael Aisenberg
> --VeriSign/D.C.--
>
>
> -----Original Message-----
> From: todd glassey [mailto:[e-mail]]
> Sent: Friday, April 26, 2002 11:49 AM
> To: Tom Gindin
> Cc: PKIX-IETF
> Subject: Re: Meaning of Non-repudiation
>
>
>
> Tom,
> I agree with you - the X.509 model is broken too. NR is a bigger thing
> than
> a bit in a data structure and using the term NR causes problems for
> auditors
> and other professionals that would have to use these protocols.
>
> I and many others define NR as the sum-total of all the Information
> Assurance technologies, techniques, and practices that make up and
> operating
> environment. Thus NR is a state specific to a totality of condition and
> maybe needs essentially gradiant levels rather than a binary on or off
> state. Thats why a single bit alone without the accompanying OID is of
> questionable value here.
>
> Todd
>
> ----- Original Message -----
> From: "Tom Gindin" <[e-mail]>
> To: "Stephen Kent" <[e-mail]>
> Cc: "David P. Kemp" <[e-mail]>; <[e-mail]>
> Sent: Wednesday, April 11, 2001 3:50 PM
> Subject: Re: Meaning of Non-repudiation
>
>
>>
>>      IMHO, if X.509 had not been calling the bit in KeyUsage
>> "non-repudiation" for some years, I would prefer to put "Persistent
> Data
>> Authentication" into KeyUsage and define several different flavors of
>> non-repudiation in ExtendedKeyUsage, profiling non-repudiation
> services in
>> parallel with those ExtendedKeyUsage values.  This would also allow us
> to
>> define different levels of NR and put them into certificates in a
> natural
>> way.  However, they have been calling the bit "non-repudiation", and
> I'm
>> not sure we can change its meaning on the installed base of
> certificates
>> and on the X.509 group without an unusual level of unanimity and
>> near-certainty that it won't break anything.
>>
>>           Tom Gindin
>>
>>
>>
>





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3R2TRw23710 for ietf-pkix-bks; Fri, 26 Apr 2002 19:29:27 -0700 (PDT)
Received: from hotmail.com (dav20.sea1.hotmail.com [207.68.162.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3R2TPa23705 for <[e-mail]>; Fri, 26 Apr 2002 19:29:25 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 26 Apr 2002 19:29:24 -0700
X-Originating-IP: [213.158.176.47]
From: "osama farook" <[e-mail]>
To: <[e-mail]>
Subject: choose between different CA vendors
Date: Thu, 25 Apr 2002 23:05:38 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01C1ECAD.B6B5F540"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 27 Apr 2002 02:29:24.0881 (UTC) FILETIME=[58CBC810:01C1ED93]
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_0014_01C1ECAD.B6B5F540
Content-Type: text/plain;
	charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

What is the criteria (technichally) to choose between different CA =
vendors to build my security server?
I want to know this to help me in my project " Building CA Serve" .

------=_NextPart_000_0014_01C1ECAD.B6B5F540
Content-Type: text/html;
	charset="windows-1256"
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=3Dwindows-1256">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV align=3Dleft><FONT face=3DArial size=3D4><STRONG>What is the =
criteria=20
(technichally) to choose between different CA vendors to build my =
security=20
server?<BR>I want to know this to help me in my project " Building CA =
Serve"=20
.</STRONG></FONT></DIV></BODY></HTML>

------=_NextPart_000_0014_01C1ECAD.B6B5F540--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3R0xtB22552 for ietf-pkix-bks; Fri, 26 Apr 2002 17:59:55 -0700 (PDT)
Received: from phnxpop6.phnx.uswest.net (phnxpop6.phnx.uswest.net [206.80.192.6]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3R0xra22548 for <[e-mail]>; Fri, 26 Apr 2002 17:59:54 -0700 (PDT)
Received: (qmail 19880 invoked by uid 0); 27 Apr 2002 00:59:58 -0000
Received: from vdsl-130-13-126-42.phnx.uswest.net (HELO ?192.168.2.12?) (130.13.126.42) by phnxpop6.phnx.uswest.net with SMTP; 27 Apr 2002 00:59:58 -0000
Date: Fri, 26 Apr 2002 17:58:42 -0700
Message-Id: <a0510030bb8ef9ab3016a@[192.168.2.12]>
From: "Hoyt L. Kesterson II" <[e-mail]>
To: "PKIX" <[e-mail]>
Mime-Version: 1.0
X-Sender: [e-mail]
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Content-Type: text/plain; charset="iso-8859-1" ; format="flowed"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3R0xsa22549
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 been talking to people about this bit for sometime. we did 
discuss it at the meeting in geneva in early march and i did discuss 
the issue at the american bar association meeting information 
security meeting just before that (and yes at the rsa meeting also)

the choice of non-repudiation for the name of the bit so long ago is 
unfortunate since so many interpretations have sprung up. i still 
believe that the intent was to signal "more" than just providing a 
signature for proof of origin. at the time i suggested that what 
"more" is would be understood from policy. i still argue that a bit 
is not enough to convey all the shades of meaning desired.

i think that "more" means some sort of "not only is this proof of who 
i am, but also,scout's honor, i really mean what i say in this 
message". i argue that the text that in 509 that that the 
nonRepudiation bit does not have to be set in certificates used to 
support signing a crl shows our intent when we wrote this text 10 
years ago, albeit poorly. that is, one doesn't have to signal "more" 
when signing a crl because cRLsign = digitalSignature + 
nonRepudiation - not only can it be proven that the proper entity 
signed the message but that it intends to stand by the content of the 
message.

it's clear that when one talks to lawyers long enough, an agreement 
that looks rock solid to engineers looks like swiss cheese to lawyers.

even if the systems could be made so unbuggerable that one could 
honestly swear in court that what was signed was what was presented 
to the reader, a lawyer could still argue about intent (i.e., i meant 
to do it and i understood the consequences of doing it). i firmly 
believe it's still a good goal to try to build that unbuggerable 
system because improved systems should focus the legal argument (but 
i suspect a lawyer will still try to throw everything into question 
if that helps the client).

if this stuff gets used frequently and the public accepts its correct 
operation as an everyday tool of life, then focus on the technology 
may go away. today it would take a rare lawyer to drag in telephone 
service providers and experts in order to convince a judge or jury 
that there is no proof that the plaintiff's telephone call to the 
client actually went to the client (of course internet telephony may 
make this an arguable point again). maybe after a 100 years the 
public will consider electronic contracts and agreements just another 
tool of everyday life.

so, if we really cannot declare something nor-reputable with just the 
stroke of a bit, should we just forget the whole thing?

i think that it might be useful to signal that the ca expects this 
certificate to be used as more than just source of origin 
authentication. can such a signal be a two state flag? maybe, but it 
could be a lot of semantics to put on one small bit. however, the bit 
could be used to signal the "more" status with an understanding that 
the precise conditions and constraints will be specified elsewhere, 
e.g. policy. a lawyer i work with on the isc suggests the phrase 
"necessary but not sufficient condition".

does this need to be fixed in x.509? YES. however, i suspect that 
changing the name would be merely a placebo and later on, we will 
still find that all is not well.

i have suggested to the directory group that, even though the 
discussion will probably be painful, we should clarify the text 509. 
however, i don't think this is something to fix by defect processing 
but in the new edition currently under development.

i hope that you people and the isc would be very active in the 
development of that text.

    hoyt


At 11:37 AM -0700 4/26/02, Aram Perez wrote:
>Maybe Hoyt can comment. If I understood him correctly, he mentioned 
>to me that he had talked to a few people during the RSA Conference 
>and that there was a consensus to have the NR bit renamed at the 
>X.509 level.
>
>Regards,
>Aram Perez
>
>
>On Friday, April 26, 2002, at 09:37  AM, Aisenberg, Michael wrote:
>
>>As an under-initiated tech-wanabe lawyer who has observed the
>>'non-repudiation'
>>debate for several years, it occurs to me that, not only do I concur in
>>Todd's observation
>>regarding the use of NR {as a technical bit-descriptor being problematic
>>vis-à-vis
>>his described more 'comprehensive' view of  NR as a 'condition' achieved
>>through the
>>deployment of an IA environment}, but would further suggest that even
>>THAT interpretation requires
>>calibration against the generally accepted legal concept of
>>non-repudiation
>>inherent in the construct and case law around UCC secs. 2-609/2-610.
>>
>>Todd's analysis suggests a non-statutory analog --based on a description
>>of a
>>complex of conditions existing simultaneously-- that provides a
>>technology-grounded basis for asserting
>>the same absolute of  'undeniability of existence' that the
>>legal/statutory phrase implies (but, lawyers would never
>>assert with the same absolutism as, say, a law of physics, unless a
>>court of last resort had
>>ruled!)--but it is of course still different from, and therefore capable
>>of being confused with the
>>bit descriptor.  All of which is a long-winded way of stating the
>>obvious--that the importation
>>of 'terms of art' from one discipline to another is risky--absent
>>precise equality of
>>definition, intent and usage--which we obviously don't have here......
>>
>>
>>Michael Aisenberg
>>--VeriSign/D.C.--
>>
>>
>>-----Original Message-----
>>From: todd glassey [mailto:[e-mail]]
>>Sent: Friday, April 26, 2002 11:49 AM
>>To: Tom Gindin
>>Cc: PKIX-IETF
>>Subject: Re: Meaning of Non-repudiation
>>
>>
>>
>>Tom,
>>I agree with you - the X.509 model is broken too. NR is a bigger thing
>>than
>>a bit in a data structure and using the term NR causes problems for
>>auditors
>>and other professionals that would have to use these protocols.
>>
>>I and many others define NR as the sum-total of all the Information
>>Assurance technologies, techniques, and practices that make up and
>>operating
>>environment. Thus NR is a state specific to a totality of condition and
>>maybe needs essentially gradiant levels rather than a binary on or off
>>state. Thats why a single bit alone without the accompanying OID is of
>>questionable value here.
>>
>>Todd
>>
>>----- Original Message -----
>>From: "Tom Gindin" <[e-mail]>
>>To: "Stephen Kent" <[e-mail]>
>>Cc: "David P. Kemp" <[e-mail]>; <[e-mail]>
>>Sent: Wednesday, April 11, 2001 3:50 PM
>>Subject: Re: Meaning of Non-repudiation
>>
>>>
>>>      IMHO, if X.509 had not been calling the bit in KeyUsage
>>>"non-repudiation" for some years, I would prefer to put "Persistent
>>Data
>>>Authentication" into KeyUsage and define several different flavors of
>>>non-repudiation in ExtendedKeyUsage, profiling non-repudiation
>>services in
>>>parallel with those ExtendedKeyUsage values.  This would also allow us
>>to
>>>define different levels of NR and put them into certificates in a
>>natural
>>>way.  However, they have been calling the bit "non-repudiation", and
>>I'm
>>>not sure we can change its meaning on the installed base of
>>certificates
>>>and on the X.509 group without an unusual level of unanimity and
>>>near-certainty that it won't break anything.
>>>
>>>           Tom Gindin



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QNKnP21178 for ietf-pkix-bks; Fri, 26 Apr 2002 16:20:49 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QNKla21174 for <[e-mail]>; Fri, 26 Apr 2002 16:20:47 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3QNKims346880; Fri, 26 Apr 2002 19:20:45 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3QNKfL46436; Fri, 26 Apr 2002 19:20:41 -0400
Importance: Normal
Sensitivity: 
To: "Aisenberg, Michael" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 26 Apr 2002 16:46:00 -0400
Subject: RE: Meaning of Non-repudiation
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/26/2002 07:20:43 PM
MIME-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=0ABBE134DF13BA6B8f9e8a93df938690918c0ABBE134DF13BA6B"
Content-Disposition: inline
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>

--0__=0ABBE134DF13BA6B8f9e8a93df938690918c0ABBE134DF13BA6B
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable



      I hope that everyone understands that whatever else the KeyUsage
non-repudiation bit might do, it does NOT imply that everything signed =
with
a certificate containing it meets UCC sections 2-609/2-610, or any simi=
lar
provisions.  The exact limit of what it does has been controversial on =
this
list in the past, and I see no reason to go over it in this context.

            Tom Gindin


"Aisenberg, Michael" <[e-mail]>@mail.imc.org on 04/26/20=
02
12:37:08 PM

Sent by:    [e-mail]


To:    "'[e-mail]'" <[e-mail]=
>,
       Tom Gindin/Watson/IBM@IBMUS
cc:    "'[e-mail]'" <[e-mail]>
Subject:    RE: Meaning of Non-repudiation



As an under-initiated tech-wanabe lawyer who has observed the
'non-repudiation'
debate for several years, it occurs to me that, not only do I concur in=

Todd's observation
regarding the use of NR {as a technical bit-descriptor being problemati=
c
vis-=E0-vis
his described more 'comprehensive' view of  NR as a 'condition' achieve=
d
through the
deployment of an IA environment}, but would further suggest that even
THAT interpretation requires
calibration against the generally accepted legal concept of
non-repudiation
inherent in the construct and case law around UCC secs. 2-609/2-610.

Todd's analysis suggests a non-statutory analog --based on a descriptio=
n
of a
complex of conditions existing simultaneously-- that provides a
technology-grounded basis for asserting
the same absolute of  'undeniability of existence' that the
legal/statutory phrase implies (but, lawyers would never
assert with the same absolutism as, say, a law of physics, unless a
court of last resort had
ruled!)--but it is of course still different from, and therefore capabl=
e
of being confused with the
bit descriptor.  All of which is a long-winded way of stating the
obvious--that the importation
of 'terms of art' from one discipline to another is risky--absent
precise equality of
definition, intent and usage--which we obviously don't have here......


Michael Aisenberg
--VeriSign/D.C.--


-----Original Message-----
From: todd glassey [mailto:[e-mail]]
Sent: Friday, April 26, 2002 11:49 AM
To: Tom Gindin
Cc: PKIX-IETF
Subject: Re: Meaning of Non-repudiation



Tom,
I agree with you - the X.509 model is broken too. NR is a bigger thing
than
a bit in a data structure and using the term NR causes problems for
auditors
and other professionals that would have to use these protocols.

I and many others define NR as the sum-total of all the Information
Assurance technologies, techniques, and practices that make up and
operating
environment. Thus NR is a state specific to a totality of condition and=

maybe needs essentially gradiant levels rather than a binary on or off
state. Thats why a single bit alone without the accompanying OID is of
questionable value here.

Todd

----- Original Message -----
From: "Tom Gindin" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>; <[e-mail]>
Sent: Wednesday, April 11, 2001 3:50 PM
Subject: Re: Meaning of Non-repudiation


>
>      IMHO, if X.509 had not been calling the bit in KeyUsage
> "non-repudiation" for some years, I would prefer to put "Persistent
Data
> Authentication" into KeyUsage and define several different flavors of=

> non-repudiation in ExtendedKeyUsage, profiling non-repudiation
services in
> parallel with those ExtendedKeyUsage values.  This would also allow u=
s
to
> define different levels of NR and put them into certificates in a
natural
> way.  However, they have been calling the bit "non-repudiation", and
I'm
> not sure we can change its meaning on the installed base of
certificates
> and on the X.509 group without an unusual level of unanimity and
> near-certainty that it won't break anything.
>
>           Tom Gindin
>
>
>


=

--0__=0ABBE134DF13BA6B8f9e8a93df938690918c0ABBE134DF13BA6B
Content-type: application/octet-stream; 
	name="=?iso-8859-1?Q?smime.p7s?="
Content-Disposition: attachment; filename="=?iso-8859-1?Q?smime.p7s?="
Content-transfer-encoding: base64

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEIzCCA4ygAwIBAgIQ
C4Pe+b9ZzSY6cFoTNpDgKTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDExMDExMDAwMDAwWhcNMDIx
MDExMjM1OTU5WjBzMREwDwYDVQQKEwhWRVJJU0lHTjEQMA4GA1UECxMHVkEtRUFTVDETMBEGA1UE
AxMKUmVjaXBpZW50czE3MDUGA1UEAxMubWFpc2VuYmVyZyAoQWlzZW5iZXJnIE1pY2hhZWwsIFZl
cmlTaWduLCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvUXjng0fglmjCF7bE23A
cpGiPS0Ci+9Ws6i/NDsGOYt21EbGOT1B+u6wazYjy29sKJkR5cicvJfyylRJ2Zl1Fc5sgewN+a88
g9x7hxQXITWaAlCPKUD/KB4qNeZvGSj1hu+ZdZvIm7N+/cUKT5W5Lvfd41B7bxlnQyADZHy3u8UC
AwEAAaOCAXwwggF4MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNy
bC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3Js
MAsGA1UdDwQEAwIFoDAiBgNVHREEGzAZgRdtYWlzZW5iZXJnQHZlcmlzaWduLmNvbTCBrAYDVR0g
BIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNp
Z24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWdu
J3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ
YIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0B
AQQFAAOBgQA8lpyvzHVxE92Tr9AX/8HdW2dKffNef2wIZXCd43hsblythAXOmU78nW4+W54zEonQ
jUoicXgE+oQZd/PVHLfEm8f67IZlrl38/wMJoNNqaaWJiCSH0qsGtNvxhNOKaspYIP5nyiT1gKcy
0F8WRd+fYUF6pq0IDxUClzkLftrxRzGCA94wggPaAgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2ln
biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlz
IHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5
OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQC4Pe+b9ZzSY6cFoTNpDg
KTAJBgUrDgMCGgUAoIICcjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wMjA0MjYxNjM1MTNaMCMGCSqGSIb3DQEJBDEWBBSVdF19mxIMHXndqUL4/wSib1ZBJjBnBgkq
hkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH
BgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAE
MYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQQIQC4Pe+b9ZzSY6cFoTNpDgKTCB1AYLKoZIhvcNAQkQAgsxgcSggcEwgawxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw
RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhAL
g975v1nNJjpwWhM2kOApMA0GCSqGSIb3DQEBAQUABIGAeBBRzPiU/xNbCFJjZH/5FYJ8x9nmfD9E
cbh+RqoRGzlTf+rCE/t8jUhrFi9HASzXsNhvFxJTmhtwjyd3ybXFPQ3ve7ZJ0ummszcdSYRchq/n
yvswcsF00QxdxQIBOWT0XkXrj6mLKrEzUtnEH5AbT5daG9N63dqrwKRknZcdsRMAAAAAAAAA

--0__=0ABBE134DF13BA6B8f9e8a93df938690918c0ABBE134DF13BA6B--



Received: by above.proper.com (8.11.6/8.11.3) id g3QM3AB19270 for ietf-pkix-bks; Fri, 26 Apr 2002 15:03:10 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QM39a19265 for <[e-mail]>; Fri, 26 Apr 2002 15:03:09 -0700 (PDT)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA27914; Fri, 26 Apr 2002 18:01:30 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100303b8ef7d15f2c9@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 26 Apr 2002 17:58:37 -0400
To: Tony Bartoletti <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Cc: "Aisenberg, Michael" <[e-mail]>, "'[e-mail]'" <[e-mail]>
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>

At 10:50 AM -0800 4/26/02, Tony Bartoletti wrote:
>At the risk of incurring PKIX list-wrath ...
>
>To my view of things, the "existence" of NR=1 in a certificate is no 
>more than a statement, by the issuing CA, that "they will not stand 
>in the way of this certificate being used as a component in some 
>form of NR scheme (and will happily accept your Visa or Mastercard, 
>thank you.)
>
>If one limits the presence of an NR bit to this weak assertion, it 
>becomes clear that the NR bit "means almost nothing."  Thus there is 
>little left to debate about it on the list.
>
>(As I recall, Tom Ginden's "Technical Non-Repudiation" document was 
>about as far as one could reasonably take application of the NR bit. 
>It was time for everyone else to put-up or shut-up, and everyone 
>shut-up.)
>
>____tony____

Tony,

I think the PKIX list discussion ended with the observation that 
there might be more benefit to the NR bit in the other direction, 
i.e., when it is NOT asserted. In that case the interpretation is 
that the CA is signalling that the cert was not issued for use in 
transactions requiring NR. Thus one would normally set the NR bit to 
0 in certs to be used for signing authentication data exchanges, vs. 
binding documents, etc.  When the bit is asserted, it is best viewed 
as a necessary, but not sufficient, condition for NR.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QK2Wr16481 for ietf-pkix-bks; Fri, 26 Apr 2002 13:02:32 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QK2Ta16476 for <[e-mail]>; Fri, 26 Apr 2002 13:02:30 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3QK2S28024163; Fri, 26 Apr 2002 13:02:28 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, <[e-mail]>
Subject: RE: Multiple paths in DPD
Date: Fri, 26 Apr 2002 12:59:34 -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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Housley, Russ
> Sent: Friday, April 26, 2002 8:04 AM
>
> Mike:
>
> I am strongly opposed to an approach that would
> require the server to maintain state.  Unless other
> people are willing to speak up and support such an
> approach, I am not willing to make changes in this
> area.  In my view, the current consensus is for
> a stateless server.
>
> Russ


Russ,

I'm probably just digging me a deeper hole but I thought to
entertain myself in determining precisely where consensus was
reached in the WG regarding stateless servers.

It turns out that I can't find one.  I looked at two sources:
the list back for this full year (2002) and the minutes of the
meetings as recorded on the IETF web site.  I searched for
"state", "stateless" and "stateful".

I found nothing in the 2002 minutes with respect to these search
targets.  It's only in Minneapolis, 14 March 2001 where the
minutes record a briefing by Denis:

    "DPD/DPV - Denis Pinkas (Bull)
    . . .
    Finally, argues for stateless servers, i.e.,
    no retry facility in DPD. (slides)"

On the list, there's only two hits on "stateful", both in a
single message from me querying Tim on an issue regarding relay.
A search for "stateless" for this entire calendar year only
found the message of today asserting consensus on the stateless
approach.  Of the 328 hits for "state" in the list for 2002 most
relate either to discussions of response states, the state
machine design model on the server, or expository use of the
word.  With respect to anything that might be construed as
consensus on stateless servers, Peter Sylvester made a comment
and Denis Pinas responded:

    [Answer 9] This would create the maintenance of state
    information which should be avoided. . . .

So I think at best we have consensus by silent affirmation.

Mike



Received: by above.proper.com (8.11.6/8.11.3) id g3QJJ0i15584 for ietf-pkix-bks; Fri, 26 Apr 2002 12:19:00 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QJIxa15580 for <[e-mail]>; Fri, 26 Apr 2002 12:18:59 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3QJIg28019831; Fri, 26 Apr 2002 12:18:45 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Hal Lockhart" <[e-mail]>, "'Peter Sylvester'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Multiple paths in DPD
Date: Fri, 26 Apr 2002 12:15:49 -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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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 Hal,

A few comments below.

Mike
-----Original Message-----
From: Hal Lockhart [mailto:[e-mail]]
Sent: Friday, April 26, 2002 11:46 AM

> > Peter Sylvester responded,
> >
> > the server does not need to maintain a state. That had been
> > discussed between Steve farrele and me some yearsz ago, in
> > order to clarify the meaning of what Mike calls 'state
token'.
> >
> > A server which returns a 'state token' does not turn it into
one
> > that MUST in a stateful mode. When the 'next request after
token'
> > comes it, the server sets up it state from the data that had
been
> > return by the 'cookie'.


> The extent to which this is true depends on how easily
> the server can go from the token to some persistent
> storage. (We are actually debating volatle state, not
> state per se.)

That was my conclusion.  I'm pretty sure there'll be abundant
state on that machine anyway.

> In Mike's specific proposal, the server has to constuct
> multiple paths relevant to a given request,

Which is must do anyway in the maxPath design scenario.

> in some order and be able to produce the "next" on demand.

As in "next record" for an SQL type query.  Which is sort
of my point.  DPD is just a tailored database access
mechanism.  And database machines have been doing this
for years.

> It seems unlikely that this can be done without remembering
> the list or at least the contents of the last response.

That is the key, to be sure.  What's the "next" record/path
to be returned?

> Handling this protocol when the information used to
> construct the paths changes between requests seems
> particularly challenging to me.

No.  One of the underlying assumptions is that no
paramters change from the client.  The client is
seeking a path compliant to a given set of parameters.
As it may turn out, the server may have several
such that qualify.  The iterative approach enables
a client to acquire these in serial query fashion
until it either finds the precise record/path
it's looking for or the server runs out of data.

Hal



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QInwx14936 for ietf-pkix-bks; Fri, 26 Apr 2002 11:49:58 -0700 (PDT)
Received: from dymwsm05.mailwatch.com (dymwsm05.mailwatch.com [204.253.83.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QInva14932 for <[e-mail]>; Fri, 26 Apr 2002 11:49:57 -0700 (PDT)
Received: from MWSC0208.MW4.MAILWATCH.COM (mwsc0208.mw4.mailwatch.com [204.253.83.244]) by dymwsm05.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3QInso02448 for <[e-mail]>; Fri, 26 Apr 2002 14:49:54 -0400
Received: from mail pickup service by MWSC0208.MW4.MAILWATCH.COM with Microsoft SMTPSVC; Fri, 26 Apr 2002 14:49:54 -0400
Received: from 204.253.83.39 ([204.253.83.39]) by MWSC0208 with SMTP id 000200084ad6f883-7082-411e-98bb-2898ce9f0575;	 Fri, 26 Apr 2002 14:49:54 -0500
Received: from bigbird.entegrity.com (bigbird.gradient.com [192.92.110.50])	by dymwsm15.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3QInsC01108;	Fri, 26 Apr 2002 14:49:54 -0400
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10)	id <JC4CDBBV>; Fri, 26 Apr 2002 14:46:23 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Peter Sylvester'" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Subject: RE: Multiple paths in DPD
Date: Fri, 26 Apr 2002 14:46:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: multipart/alternative;	boundary="----_=_NextPart_001_01C1ED52.A9B0D888"
HOP-COUNT: 1
X-MAILWATCH-INSTANCEID: 010200084ad6f883-7082-411e-98bb-2898ce9f0575
X-OriginalArrivalTime: 26 Apr 2002 18:49:54.0722 (UTC) FILETIME=[27B36020:01C1ED53]
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_01C1ED52.A9B0D888
Content-Type: text/plain;
	charset="ISO-8859-1"

Russ Housley said:

> > I am strongly opposed to an approach that would require the 
> server to 
> > maintain state.  Unless other people are willing to speak 
> up and support 
> > such an approach, I am not willing to make changes in this 
> area.  In my 
> > view, the current consensus is for a stateless server.
> > 
 
Peter Sylvester responded,
 
> the server does not need to maintain a state. That had been
> discussed between Steve farrele and me some yearsz ago, in
> order to clarify the meaning of what Mike calls 'state token'.
> 
> A server which returns a 'state token' does not turn it into one
> that MUST in a stateful mode. When the 'next request after token'
> comes it, the server sets up it state from the data that had been 
> return by the 'cookie'.

The extent to which this is true depends on how easily the server can go
from the token to some persistent storage. (We are actually debating volatle
state, not state per se.)

In Mike's specific proposal, the server has to constuct multiple paths
relevant to a given request, in some order and be able to produce the "next"
on demand. It seems unlikely that this can be done without remembering the
list or at least the contents of the last response. Handling this protocol
when the information used to construct the paths changes between requests
seems particularly challenging to me.

Hal 

------_=_NextPart_001_01C1ED52.A9B0D888
Content-Type: text/html;
	charset="ISO-8859-1"
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=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Multiple paths in DPD</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Russ Housley said:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; I am strongly opposed to an approach that =
would require the </FONT>
<BR><FONT SIZE=3D2>&gt; server to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; maintain state.&nbsp; Unless other people =
are willing to speak </FONT>
<BR><FONT SIZE=3D2>&gt; up and support </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; such an approach, I am not willing to make =
changes in this </FONT>
<BR><FONT SIZE=3D2>&gt; area.&nbsp; In my </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; view, the current consensus is for a =
stateless server.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Peter Sylvester responded,</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; the server does not need to maintain a state. =
That had been</FONT>
<BR><FONT SIZE=3D2>&gt; discussed between Steve farrele and me some =
yearsz ago, in</FONT>
<BR><FONT SIZE=3D2>&gt; order to clarify the meaning of what Mike calls =
'state token'.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; A server which returns a 'state token' does not =
turn it into one</FONT>
<BR><FONT SIZE=3D2>&gt; that MUST in a stateful mode. When the 'next =
request after token'</FONT>
<BR><FONT SIZE=3D2>&gt; comes it, the server sets up it state from the =
data that had been </FONT>
<BR><FONT SIZE=3D2>&gt; return by the 'cookie'.</FONT>
</P>

<P><FONT SIZE=3D2>The extent to which this is true depends on how =
easily the server can go from the token to some persistent storage. (We =
are actually debating volatle state, not state per se.)</FONT></P>

<P><FONT SIZE=3D2>In Mike's specific proposal, the server has to =
constuct multiple paths relevant to a given request, in some order and =
be able to produce the &quot;next&quot; on demand. It seems unlikely =
that this can be done without remembering the list or at least the =
contents of the last response. Handling this protocol when the =
information used to construct the paths changes between requests seems =
particularly challenging to me.</FONT></P>

<P><FONT SIZE=3D2>Hal </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1ED52.A9B0D888--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QIbmG14711 for ietf-pkix-bks; Fri, 26 Apr 2002 11:37:48 -0700 (PDT)
Received: from smtpout.mac.com (smtpout.mac.com [204.179.120.86]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QIbla14707 for <[e-mail]>; Fri, 26 Apr 2002 11:37:47 -0700 (PDT)
Received: from smtp-relay02.mac.com (smtp-relay02-qfe3 [10.13.10.225]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id g3QIbnW5013260 for <[e-mail]>; Fri, 26 Apr 2002 11:37:49 -0700 (PDT)
Received: from asmtp01.mac.com ([10.13.10.65]) by smtp-relay02.mac.com (Netscape Messaging Server 4.15 relay02 Jun 21 2001 23:53:48) with ESMTP id GV6UEV00.4MJ for <[e-mail]>; Fri, 26 Apr 2002 11:37:43 -0700 
Received: from localhost ([63.84.37.127]) by asmtp01.mac.com (Netscape Messaging Server 4.15 asmtp01 Jun 21 2001 23:53:48) with ESMTP id GV6UEU00.K2Y; Fri, 26 Apr 2002 11:37:42 -0700 
Date: Fri, 26 Apr 2002 11:37:59 -0700
Subject: Re: Meaning of Non-repudiation
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Mime-Version: 1.0 (Apple Message framework v481)
Cc: "Hoyt L. Kesterson II" <[e-mail]>
To: PKIX <[e-mail]>
From: Aram Perez <[e-mail]>
In-Reply-To: <[e-mail]2>
Message-Id: <[e-mail]>
X-Mailer: Apple Mail (2.481)
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3QIbla14708
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>

Maybe Hoyt can comment. If I understood him correctly, he mentioned to 
me that he had talked to a few people during the RSA Conference and that 
there was a consensus to have the NR bit renamed at the X.509 level.

Regards,
Aram Perez


On Friday, April 26, 2002, at 09:37  AM, Aisenberg, Michael wrote:

> As an under-initiated tech-wanabe lawyer who has observed the
> 'non-repudiation'
> debate for several years, it occurs to me that, not only do I concur in
> Todd's observation
> regarding the use of NR {as a technical bit-descriptor being problematic
> vis-à-vis
> his described more 'comprehensive' view of  NR as a 'condition' achieved
> through the
> deployment of an IA environment}, but would further suggest that even
> THAT interpretation requires
> calibration against the generally accepted legal concept of
> non-repudiation
> inherent in the construct and case law around UCC secs. 2-609/2-610.
>
> Todd's analysis suggests a non-statutory analog --based on a description
> of a
> complex of conditions existing simultaneously-- that provides a
> technology-grounded basis for asserting
> the same absolute of  'undeniability of existence' that the
> legal/statutory phrase implies (but, lawyers would never
> assert with the same absolutism as, say, a law of physics, unless a
> court of last resort had
> ruled!)--but it is of course still different from, and therefore capable
> of being confused with the
> bit descriptor.  All of which is a long-winded way of stating the
> obvious--that the importation
> of 'terms of art' from one discipline to another is risky--absent
> precise equality of
> definition, intent and usage--which we obviously don't have here......
>
>
> Michael Aisenberg
> --VeriSign/D.C.--
>
>
> -----Original Message-----
> From: todd glassey [mailto:[e-mail]]
> Sent: Friday, April 26, 2002 11:49 AM
> To: Tom Gindin
> Cc: PKIX-IETF
> Subject: Re: Meaning of Non-repudiation
>
>
>
> Tom,
> I agree with you - the X.509 model is broken too. NR is a bigger thing
> than
> a bit in a data structure and using the term NR causes problems for
> auditors
> and other professionals that would have to use these protocols.
>
> I and many others define NR as the sum-total of all the Information
> Assurance technologies, techniques, and practices that make up and
> operating
> environment. Thus NR is a state specific to a totality of condition and
> maybe needs essentially gradiant levels rather than a binary on or off
> state. Thats why a single bit alone without the accompanying OID is of
> questionable value here.
>
> Todd
>
> ----- Original Message -----
> From: "Tom Gindin" <[e-mail]>
> To: "Stephen Kent" <[e-mail]>
> Cc: "David P. Kemp" <[e-mail]>; <[e-mail]>
> Sent: Wednesday, April 11, 2001 3:50 PM
> Subject: Re: Meaning of Non-repudiation
>
>
>>
>>      IMHO, if X.509 had not been calling the bit in KeyUsage
>> "non-repudiation" for some years, I would prefer to put "Persistent
> Data
>> Authentication" into KeyUsage and define several different flavors of
>> non-repudiation in ExtendedKeyUsage, profiling non-repudiation
> services in
>> parallel with those ExtendedKeyUsage values.  This would also allow us
> to
>> define different levels of NR and put them into certificates in a
> natural
>> way.  However, they have been calling the bit "non-repudiation", and
> I'm
>> not sure we can change its meaning on the installed base of
> certificates
>> and on the X.509 group without an unusual level of unanimity and
>> near-certainty that it won't break anything.
>>
>>           Tom Gindin
>>
>>
>>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QISTt14484 for ietf-pkix-bks; Fri, 26 Apr 2002 11:28:29 -0700 (PDT)
Received: from dymwsm05.mailwatch.com (dymwsm05.mailwatch.com [204.253.83.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QISSa14480 for <[e-mail]>; Fri, 26 Apr 2002 11:28:28 -0700 (PDT)
Received: from mwsc0207.mw4.mailwatch.com (mwsc0207.mw4.mailwatch.com [204.253.83.129]) by dymwsm05.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3QISKo07161 for <[e-mail]>; Fri, 26 Apr 2002 14:28:20 -0400
Received: from mail pickup service by mwsc0207.mw4.mailwatch.com with Microsoft SMTPSVC; Fri, 26 Apr 2002 14:28:20 -0400
Received: from 204.253.83.72 ([204.253.83.72]) by MWSC0207 with SMTP id 00020007387aac24-c198-4ae1-a06d-06390e72c96a;	 Fri, 26 Apr 2002 14:28:20 -0500
Received: from bigbird.entegrity.com (bigbird.gradient.com [192.92.110.50])	by dymwsm10.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3QISJk13444;	Fri, 26 Apr 2002 14:28:19 -0400
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10)	id <JC4CDA04>; Fri, 26 Apr 2002 14:24:48 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Tony Bartoletti'" <[e-mail]>, "Aisenberg, Michael"	 <[e-mail]>, "'[e-mail]'"	 <[e-mail]>, "'[e-mail]'"	 <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Fri, 26 Apr 2002 14:24:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: multipart/alternative;	boundary="----_=_NextPart_001_01C1ED4F.A5D1E962"
HOP-COUNT: 1
X-MAILWATCH-INSTANCEID: 01020007387aac24-c198-4ae1-a06d-06390e72c96a
X-OriginalArrivalTime: 26 Apr 2002 18:28:20.0097 (UTC) FILETIME=[240B4710:01C1ED50]
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_01C1ED4F.A5D1E962
Content-Type: text/plain;
	charset="ISO-8859-1"

I believe the terms non-repudiation and signature date back to a time
(1980's) when nobody was talking about this stuff except a few
mathematicians. They probably realized they were using analogies to name
mathematical concepts, which did have precise meanings in that limited
scope. It is now recognized that neither analogy holds up to close scrutiny.

Unfortunately, the terminology got picked up and used very loosely by the
rest of the world. I have gotten used to hearing marketing types using
"non-repudiation" to mean any use of digital signatures. (Don't get me
started on "Trust." ;-) 

I just point them at Tom's document. I agree with Tony. What else can we do?

Hal

> -----Original Message-----
> From: Tony Bartoletti [mailto:[e-mail]]
> Sent: Friday, April 26, 2002 2:50 PM
> To: Aisenberg, Michael; '[e-mail]';
> '[e-mail]'
> Cc: '[e-mail]'
> Subject: RE: Meaning of Non-repudiation
> 
> 
> 
> 
> At the risk of incurring PKIX list-wrath ...
> 
> To my view of things, the "existence" of NR=1 in a 
> certificate is no more 
> than a statement, by the issuing CA, that "they will not 
> stand in the way 
> of this certificate being used as a component in some form of 
> NR scheme 
> (and will happily accept your Visa or Mastercard, thank you.)
> 
> If one limits the presence of an NR bit to this weak 
> assertion, it becomes 
> clear that the NR bit "means almost nothing."  Thus there is 
> little left to 
> debate about it on the list.
> 
> (As I recall, Tom Ginden's "Technical Non-Repudiation" 
> document was about 
> as far as one could reasonably take application of the NR 
> bit.  It was time 
> for everyone else to put-up or shut-up, and everyone shut-up.)
> 
> 
> ____tony____
> 
> Tony Bartoletti 925-422-3881 <[e-mail]>
> Information Operations, Warfare and Assurance Center
> Lawrence Livermore National Laboratory
> Livermore, CA 94551-9900
> 
> 
> 
> 

------_=_NextPart_001_01C1ED4F.A5D1E962
Content-Type: text/html;
	charset="ISO-8859-1"
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=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Meaning of Non-repudiation</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I believe the terms non-repudiation and signature =
date back to a time (1980's) when nobody was talking about this stuff =
except a few mathematicians. They probably realized they were using =
analogies to name mathematical concepts, which did have precise =
meanings in that limited scope. It is now recognized that neither =
analogy holds up to close scrutiny.</FONT></P>

<P><FONT SIZE=3D2>Unfortunately, the terminology got picked up and used =
very loosely by the rest of the world. I have gotten used to hearing =
marketing types using &quot;non-repudiation&quot; to mean any use of =
digital signatures. (Don't get me started on &quot;Trust.&quot; ;-) =
</FONT></P>

<P><FONT SIZE=3D2>I just point them at Tom's document. I agree with =
Tony. What else can we do?</FONT>
</P>

<P><FONT SIZE=3D2>Hal</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Tony Bartoletti [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, April 26, 2002 2:50 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Aisenberg, Michael; =
'[e-mail]';</FONT>
<BR><FONT SIZE=3D2>&gt; '[e-mail]'</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: '[e-mail]'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Meaning of Non-repudiation</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At the risk of incurring PKIX list-wrath =
...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; To my view of things, the &quot;existence&quot; =
of NR=3D1 in a </FONT>
<BR><FONT SIZE=3D2>&gt; certificate is no more </FONT>
<BR><FONT SIZE=3D2>&gt; than a statement, by the issuing CA, that =
&quot;they will not </FONT>
<BR><FONT SIZE=3D2>&gt; stand in the way </FONT>
<BR><FONT SIZE=3D2>&gt; of this certificate being used as a component =
in some form of </FONT>
<BR><FONT SIZE=3D2>&gt; NR scheme </FONT>
<BR><FONT SIZE=3D2>&gt; (and will happily accept your Visa or =
Mastercard, thank you.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; If one limits the presence of an NR bit to this =
weak </FONT>
<BR><FONT SIZE=3D2>&gt; assertion, it becomes </FONT>
<BR><FONT SIZE=3D2>&gt; clear that the NR bit &quot;means almost =
nothing.&quot;&nbsp; Thus there is </FONT>
<BR><FONT SIZE=3D2>&gt; little left to </FONT>
<BR><FONT SIZE=3D2>&gt; debate about it on the list.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; (As I recall, Tom Ginden's &quot;Technical =
Non-Repudiation&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; document was about </FONT>
<BR><FONT SIZE=3D2>&gt; as far as one could reasonably take application =
of the NR </FONT>
<BR><FONT SIZE=3D2>&gt; bit.&nbsp; It was time </FONT>
<BR><FONT SIZE=3D2>&gt; for everyone else to put-up or shut-up, and =
everyone shut-up.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ____tony____</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Tony Bartoletti 925-422-3881 =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Information Operations, Warfare and Assurance =
Center</FONT>
<BR><FONT SIZE=3D2>&gt; Lawrence Livermore National Laboratory</FONT>
<BR><FONT SIZE=3D2>&gt; Livermore, CA 94551-9900</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1ED4F.A5D1E962--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QI3M513696 for ietf-pkix-bks; Fri, 26 Apr 2002 11:03:22 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QI3Ka13692 for <[e-mail]>; Fri, 26 Apr 2002 11:03:20 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA27090; Fri, 26 Apr 2002 20:03:07 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 26 Apr 2002 20:03:07 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA11113; Fri, 26 Apr 2002 20:03:06 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA12803; Fri, 26 Apr 2002 20:03:05 +0200 (MET DST)
Date: Fri, 26 Apr 2002 20:03:05 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Multiple paths in DPD
Cc: [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>

> 
> 
> Mike:
> 
> I am strongly opposed to an approach that would require the server to 
> maintain state.  Unless other people are willing to speak up and support 
> such an approach, I am not willing to make changes in this area.  In my 
> view, the current consensus is for a stateless server.
> 


Russ, 

the server does not need to maintain a state. That had been
discussed between Steve farrele and me some yearsz ago, in
order to clarify the meaning of what Mike calls 'state token'.

A server which returns a 'state token' does not turn it into one
that MUST in a stateful mode. When the 'next request after token'
comes it, the server sets up it state from the data that had been 
return by the 'cookie'.
  


Received: by above.proper.com (8.11.6/8.11.3) id g3QHe6e13230 for ietf-pkix-bks; Fri, 26 Apr 2002 10:40:06 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QHe4a13226 for <[e-mail]>; Fri, 26 Apr 2002 10:40:04 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA27032; Fri, 26 Apr 2002 19:40:03 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 26 Apr 2002 19:40:04 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA11039; Fri, 26 Apr 2002 19:40:02 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA12798; Fri, 26 Apr 2002 19:40:02 +0200 (MET DST)
Date: Fri, 26 Apr 2002 19:40:02 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
Cc: [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>

> > 
> > The list of potential useful additional feature is as endless as the
> > list of useless features. 
> 
> No. We would not make the effort of writing these requirements if we were
> going to allow a protocol that supports many other features that are *not*
> required.
> 
> Denis


Steve Kent said a few days ago:

" We agreed 
  to allow competing protocol submissions which would be evaluated 
  against the requirements. "

This does not mean IMO, that it is forbidden to have more features
than those specified in the requirement doc. 



Received: by above.proper.com (8.11.6/8.11.3) id g3QHcsK13209 for ietf-pkix-bks; Fri, 26 Apr 2002 10:38:54 -0700 (PDT)
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QHcra13205 for <[e-mail]>; Fri, 26 Apr 2002 10:38:54 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id KAA22878; Fri, 26 Apr 2002 10:38:40 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id KAA19088; Fri, 26 Apr 2002 10:38:50 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 26 Apr 2002 10:50:14 -0800
To: "Aisenberg, Michael" <[e-mail]>, "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Cc: "'[e-mail]'" <[e-mail]>
In-Reply-To: <[e-mail]2 >
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>

At the risk of incurring PKIX list-wrath ...

To my view of things, the "existence" of NR=1 in a certificate is no more 
than a statement, by the issuing CA, that "they will not stand in the way 
of this certificate being used as a component in some form of NR scheme 
(and will happily accept your Visa or Mastercard, thank you.)

If one limits the presence of an NR bit to this weak assertion, it becomes 
clear that the NR bit "means almost nothing."  Thus there is little left to 
debate about it on the list.

(As I recall, Tom Ginden's "Technical Non-Repudiation" document was about 
as far as one could reasonably take application of the NR bit.  It was time 
for everyone else to put-up or shut-up, and everyone shut-up.)


____tony____

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QHasl13161 for ietf-pkix-bks; Fri, 26 Apr 2002 10:36:54 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QHaqa13157 for <[e-mail]>; Fri, 26 Apr 2002 10:36:52 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA27015; Fri, 26 Apr 2002 19:36:47 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 26 Apr 2002 19:36:47 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA11028; Fri, 26 Apr 2002 19:36:46 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA12795; Fri, 26 Apr 2002 19:36:46 +0200 (MET DST)
Date: Fri, 26 Apr 2002 19:36:46 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: roadmap
Cc: [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>

>  
> > - A "trusted" OCSP responder which is not a CA or an authorized responder
> >   can also issue status information based on his own local policy not
> >   established by a CA, it can have its own 'revocation service' based
> >   on the needs of the relying party.
> 
> So a trusted OCSP responder provides the revocation status information of a
> *single* certificate and has nothing to do with a DPV server that does much
> more on a *chain* of certificates.
The point was that the structure of OCSP trust delegations, i.e., the modes
of CA, authorized responder and trusted responder provide sufficient possibilities
so that trust among a DPV client and services can be establish in a same way.

A potential addition to the OCSP protocol you turn a server which was is trusted
by the client using one of the existing OCSP trust mechanism into a service that
is implmenting the DPV requirements, i.e. into a DPV server that youses an enhanced 
OCSP protocol.

> 
> > - An 'authorised' CA DPV responder can create status information about
> 
> An " 'authorised' CA DPV responder" is not a correct wording: either it is a
> CA or a DPV responder.
I am talking about an extended OCSP protocol implementing the DPV
requirements operated by an authorized OCSP responder. 

> 
> >   its immediately subordinate certs, i;e. the single OCSP response that you
> >   mention, and at the same time include some DPV response that validate
> >   the path from the intermediate CA to the trusted root, either
> >   as an entity extension or as a global extension.
>  
> > - An OCSP server can also be any entity, and not just an authorised
> >   CA responder. An OCSP responder can respond to whatever the service
> >   provider likes to provide to its clients or what they need. OCSP is
> >   not a 'A CS service'.
> 
> An OCSP server basically provides the revocation status of a certificate and
> may support extensions in addition to that basic response. Up to now, such
> extensions have not been defined.
Obviously not, since we are not at the point of defining a protocol. As far
as I have understood, Mike is waiting until the DPV reqs get settled. 

> 
> Since a DPV response is far richer than a DPV response, it would be quite
> strange to use the content of the extension and to discard the main
> response.
Who has proposed to discard something?

> Picky-backing the DPV structure in an extension of the OCSP structure would
> also lead to a strange behaviour. You could get a "valid OCSP answer" with
> an "invalid DPV answer" (e.g. because a certificate from the chain is
> revoked). These two statuses do not match together.
Why do you think that the DPV server should indicate that the
certificate is good. Again, I am not advocating OCSPv2 which some people
may consider as repaied/enhanced by technique to similar as for
the Hubble telescope. 









Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QHX6F13097 for ietf-pkix-bks; Fri, 26 Apr 2002 10:33:06 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QHX4a13093 for <[e-mail]>; Fri, 26 Apr 2002 10:33:04 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3QHX428008959; Fri, 26 Apr 2002 10:33:04 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Multiple paths in DPD
Date: Fri, 26 Apr 2002 10:30:11 -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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Russ,

Towards further clarity and FWIW, I have no issue with the
stateless server consensus per se.  It's the the software and
system design implications of the maxPath feature that strongly
concerns me.

Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Housley, Russ
> Sent: Friday, April 26, 2002 8:04 AM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: Multiple paths in DPD
>
>
>
> Mike:
>
> I am strongly opposed to an approach that would
> require the server to
> maintain state.  Unless other people are willing to
> speak up and support
> such an approach, I am not willing to make changes in
> this area.  In my
> view, the current consensus is for a stateless server.
>
> Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QHNK712918 for ietf-pkix-bks; Fri, 26 Apr 2002 10:23:20 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QHNJa12913 for <[e-mail]>; Fri, 26 Apr 2002 10:23:19 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA15682; Fri, 26 Apr 2002 19:26:10 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042619224779:300 ; Fri, 26 Apr 2002 19:22:47 +0200 
Message-ID: <[e-mail]>
Date: Fri, 26 Apr 2002 19:22:28 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/04/2002 19:22:47, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/04/2002 19:23:20, Serialize complete at 26/04/2002 19:23:20
Content-Transfer-Encoding: 7bit
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>

Peter,

> > > - This text may be created by the server or requested by the client
> > >   or modified by the server.
> >
> > No. See above.
> 
> Thus, you are restricting a potential protocol feature. If a proposal
> will allow a client to propose a text, you would consider this
> as in conflict with the requirements doc?

This feature has *already* been accepted (at least by myself, hopefully by
the WG). 

> > > I am not in favour that the usages of identififers of the clients
> > > and responders MUST be related to authentication.
> >
> >  ... otherwise it is a field that has an undefined or an ambiguous
> > semantics.

> Russ and you have proposed that the ID are derived from authenticated
> identifiers, it seems that the main difference is that I prefer that
> they are matched against information from authentication.
 
> You propose:
>   "When the request is authenticated, the requestor SHOULD be able, upon
>   request, to indicate an identifier to be included in the response.
> 
> What does mean 'SHOULD be able'?  We are talking about requirements for
> a protocol. Either the protocol has a feature that can be optionally be
> used or it hasn't.
> 
> Why should even an anonymous requester not be allowed to specify an identifier?

 ...  because in that case it would not be anymore a field that reflects an
identifier, but will be a "blind" field. The same field cannot have two
different or even more meanings.

> As indicated in the followng sentence, a server can always refuse this
> nased on the policy etc.
> 
>   How this identifier is matched with the authenticated identity depends
>   on local server conditions and/or the validation policy. The server
>   MAY choose to refuse to include an identifier in the response, or MAY
>   refuse to create a response."
> 
> > > Please read what I have written. You are turning around the argumentation.
> > > There are probably some arguments not to have a flower service in a DPV
> > > protocol. But they should be indicated. The text does only prohibity someone
> > > from saying: "We MUST NOT use this protocol because you can also request
> > > flowers and this has not been specified as a requirement."
> >
> >  ... and for that exact reason, I would suppress the flower request.
> YOU have proposed the flower feature, not me.
> 
> > It is not appropriate to overload the protocol for whatever extra reason.

> "Overloading" or making it too heavy is a judgement that should be
> weighted against the argument that would be necessary to support any feature.
> 
> > We are not going to say specifiaclly that flower requests support is
> > inappropriate, otherwise the list would be endless.
> 
> The list of potential useful additional feature is as endless as the
> list of useless features. 

No. We would not make the effort of writing these requirements if we were
going to allow a protocol that supports many other features that are *not*
required.

Denis


> Since you have not proposed a concreate
> protocol feature in a potential protocol, I don't feel that it is
> necessary to talk about this. If nobody presents any probably
> useless feature in a protocol, why should be waste our time to
> establish a list of what would be 'definitely stupid'?
> 
> It seems that you will in the future continue to say:
> 'This is not a requrement' with a new justification 'this is
> not in a requirements document'.
> 
> > This was one of the problems from RFC 3029 (i.e. Data Certification Server
> > Protocols) that had too many features.
> 
> RFC 3029 does not allow to explicitely request flowers, too bad :-)
> 
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QHC6P12615 for ietf-pkix-bks; Fri, 26 Apr 2002 10:12:06 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QHC3a12604 for <[e-mail]>; Fri, 26 Apr 2002 10:12:03 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA26939; Fri, 26 Apr 2002 19:12:02 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 26 Apr 2002 19:12:02 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA10912; Fri, 26 Apr 2002 19:12:01 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA12788; Fri, 26 Apr 2002 19:12:01 +0200 (MET DST)
Date: Fri, 26 Apr 2002 19:12:01 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
Cc: [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 text may be created by the server or requested by the client
> >   or modified by the server.
> 
> No. See above. 

Thus, you are restricting a potential protocol feature. If a proposal
will allow a client to propose a text, you would consider this
as in conflict with the requirements doc?

>  
> > I am not in favour that the usages of identififers of the clients
> > and responders MUST be related to authentication.
> 
>  ... otherwise it is a field that has an undefined or an ambiguous
> semantics.
Russ and you have proposed that the ID are derived from authenticated
identifiers, it seems that the main difference is that I prefer that
they are matched against information from authentication.  

You propose: 
  "When the request is authenticated, the requestor SHOULD be able, upon
  request, to indicate an identifier to be included in the response. 

What does mean 'SHOULD be able'?  We are talking about requirements for
a protocol. Either the protocol has a feature that can be optionally be
used or it hasn't. 

Why should even an anonymous requester not be allowed to specify an identifier?
As indicated in the followng sentence, a server can always refuse this
nased on the policy etc. 

  How this identifier is matched with the authenticated identity depends 
  on local server conditions and/or the validation policy. The server 
  MAY choose to refuse to include an identifier in the response, or MAY 
  refuse to create a response."


> > Please read what I have written. You are turning around the argumentation.
> > There are probably some arguments not to have a flower service in a DPV
> > protocol. But they should be indicated. The text does only prohibity someone
> > from saying: "We MUST NOT use this protocol because you can also request
> > flowers and this has not been specified as a requirement."
> 
>  ... and for that exact reason, I would suppress the flower request. 
YOU have proposed the flower feature, not me. 

> It is not appropriate to overload the protocol for whatever extra reason.
"Overloading" or making it too heavy is a judgement that should be
weighted against the argument that would be necessary to support any feature. 

> We are not going to say specifiaclly that flower requests support is
> inappropriate, otherwise the list would be endless.

The list of potential useful additional feature is as endless as the
list of useless features. Since you have not proposed a concreate 
protocol feature in a potential protocol, I don't feel that it is
necessary to talk about this. If nobody presents any probably
useless feature in a protocol, why should be waste our time to
establish a list of what would be 'definitely stupid'?

It seems that you will in the future continue to say:
'This is not a requrement' with a new justification 'this is
not in a requirements document'.

> This was one of the problems from RFC 3029 (i.e. Data Certification Server
> Protocols) that had too many features.

RFC 3029 does not allow to explicitely request flowers, too bad :-)






 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QGxEI12028 for ietf-pkix-bks; Fri, 26 Apr 2002 09:59:14 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QGxCa12024 for <[e-mail]>; Fri, 26 Apr 2002 09:59:13 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3QGxA28005769; Fri, 26 Apr 2002 09:59:11 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Multiple paths in DPD
Date: Fri, 26 Apr 2002 09:56:18 -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)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Russ,

I understood your objective, which led then to the max path
design feature.  Yes, I know the rough consensus seems to favor
a stateless server (although it's predictable the server will
have abundant lower-level state anyway).  But the more I thought
about it, the more convinced I became that some of the
implications of that consensus and the feature it precipitated
warrant a careful analysis before we ship this thing.

I'm actuely aware of the need for us to wrap up this work and
get on with it and I apologize again for not bringing this up
earlier. Twice I stalled producing the note because of those
factors.  But in the end I figured, we're an engineering working
group and this is an engineering question that deserves a modest
degree of further review and open dialog.

So I spent a good many cycles yesterday doing what I think I
should be doing in this WG.  I know you're busy and we all want
to get this one shipped but may I with respect ask for a brief
response in kind and in the context of the analysis?

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Housley, Russ
> Sent: Friday, April 26, 2002 8:04 AM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: Multiple paths in DPD
>
>
>
> Mike:
>
> I am strongly opposed to an approach that would
> require the server to
> maintain state.  Unless other people are willing to
> speak up and support
> such an approach, I am not willing to make changes in
> this area.  In my
> view, the current consensus is for a stateless server.
>
> Russ
>
>
> At 02:15 PM 4/25/2002 -0700, Michael Myers wrote:
> >Russ, Denis:
> >
> >This analysis and counter-proposal is a bit long
> which is why I
> >broke it out separately from my other comments.
> Apologies for
> >the length and not getting to it at the -03 stage.
> I had it on
> >my list but got sidetracked by my day job.
> >
> >Anyway, I'm having a hard time agreeing with the following.
> >
> >-----------------------------------------------------
> >     The DPD client needs to be able to limit the
> >     number of paths returned. Therefore the client
> >     MUST be able to indicate the maximum number of
> >     certification paths to be returned (provided
> >     that they can be found). If the client does
> >     not specify a maximum number, then the DPD
> >     server MUST return a single certification path.
> >
> >     . . .
> >
> >     If that number cannot be reached by the server,
> >     an indication SHOULD be returned by the DPD
> >     server showing that an additional query will
> >     not return more paths.
> >
> >     If the paths that are returned do not match the
> >     client's local criteria, then the number of
> >     number of certification paths to be returned can
> >     be extended by increasing this value. Previously
> >     found paths will likely be returned, but the
> >     client can easily discard them. This avoids
> >     requirements for state information at the server,
> >     but does not prevent a server from maintaining
> >     a cache of previous responses.
> >
> >     Avoiding the maintenance of state information for
> >     previous requests minimizes potential denial of
> >     service attacks or other problems associated with
> >     server crashes.
> >
> >-----------------------------------------------------
> >
> >I think an iterated approach based on server-side
> state would be
> >better.  The approach is basically one which, in the
> presence of
> >multiple paths, the server establishes state and returns the
> >first potentially acceptable path (given client
> inputs) to the
> >client along with a state token.  Should that path not be the
> >precise one the client is looking for, the client asks again,
> >referencing the state token.  Upon recognizing the
> state token,
> >the server then returns the next path and so on
> until either the
> >client shuts up and goes away or the server returns
> noMoreData.
> >Doing so would reduce protocol complexity, reduce extraneous
> >bits on the wire and reduce client-side and server-side code
> >footprints with no loss of security assurances.
> >
> >Here's why I think so.
> >
> >Working first from the motivating needs, it's not clear to me
> >how reduction of state will minimize potential
> denial of service
> >attacks.  If they come, they're going to come
> regardless of the
> >internal state of the server.  Possibly what you
> meant to say is
> >that doing so potentially improves the likelihood a
> server can
> >withstand DOS attacks while maintaining service to legitimate
> >requests.  I shall assume this for the time being.
> >
> >But since DOS attacks are largely predicated on throughput
> >constraints, one can simply beef up the back end or
> buy a bigger
> >pipe.  Also, to the extent that your concern over DOS attacks
> >and server crashes relates to the volatility of
> state retention,
> >an implementor of the protocol that ultimately results from
> >these requirements can choose to write that state to
> >non-volatile memory.  That is, take a fault-tolerant
> >implementation approach in those instances where mission
> >criticality is important.  They're going to anyway.
> >
> >Lastly re: DOS, my own experience strongly suggests that
> >effective responses to DOS attacks are most often
> addressed at
> >the router, long before an offending stream from a given IP
> >address gets to a back end.  I agree that we should take care
> >not to enable sensitivity to DOS attacks.  I'm just not
> >convinced that the max path approach yields much
> effect in that
> >regard while the iterated approach yeilds clear benefits in
> >design simplicity.
> >
> >To the design simplicity point, it's my estimate that in the
> >vast majority of cases where DPD will be used, the first path
> >returned will be the one the client wanted.  I also estimate
> >that there'll be far more instances of only one path vs.
> >multiple paths.  In my view we should design towards the
> >centroid of needs rather than the corner cases.
> >
> >Is this design simpler?  I think so.  It's just a
> state token.
> >The client doesn't even have to know what it is, just send it
> >back for another try.  The use of noMoreData also provides
> >unambiguous protocol closure.  The client knows for
> certain what
> >to do in that instance.  Very simple, hence a smaller client.
> >
> >Regarding extraneous bits on the wire, consider the case of
> >maxPath of M from the client and server side numPaths of N,
> >where N is larger than M.  The client receives N-M
> paths and any
> >requested revocation data.  All of which may be
> useless because
> >the path the client wants is in the remainder.  So the client
> >kicks up its M to, say, M' where M' is still less
> then N, first
> >receives again those useless N-M paths and related
> info before
> >it gets into the M'-M set.  And so on.
> >
> >I suspect once this scenario comes to the attention of
> >client-side developers, they will be tempted to bake
> in a very
> >large maxPath to ensure that a single query yields all paths.
> >Again, a lot of extraneous bits on the wire when in point of
> >fact the client just wants one.  And as I hypothesized, I
> >suspect that in the vast majority of cases that'll
> be the first
> >one.  Thus our requirements threaten to place onto
> the Internet
> >a bunch of useless bits.  I think we should be sensitive to
> >needless bandwidth consumption.
> >
> >Also, in the event multiple paths exist but the
> client doesn't
> >specify max # of paths, what are the requirements on
> the server
> >in the event of multiple queries from a client regarding the
> >same certificate?  The requirement reads "return a single
> >certification path" but provides no guidance in the
> presence of
> >multiple paths at the server, leading one to assume that the
> >first one is always sent back.
> >
> >Thus in the presence of multiple paths, there exists
> no means to
> >enable a client to get at the one it wants.  Absent that
> >guidance and any variation from the current draft
> requirements,
> >I'm sure this issue will be taken up at the protocol
> selection
> >stage of our work.  It's possible those
> considerations will lead
> >to servers trying their best and silently iterate
> through these
> >multiple paths in order to address this scenario.  That means
> >state, just as is needed for the iterated approach
> in the first
> >place.
> >
> >So I propose for your consideration the following text:
> >
> >-----------------------------------------------------
> >
> >If a DPV server has available to it multiple paths
> >conformant to the parameters a client provides, upon
> >receipt of an initial query the server MUST respond
> >with the first path in this list AND include a token
> >for reference by the client in subsequent queries.
> >
> >In the event of a single path, or a single qualifying
> >path, the server MAY exclude the token.
> >
> >Upon receipt of a DPD response containing a response
> >token indicating the existence of multiple qualifying
> >paths, in order to acquire the next path in this list
> >clients MUST include the previously supplied response
> >token in a subsequent query.
> >
> >Servers MUST then transmit the next path in the
> >qualifying list. If the last qualifying path was
> >previously transmitted, servers MUST indicate that
> >no more data exists.
> >
> >-----------------------------------------------------
> >
> >Again, apologies for the length and the delay.
> >
> >Regards,
> >
> >
> >Mike
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QGbLN11574 for ietf-pkix-bks; Fri, 26 Apr 2002 09:37:21 -0700 (PDT)
Received: from heron.verisign.com (heron.verisign.com [216.168.233.95]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QGbJa11570 for <[e-mail]>; Fri, 26 Apr 2002 09:37:20 -0700 (PDT)
Received: from VSVAPOSTALGW1.prod.netsol.com (vsvapostalgw1.prod.netsol.com [216.168.234.201]) by heron.verisign.com (nsi_0.1/8.9.1) with ESMTP id MAA25730; Fri, 26 Apr 2002 12:37:32 -0400 (EDT)
Received: by vsvapostalgw1.bkup1 with Internet Mail Service (5.5.2653.19) id <2WGQ0AMB>; Fri, 26 Apr 2002 12:37:10 -0400
Message-ID: <[e-mail]2>
From: "Aisenberg, Michael" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Subject: RE: Meaning of Non-repudiation
Date: Fri, 26 Apr 2002 12:37:08 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_002F_01C1ED1E.D026A580"
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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_002F_01C1ED1E.D026A580
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

As an under-initiated tech-wanabe lawyer who has observed the
'non-repudiation'
debate for several years, it occurs to me that, not only do I concur in
Todd's observation
regarding the use of NR {as a technical bit-descriptor being problematic
vis-=E0-vis
his described more 'comprehensive' view of  NR as a 'condition' achieved
through the
deployment of an IA environment}, but would further suggest that even
THAT interpretation requires
calibration against the generally accepted legal concept of
non-repudiation
inherent in the construct and case law around UCC secs. 2-609/2-610.

Todd's analysis suggests a non-statutory analog --based on a description
of a
complex of conditions existing simultaneously-- that provides a
technology-grounded basis for asserting
the same absolute of  'undeniability of existence' that the
legal/statutory phrase implies (but, lawyers would never
assert with the same absolutism as, say, a law of physics, unless a
court of last resort had
ruled!)--but it is of course still different from, and therefore capable
of being confused with the
bit descriptor.  All of which is a long-winded way of stating the
obvious--that the importation
of 'terms of art' from one discipline to another is risky--absent
precise equality of
definition, intent and usage--which we obviously don't have here......


Michael Aisenberg
--VeriSign/D.C.--


-----Original Message-----
From: todd glassey [mailto:[e-mail]]=20
Sent: Friday, April 26, 2002 11:49 AM
To: Tom Gindin
Cc: PKIX-IETF
Subject: Re: Meaning of Non-repudiation



Tom,
I agree with you - the X.509 model is broken too. NR is a bigger thing
than
a bit in a data structure and using the term NR causes problems for
auditors
and other professionals that would have to use these protocols.

I and many others define NR as the sum-total of all the Information
Assurance technologies, techniques, and practices that make up and
operating
environment. Thus NR is a state specific to a totality of condition and
maybe needs essentially gradiant levels rather than a binary on or off
state. Thats why a single bit alone without the accompanying OID is of
questionable value here.

Todd

----- Original Message -----
From: "Tom Gindin" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>; <[e-mail]>
Sent: Wednesday, April 11, 2001 3:50 PM
Subject: Re: Meaning of Non-repudiation


>
>      IMHO, if X.509 had not been calling the bit in KeyUsage
> "non-repudiation" for some years, I would prefer to put "Persistent
Data
> Authentication" into KeyUsage and define several different flavors of
> non-repudiation in ExtendedKeyUsage, profiling non-repudiation
services in
> parallel with those ExtendedKeyUsage values.  This would also allow us
to
> define different levels of NR and put them into certificates in a
natural
> way.  However, they have been calling the bit "non-repudiation", and
I'm
> not sure we can change its meaning on the installed base of
certificates
> and on the X.509 group without an unusual level of unanimity and
> near-certainty that it won't break anything.
>
>           Tom Gindin
>
>
>

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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdzCCAj0w
ggGmAhEAulrJTAU7ktantt9O0FOSDTANBgkqhkiG9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUG
A1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVibGljIFByaW1hcnkgQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5MDAwMDAwWhcNMDQwMTA3MjM1OTU5WjBfMQsw
CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDIgUHVi
bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0A
MIGJAoGBALZai6MNaiODgGvPOYf0IRMzBkwlou1VEpfFp4C5+oPBIKD6LxUNfKFga355LPoGDzqu
9htvsdL/LyhSX4N9S8R6t/hmH4BU/LfCjllKFFdG0ZqTvkGRA7sVgJNc6+fMCGw/PrNK/P9LbCPV
UIImRBmOI8Nx6hkkRwSedb/IpgAfAgMBAAEwDQYJKoZIhvcNAQECBQADgYEAtgAfk1ekB6dAzmVA
P1Ve7e/6VEmlMNYhfGGH7oOTC7+0M/KYrJ8Gv06ozhSBTMsETljDz1/ufNeab8tBird/gbj/hGHG
J0NlHQzssQAK3Ruku8d4ICiyot02lS7hVE+/YLl3aBGZI+jqUuiqAE5nTruQtUWbRuuOFu/EM1sz
PdUwggNDMIICrKADAgECAhAffl/nA9Hgv5kg3GuJDUsEMA0GCSqGSIb3DQEBBAUAMF8xCzAJBgNV
BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMiBQdWJsaWMg
UHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05OTAyMjUwMDAwMDBaFw0wNDAxMDUy
MzU5NTlaMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEmMCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQ
ZXJzb25uZWwgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAKcEbA+icrdKBi741yksNJ2C
vEiRSses+en8uVl4sVXAU1ixz28WO8FJ1cv0bszhzMu1xy5OiKo06bbQW3w+FVc04Ri8/931r2dZ
IArlPeqIikDSmokTKam21dunfuHnNyST/ZR0TXrkMm1M6FwWl6/dktlmihRm5OpaA6g9X/sLAgMB
AAGjgbAwga0wMQYDVR0fBCowKDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMi5j
cmwwEQYJYIZIAYb4QgEBBAQDAgEGMEcGA1UdIARAMD4wPAYLYIZIAYb4RQEHAQEwLTArBggrBgEF
BQcCARYfaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rcjAPBgNVHRMECDAGAQH/AgEBMAsG
A1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQB59xXN6GhRWWv8qaa94B77vPQ/kN/n+u3kVPdh
PVSLBrqXMloeqyzur3Orx13TP4/0zstOSGCiqGC2ON6gpvePKegRrMw5dlA83TlsC/Fa/QhUdt0W
bPcxcLi/CPfJJgaO37svGbG2uLToPEjoJ7GXKSBXA5ybZ/p9QMQ4fxiqmjCCA8QwggMtoAMCAQIC
EQCEzvIOADm1dVXaGYePUu2JMA0GCSqGSIb3DQEBBAUAMIGtMRcwFQYDVQQKEw5WZXJpU2lnbiwg
SW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1
YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTEm
MCQGA1UEAxMdVmVyaVNpZ24gQ2xhc3MgMiBQZXJzb25uZWwgQ0EwHhcNOTkwMjI1MDAwMDAwWhcN
MDQwMTA0MjM1OTU5WjCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT
aWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJqZWN0IHRvIHRlcm1zIGF0IGh0
dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAjBgNVBAMTHFZlcmlTaWduIENs
YXNzIDIgRW1wbG95ZWUgQ0EwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMCK0YdhouowA1Vr
CDbwl/oaVDUkH+h9ncjDc9PYRvWRLdk47ZTXsCZzKt6XUE3/Ihy9cACYDFgqsaRyj6W59y18YOO1
3+l9TiEhYdX8O1TJpAmcuyL5orpwYU+GRqL9BWTsCj+mWHZXuxZzRHzwpQ2XwGym8WMIJbEEF5Wg
jf5/AgMBAAGjgeIwgd8wKQYDVR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMTE4
MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwudmVyaXNpZ24uY29tL1ZTQ2xhc3MySW50LmNy
bDARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAtMCsGCCsGAQUF
BwIBFh9odHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhLWtyMA8GA1UdEwQIMAYBAf8CAQAwCwYD
VR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBABlGztRrcI5YXIhCNa0WfaUJLKhTkPH2PYbX8M5y
FD0ivPLDM+3U/AWa4GMgdaMb71UZDwZzIQJhrqaeUSt43FvIhIvV17bP1fg+l5ixRIujmI6gS/aY
MZOz8AzdUXbKl+RWRMb7lKFIfSJDzKDGXHlV9WeBG2iYNCREsZjBOiheMIIEIzCCA4ygAwIBAgIQ
C4Pe+b9ZzSY6cFoTNpDgKTANBgkqhkiG9w0BAQQFADCBrDEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxSTBHBgNVBAsTQFVzZSBpcyBzdWJq
ZWN0IHRvIHRlcm1zIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEta3IgKGMpOTkxJTAj
BgNVBAMTHFZlcmlTaWduIENsYXNzIDIgRW1wbG95ZWUgQ0EwHhcNMDExMDExMDAwMDAwWhcNMDIx
MDExMjM1OTU5WjBzMREwDwYDVQQKEwhWRVJJU0lHTjEQMA4GA1UECxMHVkEtRUFTVDETMBEGA1UE
AxMKUmVjaXBpZW50czE3MDUGA1UEAxMubWFpc2VuYmVyZyAoQWlzZW5iZXJnIE1pY2hhZWwsIFZl
cmlTaWduLCBJbmMuKTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvUXjng0fglmjCF7bE23A
cpGiPS0Ci+9Ws6i/NDsGOYt21EbGOT1B+u6wazYjy29sKJkR5cicvJfyylRJ2Zl1Fc5sgewN+a88
g9x7hxQXITWaAlCPKUD/KB4qNeZvGSj1hu+ZdZvIm7N+/cUKT5W5Lvfd41B7bxlnQyADZHy3u8UC
AwEAAaOCAXwwggF4MAkGA1UdEwQCMAAwWQYDVR0fBFIwUDBOoEygSoZIaHR0cDovL29uc2l0ZWNy
bC52ZXJpc2lnbi5jb20vVmVyaVNpZ25JbmNFeGNoYW5nZUVtcGxveWVlcy9MYXRlc3RDUkwuY3Js
MAsGA1UdDwQEAwIFoDAiBgNVHREEGzAZgRdtYWlzZW5iZXJnQHZlcmlzaWduLmNvbTCBrAYDVR0g
BIGkMIGhMIGeBgtghkgBhvhFAQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNp
Z24uY29tL0NQUzBiBggrBgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWdu
J3MgQ1BTIGluY29ycC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJ
YIZIAYb4QgEBBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjANBgkqhkiG9w0B
AQQFAAOBgQA8lpyvzHVxE92Tr9AX/8HdW2dKffNef2wIZXCd43hsblythAXOmU78nW4+W54zEonQ
jUoicXgE+oQZd/PVHLfEm8f67IZlrl38/wMJoNNqaaWJiCSH0qsGtNvxhNOKaspYIP5nyiT1gKcy
0F8WRd+fYUF6pq0IDxUClzkLftrxRzGCA94wggPaAgEBMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2ln
biwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlz
IHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5
OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBFbXBsb3llZSBDQQIQC4Pe+b9ZzSY6cFoTNpDg
KTAJBgUrDgMCGgUAoIICcjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP
Fw0wMjA0MjYxNjM1MTNaMCMGCSqGSIb3DQEJBDEWBBSVdF19mxIMHXndqUL4/wSib1ZBJjBnBgkq
hkiG9w0BCQ8xWjBYMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAH
BgUrDgMCBzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTCB0gYJKwYBBAGCNxAE
MYHEMIHBMIGsMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1
c3QgTmV0d29yazFJMEcGA1UECxNAVXNlIGlzIHN1YmplY3QgdG8gdGVybXMgYXQgaHR0cHM6Ly93
d3cudmVyaXNpZ24uY29tL3JwYS1rciAoYyk5OTElMCMGA1UEAxMcVmVyaVNpZ24gQ2xhc3MgMiBF
bXBsb3llZSBDQQIQC4Pe+b9ZzSY6cFoTNpDgKTCB1AYLKoZIhvcNAQkQAgsxgcSggcEwgawxFzAV
BgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUkw
RwYDVQQLE0BVc2UgaXMgc3ViamVjdCB0byB0ZXJtcyBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5j
b20vcnBhLWtyIChjKTk5MSUwIwYDVQQDExxWZXJpU2lnbiBDbGFzcyAyIEVtcGxveWVlIENBAhAL
g975v1nNJjpwWhM2kOApMA0GCSqGSIb3DQEBAQUABIGAeBBRzPiU/xNbCFJjZH/5FYJ8x9nmfD9E
cbh+RqoRGzlTf+rCE/t8jUhrFi9HASzXsNhvFxJTmhtwjyd3ybXFPQ3ve7ZJ0ummszcdSYRchq/n
yvswcsF00QxdxQIBOWT0XkXrj6mLKrEzUtnEH5AbT5daG9N63dqrwKRknZcdsRMAAAAAAAA=

------=_NextPart_000_002F_01C1ED1E.D026A580--



Received: by above.proper.com (8.11.6/8.11.3) id g3QFwl408470 for ietf-pkix-bks; Fri, 26 Apr 2002 08:58:47 -0700 (PDT)
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QFwja08464 for <[e-mail]>; Fri, 26 Apr 2002 08:58:45 -0700 (PDT)
Received: from tsg1 ([12.81.72.55]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020426155841.YOCK18857.mtiwmhc24.worldnet.att.net@tsg1>; Fri, 26 Apr 2002 15:58:41 +0000
Message-ID: <023501c1ed3b$06c7df20$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: "PKIX-IETF" <[e-mail]>
References: <[e-mail]>
Subject: Re: Meaning of Non-repudiation
Date: Fri, 26 Apr 2002 08:48:34 -0700
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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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 agree with you - the X.509 model is broken too. NR is a bigger thing than
a bit in a data structure and using the term NR causes problems for auditors
and other professionals that would have to use these protocols.

I and many others define NR as the sum-total of all the Information
Assurance technologies, techniques, and practices that make up and operating
environment. Thus NR is a state specific to a totality of condition and
maybe needs essentially gradiant levels rather than a binary on or off
state. Thats why a single bit alone without the accompanying OID is of
questionable value here.

Todd

----- Original Message -----
From: "Tom Gindin" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: "David P. Kemp" <[e-mail]>; <[e-mail]>
Sent: Wednesday, April 11, 2001 3:50 PM
Subject: Re: Meaning of Non-repudiation


>
>      IMHO, if X.509 had not been calling the bit in KeyUsage
> "non-repudiation" for some years, I would prefer to put "Persistent Data
> Authentication" into KeyUsage and define several different flavors of
> non-repudiation in ExtendedKeyUsage, profiling non-repudiation services in
> parallel with those ExtendedKeyUsage values.  This would also allow us to
> define different levels of NR and put them into certificates in a natural
> way.  However, they have been calling the bit "non-repudiation", and I'm
> not sure we can change its meaning on the installed base of certificates
> and on the X.509 group without an unusual level of unanimity and
> near-certainty that it won't break anything.
>
>           Tom Gindin
>
>
>




Received: by above.proper.com (8.11.6/8.11.3) id g3QFvVs08295 for ietf-pkix-bks; Fri, 26 Apr 2002 08:57:31 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QFvSa08285 for <[e-mail]>; Fri, 26 Apr 2002 08:57:28 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA26722; Fri, 26 Apr 2002 17:57:27 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 26 Apr 2002 17:57:27 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA10624; Fri, 26 Apr 2002 17:57:26 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA12767; Fri, 26 Apr 2002 17:57:26 +0200 (MET DST)
Date: Fri, 26 Apr 2002 17:57:26 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: <draft-ietf-pkix-dpv-dpd-req-04.txt>
Cc: [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 would lead to :
> >    In order to obtain the revocation status information of any
> >    certificate from the certification path, the DPV server might use,
> >    ...
> >    or a response from another DPV server.
> > 
> > I proposed:
> > 
> >    The DPV server MUST produce certificate status information for
> >    the validation time in the client request. In order to do this,
> >    the DPV server might use,  ...
> > 
> >    or a response from another DPV server.
> > 
> > The first sentence was changed.
> > 
> > In the seceond paragraph the two words indicated by XX above are indeed
> > can be deleted.
> 
> There is no basic diffence between the two proposals. The current changed
> text is sufficient. We cannot argue at length on the style of the wording.

May I remind you that since 4 years you are repeating that 
'negative revocation information' is not the same as 
'positive status information'. 

May I also remind you to the lengthy debates about how to interprete
"GOOD" in OCSP. 

Well, if everybody thinks that "obtaining revocation information"
is the same as "producing status information", ... 


> 
> Validating against one validation policy cert B from the chain (cert B +
> cert C) cannot help for validating cert A against a different policy (or
> even the same if it could work on a shorter chain) from the chain (cert A +
> cert B + cert C). Thus DPV responses on CA certificates would not be
> "useful" information. 

The fact that a French policeman may not be able to read an ID card
from country XYZ does not mean that we MUST NOT have a procedure to validate
French cards. 

Who says that this is "another" policy? How do you know that an OCSP
response obtained by some server is useful. It may not be one
that can be used for the given policy. 

The DPV server receive a certA plus a DPV response concerning the
path certB, certC. The DPV server uses the DPV response to 
to establish a path to some trusted root. It may, or may not
simply trust the DPV response to tell the truth about the current
validity, and use other services. 

At elast, the information had been useful to establish a path.  

> 
> > You might also add 'time stamps' to your list (as in ES-F).
> 
> As this is only a list of examples, do we need to say so ? As we already
> know a DPV response alone will be insufficient for validating a digital
> signature. Let us keep the mention of time-stamp tokens when we will address
> DSV requirements , ... which is the next step as soon as we finish this
> document.
Why do you talk about signature validation. You can for example have 
time stamp on "encryption cert status information" allowing you to
find out whether it was ok to encrypt data at that time or whether
you have violated some confidentiality requirement.  



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QFkMQ07484 for ietf-pkix-bks; Fri, 26 Apr 2002 08:46:22 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QFkKa07480 for <[e-mail]>; Fri, 26 Apr 2002 08:46:20 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA23102; Fri, 26 Apr 2002 17:49:11 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042617461203:288 ; Fri, 26 Apr 2002 17:46:12 +0200 
Message-ID: <[e-mail]>
Date: Fri, 26 Apr 2002 17:45:58 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/04/2002 17:46:12, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/04/2002 17:46:20, Serialize complete at 26/04/2002 17:46:20
Content-Transfer-Encoding: 7bit
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>

Peter,

> > > The protocol MUST allow to provide to the requestor and/or the
> > > responder a means to indicate a textual description indicating for example
> > > the natuer or reason of the request/response to appear in the
> > > result of the response.
> >
> > The text from the client is blindly copied in the response.
> >
> > Your are now asking for a *new* requirement that has not been mentioned
> > earlier: the inclusion of an optional text field from the server.
> >
> > We do not have such a feature in other protocols, like OCSP. There is also a
> > danger to apply different semantics on such a field. So I am not in favour
> > of adding it.
> 
> I don't agree that the server MUST blindly copy anything.

Please read again the text: "inclusion of an optional text field from the
server". This text is not copied from a client field but created by the
server.

> I don't look at the issue from a procedural standpoint but from
> the point of the data being produced.
> 
> - The response may contain a textual indication about the reason etc.
> 
> - This text may be created by the server or requested by the client
>   or modified by the server.

No. See above. 

> - It is NOT:  an opaque token from the client that MUST NOT be inspected
>   in whatever way by the server.
> 
> > Since you do not propose any specific text change, this text appears to be
> > sufficient and in fact is derived from your initial proposed wording. We
> > cannot argue for ever about the wording.
> 
> As long as you refuse textual changes (two characters + one word) as in
> 
> " The protocol MUST allow to provide to the requestor and/or the
>   responder a means to indicate a textual description indicating for example
>   the nature or reason of the request/response pair to appear in the
>   result of the response. "
> 
> I don't know what else I can do. It is somewhat difficult to
> anticipate your reaction of splitting each proposal into several ones
> while adding additional contraints to the pieces and provide a
> text change to that before having even seen what you propose.
> 
> I am not in favour of having a requirement that says that something
> MUST be blindly copied.
 
> I am not in favour that the usages of identififers of the clients
> and responders MUST be related to authentication.

 ... otherwise it is a field that has an undefined or an ambiguous
semantics.

> IMO this is an overspecification, and, as Russ turned out, some
> uses that do relate this to authentication may create a conflict
> with the requirements doc.

> > > > This should close the last issue raised during the last call.
> > > >
> > >
> > > I propose that we add somewhere in the introduction a statement like:
> > >
> > >   A protocol feature proposal MUST not be rejected as out of
> > >   scope for the sole reason of not having been mentioned in this
> > >   requirements document ".
> >
> > I would disagree to place such a requirement. If the protocol would allow,
> > for example, to ask for flowers at the same time, :-), then I believed that
> > such a feature shall be suppressed.
 
> Please read what I have written. You are turning around the argumentation.
> There are probably some arguments not to have a flower service in a DPV
> protocol. But they should be indicated. The text does only prohibity someone
> from saying: "We MUST NOT use this protocol because you can also request
> flowers and this has not been specified as a requirement."

 ... and for that exact reason, I would suppress the flower request. 
It is not appropriate to overload the protocol for whatever extra reason.
We are not going to say specifiaclly that flower requests support is
inappropriate, otherwise the list would be endless.

This was one of the problems from RFC 3029 (i.e. Data Certification Server
Protocols) that had too many features.

Denis

 
> Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QFhtI07443 for ietf-pkix-bks; Fri, 26 Apr 2002 08:43:55 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QFhsa07439 for <[e-mail]>; Fri, 26 Apr 2002 08:43:54 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA27340; Fri, 26 Apr 2002 17:46:44 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042617433431:286 ; Fri, 26 Apr 2002 17:43:34 +0200 
Message-ID: <[e-mail]>
Date: Fri, 26 Apr 2002 17:43:20 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: roadmap
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/04/2002 17:43:34, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/04/2002 17:43:54, Serialize complete at 26/04/2002 17:43:54
Content-Transfer-Encoding: 7bit
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>

Peter,

> > Michael,
> >
> > > Peter,
> > >
> > > v2's status mostly tracks that of the DPV and DPD requirements,
> > > which have only recently settled down after about a year's worth
> > > of effort.

> > OCSP *cannot* be the right vector to support DPV requirements since the role
> > of a CA is different from the role of a DPV server: a CA is only responsible
> > for the certificates that it has issued. A DPV server can be any entity
> > provided that it supports the appropriate validation policy which is *not*
> > established by a CA. As another argument: having at the same time in the
> > same response both a *single* OSCP response and a DPV response would be
> > quite odd. The DPV response provides information which would make the
> > *single* OCSP response useless. However the DPV response may include
> > *several* OCSP responses *and* the full certification path, if requested by
> > the client.

> Without saying whether I support or not the idea of using OCSP, I
> do not exactly understand the reasoning given above:
> 
>   I do not see why your comparison a CA role and he possibilities of
>   an DPV service has any relation with OCSP as a protocol:
 
> - A "trusted" OCSP responder which is not a CA or an authorized responder
>   can also issue status information based on his own local policy not
>   established by a CA, it can have its own 'revocation service' based
>   on the needs of the relying party.

So a trusted OCSP responder provides the revocation status information of a
*single* certificate and has nothing to do with a DPV server that does much
more on a *chain* of certificates.

> - An 'authorised' CA DPV responder can create status information about

An " 'authorised' CA DPV responder" is not a correct wording: either it is a
CA or a DPV responder.

>   its immediately subordinate certs, i;e. the single OCSP response that you
>   mention, and at the same time include some DPV response that validate
>   the path from the intermediate CA to the trusted root, either
>   as an entity extension or as a global extension.
 
> - An OCSP server can also be any entity, and not just an authorised
>   CA responder. An OCSP responder can respond to whatever the service
>   provider likes to provide to its clients or what they need. OCSP is
>   not a 'A CS service'.

An OCSP server basically provides the revocation status of a certificate and
may support extensions in addition to that basic response. Up to now, such
extensions have not been defined.

Since a DPV response is far richer than a DPV response, it would be quite
strange to use the content of the extension and to discard the main
response.

Picky-backing the DPV structure in an extension of the OCSP structure would
also lead to a strange behaviour. You could get a "valid OCSP answer" with
an "invalid DPV answer" (e.g. because a certificate from the chain is
revoked). These two statuses do not match together.

Denis

> > So my request is the same as made on the mailing list: RFC250bis should only
> > be updated to allow to specify a certificate using additional ways. OCSPv2
> > should be discontinued or at least the name "OCSPv2" dropped. This does not
> > mean that some ideas from that protocol cannot be re-used to fit with the
> > DPV requirements.
> 
> It might be a useful exercise to replace in 2650 all identifiers and structure
> names in the ASN1 definitions of RFC 2560 by i1, i2, .. and S1, S2 and see whether
> one nderstand the text, in particular reqCert and CertID.
> 
> >
> > However, this discussion is not directly related to the roadmap. ;-)
> >
> > Denis
> >
> > > As I said before, it didn't make much sense to track
> > > that moving target with incremental I-Ds.  I once had three
> > > separate I-Ds but that got so hard to manage and work due to
> > > syntatic and editorial overlap (not to mention review) that I
> > > put them all in one.  I prefer to keep that structure together
> > > while we see how things shake out re: DPV/DPD.  Since 2560bis is
> > > pretty well on its way, I think we should let that go forward
> > > cleanly rather than force a reset due to adding new syntax.
> > >
> > > Mike
> > >
> > > Michael Myers
> > > t: +415.819.1362
> > > e: mailto:[e-mail]
> > > w: http://www.traceroutesecurity.com
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]On Behalf Of
> > > > Peter Gutmann
> > > > Sent: Tuesday, April 23, 2002 8:33 PM
> > > > To: [e-mail]
> > > > Cc: [e-mail]
> > > > Subject: Re: roadmap
> > > >
> > > >
> > > >
> > > > Peter Sylvester <[e-mail]> writes:
> > > >
> > > > >Thus, it is not just a question of whether OCSP v2
> > > > being alive or not.
> > > >
> > > > Can I also add a general complaint about the vague
> > > > status of OCSPv2, there's
> > > > already software deployed which uses the extended
> > > > range of cert IDs in the v2
> > > > draft, which makes it annoying to have it fading in
> > > > and out of consciousness
> > > > every few months.  Perhaps the new cert IDs (which
> > > > are a trivial change) could
> > > > be moved into 2560-bis, without requiring all the
> > > > extra stuff which was added
> > > > in the rest of the v2 draft.
> > > >
> > > > Peter.
> > > >
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QFRmX07148 for ietf-pkix-bks; Fri, 26 Apr 2002 08:27:48 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QFRia07144 for <[e-mail]>; Fri, 26 Apr 2002 08:27:44 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA26550; Fri, 26 Apr 2002 17:27:38 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 26 Apr 2002 17:27:38 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA10458; Fri, 26 Apr 2002 17:27:37 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA12760; Fri, 26 Apr 2002 17:27:37 +0200 (MET DST)
Date: Fri, 26 Apr 2002 17:27:37 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
Cc: [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>

> > 
> > The protocol MUST allow to provide to the requestor and/or the
> > responder a means to indicate a textual description indicating for example
> > the natuer or reason of the request/response to appear in the
> > result of the response.
> 
> The text from the client is blindly copied in the response. 
> 
> Your are now asking for a *new* requirement that has not been mentioned
> earlier: the inclusion of an optional text field from the server.
> 
> We do not have such a feature in other protocols, like OCSP. There is also a
> danger to apply different semantics on such a field. So I am not in favour
> of adding it.

I don't agree that the server MUST blindly copy anything.

I don't look at the issue from a procedural standpoint but from
the point of the data being produced. 

- The response may contain a textual indication about the reason etc.

- This text may be created by the server or requested by the client
  or modified by the server. 

- It is NOT:  an opaque token from the client that MUST NOT be inspected
  in whatever way by the server.  

> Since you do not propose any specific text change, this text appears to be
> sufficient and in fact is derived from your initial proposed wording. We
> cannot argue for ever about the wording.

As long as you refuse textual changes (two characters + one word) as in 

" The protocol MUST allow to provide to the requestor and/or the
  responder a means to indicate a textual description indicating for example
  the nature or reason of the request/response pair to appear in the
  result of the response. "

I don't know what else I can do. It is somewhat difficult to
anticipate your reaction of splitting each proposal into several ones
while adding additional contraints to the pieces and provide a
text change to that before having even seen what you propose. 
 
I am not in favour of having a requirement that says that something
MUST be blindly copied. 

I am not in favour that the usages of identififers of the clients
and responders MUST be related to authentication. 

IMO this is an overspecification, and, as Russ turned out, some
uses that do relate this to authentication may create a conflict
with the requirements doc. 



> > > This should close the last issue raised during the last call.
> > >
> > 
> > I propose that we add somewhere in the introduction a statement like:
> > 
> >   A protocol feature proposal MUST not be rejected as out of
> >   scope for the sole reason of not having been mentioned in this
> >   requirements document ".
> 
> I would disagree to place such a requirement. If the protocol would allow,
> for example, to ask for flowers at the same time, :-), then I believed that
> such a feature shall be suppressed.

Please read what I have written. You are turning around the argumentation.
There are probably some arguments not to have a flower service in a DPV 
protocol. But they should be indicated. The text does only prohibity someone 
from saying: "We MUST NOT use this protocol because you can also request
flowers and this has not been specified as a requirement." 
 
Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QF42D06432 for ietf-pkix-bks; Fri, 26 Apr 2002 08:04:02 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3QF41a06428 for <[e-mail]>; Fri, 26 Apr 2002 08:04:01 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Apr 2002 15:02:41 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA03421 for <[e-mail]>; Fri, 26 Apr 2002 11:02:27 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3QF45k11859 for <[e-mail]>; Fri, 26 Apr 2002 11:04:05 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1XH9M>; Fri, 26 Apr 2002 11:01:32 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.32]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1XH9J; Fri, 26 Apr 2002 11:01:25 -0400
From: "Housley, Russ" <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 26 Apr 2002 11:03:50 -0400
Subject: Re: Multiple paths in DPD
In-Reply-To: <[e-mail]>
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>

Mike:

I am strongly opposed to an approach that would require the server to 
maintain state.  Unless other people are willing to speak up and support 
such an approach, I am not willing to make changes in this area.  In my 
view, the current consensus is for a stateless server.

Russ


At 02:15 PM 4/25/2002 -0700, Michael Myers wrote:
>Russ, Denis:
>
>This analysis and counter-proposal is a bit long which is why I
>broke it out separately from my other comments.  Apologies for
>the length and not getting to it at the -03 stage.  I had it on
>my list but got sidetracked by my day job.
>
>Anyway, I'm having a hard time agreeing with the following.
>
>-----------------------------------------------------
>     The DPD client needs to be able to limit the
>     number of paths returned. Therefore the client
>     MUST be able to indicate the maximum number of
>     certification paths to be returned (provided
>     that they can be found). If the client does
>     not specify a maximum number, then the DPD
>     server MUST return a single certification path.
>
>     . . .
>
>     If that number cannot be reached by the server,
>     an indication SHOULD be returned by the DPD
>     server showing that an additional query will
>     not return more paths.
>
>     If the paths that are returned do not match the
>     client's local criteria, then the number of
>     number of certification paths to be returned can
>     be extended by increasing this value. Previously
>     found paths will likely be returned, but the
>     client can easily discard them. This avoids
>     requirements for state information at the server,
>     but does not prevent a server from maintaining
>     a cache of previous responses.
>
>     Avoiding the maintenance of state information for
>     previous requests minimizes potential denial of
>     service attacks or other problems associated with
>     server crashes.
>
>-----------------------------------------------------
>
>I think an iterated approach based on server-side state would be
>better.  The approach is basically one which, in the presence of
>multiple paths, the server establishes state and returns the
>first potentially acceptable path (given client inputs) to the
>client along with a state token.  Should that path not be the
>precise one the client is looking for, the client asks again,
>referencing the state token.  Upon recognizing the state token,
>the server then returns the next path and so on until either the
>client shuts up and goes away or the server returns noMoreData.
>Doing so would reduce protocol complexity, reduce extraneous
>bits on the wire and reduce client-side and server-side code
>footprints with no loss of security assurances.
>
>Here's why I think so.
>
>Working first from the motivating needs, it's not clear to me
>how reduction of state will minimize potential denial of service
>attacks.  If they come, they're going to come regardless of the
>internal state of the server.  Possibly what you meant to say is
>that doing so potentially improves the likelihood a server can
>withstand DOS attacks while maintaining service to legitimate
>requests.  I shall assume this for the time being.
>
>But since DOS attacks are largely predicated on throughput
>constraints, one can simply beef up the back end or buy a bigger
>pipe.  Also, to the extent that your concern over DOS attacks
>and server crashes relates to the volatility of state retention,
>an implementor of the protocol that ultimately results from
>these requirements can choose to write that state to
>non-volatile memory.  That is, take a fault-tolerant
>implementation approach in those instances where mission
>criticality is important.  They're going to anyway.
>
>Lastly re: DOS, my own experience strongly suggests that
>effective responses to DOS attacks are most often addressed at
>the router, long before an offending stream from a given IP
>address gets to a back end.  I agree that we should take care
>not to enable sensitivity to DOS attacks.  I'm just not
>convinced that the max path approach yields much effect in that
>regard while the iterated approach yeilds clear benefits in
>design simplicity.
>
>To the design simplicity point, it's my estimate that in the
>vast majority of cases where DPD will be used, the first path
>returned will be the one the client wanted.  I also estimate
>that there'll be far more instances of only one path vs.
>multiple paths.  In my view we should design towards the
>centroid of needs rather than the corner cases.
>
>Is this design simpler?  I think so.  It's just a state token.
>The client doesn't even have to know what it is, just send it
>back for another try.  The use of noMoreData also provides
>unambiguous protocol closure.  The client knows for certain what
>to do in that instance.  Very simple, hence a smaller client.
>
>Regarding extraneous bits on the wire, consider the case of
>maxPath of M from the client and server side numPaths of N,
>where N is larger than M.  The client receives N-M paths and any
>requested revocation data.  All of which may be useless because
>the path the client wants is in the remainder.  So the client
>kicks up its M to, say, M' where M' is still less then N, first
>receives again those useless N-M paths and related info before
>it gets into the M'-M set.  And so on.
>
>I suspect once this scenario comes to the attention of
>client-side developers, they will be tempted to bake in a very
>large maxPath to ensure that a single query yields all paths.
>Again, a lot of extraneous bits on the wire when in point of
>fact the client just wants one.  And as I hypothesized, I
>suspect that in the vast majority of cases that'll be the first
>one.  Thus our requirements threaten to place onto the Internet
>a bunch of useless bits.  I think we should be sensitive to
>needless bandwidth consumption.
>
>Also, in the event multiple paths exist but the client doesn't
>specify max # of paths, what are the requirements on the server
>in the event of multiple queries from a client regarding the
>same certificate?  The requirement reads "return a single
>certification path" but provides no guidance in the presence of
>multiple paths at the server, leading one to assume that the
>first one is always sent back.
>
>Thus in the presence of multiple paths, there exists no means to
>enable a client to get at the one it wants.  Absent that
>guidance and any variation from the current draft requirements,
>I'm sure this issue will be taken up at the protocol selection
>stage of our work.  It's possible those considerations will lead
>to servers trying their best and silently iterate through these
>multiple paths in order to address this scenario.  That means
>state, just as is needed for the iterated approach in the first
>place.
>
>So I propose for your consideration the following text:
>
>-----------------------------------------------------
>
>If a DPV server has available to it multiple paths
>conformant to the parameters a client provides, upon
>receipt of an initial query the server MUST respond
>with the first path in this list AND include a token
>for reference by the client in subsequent queries.
>
>In the event of a single path, or a single qualifying
>path, the server MAY exclude the token.
>
>Upon receipt of a DPD response containing a response
>token indicating the existence of multiple qualifying
>paths, in order to acquire the next path in this list
>clients MUST include the previously supplied response
>token in a subsequent query.
>
>Servers MUST then transmit the next path in the
>qualifying list. If the last qualifying path was
>previously transmitted, servers MUST indicate that
>no more data exists.
>
>-----------------------------------------------------
>
>Again, apologies for the length and the delay.
>
>Regards,
>
>
>Mike


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QEm3s05911 for ietf-pkix-bks; Fri, 26 Apr 2002 07:48:03 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QEm1a05907 for <[e-mail]>; Fri, 26 Apr 2002 07:48:01 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA18350; Fri, 26 Apr 2002 16:50:51 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042616472899:278 ; Fri, 26 Apr 2002 16:47:28 +0200 
Message-ID: <[e-mail]>
Date: Fri, 26 Apr 2002 16:47:18 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: <draft-ietf-pkix-dpv-dpd-req-04.txt>
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/04/2002 16:47:29, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/04/2002 16:48:00, Serialize complete at 26/04/2002 16:48:00
Content-Transfer-Encoding: 7bit
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>

Peter,

> > > > The client can request that the server determine the certificate
> > > > validity at a time other than the current time. The DPV server MUST
> > > > obtain revocation status information for the validation time
> > > > in the client request.
> > > > In order to obtain the revocation status information of any
> > > > certificate from the certification path, the DPV server might use, in
> > > > accordance with the validation policy, different sources of revocation
> > > > information, e.g. a combination of OCSP responses, CRLs, or delta-CRLs.
> > > > If the revocation status information for the requested validation time
> > > > is unavailable, then the DPV server MUST return a status indicating
> > > > that the certificate is invalid.
> >
> > > replace by:
> > >
> > > The DPV server MUST produce certificate status information for
> > > the validation time in the client request. In order to do this,
> > > the server might use, in accordance with the validation policy,
> > > different sources of external information concerning revocation
> > > information, e.g., a combination of OCSP responses, CRLs, or
> > > delta-CRLs, or other status information from other DPV servers.
> > >
> > > If the certificate status information for the requested validation
> > > time is cannot be created, then the DPV server MUST return a status
>          XXX                   XXXXX
> > > indicating that the certificate is invalid.
> >
> > The last sentence you propose is not English. I simply propose to add to the
> > current sentence: "or a response from another DPV server".
> 
> This would lead to :
>    In order to obtain the revocation status information of any
>    certificate from the certification path, the DPV server might use,
>    ...
>    or a response from another DPV server.
> 
> I proposed:
> 
>    The DPV server MUST produce certificate status information for
>    the validation time in the client request. In order to do this,
>    the DPV server might use,  ...
> 
>    or a response from another DPV server.
> 
> The first sentence was changed.
> 
> In the seceond paragraph the two words indicated by XX above are indeed
> can be deleted.

There is no basic diffence between the two proposals. The current changed
text is sufficient. We cannot argue at length on the style of the wording.

> > > > The DPV client MUST be able to provide to the validation server,
> > > > associated with each certificate to be validated, "useful
> > > > certificates", as well as "useful revocation information". Revocation
> > > > information includes OCSP responses, CRLs, and delta-CRLs.
> >
> > > replace by:
> > >
> > > The DPV client MUST be able to provide to the validation server,
> > > associated with each certificate to be validated, "useful
> > > certificates", as well as "useful information" e.g., revocation
> > > information of OCSP responses, CRLs, and delta-CRLs, or status
> > > information from other DPV servers.
> >
> > No. If there is one DPV answer, then that answer is self-sufficient and
> > there is no reason for the client to make another query.
> 
> The client does not trust neither the OCSP response, neither the CRls,
> neither the DPV server, it presents all these information to *HIS*
> server.
> 
> Furthermore DPV responses may concern parts of the certification path.

Validating against one validation policy cert B from the chain (cert B +
cert C) cannot help for validating cert A against a different policy (or
even the same if it could work on a shorter chain) from the chain (cert A +
cert B + cert C). Thus DPV responses on CA certificates would not be
"useful" information. 

> You might also add 'time stamps' to your list (as in ES-F).

As this is only a list of examples, do we need to say so ? As we already
know a DPV response alone will be insufficient for validating a digital
signature. Let us keep the mention of time-stamp tokens when we will address
DSV requirements , ... which is the next step as soon as we finish this
document.

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QEhpa05832 for ietf-pkix-bks; Fri, 26 Apr 2002 07:43:51 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QEhna05828 for <[e-mail]>; Fri, 26 Apr 2002 07:43:49 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA28450; Fri, 26 Apr 2002 16:46:39 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042616432941:276 ; Fri, 26 Apr 2002 16:43:29 +0200 
Message-ID: <[e-mail]>
Date: Fri, 26 Apr 2002 16:43:19 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/04/2002 16:43:29, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/04/2002 16:43:49, Serialize complete at 26/04/2002 16:43:49
Content-Transfer-Encoding: 7bit
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>

Peter,

> > So I am prepared to include two paragraphs:
> >
> > The requestor MUST be able, upon request, to have a text field to be
> > copied in the response. As an example, this field may relate to the
> > nature or reason of the request/response.
> 
> I was thnking moire to a service like:
> 
> The protocol MUST allow to provide to the requestor and/or the
> responder a means to indicate a textual description indicating for example
> the natuer or reason of the request/response to appear in the
> result of the response.

The text from the client is blindly copied in the response. 

Your are now asking for a *new* requirement that has not been mentioned
earlier: the inclusion of an optional text field from the server.

We do not have such a feature in other protocols, like OCSP. There is also a
danger to apply different semantics on such a field. So I am not in favour
of adding it.

> > When the request is authenticated, the requestor SHOULD be able, upon
> > request, to indicate an identifier to be included in the response.
> > How this identifier is matched with the authenticated identity depends
> > on local server conditions and/or the validation policy. The server
> > MAY choose to refuse to include an identifier in the response, or MAY
> > refuse to create a response.
> 
> There are
> 
> - IDs identifying the requesting entity (or entities) or
>   entities which are entitled to use the response.
> 
> - IDs identifying the responding or responsible entity (or entities)
> 
> I give an example (probably using the wrong rules).
> 
> "We, the President of Unites States, and the General Secretary of
>  the United Nation", certify to you, President of France, President
>  of the French General assembly, and president of the French Senate,
>  the the certificate XXYZ can be used by you as a strong authentication
>  method to demand deployment of a combined UN ad US forces on May 5
>  according to plan LEF".
> 
> The request had been signed by two of three French authorities containg
> the name of the persons involved and their roles. The response has
> been signed by the two persons occupying the indicated 'role', plus
> by the presidents of the congress and senate and by the members of
> the UN security council.

Since you do not propose any specific text change, this text appears to be
sufficient and in fact is derived from your initial proposed wording. We
cannot argue for ever about the wording.

> > This should close the last issue raised during the last call.
> >
> 
> I propose that we add somewhere in the introduction a statement like:
> 
>   A protocol feature proposal MUST not be rejected as out of
>   scope for the sole reason of not having been mentioned in this
>   requirements document ".

I would disagree to place such a requirement. If the protocol would allow,
for example, to ask for flowers at the same time, :-), then I believed that
such a feature shall be suppressed.

This should place a final end to this large set of exchanged e-mails.

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QETpk05326 for ietf-pkix-bks; Fri, 26 Apr 2002 07:29:51 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QETma05319 for <[e-mail]>; Fri, 26 Apr 2002 07:29:48 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA26194; Fri, 26 Apr 2002 16:29:40 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 26 Apr 2002 16:29:41 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA10129; Fri, 26 Apr 2002 16:29:39 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA12747; Fri, 26 Apr 2002 16:29:39 +0200 (MET DST)
Date: Fri, 26 Apr 2002 16:29:39 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
Cc: [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>

> >
> >The protocol MUST allow to provide to the requestor and/or the
> >responder a means to indicate a textual description indicating for example
> >the natuer or reason of the request/response to appear in the
> >result of the response.
> 
> I think you are asking for an optional comment field.  Right?

Yes, one might call this this way: The USAGE of the field is optional.

> 
> > > When the request is authenticated, the requestor SHOULD be able, upon
> > > request, to indicate an identifier to be included in the response.
> > > How this identifier is matched with the authenticated identity depends
> > > on local server conditions and/or the validation policy. The server
> > > MAY choose to refuse to include an identifier in the response, or MAY
> > > refuse to create a response.
> >
> >There are
> >
> >- IDs identifying the requesting entity (or entities) or
> >   entities which are entitled to use the response.
> >
> >- IDs identifying the responding or responsible entity (or entities)
> >
> >I give an example (probably using the wrong rules).
> >
> >"We, the President of Unites States, and the General Secretary of
> >  the United Nation", certify to you, President of France, President
> >  of the French General assembly, and president of the French Senate,
> >  the the certificate XXYZ can be used by you as a strong authentication
> >  method to demand deployment of a combined UN ad US forces on May 5
> >  according to plan LEF".
> >
> >The request had been signed by two of three French authorities containg
> >the name of the persons involved and their roles. The response has
> >been signed by the two persons occupying the indicated 'role', plus
> >by the presidents of the congress and senate and by the members of
> >the UN security council.
> 
> I do not think that such rules have anything to do with DPV and DPD.  We 
> are not dealing with multi-party trust.  The client trusts the server that 
> was queried.  The client does not care whether the server consulted other 
> parties to come up with the response.


You are already dealing with multipart trust, you trust into each entity in a chain
telling the truth about its subordinate certificate. 

But, note, that there are TWO requirements, one for the 'client identifiers',
and another for the 'service identifiers'. For both fields, a similar
statement as with the 'optional comment' can be made, with the difference
that the syntax of the field is not pur text but "identifiers" which may
or may not correspond to some authenticated entity of the request/response.

If the DPV response is immediately consumed by the client without
storing it elsewhere, then all additional information are somewhat
unnecessary since the valid or not response conditions the treatment.

But if the response is saved and may be reverified by some other entity
years later, identification of the participating entities may be necessary,
for different reasons. One example would be that the DPV server
takes a response from another relay, authnticated it, but does NOT
return the authentication information into the final response, simply
because there is none which is permenant (SSL connection), BUT the
id of the relayed service allows to find a service that can validate
against a journal whether the attestation is valid.

Well, see below.

> 
> > > This should close the last issue raised during the last call.
> >
> >I propose that we add somewhere in the introduction a statement like:
> >
> >   A protocol feature proposal MUST not be rejected as out of
> >   scope for the sole reason of not having been mentioned in this
> >   requirements document ".
> 
> I would not mind such a statement as long as it was explanatory (no 
> MUST).  That is, a protocol that conforms to the requirements document can 
> also meet other requirements so long as they are not in conflict with the 
> ones in the requirement document.

I am not sure about the right wording, by using a MUST in whatever context
I would like to be sure that one cannot say: this protocol is not good
because it has feature that are not required in the req doc. 

Of course, conflicts with the requirements is a show stopper.  
> 
> Russ
>
Peter 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QDxC704030 for ietf-pkix-bks; Fri, 26 Apr 2002 06:59:12 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3QDxAa04025 for <[e-mail]>; Fri, 26 Apr 2002 06:59:10 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Apr 2002 13:57:51 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA23986 for <[e-mail]>; Fri, 26 Apr 2002 09:57:37 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3QDxCj00616 for <[e-mail]>; Fri, 26 Apr 2002 09:59:12 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1XF0L>; Fri, 26 Apr 2002 09:56:38 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.73]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1XF0H; Fri, 26 Apr 2002 09:56:33 -0400
From: "Housley, Russ" <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 26 Apr 2002 09:58:57 -0400
Subject: Re: Open issue: requester identifier in DPV response
In-Reply-To: <[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>

Peter:

> > So I am prepared to include two paragraphs:
> >
> > The requestor MUST be able, upon request, to have a text field to be
> > copied in the response. As an example, this field may relate to the
> > nature or reason of the request/response.
>
>I was thnking moire to a service like:
>
>The protocol MUST allow to provide to the requestor and/or the
>responder a means to indicate a textual description indicating for example
>the natuer or reason of the request/response to appear in the
>result of the response.

I think you are asking for an optional comment field.  Right?

> > When the request is authenticated, the requestor SHOULD be able, upon
> > request, to indicate an identifier to be included in the response.
> > How this identifier is matched with the authenticated identity depends
> > on local server conditions and/or the validation policy. The server
> > MAY choose to refuse to include an identifier in the response, or MAY
> > refuse to create a response.
>
>There are
>
>- IDs identifying the requesting entity (or entities) or
>   entities which are entitled to use the response.
>
>- IDs identifying the responding or responsible entity (or entities)
>
>I give an example (probably using the wrong rules).
>
>"We, the President of Unites States, and the General Secretary of
>  the United Nation", certify to you, President of France, President
>  of the French General assembly, and president of the French Senate,
>  the the certificate XXYZ can be used by you as a strong authentication
>  method to demand deployment of a combined UN ad US forces on May 5
>  according to plan LEF".
>
>The request had been signed by two of three French authorities containg
>the name of the persons involved and their roles. The response has
>been signed by the two persons occupying the indicated 'role', plus
>by the presidents of the congress and senate and by the members of
>the UN security council.

I do not think that such rules have anything to do with DPV and DPD.  We 
are not dealing with multi-party trust.  The client trusts the server that 
was queried.  The client does not care whether the server consulted other 
parties to come up with the response.

> > This should close the last issue raised during the last call.
>
>I propose that we add somewhere in the introduction a statement like:
>
>   A protocol feature proposal MUST not be rejected as out of
>   scope for the sole reason of not having been mentioned in this
>   requirements document ".

I would not mind such a statement as long as it was explanatory (no 
MUST).  That is, a protocol that conforms to the requirements document can 
also meet other requirements so long as they are not in conflict with the 
ones in the requirement document.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QDNmq01958 for ietf-pkix-bks; Fri, 26 Apr 2002 06:23:48 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QDNka01954 for <[e-mail]>; Fri, 26 Apr 2002 06:23:46 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA25702; Fri, 26 Apr 2002 15:23:36 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 26 Apr 2002 15:23:36 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA09852; Fri, 26 Apr 2002 15:23:29 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA12732; Fri, 26 Apr 2002 15:23:29 +0200 (MET DST)
Date: Fri, 26 Apr 2002 15:23:29 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: roadmap
Cc: [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>

> Michael,
> 
> > Peter,
> > 
> > v2's status mostly tracks that of the DPV and DPD requirements,
> > which have only recently settled down after about a year's worth
> > of effort.  
> 
> OCSP *cannot* be the right vector to support DPV requirements since the role
> of a CA is different from the role of a DPV server: a CA is only responsible
> for the certificates that it has issued. A DPV server can be any entity
> provided that it supports the appropriate validation policy which is *not*
> established by a CA. As another argument: having at the same time in the
> same response both a *single* OSCP response and a DPV response would be
> quite odd. The DPV response provides information which would make the
> *single* OCSP response useless. However the DPV response may include
> *several* OCSP responses *and* the full certification path, if requested by
> the client.
Without saying whether I support or not the idea of using OCSP, I
do not exactly understand the reasoning given above: 

  I do not see why your comparison a CA role and he possibilities of
  an DPV service has any relation with OCSP as a protocol:

- A "trusted" OCSP responder which is not a CA or an authorized responder
  can also issue status information based on his own local policy not
  established by a CA, it can have its own 'revocation service' based
  on the needs of the relying party. 

- An 'authorised' CA DPV responder can create status information about
  its immediately subordinate certs, i;e. the single OCSP response that you
  mention, and at the same time include some DPV response that validate
  the path from the intermediate CA to the trusted root, either
  as an entity extension or as a global extension. 

- An OCSP server can also be any entity, and not just an authorised
  CA responder. An OCSP responder can respond to whatever the service
  provider likes to provide to its clients or what they need. OCSP is
  not a 'A CS service'.   


> 
> So my request is the same as made on the mailing list: RFC250bis should only
> be updated to allow to specify a certificate using additional ways. OCSPv2
> should be discontinued or at least the name "OCSPv2" dropped. This does not
> mean that some ideas from that protocol cannot be re-used to fit with the
> DPV requirements.

It might be a useful exercise to replace in 2650 all identifiers and structure 
names in the ASN1 definitions of RFC 2560 by i1, i2, .. and S1, S2 and see whether
one nderstand the text, in particular reqCert and CertID. 

> 
> However, this discussion is not directly related to the roadmap. ;-)
> 
> Denis
> 
> > As I said before, it didn't make much sense to track
> > that moving target with incremental I-Ds.  I once had three
> > separate I-Ds but that got so hard to manage and work due to
> > syntatic and editorial overlap (not to mention review) that I
> > put them all in one.  I prefer to keep that structure together
> > while we see how things shake out re: DPV/DPD.  Since 2560bis is
> > pretty well on its way, I think we should let that go forward
> > cleanly rather than force a reset due to adding new syntax.
> > 
> > Mike
> > 
> > Michael Myers
> > t: +415.819.1362
> > e: mailto:[e-mail]
> > w: http://www.traceroutesecurity.com
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]On Behalf Of
> > > Peter Gutmann
> > > Sent: Tuesday, April 23, 2002 8:33 PM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: roadmap
> > >
> > >
> > >
> > > Peter Sylvester <[e-mail]> writes:
> > >
> > > >Thus, it is not just a question of whether OCSP v2
> > > being alive or not.
> > >
> > > Can I also add a general complaint about the vague
> > > status of OCSPv2, there's
> > > already software deployed which uses the extended
> > > range of cert IDs in the v2
> > > draft, which makes it annoying to have it fading in
> > > and out of consciousness
> > > every few months.  Perhaps the new cert IDs (which
> > > are a trivial change) could
> > > be moved into 2560-bis, without requiring all the
> > > extra stuff which was added
> > > in the rest of the v2 draft.
> > >
> > > Peter.
> > >
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QChQV29830 for ietf-pkix-bks; Fri, 26 Apr 2002 05:43:26 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3QChPa29826 for <[e-mail]>; Fri, 26 Apr 2002 05:43:25 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 26 Apr 2002 12:42:05 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA13565 for <[e-mail]>; Fri, 26 Apr 2002 08:41:51 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3QChRB18135 for <[e-mail]>; Fri, 26 Apr 2002 08:43:27 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1XD52>; Fri, 26 Apr 2002 08:40:54 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.73]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1XD51; Fri, 26 Apr 2002 08:40:49 -0400
From: "Housley, Russ" <[e-mail]>
To: Peter Williams <[e-mail]>
Cc: PKIX <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 26 Apr 2002 08:34:42 -0400
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
In-Reply-To: <[e-mail]. com>
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>

Peter Williams:

>let me ask you to laboriously confirm an example, which
>tests your meaning on a critical case.
>
>Citing to DoD CP 2.0 policy on relying party obligations
>for my example:
>
>(a) If DoD requires DoD RPs to regard a given revoked/expired cert as-if
>valid, for some reason, a DPV validation policy may
>NOT override 2459 logic to accommodate that CP's
>policy rule.
>
>         Is (a) correct?

I understand the need for this requirement.  In my view, the DPV server 
should say that the path is invalid and provide the reason as 
expiration.  The client, knowing the context of the query, can allow the 
grace period or not.

>(b) DoD UAs which delegate path
>processing to a DPV server CANNOT correctly implement
>the DoD CP obligation on RPs re as-if validiaty status - that is
>they CANNOT invoke security based on DPV-processed paths that
>contain factually invalid/expired certs.
>
>         Is (b) correct?

No correct. As above, the DPV server gives the client the status of the 
path, then the client can proceed to use the public key associated with an 
invalid path is the situation warrants.  For example, the path associated 
with the signature on an S/MIME message may be invalid, yet the contents is 
displayed to the human user with a warning that the certificate is expired 
(or revoked due to affiliation change, or revoked due to key compromise, or 
whatever).  The human needs to factor the reason for invalidity into any 
decision about the quality of the information in the message.

>(c) A DoD UA which does not use DPV and performs its own path
>processing CAN follow the DoD CPs obligations on the RP, and use
>paths containing factually-invalid certs that have been redesignated
>by the CP as-if valid.
>
>         Is (c) correct?

Correct.  However, this is not the only acceptable implementation 
architecture.  The path validation could be performed in accordance with 
RFC 2459 (or the soon to be published RFC 3280), then the DoD UA could make 
a policy decision to proceed with the public key anyway.

I would prefer to see grace periods (and other policy driven decisions to 
proceed with a particular invalid certificate) implemented in the 
application, not in the certification path processing.  In this may, as 
much application-specific context can be applied to the exceptions.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id g3QCUKT29619 for ietf-pkix-bks; Fri, 26 Apr 2002 05:30:20 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QCUIa29615 for <[e-mail]>; Fri, 26 Apr 2002 05:30:18 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA24426; Fri, 26 Apr 2002 14:30:16 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 26 Apr 2002 14:30:17 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA09325; Fri, 26 Apr 2002 14:30:16 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA12721; Fri, 26 Apr 2002 14:30:15 +0200 (MET DST)
Date: Fri, 26 Apr 2002 14:30:15 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
Cc: [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>

> 
> So I am prepared to include two paragraphs:
> 
> The requestor MUST be able, upon request, to have a text field to be 
> copied in the response. As an example, this field may relate to the 
> nature or reason of the request/response.

I was thnking moire to a service like: 

The protocol MUST allow to provide to the requestor and/or the
responder a means to indicate a textual description indicating for example
the natuer or reason of the request/response to appear in the
result of the response. 

> When the request is authenticated, the requestor SHOULD be able, upon
> request, to indicate an identifier to be included in the response. 
> How this identifier is matched with the authenticated identity depends 
> on local server conditions and/or the validation policy. The server 
> MAY choose to refuse to include an identifier in the response, or MAY 
> refuse to create a response. 

There are

- IDs identifying the requesting entity (or entities) or
  entities which are entitled to use the response. 

- IDs identifying the responding or responsible entity (or entities)

I give an example (probably using the wrong rules). 

"We, the President of Unites States, and the General Secretary of
 the United Nation", certify to you, President of France, President
 of the French General assembly, and president of the French Senate,
 the the certificate XXYZ can be used by you as a strong authentication 
 method to demand deployment of a combined UN ad US forces on May 5 
 according to plan LEF". 

The request had been signed by two of three French authorities containg
the name of the persons involved and their roles. The response has
been signed by the two persons occupying the indicated 'role', plus
by the presidents of the congress and senate and by the members of
the UN security council.


> 
> This should close the last issue raised during the last call.
>

I propose that we add somewhere in the introduction a statement like: 

  A protocol feature proposal MUST not be rejected as out of
  scope for the sole reason of not having been mentioned in this 
  requirements document ". 



Received: by above.proper.com (8.11.6/8.11.3) id g3QCEjr29364 for ietf-pkix-bks; Fri, 26 Apr 2002 05:14:45 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QCEga29360 for <[e-mail]>; Fri, 26 Apr 2002 05:14:42 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00738; Fri, 26 Apr 2002 08:14:40 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-pkalgs-asn1-01.txt
Date: Fri, 26 Apr 2002 08:14:40 -0400
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		: Update for Section 3 in       
                          draft-ietf-pkix-ipki-pkalgs-05.txt
	Author(s)	: T. Polk, R. Housley
	Filename	: draft-ietf-pkix-new-pkalgs-asn1-01.txt
	Pages		: 8
	Date		: 25-Apr-02
	
As all members of the PKIX Working Group know, draft-ietf-pkix-ipki-
pkalgs-05.txt is with the RFC Editor.  However, an error in the ASN.1
modules was discovered.  The authors are working with the RFC Editor
to ensure that the corrected ASN.1 modules are included in the final
text, and we are publishing this Internet-Draft to distribute the
corrected ASN.1 module as quickly as possible.
This Internet-Draft contains only the updated ASN.1 module.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-pkalgs-asn1-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-new-pkalgs-asn1-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-new-pkalgs-asn1-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-new-pkalgs-asn1-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QBI1s28368 for ietf-pkix-bks; Fri, 26 Apr 2002 04:18:01 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QBHwa28364 for <[e-mail]>; Fri, 26 Apr 2002 04:17:58 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA23821; Fri, 26 Apr 2002 13:17:55 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 26 Apr 2002 13:17:56 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA09162; Fri, 26 Apr 2002 13:17:55 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA12703; Fri, 26 Apr 2002 13:17:54 +0200 (MET DST)
Date: Fri, 26 Apr 2002 13:17:54 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: <draft-ietf-pkix-dpv-dpd-req-04.txt>
Cc: [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>

> > >
> > > The client can request that the server determine the certificate
> > > validity at a time other than the current time. The DPV server MUST
> > > obtain revocation status information for the validation time
> > > in the client request.
> > > In order to obtain the revocation status information of any
> > > certificate from the certification path, the DPV server might use, in
> > > accordance with the validation policy, different sources of revocation
> > > information, e.g. a combination of OCSP responses, CRLs, or delta-CRLs.
> > > If the revocation status information for the requested validation time
> > > is unavailable, then the DPV server MUST return a status indicating
> > > that the certificate is invalid.
> 
> > replace by:
> > 
> > The DPV server MUST produce certificate status information for
> > the validation time in the client request. In order to do this,
> > the server might use, in accordance with the validation policy,
> > different sources of external information concerning revocation
> > information, e.g., a combination of OCSP responses, CRLs, or
> > delta-CRLs, or other status information from other DPV servers.
> > 
> > If the certificate status information for the requested validation
> > time is cannot be created, then the DPV server MUST return a status
         XXX                   XXXXX 
> > indicating that the certificate is invalid.
> 
> The last sentence you propose is not English. I simply propose to add to the
> current sentence: "or a response from another DPV server".

This would lead to :
   In order to obtain the revocation status information of any
   certificate from the certification path, the DPV server might use,
   ...
   or a response from another DPV server.

I proposed: 

   The DPV server MUST produce certificate status information for
   the validation time in the client request. In order to do this,
   the DPV server might use,  ...

   or a response from another DPV server.


The first sentence was changed. 

In the seceond paragraph the two words indicated by XX above are indeed
can be deleted. 

> 
> > > The DPV client MUST be able to provide to the validation server,
> > > associated with each certificate to be validated, "useful
> > > certificates", as well as "useful revocation information". Revocation
> > > information includes OCSP responses, CRLs, and delta-CRLs.
> 
> > replace by:
> > 
> > The DPV client MUST be able to provide to the validation server,
> > associated with each certificate to be validated, "useful
> > certificates", as well as "useful information" e.g., revocation
> > information of OCSP responses, CRLs, and delta-CRLs, or status
> > information from other DPV servers.
> 
> No. If there is one DPV answer, then that answer is self-sufficient and
> there is no reason for the client to make another query.

The client does not trust neither the OCSP response, neither the CRls,
neither the DPV server, it presents all these information to *HIS*
server. 

Furthermore DPV responses may concern parts of the certification path.

You might also add 'time stamps' to your list (as in ES-F). 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3QAJd723292 for ietf-pkix-bks; Fri, 26 Apr 2002 03:19:39 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3QAJca23285 for <[e-mail]>; Fri, 26 Apr 2002 03:19:38 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA26684; Fri, 26 Apr 2002 12:22:24 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042612190160:218 ; Fri, 26 Apr 2002 12:19:01 +0200 
Message-ID: <[e-mail]>
Date: Fri, 26 Apr 2002 12:19:00 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Open issue: DPV additional information
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/04/2002 12:19:01, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 26/04/2002 12:19:34, Serialize complete at 26/04/2002 12:19:34
Content-Transfer-Encoding: 7bit
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>

Peter,

See my comments below.

> We are much closer, Denis. Thankyou for your thoughtful
> message on the target issue.
> 
> Let me reformulate a description of the mode that our RP-grade customers
> need of DPV, based on our having deployed SCVP and having
> got(ten) their feedback on needs and requirements. Lets see if we
> are now in agreement tht the model is embraced within the
> DPV requirements document. Im looking for an assurance, from you, not
> adoption of my phrasing. If the model is unacceptable,
> we need to fix the requirements.
> 
> A validation policy is a rule set, executed by a DPV server;
> the policy document has no operational function, and makes no assertions:
> a validation policy serves as configuration for a DPV server that performs
> delegated path processing on behalf of the DPV client - who
> is normally an RP.
> 
> The DPV server operator may make (NR) assertions by issuing
> a DPV response. For a given DPV request, the DPV server selects the
> validation policy from a set of policies, which the operator
> has configured it to handle, based on the citation
> of required policy by a DPV client. The selected validation policy
> indirectly controls the NR assertions that the operator makes.
> 
> If the user cites a validation policy to a DPV server,
> and that validation policy rule identifies that a particular

> OCSP server is "locally trusted", then revocation

I would say: 

OCSP server is directly trusted under that policy, then revocation 

> information from that source may be used in 2459
> path processing by the DPV server.
 
> If a DPV user does not wish to use a validation
> policy that names a particular OCSP responder as
> locally trusted, it should not cite that validation
> policy identification. 

We are very close, but I would say it slightly differently.

Before using a validation policy, the user shall make sure that it fits its
needs. 

> If a DPV user does not wish to use a validation
> policy that names a particular OCSP responder as
> locally trusted, it should not cite that validation
> policy identification. 

Most of the time a RP will be ignorant of the details of the validation
policy and thus will take it as a whole or not. Some managers may inspect a
policy to that level of details (e.g. look which OCSP responders are locally
trusted) and then tell RPs which policies are adequate or not.

> Citation of a policy
> by a user implies that a user is prepared to
> accept the underlying validity of the assurance data
> supplied to the requestor by the DPV server alongside
> NR assertions, including such assurance
> data as OCSP responses.

Yes.

Denis 

 
> >>>>An "OCSP responder that is locally trusted by the DPV
> >>>>client through a
> >>>>validation policy rule" does not make sense. An OCSP
> >>>>responder can be
> >>>>trusted under a given validation policy. If an OCSP
> >>>>responder is locally
> >>>>trusted by a client, then the DPV server is unaware of it.
> >>>>
> >>>>In the chain of trust: a validation policy does not know
> >>>>who the clients are
> >>>>and it is a validation policy issuer that defines which
> >>>>OCSP responders are
> >>>>trusted, not the clients. It is up to the clients to query
> >>>>DPV servers they
> >>>>trust and then they will accept whatever is defined in the
> >>>>validation
> >>>>policy.
> >>>>
> >>>>Denis
> >>>>
> >>>>> and that the DPV server will accept the OCSP response on the
> >>>>> client's behalf in a manner conforming to the rules of
> >>>>OCSP standard.
> >>>>
> >>>>> Given every opportunity to confirm this entailment, todate, Denis
> >>>>> has not done so. With confirmation, we can proceed.
> >>>>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PLIXl09025 for ietf-pkix-bks; Thu, 25 Apr 2002 14:18:33 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PLIWa09021 for <[e-mail]>; Thu, 25 Apr 2002 14:18:32 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3PLIRTt027966; Thu, 25 Apr 2002 14:18:27 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Housley, Russ" <[e-mail]>, "'PKIX '" <[e-mail]>
Subject: Multiple paths in DPD
Date: Thu, 25 Apr 2002 14:15:35 -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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Russ, Denis:

This analysis and counter-proposal is a bit long which is why I
broke it out separately from my other comments.  Apologies for
the length and not getting to it at the -03 stage.  I had it on
my list but got sidetracked by my day job.

Anyway, I'm having a hard time agreeing with the following.

-----------------------------------------------------
    The DPD client needs to be able to limit the
    number of paths returned. Therefore the client
    MUST be able to indicate the maximum number of
    certification paths to be returned (provided
    that they can be found). If the client does
    not specify a maximum number, then the DPD
    server MUST return a single certification path.

    . . .

    If that number cannot be reached by the server,
    an indication SHOULD be returned by the DPD
    server showing that an additional query will
    not return more paths.

    If the paths that are returned do not match the
    client's local criteria, then the number of
    number of certification paths to be returned can
    be extended by increasing this value. Previously
    found paths will likely be returned, but the
    client can easily discard them. This avoids
    requirements for state information at the server,
    but does not prevent a server from maintaining
    a cache of previous responses.

    Avoiding the maintenance of state information for
    previous requests minimizes potential denial of
    service attacks or other problems associated with
    server crashes.

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

I think an iterated approach based on server-side state would be
better.  The approach is basically one which, in the presence of
multiple paths, the server establishes state and returns the
first potentially acceptable path (given client inputs) to the
client along with a state token.  Should that path not be the
precise one the client is looking for, the client asks again,
referencing the state token.  Upon recognizing the state token,
the server then returns the next path and so on until either the
client shuts up and goes away or the server returns noMoreData.
Doing so would reduce protocol complexity, reduce extraneous
bits on the wire and reduce client-side and server-side code
footprints with no loss of security assurances.

Here's why I think so.

Working first from the motivating needs, it's not clear to me
how reduction of state will minimize potential denial of service
attacks.  If they come, they're going to come regardless of the
internal state of the server.  Possibly what you meant to say is
that doing so potentially improves the likelihood a server can
withstand DOS attacks while maintaining service to legitimate
requests.  I shall assume this for the time being.

But since DOS attacks are largely predicated on throughput
constraints, one can simply beef up the back end or buy a bigger
pipe.  Also, to the extent that your concern over DOS attacks
and server crashes relates to the volatility of state retention,
an implementor of the protocol that ultimately results from
these requirements can choose to write that state to
non-volatile memory.  That is, take a fault-tolerant
implementation approach in those instances where mission
criticality is important.  They're going to anyway.

Lastly re: DOS, my own experience strongly suggests that
effective responses to DOS attacks are most often addressed at
the router, long before an offending stream from a given IP
address gets to a back end.  I agree that we should take care
not to enable sensitivity to DOS attacks.  I'm just not
convinced that the max path approach yields much effect in that
regard while the iterated approach yeilds clear benefits in
design simplicity.

To the design simplicity point, it's my estimate that in the
vast majority of cases where DPD will be used, the first path
returned will be the one the client wanted.  I also estimate
that there'll be far more instances of only one path vs.
multiple paths.  In my view we should design towards the
centroid of needs rather than the corner cases.

Is this design simpler?  I think so.  It's just a state token.
The client doesn't even have to know what it is, just send it
back for another try.  The use of noMoreData also provides
unambiguous protocol closure.  The client knows for certain what
to do in that instance.  Very simple, hence a smaller client.

Regarding extraneous bits on the wire, consider the case of
maxPath of M from the client and server side numPaths of N,
where N is larger than M.  The client receives N-M paths and any
requested revocation data.  All of which may be useless because
the path the client wants is in the remainder.  So the client
kicks up its M to, say, M' where M' is still less then N, first
receives again those useless N-M paths and related info before
it gets into the M'-M set.  And so on.

I suspect once this scenario comes to the attention of
client-side developers, they will be tempted to bake in a very
large maxPath to ensure that a single query yields all paths.
Again, a lot of extraneous bits on the wire when in point of
fact the client just wants one.  And as I hypothesized, I
suspect that in the vast majority of cases that'll be the first
one.  Thus our requirements threaten to place onto the Internet
a bunch of useless bits.  I think we should be sensitive to
needless bandwidth consumption.

Also, in the event multiple paths exist but the client doesn't
specify max # of paths, what are the requirements on the server
in the event of multiple queries from a client regarding the
same certificate?  The requirement reads "return a single
certification path" but provides no guidance in the presence of
multiple paths at the server, leading one to assume that the
first one is always sent back.

Thus in the presence of multiple paths, there exists no means to
enable a client to get at the one it wants.  Absent that
guidance and any variation from the current draft requirements,
I'm sure this issue will be taken up at the protocol selection
stage of our work.  It's possible those considerations will lead
to servers trying their best and silently iterate through these
multiple paths in order to address this scenario.  That means
state, just as is needed for the iterated approach in the first
place.

So I propose for your consideration the following text:

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

If a DPV server has available to it multiple paths
conformant to the parameters a client provides, upon
receipt of an initial query the server MUST respond
with the first path in this list AND include a token
for reference by the client in subsequent queries.

In the event of a single path, or a single qualifying
path, the server MAY exclude the token.

Upon receipt of a DPD response containing a response
token indicating the existence of multiple qualifying
paths, in order to acquire the next path in this list
clients MUST include the previously supplied response
token in a subsequent query.

Servers MUST then transmit the next path in the
qualifying list. If the last qualifying path was
previously transmitted, servers MUST indicate that
no more data exists.

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

Again, apologies for the length and the delay.

Regards,


Mike



Received: by above.proper.com (8.11.6/8.11.3) id g3PJDGd06229 for ietf-pkix-bks; Thu, 25 Apr 2002 12:13:16 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PJDFa06225 for <[e-mail]>; Thu, 25 Apr 2002 12:13:15 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 25 Apr 2002 12:10:02 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 25 Apr 2002 12:10:02 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <JQL5AWGV>; Thu, 25 Apr 2002 12:13:04 -0700
Content-return: allowed
Date: Thu, 25 Apr 2002 12:13:03 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
To: "'Housley, Russ'" <[e-mail]>
Cc: PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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,

let me ask you to laboriously confirm an example, which 
tests your meaning on a critical case.

Citing to DoD CP 2.0 policy on relying party obligations
for my example:
 
(a) If DoD requires DoD RPs to regard a given revoked/expired cert as-if
valid, for some reason, a DPV validation policy may
NOT override 2459 logic to accommodate that CP's 
policy rule.

	Is (a) correct?

(b) DoD UAs which delegate path
processing to a DPV server CANNOT correctly implement
the DoD CP obligation on RPs re as-if validiaty status - that is 
they CANNOT invoke security based on DPV-processed paths that 
contain factually invalid/expired certs. 

	Is (b) correct?

(c) A DoD UA which does not use DPV and performs its own path 
processing CAN follow the DoD CPs obligations on the RP, and use
paths containing factually-invalid certs that have been redesignated 
by the CP as-if valid.

	Is (c) correct?


>>>>Mike:
>>>>
>>>>I think that RFC 2459 (and soon RFC 3280) clearly define a valid 
>>>>certification path.
>>>>
>>>>Anything that does not meet this definition is invalid, 
>>>>regardless of the 
>>>>reason.
 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PIpc205735 for ietf-pkix-bks; Thu, 25 Apr 2002 11:51:38 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PIpba05730 for <[e-mail]>; Thu, 25 Apr 2002 11:51:37 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 25 Apr 2002 11:48:24 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 25 Apr 2002 11:48:24 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <JQL5AWDK>; Thu, 25 Apr 2002 11:51:26 -0700
Content-return: allowed
Date: Thu, 25 Apr 2002 11:51:25 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Open issue: DPV additional information
To: "'Denis Pinkas'" <[e-mail]>
Cc: pkix <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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 are much closer, Denis. Thankyou for your thoughtful
message on the target issue.

Let me reformulate a description of the mode that our RP-grade customers
need of DPV, based on our having deployed SCVP and having 
got(ten) their feedback on needs and requirements. Lets see if we 
are now in agreement tht the model is embraced within the
DPV requirements document. Im looking for an assurance, from you, not 
adoption of my phrasing. If the model is unacceptable,
we need to fix the requirements.

A validation policy is a rule set, executed by a DPV server;
the policy document has no operational function, and makes no assertions:
a validation policy serves as configuration for a DPV server that performs
delegated path processing on behalf of the DPV client - who
is normally an RP. 

The DPV server operator may make (NR) assertions by issuing
a DPV response. For a given DPV request, the DPV server selects the 
validation policy from a set of policies, which the operator
has configured it to handle, based on the citation
of required policy by a DPV client. The selected validation policy
indirectly controls the NR assertions that the operator makes. 

If the user cites a validation policy to a DPV server,
and that validation policy rule identifies that a particular 
OCSP server is "locally trusted", then revocation 
information from that source may be used in 2459
path processing by the DPV server.

If a DPV user does not wish to use a validation
policy that names a particular OCSP responder as
locally trusted, it should not cite that validation
policy identification. Citation of a policy
by a user implies that a user is prepared to
accept the underlying validity of the assurance data 
supplied to the requestor by the DPV server alongside 
NR assertions, including such assurance
data as OCSP responses.

 
>>>>An "OCSP responder that is locally trusted by the DPV 
>>>>client through a
>>>>validation policy rule" does not make sense. An OCSP 
>>>>responder can be
>>>>trusted under a given validation policy. If an OCSP 
>>>>responder is locally
>>>>trusted by a client, then the DPV server is unaware of it.
>>>>
>>>>In the chain of trust: a validation policy does not know 
>>>>who the clients are
>>>>and it is a validation policy issuer that defines which 
>>>>OCSP responders are
>>>>trusted, not the clients. It is up to the clients to query 
>>>>DPV servers they
>>>>trust and then they will accept whatever is defined in the 
>>>>validation
>>>>policy.   
>>>>
>>>>Denis
>>>>
>>>>> and that the DPV server will accept the OCSP response on the
>>>>> client's behalf in a manner conforming to the rules of 
>>>>OCSP standard.
>>>> 
>>>>> Given every opportunity to confirm this entailment, todate, Denis
>>>>> has not done so. With confirmation, we can proceed.
>>>>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PInNo05659 for ietf-pkix-bks; Thu, 25 Apr 2002 11:49:23 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PInMa05655 for <[e-mail]>; Thu, 25 Apr 2002 11:49:22 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3PInLTt012738; Thu, 25 Apr 2002 11:49:21 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Peter Williams" <[e-mail]>, "PKIX" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Thu, 25 Apr 2002 11:46:28 -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 V5.50.4133.2400
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>

Peter,

I like what Russ said.  With respect to this WG, valid is
whatever 2459 or its successors says it is.  Invalid means one
or more those conditions aren't satisifed.  I see you agree.

I infer from my reading of the I-D that amendments to this
baseline are not necessarily client-driven.  -04 clearly states:
"If the DPV request does not specify a validation policy, the
server response MUST indicate the one that was used."

Mike


Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com

> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Thursday, April 25, 2002 11:19 AM
> To: 'Michael Myers'; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
>
> Mike,
>
> My question was not: what is Mike's/PeterW's opinion
> about the nature of
> validity (or DoD policy opinion, or the RSA/VeriSign policy
> opinion, or the VeriSign CPS 1.2 policy opinion, or
> the VeriSign CPS 2.0 policy opinion, or the next
> VeriSign v3.0 policy opinion ).
>
> The question was, do you have a citable, consensus definition
> that you can share with us, that is purely "technical"
>
> (a) Requirement A
>
> Id be happy to accept RFC 2459 as the definition of
> 2459-valid.
> Conformance to 2459 defines a reasonable process for
> asserting
> valid, in a technical sense.
>
> (b) Requirement B
>
> Any other amendment by a DPV server to
> the result of 2459 path processing must be based on
> application
> of a rule from a requestor-cited validation policy.
>
> I  provide two examples rules:
>
> (1) A path that is 2459-valid at one moment
> can be cited as invalid, under given validation policy
> whose nth policy rule states: all certs within
> 6 months of expiry are to be treated as revoked.
>
> (2) For DoD, a path that is 2459-invalid at one moment
> can be cited as valid, under given validation policy
> whose nth policy rule statea: all CA certs in a special
> exception class, maintained by the validation policy, are to
> be treated as if operational, for 36 months beyond the
> earlier of their validity-end date or an authorized
> CRL-based revocation date
>
> Can we agree that these basic processing requirements
> drive the
> protocol design for DPV?



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PIJEv05067 for ietf-pkix-bks; Thu, 25 Apr 2002 11:19:14 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PIJCa05063 for <[e-mail]>; Thu, 25 Apr 2002 11:19:12 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 25 Apr 2002 11:15:49 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 25 Apr 2002 11:15:49 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <JQL5AV0A>; Thu, 25 Apr 2002 11:18:52 -0700
Content-return: allowed
Date: Thu, 25 Apr 2002 11:18:51 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
To: "'Michael Myers'" <[e-mail]>, PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="iso-8859-1"
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>

Mike,

My question was not: what is Mike's/PeterW's opinion about the nature of
validity (or DoD policy opinion, or the RSA/VeriSign policy
opinion, or the VeriSign CPS 1.2 policy opinion, or
the VeriSign CPS 2.0 policy opinion, or the next 
VeriSign v3.0 policy opinion ).

The question was, do you have a citable, consensus definition
that you can share with us, that is purely "technical"

(a) Requirement A

Id be happy to accept RFC 2459 as the definition of 2459-valid. 
Conformance to 2459 defines a reasonable process for asserting 
valid, in a technical sense.

(b) Requirement B

Any other amendment by a DPV server to
the result of 2459 path processing must be based on application
of a rule from a requestor-cited validation policy.

I  provide two examples rules:

(1) A path that is 2459-valid at one moment
can be cited as invalid, under given validation policy
whose nth policy rule states: all certs within
6 months of expiry are to be treated as revoked.

(2) For DoD, a path that is 2459-invalid at one moment
can be cited as valid, under given validation policy
whose nth policy rule statea: all CA certs in a special
exception class, maintained by the validation policy, are to 
be treated as if operational, for 36 months beyond the
earlier of their validity-end date or an authorized 
CRL-based revocation date

Can we agree that these basic processing requirements drive the 
protocol design for DPV?


>>>>> (1) Can you provide a citation or other professional
>>>>> reference for the "precise technical meanings" of "valid" and
>>>>> "invalid", please?
>>>>
>>>>Which of the following do you believe should be eliminated from
>>>>such a definition:
>>>>
>>>>1. Formation of a valid path IAW 2459;
>>>>
>>>>2. Confirmation of revocation status for each
>>>>   certificate in said path;
>>>>
>>>>3. Cryptographic validation of said path IAW 2459.
>>>>
>>>>4. Other practices as required by policy.
>>>>
>>>>> (2) Could you also perhaps help me compare
>>>>> the definition(s) of "valid" used in the
>>>>> VeriSign CPs (1.2 and 2.0)and the US DOD CP v2 (March
>>>>> 1999), perhaps, against the recognised
>>>>> definition of "valid" (see above (1))?
>>>>
>>>>Nope.  Go for it.
>>>>
>>>>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PGS4B02175 for ietf-pkix-bks; Thu, 25 Apr 2002 09:28:04 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PGS3a02171 for <[e-mail]>; Thu, 25 Apr 2002 09:28:03 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3PGS1Tt027768; Thu, 25 Apr 2002 09:28:01 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: "'PKIX '" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Thu, 25 Apr 2002 09:25:08 -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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Denis,

It is good to see that we can occasionally agree :)

Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Thursday, April 25, 2002 6:15 AM
> To: Housley, Russ
> Cc: Michael Myers; 'PKIX '
> Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
>
>
> > > > DPV REQUIREMENTS
> > > > ****************
> > > >
> > > > Editorial
> > > > ---------
> > > > "Unless an error is reported, the DPV response MUST
> > > > indicate one
> > > > of the following two status alternatives:"
> > > >
> > > > MM3: Change "two" to "three" to reflect {valid, invalid,
> > > > unknown}
> > > >
> > > > [RH] I am having a real problem differentiating
> > > > invalid and unknown. To my way of thinking, the
> > > > actions taken by a client will be the same in
> > > > either case.
> > >
> > >{valid, invalid, unknown} is the resolution of record and
> > >defined in the text.  My comment was just pointing out an
> > >editorial wrinkle that needs smoothing out.
> >
> > [RH] I agree that a change was made to add the
> "unknown" response in draft
> > -04.  I am not convinced that we did anything
> useful for the client.  I
> > think the client will treat "invalid" and "unknown"
> exactly the same.
>
> [DP] I do not think that the client will always treat
> "invalid" and
> "unknown" exactly the same. I provide an example:
>
> A client queries a DPV server and gets back
> "invalid". It does not make
> sense for the client to query another DPV server,
> since the response will
> never be "valid".
>
> A client queries a DPV server and gets back
> "unknown". It makes sense to
> query another DPV server, since the response could
> then either be "valid",
> "invalid" or still "unkown".
>
> Also "unknown" can be used as a clean way to stop a
> loop mechanism, when the
> same protocol is used between DPV servers.
>
> As said later on in an e-mail sent by Tony:
>
> " Seems you have two choices:
>
> 1.  Go with "Trinary Value", in which case the
> semantics are satisfied by
>
>    a. Success_Valid
>    b. Failure_Invalid
>    c. Failure_Unknown
>
> 2.  Go with "Binary Value", using either
>
>    a. Valid
>    b. Invalid (see reason code for details)
>
>    or
>
>    a. Success
>    b. Failure (see reason codes for details)"
>
> The two approaches end up with the same result. We
> did discussed that point
> in Minneapolis and we decided to go with a trinary
> status. This mimics the
> three OCSP statuses, although the semantics of the
> DPV statuses are fully
> different.
>
> Denis
>
> (text deleted)
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PGL8c02019 for ietf-pkix-bks; Thu, 25 Apr 2002 09:21:08 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PGL7a02015 for <[e-mail]>; Thu, 25 Apr 2002 09:21:07 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3PGL4Tt027082; Thu, 25 Apr 2002 09:21:05 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, "'PKIX '" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Thu, 25 Apr 2002 09:18:11 -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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Denis,

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Thursday, April 25, 2002 6:48 AM
>
> . . .
>
> > > Multiple paths issue
> > > --------------------
> > > MM12:  This subset of DPD requirements seems to be leading
> > > towards a sub-optimal system design.  To be addressed in a
> > > separate email.
> > >
> > > [RH] I will wait for the mail to reply ...
>
> Please send it soon, since this is the VERY last
> comment (not raised during the WG last call period).
> However, if this is going to avoid an issue raised
> during the IESG Last call period, then we had better
> to solve that last one now.

Working it.  Apologies for not bringing it earlier.  It was on
my list of -03 issues but I got preoccupied with my day job and
overlooked making a post.

> > > Signing DPD responses an option
> . . .
>
> I propose to update the text in the following way:
>
> For the client to be confident that all the elements
> from the response originates from the expected DPD
> server, an authenticated response MAY be required.
> For example, the server might sign the response or data
> authentication might also be achieved using a
> lower-layer security protocol.
>
> Denis

This works for me.

Mike



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PGDbp01800 for ietf-pkix-bks; Thu, 25 Apr 2002 09:13:37 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PGDaa01792 for <[e-mail]>; Thu, 25 Apr 2002 09:13:36 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3PGDITt026371; Thu, 25 Apr 2002 09:13:19 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: roadmap
Date: Thu, 25 Apr 2002 09:10:25 -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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Denis,

I agree with Ambarish.  This is a reset to interop testing we
don't want to incur.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Thursday, April 25, 2002 6:14 AM
>
> . . .
>
> So my request is the same as made on the mailing
> list: RFC250bis should only  be updated to allow
> to specify a certificate using additional ways.





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PGArN01756 for ietf-pkix-bks; Thu, 25 Apr 2002 09:10:53 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PGApa01752 for <[e-mail]>; Thu, 25 Apr 2002 09:10:51 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3PGAoTt026154; Thu, 25 Apr 2002 09:10:51 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: "'PKIX '" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Thu, 25 Apr 2002 09:07: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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Russ,

I knew it was something simple.  Intersection of policy lists.
Got it.

I suspect though that in the vast majority of cases, this could
better be handled by client-side local configuration logic at
the gain of reduced protocol complexity, always a good thing.
I'm doubtful many folks are actually going to do this in
practice.

Where on the wire signalling is relevant, as a design option,
one could have a SEQ OF policy OIDs in the request and task the
server to do the intersection.  That way, one has an equivalent
functionality with only a very slight increase in protocol
complexity and further reduction in client-side code footprint,
an added benefit with respect to the various thin-client
arguments that have been made.  Only issue I see to this
approach is the instance where the intersection yields multiple
OIDs.  Then the server chooses vs. the client.  But then, how's
a client going to choose?

So I guess I can accept the requirement, but the requirements
document seems to constrain the technical approach.

Mike


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Thursday, April 25, 2002 6:33 AM
> To: Michael Myers
> Cc: 'PKIX '
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
> Mike:
>
> I was not the advocate for this requirement, but the
> one of the scenarios
> that the advocate had in mind was straightforward.
> The client has several
> acceptable policies, so the client asks the server
> for a list of supported
> policies, and the makes the query based on a policy
> that is on both lists.
>
> Russ
>
>
> At 03:14 PM 4/24/2002 -0700, Michael Myers wrote:
> >Russ,
> >
> >Will take up the "unknown" thread via Trevor's
> recent posting.
> >Good to hear you interpret the text as I do re: DPD
> server auth,
> >namely there's no prejudice against lower layer mechanisms.
> >
> >I'm still though trying to understand what needs policy
> >discovery truly addresses.  What might be called the
> use cases.
> >To my way of thinking about this, a client is interested in
> >*its* policy or the one or ones it is constrained to
> use, static
> >or otherwise, implicit default or directly signalled in its
> >request.  Would a discovery query prove this?
> Certainly.  But
> >so would an unsupportedPolicy response back from the server.
> >
> >I can see that policy discovery could be useful to the
> >initialization of a freshly installed client,
> especially from an
> >enterprise perspective, but then there's a trust
> issue there.  A
> >policy discovery function might also be useful in
> developing an
> >Internet-wide profile of which servers do which
> things, but I'm
> >not sure that's the intent.  Or is it?
> >
> >As I said, I'm just trying to understand the driver
> behind the
> >discovery piece.  Maybe like the roots issue, I'm overlooking
> >something obvious.
> >
> >Mike
> >
> >
> > > -----Original Message-----
> > > From: Housley, Russ [mailto:[e-mail]]
> > > Sent: Wednesday, April 24, 2002 11:21 AM
> > > To: Michael Myers
> > > Cc: 'PKIX '
> > > Subject: RE: Comments on
> draft-ietf-pkix-dpv-dpd-req-04.txt
> > >
> > >
> > > Mike:
> > >
> > > > > DPV REQUIREMENTS
> > > > > ****************
> > > > >
> > > > > Editorial
> > > > > ---------
> > > > > "Unless an error is reported, the DPV response MUST
> > > > > indicate one
> > > > > of the following two status alternatives:"
> > > > >
> > > > > MM3: Change "two" to "three" to reflect
> {valid, invalid,
> > > > > unknown}
> > > > >
> > > > > [RH] I am having a real problem differentiating
> > > > > invalid and unknown. To my way of thinking, the
> > > > > actions taken by a client will be the same in
> > > > > either case.
> > > >
> > > >{valid, invalid, unknown} is the resolution of record and
> > > >defined in the text.  My comment was just pointing out an
> > > >editorial wrinkle that needs smoothing out.
> > >
> > > [RH] I agree that a change was made to add the
> > > "unknown" response in draft
> > > -04.  I am not convinced that we did anything useful
> > > for the client.  I
> > > think the client will treat "invalid" and "unknown"
> > > exactly the same.
> > >
> > >
> > > > > Signing DPD responses an option
> > > > > -------------------------------
> > > > > "For the client to be confident that the response
> > > originates
> > > > > from the expected DPD server, the server MAY
> provide an
> > > > > authenticated response. For example, the server
> > > might sign the
> > > > > response."
> > > > >
> > > > > And,
> > > > >
> > > > > "The DPD server MAY require client
> > > authentication, therefore,
> > > > > the DPD request MUST be able to be authenticated."
> > > > >
> > > > > MM14:  Signing is an example, not a
> requirement, correct?
> > > > > Lower-layer security protocols could equally
> > > address server auth
> > > > > needs.  Suggest appending to the last sentence of
> > > the first
> > > > > requirement " . . . or the client could invoke a
> > > lower-layer
> > > > > security protocol that authenticates the server
> > > (e.g. TLS)."
> > > > > This also folds in well with the MUST regarding
> > > support for
> > > > > client auth.
> > > > >
> > > > > [RH] DPV requires signature on the response.  Why
> > > not allow
> > > > > some consistency?
> > > >
> > > >I see no needs-based driver for signed DPD
> responses.  A DPD
> > > >server is simply acting as an aggregation point
> for access to
> > > >signed data produced by others.   As I said before,
> > > one of the
> > > >potential features of DPD over DPV is that a DPD
> > > server arguably
> > > >need not be trusted in a certification sense while a
> > > DPV server
> > > >clearly must (assuming of course that server
> does not combine
> > > >both functions).  A non-normative statement that
> where DPD
> > > >server auth is relevant lower layer protocols can
> > > suffice would
> > > >preserve this quality with no loss of security assurance.
> > >
> > > [RH] Just rereading the text, I think that the text
> > > in draft -04 allows
> > > either lower layer mechanisms or signatures within
> > > the DPD protocol.  I do
> > > not think that there is a need to change anything here.
> > >
> > >
> > > > > POLICY DISCOVERY REQUIREMENT
> > > > > ****************************
> > > > >
> > > > > Thought we got rid of PDP-type requirements
> > > > > -------------------------------------------
> > > > > "The client MUST be able to obtain references for
> > > the default
> > > > > policy or for all of the policies supported by
> > > the server by
> > > > > using an additional request/response pair. The
> > > response can
> > > > > include references to previously defined policies or
> > > > > to a priori
> > > > > known policies."
> > > > >
> > > > > MM15:  I thought we got rid of all PDP-type
> > > requirements in this
> > > > > DPV/DPD requirements document.  The above text
> > > seems to mandate
> > > > > that any protocol responsive to this document
> > > MUST define a
> > > > > request/response pair for policy discovery.
> > > > >
> > > > > [RH] We want the client to be able to get a list
> > > of the policies.
> > > > > PDP (in a future document) will address the
> > > definition of said
> > > > > policies.
> > > >
> > > >A DPV or DPD server can iterate through its list
> of policy
> > > >definitions and either execute accordingly or send back
> > > >unsupportedPolicy.  What's important to the client
> > > is that the
> > > >server either does or does not support the
> policy the client
> > > >specifies in its request.
> > >
> > > The requirement says that the client can ask the
> > > server for a list of
> > > policy identifiers that it is currently supporting.
> > > This does not mean
> > > that they were dynamically defined policies.
> > >
> > > Russ
> > >
> >
> >Mike
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PFmgH28654 for ietf-pkix-bks; Thu, 25 Apr 2002 08:48:42 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PFmea28649 for <[e-mail]>; Thu, 25 Apr 2002 08:48:40 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3PFmOTt024206; Thu, 25 Apr 2002 08:48:24 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>, "pkix" <[e-mail]>
Subject: RE: Open issue: DPV additional information
Date: Thu, 25 Apr 2002 08:45:30 -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)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Denis,

In that scenario there are really two questions.  First, is the
certificate valid in the sense that it is reliable and the
circumstances relating to its issuance haven't changed in any
material way.  Having determined that, the next question is
"acceptable for a given purpose"?  Clearly the latter case is
more in scope of your rental car company.

However, your rental car company is then a relying party to the
issuer of those certificates it chooses to accept and thus
subject to any relying party agreement those CAs may have in
force at the time.  Maybe none such exists, but it's still a
relying party (at least as far as this technologist understands
the concept).

So I think it's dangerous to promulgate a notion that would lead
folks to believe that a certificate can be unilaterally asserted
as "valid" without any reference or relationship whatsoever to
the party that originally issued the certificate (where "valid"
has, or soon will have, a precise technical meaning in this WG).

What I hear you saying is, "acceptable for a given purpose"
which assertion can certainly lie beyond the scope of a CA.  One
that basis I agree with you.  Note, however, that if your rental
car company parses a cert looking for CA identity or equivalent,
and tosses it because it's not in the acceptable set without
ever bothering to run a path check (which design approach seems
likely), it's better to send back "unknown" rather than
"invalid". Better yet perhaps, an unsigned error. I suspect the
certificate's issuer may take offense at other parties claiming
its certificates are invalid when in point of fact they're not.

As Hal said, we've probably kicked this one to death but I just
wanted to raise that little flag of caution regarding the
relying party concept now that I better understand your
position.

Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Thursday, April 25, 2002 6:11 AM
> To: Michael Myers
> Cc: [e-mail]; pkix
> Subject: Re: Open issue: DPV additional information
>
>
>
> Michael,
>
> > Denis,
>
> > It is precisely that issue of responsibility, in a broader
> > sense.  I'm quite certain that organizational entities who
> > create, issue and maintain the reliability of public key
> > certificates will will be the first to claim jursidiction
> > regarding their validity. Who is going to claim otherwise?
>
> Let me provide you with an example:
>
> Avis Rent a Car (TM) is wishing to accept tourist car
> reservations using
> public key certificates in France. Avis Rent a Car
> (TM) will define the
> "Avis Rent a Car (TM) reservation policy in France
> for tourism vehicules"
> and state that under this policy Microsoft
> certificates class X, Verisign
> Certificates Class Y and Debis certificates Class Z
> are adequate. Microsoft,
> Verisign and Debis as CAs, are fully ignorant which
> applications are making
> use of their certificates.
>
> There needs not be any relationship between
> validation policy issuers and
> CAs.
>
> Validation policy issuers will pick up in their
> validation policies which
> CAs are appropriate.
>
> Denis
>
>
> > Mike
> >
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[e-mail]]
> > > Sent: Wednesday, April 17, 2002 8:02 AM
> > > > Extract from the road map document:
> > >
> > > Certification Authority (CA) - An authority
> > > trusted by one or more users to create and assign
> > > public key certificates. Optionally the CA may
> > > create the user's keys. It is important to
> > > note that the CA is responsible for the public key
> >                       ^^^^^^^^^^^^^^^
> > > certificates during their whole lifetime, not just
> > > for issuing them.
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PEU2026126 for ietf-pkix-bks; Thu, 25 Apr 2002 07:30:02 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3PETua26099 for <[e-mail]>; Thu, 25 Apr 2002 07:29:56 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 25 Apr 2002 14:28:38 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA14192 for <[e-mail]>; Thu, 25 Apr 2002 10:28:24 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3PEU0j21341 for <[e-mail]>; Thu, 25 Apr 2002 10:30:00 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1WTN4>; Thu, 25 Apr 2002 10:27:12 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.178]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1WTNK; Thu, 25 Apr 2002 10:26:58 -0400
From: "Housley, Russ" <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: "'PKIX '" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 25 Apr 2002 09:32:37 -0400
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
In-Reply-To: <[e-mail]>
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>

Mike:

I was not the advocate for this requirement, but the one of the scenarios 
that the advocate had in mind was straightforward.  The client has several 
acceptable policies, so the client asks the server for a list of supported 
policies, and the makes the query based on a policy that is on both lists.

Russ


At 03:14 PM 4/24/2002 -0700, Michael Myers wrote:
>Russ,
>
>Will take up the "unknown" thread via Trevor's recent posting.
>Good to hear you interpret the text as I do re: DPD server auth,
>namely there's no prejudice against lower layer mechanisms.
>
>I'm still though trying to understand what needs policy
>discovery truly addresses.  What might be called the use cases.
>To my way of thinking about this, a client is interested in
>*its* policy or the one or ones it is constrained to use, static
>or otherwise, implicit default or directly signalled in its
>request.  Would a discovery query prove this?  Certainly.  But
>so would an unsupportedPolicy response back from the server.
>
>I can see that policy discovery could be useful to the
>initialization of a freshly installed client, especially from an
>enterprise perspective, but then there's a trust issue there.  A
>policy discovery function might also be useful in developing an
>Internet-wide profile of which servers do which things, but I'm
>not sure that's the intent.  Or is it?
>
>As I said, I'm just trying to understand the driver behind the
>discovery piece.  Maybe like the roots issue, I'm overlooking
>something obvious.
>
>Mike
>
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> > Sent: Wednesday, April 24, 2002 11:21 AM
> > To: Michael Myers
> > Cc: 'PKIX '
> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> >
> >
> > Mike:
> >
> > > > DPV REQUIREMENTS
> > > > ****************
> > > >
> > > > Editorial
> > > > ---------
> > > > "Unless an error is reported, the DPV response MUST
> > > > indicate one
> > > > of the following two status alternatives:"
> > > >
> > > > MM3: Change "two" to "three" to reflect {valid, invalid,
> > > > unknown}
> > > >
> > > > [RH] I am having a real problem differentiating
> > > > invalid and unknown. To my way of thinking, the
> > > > actions taken by a client will be the same in
> > > > either case.
> > >
> > >{valid, invalid, unknown} is the resolution of record and
> > >defined in the text.  My comment was just pointing out an
> > >editorial wrinkle that needs smoothing out.
> >
> > [RH] I agree that a change was made to add the
> > "unknown" response in draft
> > -04.  I am not convinced that we did anything useful
> > for the client.  I
> > think the client will treat "invalid" and "unknown"
> > exactly the same.
> >
> >
> > > > Signing DPD responses an option
> > > > -------------------------------
> > > > "For the client to be confident that the response
> > originates
> > > > from the expected DPD server, the server MAY provide an
> > > > authenticated response. For example, the server
> > might sign the
> > > > response."
> > > >
> > > > And,
> > > >
> > > > "The DPD server MAY require client
> > authentication, therefore,
> > > > the DPD request MUST be able to be authenticated."
> > > >
> > > > MM14:  Signing is an example, not a requirement, correct?
> > > > Lower-layer security protocols could equally
> > address server auth
> > > > needs.  Suggest appending to the last sentence of
> > the first
> > > > requirement " . . . or the client could invoke a
> > lower-layer
> > > > security protocol that authenticates the server
> > (e.g. TLS)."
> > > > This also folds in well with the MUST regarding
> > support for
> > > > client auth.
> > > >
> > > > [RH] DPV requires signature on the response.  Why
> > not allow
> > > > some consistency?
> > >
> > >I see no needs-based driver for signed DPD responses.  A DPD
> > >server is simply acting as an aggregation point for access to
> > >signed data produced by others.   As I said before,
> > one of the
> > >potential features of DPD over DPV is that a DPD
> > server arguably
> > >need not be trusted in a certification sense while a
> > DPV server
> > >clearly must (assuming of course that server does not combine
> > >both functions).  A non-normative statement that where DPD
> > >server auth is relevant lower layer protocols can
> > suffice would
> > >preserve this quality with no loss of security assurance.
> >
> > [RH] Just rereading the text, I think that the text
> > in draft -04 allows
> > either lower layer mechanisms or signatures within
> > the DPD protocol.  I do
> > not think that there is a need to change anything here.
> >
> >
> > > > POLICY DISCOVERY REQUIREMENT
> > > > ****************************
> > > >
> > > > Thought we got rid of PDP-type requirements
> > > > -------------------------------------------
> > > > "The client MUST be able to obtain references for
> > the default
> > > > policy or for all of the policies supported by
> > the server by
> > > > using an additional request/response pair. The
> > response can
> > > > include references to previously defined policies or
> > > > to a priori
> > > > known policies."
> > > >
> > > > MM15:  I thought we got rid of all PDP-type
> > requirements in this
> > > > DPV/DPD requirements document.  The above text
> > seems to mandate
> > > > that any protocol responsive to this document
> > MUST define a
> > > > request/response pair for policy discovery.
> > > >
> > > > [RH] We want the client to be able to get a list
> > of the policies.
> > > > PDP (in a future document) will address the
> > definition of said
> > > > policies.
> > >
> > >A DPV or DPD server can iterate through its list of policy
> > >definitions and either execute accordingly or send back
> > >unsupportedPolicy.  What's important to the client
> > is that the
> > >server either does or does not support the policy the client
> > >specifies in its request.
> >
> > The requirement says that the client can ask the
> > server for a list of
> > policy identifiers that it is currently supporting.
> > This does not mean
> > that they were dynamically defined policies.
> >
> > Russ
> >
>
>Mike


Received: by above.proper.com (8.11.6/8.11.3) id g3PETwG26110 for ietf-pkix-bks; Thu, 25 Apr 2002 07:29:58 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3PETua26098 for <[e-mail]>; Thu, 25 Apr 2002 07:29:56 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 25 Apr 2002 14:28:37 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA14189 for <[e-mail]>; Thu, 25 Apr 2002 10:28:23 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3PETuj21317 for <[e-mail]>; Thu, 25 Apr 2002 10:29:58 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1WTNV>; Thu, 25 Apr 2002 10:27:12 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.178]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1WTNN; Thu, 25 Apr 2002 10:26:59 -0400
From: "Housley, Russ" <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: PKIX <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 25 Apr 2002 09:57:56 -0400
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
In-Reply-To: <[e-mail]>
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>

Mike:

I think that RFC 2459 (and soon RFC 3280) clearly define a valid 
certification path.

Anything that does not meet this definition is invalid, regardless of the 
reason.

Russ


At 07:47 PM 4/24/2002 -0700, Michael Myers wrote:

>Peter,
>
>See below.
>
>Mike
>
>
> > -----Original Message-----
> > From: Peter Williams [mailto:[e-mail]]
> > Sent: Wednesday, April 24, 2002 6:51 PM
> > To: 'Michael Myers'; PKIX
> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> >
> >
> >
> > Mike,
> >
> > (1) Can you provide a citation or other professional
> > reference for the "precise technical meanings" of "valid" and
> > "invalid", please?
>
>Which of the following do you believe should be eliminated from
>such a definition:
>
>1. Formation of a valid path IAW 2459;
>
>2. Confirmation of revocation status for each
>    certificate in said path;
>
>3. Cryptographic validation of said path IAW 2459.
>
>4. Other practices as required by policy.
>
> > (2) Could you also perhaps help me compare
> > the definition(s) of "valid" used in the
> > VeriSign CPs (1.2 and 2.0)and the US DOD CP v2 (March
> > 1999), perhaps, against the recognised
> > definition of "valid" (see above (1))?
>
>Nope.  Go for it.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PETwu26111 for ietf-pkix-bks; Thu, 25 Apr 2002 07:29:58 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3PETua26105 for <[e-mail]>; Thu, 25 Apr 2002 07:29:56 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 25 Apr 2002 14:28:38 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA14200 for <[e-mail]>; Thu, 25 Apr 2002 10:28:25 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3PEU1j21346 for <[e-mail]>; Thu, 25 Apr 2002 10:30:01 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1WTNW>; Thu, 25 Apr 2002 10:27:12 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.178]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1WTN3; Thu, 25 Apr 2002 10:26:59 -0400
From: "Housley, Russ" <[e-mail]>
To: Tony Bartoletti <[e-mail]>
Cc: PKIX  <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 25 Apr 2002 10:05:22 -0400
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.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>

Tony:

Agree.  I like choice 2.

Russ

At 06:58 PM 4/24/2002 -0800, Tony Bartoletti wrote:

>Seems you have two choices:
>
>1.  Go with "Trinary Value", in which case the semantics are satisfied by
>
>   a. Success_Valid
>   b. Failure_Invalid
>   c. Failure_Unknown
>
>2.  Go with "Binary Value", using either
>
>   a. Valid
>   b. Invalid (see reason code for details)
>
>   or
>
>   a. Success
>   b. Failure (see reason codes for details)
>
> From a state-machine point of view, even the latter choices are workable, 
> ASSUMING that the indicated reason-codes are "reasonably 
> standardized".  The only "client-side-reason" I can see for this 3-valued 
> (or n-valued) response would be a case of clientware capable of 
> automatically seeking a "second opinion" from another source, where the 
> trinary "unknown" is returned (or the reason-code associated with the 
> binary response indicates a possible transient lack of information.)
>
>The "Server-side" argument for trinary response (not wanting to pronounce 
>a certificate "invalid" given lack of information or authority) seems 
>satisfied by Trevor's Success/Failure terminology, correct?
>
>Cheers!
>
>____tony____
>
>Tony Bartoletti 925-422-3881 <[e-mail]>
>Information Operations, Warfare and Assurance Center
>Lawrence Livermore National Laboratory
>Livermore, CA 94551-9900
>
>
>
>At 06:17 PM 4/24/02 -0700, Michael Myers wrote:
>
>>Trevor,
>>
>>It is my firm belief that at a meta level we are faced
>>fundamentally with a trinary valued state variable.  I've yet to
>>hear a needs-based argument that dissuades me from that
>>conviction.  Maybe we should discuss offlist and spare the WG
>>further chatter.  My contact info is below.
>>
>>Mike
>>
>>Michael Myers
>>t: +415.819.1362
>>e: mailto:[e-mail]
>>w: http://www.traceroutesecurity.com
>>
>>
>>
>>
>>
>> > -----Original Message-----
>> > From: Trevor Freeman [mailto:[e-mail]]
>> > Sent: Wednesday, April 24, 2002 6:00 PM
>> > To: Michael Myers; PKIX
>> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>> >
>> >
>> > Michael,
>> > Success and failure have precise technical meaning.
>> > The client is asking
>> > either "can you validate this certificate" or "can
>> > you build a path with
>> > this certificate" The server can succeed in that task
>> > - which implies
>> > the certificate is valid or the server build a path,
>> > or the server
>> > failed. Using these semantics, failure to comply with
>> > the clients
>> > request on the server's part implies nothing about
>> > the certificate only
>> > about the server ability, but retains a binary
>> > response which is simple
>> > for the client to process.
>> > We can add specific reasons for the failure in the
>> > protocol document
>> > which allow the server to express whatever it wants about its
>> > inadequacies.
>> > Is that OK for now?
>> >
>> > Trevor
>> >
>> > -----Original Message-----
>> > From: Michael Myers [mailto:[e-mail]]
>> > Sent: Wednesday, April 24, 2002 5:44 PM
>> > To: Trevor Freeman; PKIX
>> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>> >
>> > Trevor,
>> >
>> > No, what I'm saying is that valid and invalid have precise
>> > technical meanings that could be potentially relevant to an
>> > arbitration panel if not a court of law.  The unknown state
>> > affords a service provider or enterprise deploying a
>> > server the
>> > means to escape out of binding itself into a situation that
>> > could possibly put it at financial risk.
>> >
>> > I could be totally wrong in that perception, but that's what I
>> > think.  Several years ago it was just crypto and toolkits.
>> > Today there's laws and regulations and jurisdictional forums
>> > considering how this technology applies to societal
>> > factors.  I
>> > for one think we need to be responsible in this regard.
>> >
>> > Else maybe what you're talking about is more aligned
>> > with Peter
>> > Gutman's certOK proposal.
>> >
>> > Mike
>> >
>> >
>> >
>> > Michael Myers
>> > t: +415.819.1362
>> > e: mailto:[e-mail]
>> > w: http://www.traceroutesecurity.com
>> >
>> > > -----Original Message-----
>> > > From: Trevor Freeman [mailto:[e-mail]]
>> > > Sent: Wednesday, April 24, 2002 4:44 PM
>> > > To: Michael Myers; PKIX
>> > > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>> > >
>> > >
>> > > Mike,
>> > > All you are saying is that the server needs to
>> > > clarity the reason for
>> > > the inability to validate the certificate. You
>> > > objection seems to be
>> > > wording of the return state in the requirement
>> > > document implying more
>> > > than is intended. Rather that naming them in the
>> > > requirements document
>> > > valid and invalid, we can name them success and
>> > > failure. Success means
>> > > the server was able to complete the client request,
>> > > and failure means it
>> > > did not.
>> > >
>> > > Trevor
>> > > -----Original Message-----
>> > > From: Michael Myers [mailto:[e-mail]]
>> > > Sent: Wednesday, April 24, 2002 3:54 PM
>> > > To: Trevor Freeman; PKIX
>> > > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>> > >
>> > > Trevor,
>> > >
>> > > I agree with you and Russ that from a state machine
>> > > perspective,
>> > > a client will probably take the same action in both
>> > > the unknown
>> > > and invalid cases.  However, from a server, or more
>> > > importantly
>> > > a service perspective, I suspect there exists an appreciable
>> > > semantic difference  in a legal or liability sense
>> > > between these
>> > > two states.
>> > >
>> > > I've had the pleasure over the past few years of abundant
>> > > exposure to lawyers, bankers, regulators and other
>> > such types
>> > > regarding these and related issues.  I'm sure many
>> > of us share
>> > > that experience in one form or another.
>> > >
>> > > Now, I'm no lawyer but given that exposure it seems
>> > > to me that a
>> > > service (i.e. that which runs a server) is setting
>> > > itself up for
>> > > disaster by asserting a digitally signed "invalid"
>> > > when in point
>> > > of fact that service hasn't the data, jurisdiction or
>> > > delegation
>> > > to make such an unequivocal assertion.
>> > >
>> > > As a hypothetical, consider a party seeking damages
>> > > to which an
>> > > invalid assertion is useful as evidence even though the
>> > > certificate in question is provably valid given
>> > access to the
>> > > relevant data.  That plaintiff could arguably find
>> > > some service
>> > > that doesn't know diddly about the certificate to issue a
>> > > digitally signed "invalid" and there you go.  That
>> > > TTP may have
>> > > just stuck its neck out.
>> > >
>> > > I know that's probably a stretch, but not
>> > inconceivable given
>> > > some the purposes to which certs and sigs are today being
>> > > applied.  Better it seems by far to enable an "out"
>> > > via unknown
>> > > even if at the other end, the client does nothing
>> > differently.
>> > >
>> > > Valid and Invalid mean something very precise to my way of
>> > > thinking.  It means data was accumulated, a path was
>> > > successfully constructed, revocation information was
>> > > checked and
>> > > the entire dataset checked according to 2459 and
>> > whatever else
>> > > might specified by the policy in place at the time
>> > between the
>> > > client and the server/service.  Break any one of those
>> > > assumptions and one can't assert invalid.  Hence we need
>> > > unknown.
>> > >
>> > > Mike
>> > >
>> > >
>> > > > -----Original Message-----
>> > > > From: Trevor Freeman
>>[mailto:[e-mail]]
>> > > Sent: Wednesday, April 24, 2002 11:33 AM
>> > > To: Michael Myers; PKIX
>> > > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>> > >
>> > >
>> > > Mike,
>> > > I realise there has been several mailing on this
>> > > topic, but so far no
>> > > consensus.
>> > > Apart form references to 2560, I have not seen much
>> > > in the way of
>> > > reasoned justification as to why we need another
>> > > return code in DPV/DPD.
>> > > All this additional return value is indicating is
>> > > some kind of failure
>> > > on the part of the server. We have defined the
>> > requirement for
>> > > additional information on the error to be returned by
>> > > the server to
>> > > clarify the nature of the failure to the client. If
>> > > you want to refine
>> > > the defined list of sub-status reasons when we get to
>> > > define the
>> > > protocol then I am sure we can debate this more
>> > > meaningfully then.
>> > > However since one of the goals of the DPV protocol is
>> > > to address
>> > > constrained clients, then we have to be hard core on
>> > > not complication
>> > > the protocol.
>> > >
>> > > Trevor
>> >
>> >
>
>Tony Bartoletti 925-422-3881 <[e-mail]>
>Information Operations, Warfare and Assurance Center
>Lawrence Livermore National Laboratory
>Livermore, CA 94551-9900
>
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PDlt925016 for ietf-pkix-bks; Thu, 25 Apr 2002 06:47:55 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDlra25012 for <[e-mail]>; Thu, 25 Apr 2002 06:47:54 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA19268; Thu, 25 Apr 2002 15:50:39 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042515471795:115 ; Thu, 25 Apr 2002 15:47:17 +0200 
Message-ID: <[e-mail]>
Date: Thu, 25 Apr 2002 15:47:36 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, "'PKIX '" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:47:18, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:47:49, Serialize complete at 25/04/2002 15:47:49
Content-Transfer-Encoding: 7bit
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>

Michael,

> Russ,
> 
> That was quick.  Thanks.  A few responses below, else I concur.
> 
> Mike
> 
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> >
> >
> > DPV REQUIREMENTS
> > ****************
> >
> > Editorial
> > ---------
> > "Unless an error is reported, the DPV response MUST
> > indicate one
> > of the following two status alternatives:"
> >
> > MM3: Change "two" to "three" to reflect {valid, invalid,
> > unknown}
> >
> > [RH] I am having a real problem differentiating
> > invalid and unknown. To my way of thinking, the
> > actions taken by a client will be the same in
> > either case.
> 
> {valid, invalid, unknown} is the resolution of record and
> defined in the text.  My comment was just pointing out an
> editorial wrinkle that needs smoothing out.

I have maintained the three states.

 
> > DPD REQUIREMENTS
> > ****************
> >
> >
> > Multiple paths issue
> > --------------------
> > MM12:  This subset of DPD requirements seems to be leading
> > towards a sub-optimal system design.  To be addressed in a
> > separate email.
> >
> > [RH] I will wait for the mail to reply ...

Please send it soon, since this is the VERY last comment (not raised during
the WG last call period). However, if this is going to avoid an issue raised
during the IESG Last call period, then we had better to solve that last one
now.

 
> Forthcoming.
> 
> > Signing DPD responses an option
> > -------------------------------
> > "For the client to be confident that the response originates
> > from the expected DPD server, the server MAY provide an
> > authenticated response. For example, the server might sign the
> > response."
> >
> > And,
> >
> > "The DPD server MAY require client authentication, therefore,
> > the DPD request MUST be able to be authenticated."
> >
> > MM14:  Signing is an example, not a requirement, correct?
> > Lower-layer security protocols could equally address
> > server auth
> > needs.  Suggest appending to the last sentence of the first
> > requirement " . . . or the client could invoke a lower-layer
> > security protocol that authenticates the server (e.g. TLS)."
> > This also folds in well with the MUST regarding support for
> > client auth.
> >
> > [RH] DPV requires signature on the response.  Why not allow
> > some consistency?
> 
> I see no needs-based driver for signed DPD responses.  A DPD
> server is simply acting as an aggregation point for access to
> signed data produced by others.   As I said before, one of the
> potential features of DPD over DPV is that a DPD server arguably
> need not be trusted in a certification sense while a DPV server
> clearly must (assuming of course that server does not combine
> both functions).  A non-normative statement that where DPD
> server auth is relevant lower layer protocols can suffice would
> preserve this quality with no loss of security assurance.

I propose to update the text in the following way:

For the client to be confident that all the elements from the response 
originates from the expected DPD server, an authenticated response MAY 
be required. For example, the server might sign the response or data 
authentication might also be achieved using a lower-layer security 
protocol.

Denis

 
> > POLICY DISCOVERY REQUIREMENT
> > ****************************
> >
> > Thought we got rid of PDP-type requirements
> > -------------------------------------------
> > "The client MUST be able to obtain references for the default
> > policy or for all of the policies supported by the server by
> > using an additional request/response pair. The response can
> > include references to previously defined policies or
> > to a priori
> > known policies."
> >
> > MM15:  I thought we got rid of all PDP-type
> > requirements in this
> > DPV/DPD requirements document.  The above text seems
> > to mandate
> > that any protocol responsive to this document MUST define a
> > request/response pair for policy discovery.
> >
> > [RH] We want the client to be able to get a list of
> > the policies.
> > PDP (in a future document) will address the definition of said
> > policies.
> 
> A DPV or DPD server can iterate through its list of policy
> definitions and either execute accordingly or send back
> unsupportedPolicy.  What's important to the client is that the
> server either does or does not support the policy the client
> specifies in its request.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PDNov23369 for ietf-pkix-bks; Thu, 25 Apr 2002 06:23:50 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDNna23365 for <[e-mail]>; Thu, 25 Apr 2002 06:23:49 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA14596; Thu, 25 Apr 2002 15:26:38 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042515233985:106 ; Thu, 25 Apr 2002 15:23:39 +0200 
Message-ID: <[e-mail]>
Date: Thu, 25 Apr 2002 15:23:58 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Two  more nits re: DPV/DPD rqmts
References: <[e-mail]> <[e-mail]> <004e01c1e4ee$5e51e7e0$020aff0a@tsg1> <p05100308b8ea318575de@[128.89.88.34]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:23:40, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:23:49, Serialize complete at 25/04/2002 15:23:49
Content-Transfer-Encoding: 7bit
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>

Steve,

(...)

> In the case of DPV and DPD, the WG discussed the matter some time ago
> and agreed that it would be highly desirable to have just one
> standard protocol satisfying the requirements we agree upon.  We
> failed to do this in the case of CMC and CMP and the user and vendor
> community suffered as a result. So, yes, the intent in this case is
> to have just one standard for DPV and DPD.

I would rather say " ... just one protocol for DPV and one protocol for
DPD". At this time it is too early to say whether they will described in one
document or two.

Denis

> Steve


Received: by above.proper.com (8.11.6/8.11.3) id g3PDIQS23133 for ietf-pkix-bks; Thu, 25 Apr 2002 06:18:26 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDIPa23129 for <[e-mail]>; Thu, 25 Apr 2002 06:18:25 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA09158; Thu, 25 Apr 2002 15:21:14 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042515180480:102 ; Thu, 25 Apr 2002 15:18:04 +0200 
Message-ID: <[e-mail]>
Date: Thu, 25 Apr 2002 15:18:23 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:18:05, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:18:24, Serialize complete at 25/04/2002 15:18:24
Content-Transfer-Encoding: 7bit
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>

Peter,

I believe that we have now achieved consensus for the inclusion of 
two different requirements for two different purposes:

So I am prepared to include two paragraphs:

The requestor MUST be able, upon request, to have a text field to be 
copied in the response. As an example, this field may relate to the 
nature or reason of the request/response.

When the request is authenticated, the requestor SHOULD be able, upon
request, to indicate an identifier to be included in the response. 
How this identifier is matched with the authenticated identity depends 
on local server conditions and/or the validation policy. The server 
MAY choose to refuse to include an identifier in the response, or MAY 
refuse to create a response. 

This should close the last issue raised during the last call.

Denis

> > >1. The requestor MUST be able, upon request, to have a field to be copied
> > >    in the response.
> > >
> > >2. When the request is authenticated, the requestor SHOULD be able, upon
> > >    request, to have an identifier to be included in the response. How this
> > >    identifier is derived from the authenticated identity depends on local
> > >    server conditions. The server MAY choose to refuse to include an
> > >    identitier in the response.
> > >
> > >Opinions ?
> >
> > I think that the first alternative is too vague to be useful.  I nonce
> > mechanism that might be included to detect reply would fulfill the requirement.
> >
> > I think that the second is acceptable.  I could live with it in order to
> > reach closure, but I do not think that it is necessary.
> 
> 1:
>    Actually Denis has added a new requirement here which is something that
>    I had in mind but forgotten during the other discussions.
> 
>    'a field' could mean 'a textual description identifying the nature or reason
>    of the request/response'.
> 
>    This is not nonce processing, I have some tendency to avoid to encourage
>    people to hide something necessary in a nonce.
> 
> 2:
>    What about:
> 
>    When the request is authenticated, the requestor SHOULD be able, upon
>    request, to indicate an identifier to be included in the response. How this
>    identifier is matched with the authenticated identity depends on local
>    server conditions and/or the validation policy.
>    The server MAY choose to refuse to include an identitier in the response,
>    or MAY refuse to create a response.
> 
> >
> > Russ
> >
> Peter


Received: by above.proper.com (8.11.6/8.11.3) id g3PDIOV23126 for ietf-pkix-bks; Thu, 25 Apr 2002 06:18:24 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDINa23122 for <[e-mail]>; Thu, 25 Apr 2002 06:18:23 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA09154 for <[e-mail]>; Thu, 25 Apr 2002 15:21:14 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042515162755:101 ; Thu, 25 Apr 2002 15:16:27 +0200 
Message-ID: <[e-mail]>
Date: Thu, 25 Apr 2002 15:16:45 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: RFC 3039 changes
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:16:27, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:18:24, Serialize complete at 25/04/2002 15:18:24
Content-Transfer-Encoding: 7bit
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>

At the last IETF meeting Stefan Santesson announced that he wanted to revise
RFC 3039. There was no time to have a discussion during the meeting.

One of the points was to change the text about the exclusion of the DS bit
with the NR bit. I have very strong reservations for any change in that
direction.

The second point was to change the scope of the document to cover
certificates issued to human beings rather than only Qualified Certificates.
When the document was created, the title has been very carefully chosen and
that title should stay as it is. Of course, the names of the extensions
(QC statement) cannot be changed.

Further more, an ETSI TS profiles RFC 3039 and any change to RFC 3039 
(or a removal of RFC 3039) would need to update that TS.

For these reasons, I have strong reservations for issuing a new document
that would obsolete RFC 3039. We need stable documents or otherwise strong
reasons to change documents.


Denis


Received: by above.proper.com (8.11.6/8.11.3) id g3PDH9q23059 for ietf-pkix-bks; Thu, 25 Apr 2002 06:17:09 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDH8a23055 for <[e-mail]>; Thu, 25 Apr 2002 06:17:08 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA16872; Thu, 25 Apr 2002 15:19:54 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042515145189:99 ; Thu, 25 Apr 2002 15:14:51 +0200 
Message-ID: <[e-mail]>
Date: Thu, 25 Apr 2002 15:15:09 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: Michael Myers <[e-mail]>, "'PKIX '" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:14:52, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:17:04, Serialize complete at 25/04/2002 15:17:04
Content-Transfer-Encoding: 7bit
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>

 
> > > DPV REQUIREMENTS
> > > ****************
> > >
> > > Editorial
> > > ---------
> > > "Unless an error is reported, the DPV response MUST
> > > indicate one
> > > of the following two status alternatives:"
> > >
> > > MM3: Change "two" to "three" to reflect {valid, invalid,
> > > unknown}
> > >
> > > [RH] I am having a real problem differentiating
> > > invalid and unknown. To my way of thinking, the
> > > actions taken by a client will be the same in
> > > either case.
> >
> >{valid, invalid, unknown} is the resolution of record and
> >defined in the text.  My comment was just pointing out an
> >editorial wrinkle that needs smoothing out.
> 
> [RH] I agree that a change was made to add the "unknown" response in draft
> -04.  I am not convinced that we did anything useful for the client.  I
> think the client will treat "invalid" and "unknown" exactly the same.

[DP] I do not think that the client will always treat "invalid" and
"unknown" exactly the same. I provide an example:

A client queries a DPV server and gets back "invalid". It does not make
sense for the client to query another DPV server, since the response will
never be "valid".

A client queries a DPV server and gets back "unknown". It makes sense to
query another DPV server, since the response could then either be "valid",
"invalid" or still "unkown".
 
Also "unknown" can be used as a clean way to stop a loop mechanism, when the
same protocol is used between DPV servers.

As said later on in an e-mail sent by Tony:

" Seems you have two choices:

1.  Go with "Trinary Value", in which case the semantics are satisfied by

   a. Success_Valid
   b. Failure_Invalid
   c. Failure_Unknown

2.  Go with "Binary Value", using either

   a. Valid
   b. Invalid (see reason code for details)

   or

   a. Success
   b. Failure (see reason codes for details)"

The two approaches end up with the same result. We did discussed that point
in Minneapolis and we decided to go with a trinary status. This mimics the
three OCSP statuses, although the semantics of the DPV statuses are fully
different.
 
Denis

(text deleted)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PDH8S23054 for ietf-pkix-bks; Thu, 25 Apr 2002 06:17:08 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDH6a23048 for <[e-mail]>; Thu, 25 Apr 2002 06:17:06 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA16874; Thu, 25 Apr 2002 15:19:55 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042515152719:100 ; Thu, 25 Apr 2002 15:15:27 +0200 
Message-ID: <[e-mail]>
Date: Thu, 25 Apr 2002 15:15:45 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: <draft-ietf-pkix-dpv-dpd-req-04.txt>
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:15:27, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:17:05, Serialize complete at 25/04/2002 15:17:05
Content-Transfer-Encoding: 7bit
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>

Peter,

> Here some proposals for a text change.
> 
> >
> > The client can request that the server determine the certificate
> > validity at a time other than the current time. The DPV server MUST
> > obtain revocation status information for the validation time
> > in the client request.
> > In order to obtain the revocation status information of any
> > certificate from the certification path, the DPV server might use, in
> > accordance with the validation policy, different sources of revocation
> > information, e.g. a combination of OCSP responses, CRLs, or delta-CRLs.
> > If the revocation status information for the requested validation time
> > is unavailable, then the DPV server MUST return a status indicating
> > that the certificate is invalid.

> replace by:
> 
> The DPV server MUST produce certificate status information for
> the validation time in the client request. In order to do this,
> the server might use, in accordance with the validation policy,
> different sources of external information concerning revocation
> information, e.g., a combination of OCSP responses, CRLs, or
> delta-CRLs, or other status information from other DPV servers.
> 
> If the certificate status information for the requested validation
> time is cannot be created, then the DPV server MUST return a status
> indicating that the certificate is invalid.

The last sentence you propose is not English. I simply propose to add to the
current sentence: "or a response from another DPV server".

> > The DPV client MUST be able to provide to the validation server,
> > associated with each certificate to be validated, "useful
> > certificates", as well as "useful revocation information". Revocation
> > information includes OCSP responses, CRLs, and delta-CRLs.

> replace by:
> 
> The DPV client MUST be able to provide to the validation server,
> associated with each certificate to be validated, "useful
> certificates", as well as "useful information" e.g., revocation
> information of OCSP responses, CRLs, and delta-CRLs, or status
> information from other DPV servers.

No. If there is one DPV answer, then that answer is self-sufficient and
there is no reason for the client to make another query.

> > The DPV response MUST be bound to the DPV request. This can be
> > accomplished by repeating the important components from the request in
> > the response or by including a one-way hash of the request in the
> > response.

> add:
> 
> In some environments it may be necessary to present only a response
> to another relying party without the corresponding request.
> In this case the response MUST be sufficient self contained.

Accepted.

> > 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
> > (e.g. a badly formatted request, etc.). The certificate from the DPV
> > server SHALL be used to identify the DPV server.
> 
> Replace 'identify' with 'authenticate'.

Accepted. 

Denis

> > another DPV server. Unlike the original client, the DPV server is
> > expected to have moderate computing and memory resources, enabling the
>                    sufficient ???
> 
> ----- End Included Message -----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PDEqX22915 for ietf-pkix-bks; Thu, 25 Apr 2002 06:14:52 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDEpa22911 for <[e-mail]>; Thu, 25 Apr 2002 06:14:51 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA09150; Thu, 25 Apr 2002 15:17:37 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042515142845:98 ; Thu, 25 Apr 2002 15:14:28 +0200 
Message-ID: <[e-mail]>
Date: Thu, 25 Apr 2002 15:14:47 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, "'PKIX '" <[e-mail]>
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:14:28, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:14:47, Serialize complete at 25/04/2002 15:14:47
Content-Transfer-Encoding: 7bit
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>

Michael,

> Russ,
> 
> Will take up the "unknown" thread via Trevor's recent posting.
> Good to hear you interpret the text as I do re: DPD server auth,
> namely there's no prejudice against lower layer mechanisms.
> 
> I'm still though trying to understand what needs policy
> discovery truly addresses.  What might be called the use cases.
> To my way of thinking about this, a client is interested in
> *its* policy or the one or ones it is constrained to use, static
> or otherwise, implicit default or directly signalled in its
> request.  Would a discovery query prove this?  Certainly.  But
> so would an unsupportedPolicy response back from the server.
> 
> I can see that policy discovery could be useful to the
> initialization of a freshly installed client, especially from an
> enterprise perspective, but then there's a trust issue there.  A
> policy discovery function might also be useful in developing an
> Internet-wide profile of which servers do which things, but I'm
> not sure that's the intent.  Or is it?
> 
> As I said, I'm just trying to understand the driver behind the
> discovery piece.  Maybe like the roots issue, I'm overlooking
> something obvious.

The driver is simple: a client is not constrained to use one validation
policy only. Depending of the application, one specific policy may be
required. Before sending a full request, it is just easier to know whether
that policy is supported. Getting at one time all supported policies is
simply an optimisation.

Denis 


> Mike
> 
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> > Sent: Wednesday, April 24, 2002 11:21 AM
> > To: Michael Myers
> > Cc: 'PKIX '
> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> >
> >
> > Mike:
> >
> > > > DPV REQUIREMENTS
> > > > ****************
> > > >
> > > > Editorial
> > > > ---------
> > > > "Unless an error is reported, the DPV response MUST
> > > > indicate one
> > > > of the following two status alternatives:"
> > > >
> > > > MM3: Change "two" to "three" to reflect {valid, invalid,
> > > > unknown}
> > > >
> > > > [RH] I am having a real problem differentiating
> > > > invalid and unknown. To my way of thinking, the
> > > > actions taken by a client will be the same in
> > > > either case.
> > >
> > >{valid, invalid, unknown} is the resolution of record and
> > >defined in the text.  My comment was just pointing out an
> > >editorial wrinkle that needs smoothing out.
> >
> > [RH] I agree that a change was made to add the
> > "unknown" response in draft
> > -04.  I am not convinced that we did anything useful
> > for the client.  I
> > think the client will treat "invalid" and "unknown"
> > exactly the same.
> >
> >
> > > > Signing DPD responses an option
> > > > -------------------------------
> > > > "For the client to be confident that the response
> > originates
> > > > from the expected DPD server, the server MAY provide an
> > > > authenticated response. For example, the server
> > might sign the
> > > > response."
> > > >
> > > > And,
> > > >
> > > > "The DPD server MAY require client
> > authentication, therefore,
> > > > the DPD request MUST be able to be authenticated."
> > > >
> > > > MM14:  Signing is an example, not a requirement, correct?
> > > > Lower-layer security protocols could equally
> > address server auth
> > > > needs.  Suggest appending to the last sentence of
> > the first
> > > > requirement " . . . or the client could invoke a
> > lower-layer
> > > > security protocol that authenticates the server
> > (e.g. TLS)."
> > > > This also folds in well with the MUST regarding
> > support for
> > > > client auth.
> > > >
> > > > [RH] DPV requires signature on the response.  Why
> > not allow
> > > > some consistency?
> > >
> > >I see no needs-based driver for signed DPD responses.  A DPD
> > >server is simply acting as an aggregation point for access to
> > >signed data produced by others.   As I said before,
> > one of the
> > >potential features of DPD over DPV is that a DPD
> > server arguably
> > >need not be trusted in a certification sense while a
> > DPV server
> > >clearly must (assuming of course that server does not combine
> > >both functions).  A non-normative statement that where DPD
> > >server auth is relevant lower layer protocols can
> > suffice would
> > >preserve this quality with no loss of security assurance.
> >
> > [RH] Just rereading the text, I think that the text
> > in draft -04 allows
> > either lower layer mechanisms or signatures within
> > the DPD protocol.  I do
> > not think that there is a need to change anything here.
> >
> >
> > > > POLICY DISCOVERY REQUIREMENT
> > > > ****************************
> > > >
> > > > Thought we got rid of PDP-type requirements
> > > > -------------------------------------------
> > > > "The client MUST be able to obtain references for
> > the default
> > > > policy or for all of the policies supported by
> > the server by
> > > > using an additional request/response pair. The
> > response can
> > > > include references to previously defined policies or
> > > > to a priori
> > > > known policies."
> > > >
> > > > MM15:  I thought we got rid of all PDP-type
> > requirements in this
> > > > DPV/DPD requirements document.  The above text
> > seems to mandate
> > > > that any protocol responsive to this document
> > MUST define a
> > > > request/response pair for policy discovery.
> > > >
> > > > [RH] We want the client to be able to get a list
> > of the policies.
> > > > PDP (in a future document) will address the
> > definition of said
> > > > policies.
> > >
> > >A DPV or DPD server can iterate through its list of policy
> > >definitions and either execute accordingly or send back
> > >unsupportedPolicy.  What's important to the client
> > is that the
> > >server either does or does not support the policy the client
> > >specifies in its request.
> >
> > The requirement says that the client can ask the
> > server for a list of
> > policy identifiers that it is currently supporting.
> > This does not mean
> > that they were dynamically defined policies.
> >
> > Russ
> >
> 
> Mike


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PDELc22892 for ietf-pkix-bks; Thu, 25 Apr 2002 06:14:21 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDEKa22888 for <[e-mail]>; Thu, 25 Apr 2002 06:14:20 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA19762; Thu, 25 Apr 2002 15:16:50 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042515135867:97 ; Thu, 25 Apr 2002 15:13:58 +0200 
Message-ID: <[e-mail]>
Date: Thu, 25 Apr 2002 15:14:17 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: Peter Gutmann <[e-mail]>, [e-mail], [e-mail]
Subject: Re: roadmap
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:13:58, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:14:01, Serialize complete at 25/04/2002 15:14:01
Content-Transfer-Encoding: 7bit
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>

Michael,

> Peter,
> 
> v2's status mostly tracks that of the DPV and DPD requirements,
> which have only recently settled down after about a year's worth
> of effort.  

OCSP *cannot* be the right vector to support DPV requirements since the role
of a CA is different from the role of a DPV server: a CA is only responsible
for the certificates that it has issued. A DPV server can be any entity
provided that it supports the appropriate validation policy which is *not*
established by a CA. As another argument: having at the same time in the
same response both a *single* OSCP response and a DPV response would be
quite odd. The DPV response provides information which would make the
*single* OCSP response useless. However the DPV response may include
*several* OCSP responses *and* the full certification path, if requested by
the client.

So my request is the same as made on the mailing list: RFC250bis should only
be updated to allow to specify a certificate using additional ways. OCSPv2
should be discontinued or at least the name "OCSPv2" dropped. This does not
mean that some ideas from that protocol cannot be re-used to fit with the
DPV requirements.

However, this discussion is not directly related to the roadmap. ;-)

Denis

> As I said before, it didn't make much sense to track
> that moving target with incremental I-Ds.  I once had three
> separate I-Ds but that got so hard to manage and work due to
> syntatic and editorial overlap (not to mention review) that I
> put them all in one.  I prefer to keep that structure together
> while we see how things shake out re: DPV/DPD.  Since 2560bis is
> pretty well on its way, I think we should let that go forward
> cleanly rather than force a reset due to adding new syntax.
> 
> Mike
> 
> Michael Myers
> t: +415.819.1362
> e: mailto:[e-mail]
> w: http://www.traceroutesecurity.com
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of
> > Peter Gutmann
> > Sent: Tuesday, April 23, 2002 8:33 PM
> > To: [e-mail]
> > Cc: [e-mail]
> > Subject: Re: roadmap
> >
> >
> >
> > Peter Sylvester <[e-mail]> writes:
> >
> > >Thus, it is not just a question of whether OCSP v2
> > being alive or not.
> >
> > Can I also add a general complaint about the vague
> > status of OCSPv2, there's
> > already software deployed which uses the extended
> > range of cert IDs in the v2
> > draft, which makes it annoying to have it fading in
> > and out of consciousness
> > every few months.  Perhaps the new cert IDs (which
> > are a trivial change) could
> > be moved into 2560-bis, without requiring all the
> > extra stuff which was added
> > in the rest of the v2 draft.
> >
> > Peter.
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3PDDIM22840 for ietf-pkix-bks; Thu, 25 Apr 2002 06:13:18 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDD9a22828 for <[e-mail]>; Thu, 25 Apr 2002 06:13:09 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA13390; Thu, 25 Apr 2002 15:15:50 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042515105778:95 ; Thu, 25 Apr 2002 15:10:57 +0200 
Message-ID: <[e-mail]>
Date: Thu, 25 Apr 2002 15:11:16 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Hal Lockhart <[e-mail]>
CC: "'Michael Myers'" <[e-mail]>, [e-mail], pkix <[e-mail]>
Subject: Re: Open issue: DPV additional information
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:10:57, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:13:00, Serialize complete at 25/04/2002 15:13:00
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3PDDAa22831
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>

Hal,

> Hal Lockhart a écrit :
> 
> As entertaining as it is to watch you guys talk past each other, this
> thread is getting tiresome. Let me take a crack at why I don't think there
> is any real disagreement here.
> 
> I think what Denis is saying is that if an entity is a CA, by definition
> they are trusted to issue and revoke the certificates they issue, by
> virture of being a CA. They can also delegate someone else to do the
> revocation, also by virtue of being a CA. If a RP decides to trust their
> certs, they must also trust their revocation arrangements.
> 
> In contrast, when somebody sets up a DPV server, whether or not they also
> run a CA, there is an independant decision to trust the DPV server. It
> does not follow as an automatic consequence of the fact thet the same
> organization (or key even) may have issued one or more of the certs in the
> chain in question.
> 
> In other words, a CA may run a DPV server, but the server will be trusted
> because RPs choose to do so, not because they have previously chosen to
> trust certs issued by the CA.
 
> Everybody agree? ;-)

In other words, an organisation supporting a CA may also run a DPV server,
but the DPV server will be trusted because RPs choose to do so, not because
RPS have previously chosen to trust certs issued by the CA hosted by the
same organization.

Denis

> 
> Hal
> 
> > -----Original Message-----
> > From: Michael Myers [mailto:[e-mail]]
> > Sent: Wednesday, April 17, 2002 11:22 AM
> > To: Denis Pinkas; [e-mail]
> > Cc: pkix
> > Subject: RE: Open issue: DPV additional information
> >
> >
> >
> > Denis,
> >
> > It is precisely that issue of responsibility, in a broader
> > sense.  I'm quite certain that organizational entities who
> > create, issue and maintain the reliability of public key
> > certificates will will be the first to claim jursidiction
> > regarding their validity. Who is going to claim otherwise?
> >
> > Mike
> >
> >
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[e-mail]]
> > > Sent: Wednesday, April 17, 2002 8:02 AM
> > > > Extract from the road map document:
> > >
> > > Certification Authority (CA) - An authority
> > > trusted by one or more users to create and assign
> > > public key certificates. Optionally the CA may
> > > create the user's keys. It is important to
> > > note that the CA is responsible for the public key
> >                       ^^^^^^^^^^^^^^^
> > > certificates during their whole lifetime, not just
> > > for issuing them.
> >


Received: by above.proper.com (8.11.6/8.11.3) id g3PDDBF22836 for ietf-pkix-bks; Thu, 25 Apr 2002 06:13:11 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDD9a22829 for <[e-mail]>; Thu, 25 Apr 2002 06:13:09 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA13396; Thu, 25 Apr 2002 15:15:52 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042515121941:96 ; Thu, 25 Apr 2002 15:12:19 +0200 
Message-ID: <[e-mail]>
Date: Thu, 25 Apr 2002 15:12:38 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Open issue: DPV additional information
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:12:19, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:13:04, Serialize complete at 25/04/2002 15:13:04
Content-Transfer-Encoding: 7bit
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>

> Providing that Denis and Russ both agree the DPV requirements entail 
> the following matter (informally expressed), I am happy to proceed, 
> on this issue:
 
> Without prejudice to other modes of operation, 
> a DPV server can use an OCSP response issued by an OCSP
> responder that is locally trusted by the DPV client through a validation
> policy rule) 

An "OCSP responder that is locally trusted by the DPV client through a
validation policy rule" does not make sense. An OCSP responder can be
trusted under a given validation policy. If an OCSP responder is locally
trusted by a client, then the DPV server is unaware of it.

In the chain of trust: a validation policy does not know who the clients are
and it is a validation policy issuer that defines which OCSP responders are
trusted, not the clients. It is up to the clients to query DPV servers they
trust and then they will accept whatever is defined in the validation
policy.   

Denis

> and that the DPV server will accept the OCSP response on the
> client's behalf in a manner conforming to the rules of OCSP standard.
 
> Given every opportunity to confirm this entailment, todate, Denis
> has not done so. With confirmation, we can proceed.


Received: by above.proper.com (8.11.6/8.11.3) id g3PDD5P22826 for ietf-pkix-bks; Thu, 25 Apr 2002 06:13:05 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3PDD3a22819 for <[e-mail]>; Thu, 25 Apr 2002 06:13:03 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA13386; Thu, 25 Apr 2002 15:15:46 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002042515101248:94 ; Thu, 25 Apr 2002 15:10:12 +0200 
Message-ID: <[e-mail]>
Date: Thu, 25 Apr 2002 15:10:31 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail], pkix <[e-mail]>
Subject: Re: Open issue: DPV additional information
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:10:12, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 25/04/2002 15:12:56, Serialize complete at 25/04/2002 15:12:56
Content-Transfer-Encoding: 7bit
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>

Michael,

> Denis,
 
> It is precisely that issue of responsibility, in a broader
> sense.  I'm quite certain that organizational entities who
> create, issue and maintain the reliability of public key
> certificates will will be the first to claim jursidiction
> regarding their validity. Who is going to claim otherwise?

Let me provide you with an example:

Avis Rent a Car (TM) is wishing to accept tourist car reservations using
public key certificates in France. Avis Rent a Car (TM) will define the 
"Avis Rent a Car (TM) reservation policy in France for tourism vehicules" 
and state that under this policy Microsoft certificates class X, Verisign
Certificates Class Y and Debis certificates Class Z are adequate. Microsoft,
Verisign and Debis as CAs, are fully ignorant which applications are making
use of their certificates.

There needs not be any relationship between validation policy issuers and
CAs.

Validation policy issuers will pick up in their validation policies which
CAs are appropriate.

Denis

 
> Mike
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, April 17, 2002 8:02 AM
> > > Extract from the road map document:
> >
> > Certification Authority (CA) - An authority
> > trusted by one or more users to create and assign
> > public key certificates. Optionally the CA may
> > create the user's keys. It is important to
> > note that the CA is responsible for the public key
>                       ^^^^^^^^^^^^^^^
> > certificates during their whole lifetime, not just
> > for issuing them.


Received: by above.proper.com (8.11.6/8.11.3) id g3PBHcm19460 for ietf-pkix-bks; Thu, 25 Apr 2002 04:17:38 -0700 (PDT)
Received: from web20507.mail.yahoo.com (web20507.mail.yahoo.com [216.136.226.142]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3PBHba19455 for <[e-mail]>; Thu, 25 Apr 2002 04:17:37 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [203.2.208.130] by web20507.mail.yahoo.com via HTTP; Thu, 25 Apr 2002 04:17:37 PDT
Date: Thu, 25 Apr 2002 04:17:37 -0700 (PDT)
From: Eve Chow <[e-mail]>
Subject: code signing
To: [e-mail]
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>

Dear all , 

I found different code signing cert available in the
Verisign site - some for MS Authenticode , some for
Netscape object signing  , VBA macro / Macromedia
flash - are there any difference in the certificate
format for different siged object ? 

While I know the signing method for Authenticode and
netscape object signing is different , I am not sure
if there is standard for the other objects . If anyone
know any reference on this please recommend , thanks !


Eve Chow





=====
Eve Chow

1# Rule of Thumb : 
Something really BAD will come up if nothing is WRONG throughout the project

__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3P35io02919 for ietf-pkix-bks; Wed, 24 Apr 2002 20:05:44 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3P35ha02914 for <[e-mail]>; Wed, 24 Apr 2002 20:05:43 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3P35hTt013522; Wed, 24 Apr 2002 20:05:44 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Tony Bartoletti" <[e-mail]>, "Trevor Freeman" <[e-mail]>, "PKIX " <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Wed, 24 Apr 2002 20:02:51 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Tony Bartoletti
> Sent: Wednesday, April 24, 2002 7:58 PM
>
> . . .
>
> The "Server-side" argument for trinary response (not
> wanting to pronounce a certificate "invalid" given
> lack of information or authority) seems satisfied by
> Trevor's Success/Failure terminology, correct?
>
> Cheers!


Hi Tony,

I must respectfully disagree for reasons previously cited
pending a convincing needs-based argument.  Else perhaps what
we're really backing ourselves into is a variation of if not
precisely the semantics of Peter Gutman's OCSP-based certOK
mechanism.

Mike





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3P2oV102645 for ietf-pkix-bks; Wed, 24 Apr 2002 19:50:31 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3P2oUa02641 for <[e-mail]>; Wed, 24 Apr 2002 19:50:30 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3P2oVTt012442; Wed, 24 Apr 2002 19:50:31 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Peter Williams" <[e-mail]>, "PKIX" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Wed, 24 Apr 2002 19:47:39 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Peter,

See below.

Mike


> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 6:51 PM
> To: 'Michael Myers'; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
>
> Mike,
>
> (1) Can you provide a citation or other professional
> reference for the "precise technical meanings" of "valid" and
> "invalid", please?

Which of the following do you believe should be eliminated from
such a definition:

1. Formation of a valid path IAW 2459;

2. Confirmation of revocation status for each
   certificate in said path;

3. Cryptographic validation of said path IAW 2459.

4. Other practices as required by policy.

> (2) Could you also perhaps help me compare
> the definition(s) of "valid" used in the
> VeriSign CPs (1.2 and 2.0)and the US DOD CP v2 (March
> 1999), perhaps, against the recognised
> definition of "valid" (see above (1))?

Nope.  Go for it.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3P1pFq01596 for ietf-pkix-bks; Wed, 24 Apr 2002 18:51:15 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3P1pEa01592 for <[e-mail]>; Wed, 24 Apr 2002 18:51:14 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 24 Apr 2002 18:48:05 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 24 Apr 2002 18:48:04 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <JQL5ASBW>; Wed, 24 Apr 2002 18:51:07 -0700
Content-return: allowed
Date: Wed, 24 Apr 2002 18:51:06 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
To: "'Michael Myers'" <[e-mail]>, PKIX <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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>

Mike,

(1) Can you provide a citation or other professional
reference for the "precise technical meanings" of "valid" and
"invalid", please?


(2) Could you also perhaps help me compare
the definition(s) of "valid" used in the 
VeriSign CPs (1.2 and 2.0)and the US DOD CP v2 (March 
1999), perhaps, against the recognised
definition of "valid" (see above (1))?

In my reading, the two policies seem
to offer very different notions of validity:



(a1) VeriSign CPS 1.2 (that was effective during issuing of 
many intermediate CA certs:)

"CERTIFICATE MANAGEMENT
Certificate management includes, but is not limited to storage, 
dissemination, publication, revocation, and suspension of certificates. 
An IA undertakes certificate management functions by serving as a 
registration authority for subscriber certificates. An IA designates 
issued and accepted certificates as valid by publication.

VALID CERTIFICATE
A certificate issued by an IA and accepted by the subscriber listed in it.

VALIDATE A CERTIFICATE (i.e., of an END-USER SUBSCRIBER CERTIFICATE) 
The process performed by a recipient or relying party to confirm that 
an end-user subscriber certificate is valid and was operational at the 
date and time a pertinent digital signature was created.

VALIDATE A CERTIFICATE CHAIN 
For each certificate in a chain, the process performed by the recipient 
or relying party to authenticate the public key (in each certificate),
confirm 
that each certificate is valid, was issued within the operational period of 
the corresponding IA certificate, and that all parties (IAs, end-user 
subscribers, recipients, and relying parties) have operated in accordance 
with this CPS as to all certificates in the chain."

(a2) CPS 2.0 - currently effective:

This CPS avoids use of the term valid (in respect of certificate)
altogether:


"Relying Party Agreements also require Relying Parties to check the 
status of a Certificate on which they wish to rely, as well as all the 
Certificates in its Certificate Chain in accordance with CPS ?? 4.4.10, 
4.4.12.  If any of the Certificates in the Certificate Chain have been 
revoked, according to Relying Party Agreements, the Relying Party must 
not rely on the end-user Subscriber Certificate or other revoked Certificate
in the Certificate Chain. 


(b) DoD CP v2.0

"2.1.4	Relying party obligations

check each certificate for validity, using procedures described in the X.509

standard, and prior to reliance."

"The authorized source for information concerning the 
validity of a certificate shall be the revocation mechanism 
provided by the CA as defined in its CPS."

But note that validity is fungible in DoD CP (and a DOD
validation policy by construction)

"CA termination will be handled in accordance with section 4.8 
above. If the termination is for convenience, contract expiration, 
re-organization, or other non-security related reason, then 
certificates may continue to be considered valid at the 
discretion of the program or relying party (who has been made 
aware of the termination)."

>>>>-----Original Message-----
>>>>From: Michael Myers [mailto:[e-mail]]
>>>>Sent: Wednesday, April 24, 2002 5:44 PM
>>>>To: Trevor Freeman; PKIX
>>>>Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>>>>
>>>>
>>>>
>>>>Trevor,
>>>>
>>>>No, what I'm saying is that valid and invalid have precise
>>>>technical meanings that could be potentially relevant to an
>>>>arbitration panel if not a court of law. 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3P1krK01491 for ietf-pkix-bks; Wed, 24 Apr 2002 18:46:53 -0700 (PDT)
Received: from smtp-2.llnl.gov (smtp-2.llnl.gov [128.115.250.82]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3P1kqa01487 for <[e-mail]>; Wed, 24 Apr 2002 18:46:52 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-2.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id SAA15640; Wed, 24 Apr 2002 18:46:40 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id SAA17360; Wed, 24 Apr 2002 18:46:50 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 24 Apr 2002 18:58:17 -0800
To: "Michael Myers" <[e-mail]>, "Trevor Freeman" <[e-mail]>, "PKIX " <[e-mail]>
From: Tony Bartoletti <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
In-Reply-To: <[e-mail]>
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>

Seems you have two choices:

1.  Go with "Trinary Value", in which case the semantics are satisfied by

   a. Success_Valid
   b. Failure_Invalid
   c. Failure_Unknown

2.  Go with "Binary Value", using either

   a. Valid
   b. Invalid (see reason code for details)

   or

   a. Success
   b. Failure (see reason codes for details)

 From a state-machine point of view, even the latter choices are workable, 
ASSUMING that the indicated reason-codes are "reasonably 
standardized".  The only "client-side-reason" I can see for this 3-valued 
(or n-valued) response would be a case of clientware capable of 
automatically seeking a "second opinion" from another source, where the 
trinary "unknown" is returned (or the reason-code associated with the 
binary response indicates a possible transient lack of information.)

The "Server-side" argument for trinary response (not wanting to pronounce a 
certificate "invalid" given lack of information or authority) seems 
satisfied by Trevor's Success/Failure terminology, correct?

Cheers!

____tony____

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900



At 06:17 PM 4/24/02 -0700, Michael Myers wrote:

>Trevor,
>
>It is my firm belief that at a meta level we are faced
>fundamentally with a trinary valued state variable.  I've yet to
>hear a needs-based argument that dissuades me from that
>conviction.  Maybe we should discuss offlist and spare the WG
>further chatter.  My contact info is below.
>
>Mike
>
>Michael Myers
>t: +415.819.1362
>e: mailto:[e-mail]
>w: http://www.traceroutesecurity.com
>
>
>
>
>
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[e-mail]]
> > Sent: Wednesday, April 24, 2002 6:00 PM
> > To: Michael Myers; PKIX
> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> >
> >
> > Michael,
> > Success and failure have precise technical meaning.
> > The client is asking
> > either "can you validate this certificate" or "can
> > you build a path with
> > this certificate" The server can succeed in that task
> > - which implies
> > the certificate is valid or the server build a path,
> > or the server
> > failed. Using these semantics, failure to comply with
> > the clients
> > request on the server's part implies nothing about
> > the certificate only
> > about the server ability, but retains a binary
> > response which is simple
> > for the client to process.
> > We can add specific reasons for the failure in the
> > protocol document
> > which allow the server to express whatever it wants about its
> > inadequacies.
> > Is that OK for now?
> >
> > Trevor
> >
> > -----Original Message-----
> > From: Michael Myers [mailto:[e-mail]]
> > Sent: Wednesday, April 24, 2002 5:44 PM
> > To: Trevor Freeman; PKIX
> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> >
> > Trevor,
> >
> > No, what I'm saying is that valid and invalid have precise
> > technical meanings that could be potentially relevant to an
> > arbitration panel if not a court of law.  The unknown state
> > affords a service provider or enterprise deploying a
> > server the
> > means to escape out of binding itself into a situation that
> > could possibly put it at financial risk.
> >
> > I could be totally wrong in that perception, but that's what I
> > think.  Several years ago it was just crypto and toolkits.
> > Today there's laws and regulations and jurisdictional forums
> > considering how this technology applies to societal
> > factors.  I
> > for one think we need to be responsible in this regard.
> >
> > Else maybe what you're talking about is more aligned
> > with Peter
> > Gutman's certOK proposal.
> >
> > Mike
> >
> >
> >
> > Michael Myers
> > t: +415.819.1362
> > e: mailto:[e-mail]
> > w: http://www.traceroutesecurity.com
> >
> > > -----Original Message-----
> > > From: Trevor Freeman [mailto:[e-mail]]
> > > Sent: Wednesday, April 24, 2002 4:44 PM
> > > To: Michael Myers; PKIX
> > > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> > >
> > >
> > > Mike,
> > > All you are saying is that the server needs to
> > > clarity the reason for
> > > the inability to validate the certificate. You
> > > objection seems to be
> > > wording of the return state in the requirement
> > > document implying more
> > > than is intended. Rather that naming them in the
> > > requirements document
> > > valid and invalid, we can name them success and
> > > failure. Success means
> > > the server was able to complete the client request,
> > > and failure means it
> > > did not.
> > >
> > > Trevor
> > > -----Original Message-----
> > > From: Michael Myers [mailto:[e-mail]]
> > > Sent: Wednesday, April 24, 2002 3:54 PM
> > > To: Trevor Freeman; PKIX
> > > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> > >
> > > Trevor,
> > >
> > > I agree with you and Russ that from a state machine
> > > perspective,
> > > a client will probably take the same action in both
> > > the unknown
> > > and invalid cases.  However, from a server, or more
> > > importantly
> > > a service perspective, I suspect there exists an appreciable
> > > semantic difference  in a legal or liability sense
> > > between these
> > > two states.
> > >
> > > I've had the pleasure over the past few years of abundant
> > > exposure to lawyers, bankers, regulators and other
> > such types
> > > regarding these and related issues.  I'm sure many
> > of us share
> > > that experience in one form or another.
> > >
> > > Now, I'm no lawyer but given that exposure it seems
> > > to me that a
> > > service (i.e. that which runs a server) is setting
> > > itself up for
> > > disaster by asserting a digitally signed "invalid"
> > > when in point
> > > of fact that service hasn't the data, jurisdiction or
> > > delegation
> > > to make such an unequivocal assertion.
> > >
> > > As a hypothetical, consider a party seeking damages
> > > to which an
> > > invalid assertion is useful as evidence even though the
> > > certificate in question is provably valid given
> > access to the
> > > relevant data.  That plaintiff could arguably find
> > > some service
> > > that doesn't know diddly about the certificate to issue a
> > > digitally signed "invalid" and there you go.  That
> > > TTP may have
> > > just stuck its neck out.
> > >
> > > I know that's probably a stretch, but not
> > inconceivable given
> > > some the purposes to which certs and sigs are today being
> > > applied.  Better it seems by far to enable an "out"
> > > via unknown
> > > even if at the other end, the client does nothing
> > differently.
> > >
> > > Valid and Invalid mean something very precise to my way of
> > > thinking.  It means data was accumulated, a path was
> > > successfully constructed, revocation information was
> > > checked and
> > > the entire dataset checked according to 2459 and
> > whatever else
> > > might specified by the policy in place at the time
> > between the
> > > client and the server/service.  Break any one of those
> > > assumptions and one can't assert invalid.  Hence we need
> > > unknown.
> > >
> > > Mike
> > >
> > >
> > > > -----Original Message-----
> > > > From: Trevor Freeman
>[mailto:[e-mail]]
> > > Sent: Wednesday, April 24, 2002 11:33 AM
> > > To: Michael Myers; PKIX
> > > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> > >
> > >
> > > Mike,
> > > I realise there has been several mailing on this
> > > topic, but so far no
> > > consensus.
> > > Apart form references to 2560, I have not seen much
> > > in the way of
> > > reasoned justification as to why we need another
> > > return code in DPV/DPD.
> > > All this additional return value is indicating is
> > > some kind of failure
> > > on the part of the server. We have defined the
> > requirement for
> > > additional information on the error to be returned by
> > > the server to
> > > clarify the nature of the failure to the client. If
> > > you want to refine
> > > the defined list of sub-status reasons when we get to
> > > define the
> > > protocol then I am sure we can debate this more
> > > meaningfully then.
> > > However since one of the goals of the DPV protocol is
> > > to address
> > > constrained clients, then we have to be hard core on
> > > not complication
> > > the protocol.
> > >
> > > Trevor
> >
> >

Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3P1KYM00992 for ietf-pkix-bks; Wed, 24 Apr 2002 18:20:34 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3P1KWa00988 for <[e-mail]>; Wed, 24 Apr 2002 18:20:32 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3P1KXTt006178; Wed, 24 Apr 2002 18:20:33 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, "PKIX " <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Wed, 24 Apr 2002 18:17:40 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Trevor,

It is my firm belief that at a meta level we are faced
fundamentally with a trinary valued state variable.  I've yet to
hear a needs-based argument that dissuades me from that
conviction.  Maybe we should discuss offlist and spare the WG
further chatter.  My contact info is below.

Mike

Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com





> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 6:00 PM
> To: Michael Myers; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
> Michael,
> Success and failure have precise technical meaning.
> The client is asking
> either "can you validate this certificate" or "can
> you build a path with
> this certificate" The server can succeed in that task
> - which implies
> the certificate is valid or the server build a path,
> or the server
> failed. Using these semantics, failure to comply with
> the clients
> request on the server's part implies nothing about
> the certificate only
> about the server ability, but retains a binary
> response which is simple
> for the client to process.
> We can add specific reasons for the failure in the
> protocol document
> which allow the server to express whatever it wants about its
> inadequacies.
> Is that OK for now?
>
> Trevor
>
> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 5:44 PM
> To: Trevor Freeman; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
> Trevor,
>
> No, what I'm saying is that valid and invalid have precise
> technical meanings that could be potentially relevant to an
> arbitration panel if not a court of law.  The unknown state
> affords a service provider or enterprise deploying a
> server the
> means to escape out of binding itself into a situation that
> could possibly put it at financial risk.
>
> I could be totally wrong in that perception, but that's what I
> think.  Several years ago it was just crypto and toolkits.
> Today there's laws and regulations and jurisdictional forums
> considering how this technology applies to societal
> factors.  I
> for one think we need to be responsible in this regard.
>
> Else maybe what you're talking about is more aligned
> with Peter
> Gutman's certOK proposal.
>
> Mike
>
>
>
> Michael Myers
> t: +415.819.1362
> e: mailto:[e-mail]
> w: http://www.traceroutesecurity.com
>
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[e-mail]]
> > Sent: Wednesday, April 24, 2002 4:44 PM
> > To: Michael Myers; PKIX
> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> >
> >
> > Mike,
> > All you are saying is that the server needs to
> > clarity the reason for
> > the inability to validate the certificate. You
> > objection seems to be
> > wording of the return state in the requirement
> > document implying more
> > than is intended. Rather that naming them in the
> > requirements document
> > valid and invalid, we can name them success and
> > failure. Success means
> > the server was able to complete the client request,
> > and failure means it
> > did not.
> >
> > Trevor
> > -----Original Message-----
> > From: Michael Myers [mailto:[e-mail]]
> > Sent: Wednesday, April 24, 2002 3:54 PM
> > To: Trevor Freeman; PKIX
> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> >
> > Trevor,
> >
> > I agree with you and Russ that from a state machine
> > perspective,
> > a client will probably take the same action in both
> > the unknown
> > and invalid cases.  However, from a server, or more
> > importantly
> > a service perspective, I suspect there exists an appreciable
> > semantic difference  in a legal or liability sense
> > between these
> > two states.
> >
> > I've had the pleasure over the past few years of abundant
> > exposure to lawyers, bankers, regulators and other
> such types
> > regarding these and related issues.  I'm sure many
> of us share
> > that experience in one form or another.
> >
> > Now, I'm no lawyer but given that exposure it seems
> > to me that a
> > service (i.e. that which runs a server) is setting
> > itself up for
> > disaster by asserting a digitally signed "invalid"
> > when in point
> > of fact that service hasn't the data, jurisdiction or
> > delegation
> > to make such an unequivocal assertion.
> >
> > As a hypothetical, consider a party seeking damages
> > to which an
> > invalid assertion is useful as evidence even though the
> > certificate in question is provably valid given
> access to the
> > relevant data.  That plaintiff could arguably find
> > some service
> > that doesn't know diddly about the certificate to issue a
> > digitally signed "invalid" and there you go.  That
> > TTP may have
> > just stuck its neck out.
> >
> > I know that's probably a stretch, but not
> inconceivable given
> > some the purposes to which certs and sigs are today being
> > applied.  Better it seems by far to enable an "out"
> > via unknown
> > even if at the other end, the client does nothing
> differently.
> >
> > Valid and Invalid mean something very precise to my way of
> > thinking.  It means data was accumulated, a path was
> > successfully constructed, revocation information was
> > checked and
> > the entire dataset checked according to 2459 and
> whatever else
> > might specified by the policy in place at the time
> between the
> > client and the server/service.  Break any one of those
> > assumptions and one can't assert invalid.  Hence we need
> > unknown.
> >
> > Mike
> >
> >
> > > -----Original Message-----
> > > From: Trevor Freeman
[mailto:[e-mail]]
> > Sent: Wednesday, April 24, 2002 11:33 AM
> > To: Michael Myers; PKIX
> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> >
> >
> > Mike,
> > I realise there has been several mailing on this
> > topic, but so far no
> > consensus.
> > Apart form references to 2560, I have not seen much
> > in the way of
> > reasoned justification as to why we need another
> > return code in DPV/DPD.
> > All this additional return value is indicating is
> > some kind of failure
> > on the part of the server. We have defined the
> requirement for
> > additional information on the error to be returned by
> > the server to
> > clarify the nature of the failure to the client. If
> > you want to refine
> > the defined list of sub-status reasons when we get to
> > define the
> > protocol then I am sure we can debate this more
> > meaningfully then.
> > However since one of the goals of the DPV protocol is
> > to address
> > constrained clients, then we have to be hard core on
> > not complication
> > the protocol.
> >
> > Trevor
>
>




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3P13h800632 for ietf-pkix-bks; Wed, 24 Apr 2002 18:03:43 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3P13fa00628 for <[e-mail]>; Wed, 24 Apr 2002 18:03:41 -0700 (PDT)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Apr 2002 18:03:40 -0700
Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Apr 2002 18:03:40 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Apr 2002 18:03:39 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Apr 2002 18:03:39 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Wed, 24 Apr 2002 17:59:53 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Wed, 24 Apr 2002 17:59:52 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Thread-Index: AcHr8jddH5rhauP3RsS84FDdK/UNmwAAKfFA
From: "Trevor Freeman" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "PKIX " <[e-mail]>
X-OriginalArrivalTime: 25 Apr 2002 00:59:53.0202 (UTC) FILETIME=[82331D20:01C1EBF4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3P13ga00629
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>

Michael,
Success and failure have precise technical meaning. The client is asking
either "can you validate this certificate" or "can you build a path with
this certificate" The server can succeed in that task - which implies
the certificate is valid or the server build a path, or the server
failed. Using these semantics, failure to comply with the clients
request on the server's part implies nothing about the certificate only
about the server ability, but retains a binary response which is simple
for the client to process.
We can add specific reasons for the failure in the protocol document
which allow the server to express whatever it wants about its
inadequacies.
Is that OK for now?

Trevor

-----Original Message-----
From: Michael Myers [mailto:[e-mail]] 
Sent: Wednesday, April 24, 2002 5:44 PM
To: Trevor Freeman; PKIX 
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt

Trevor,

No, what I'm saying is that valid and invalid have precise
technical meanings that could be potentially relevant to an
arbitration panel if not a court of law.  The unknown state
affords a service provider or enterprise deploying a server the
means to escape out of binding itself into a situation that
could possibly put it at financial risk.

I could be totally wrong in that perception, but that's what I
think.  Several years ago it was just crypto and toolkits.
Today there's laws and regulations and jurisdictional forums
considering how this technology applies to societal factors.  I
for one think we need to be responsible in this regard.

Else maybe what you're talking about is more aligned with Peter
Gutman's certOK proposal.

Mike



Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com

> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 4:44 PM
> To: Michael Myers; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
> Mike,
> All you are saying is that the server needs to
> clarity the reason for
> the inability to validate the certificate. You
> objection seems to be
> wording of the return state in the requirement
> document implying more
> than is intended. Rather that naming them in the
> requirements document
> valid and invalid, we can name them success and
> failure. Success means
> the server was able to complete the client request,
> and failure means it
> did not.
>
> Trevor
> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 3:54 PM
> To: Trevor Freeman; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
> Trevor,
>
> I agree with you and Russ that from a state machine
> perspective,
> a client will probably take the same action in both
> the unknown
> and invalid cases.  However, from a server, or more
> importantly
> a service perspective, I suspect there exists an appreciable
> semantic difference  in a legal or liability sense
> between these
> two states.
>
> I've had the pleasure over the past few years of abundant
> exposure to lawyers, bankers, regulators and other such types
> regarding these and related issues.  I'm sure many of us share
> that experience in one form or another.
>
> Now, I'm no lawyer but given that exposure it seems
> to me that a
> service (i.e. that which runs a server) is setting
> itself up for
> disaster by asserting a digitally signed "invalid"
> when in point
> of fact that service hasn't the data, jurisdiction or
> delegation
> to make such an unequivocal assertion.
>
> As a hypothetical, consider a party seeking damages
> to which an
> invalid assertion is useful as evidence even though the
> certificate in question is provably valid given access to the
> relevant data.  That plaintiff could arguably find
> some service
> that doesn't know diddly about the certificate to issue a
> digitally signed "invalid" and there you go.  That
> TTP may have
> just stuck its neck out.
>
> I know that's probably a stretch, but not inconceivable given
> some the purposes to which certs and sigs are today being
> applied.  Better it seems by far to enable an "out"
> via unknown
> even if at the other end, the client does nothing differently.
>
> Valid and Invalid mean something very precise to my way of
> thinking.  It means data was accumulated, a path was
> successfully constructed, revocation information was
> checked and
> the entire dataset checked according to 2459 and whatever else
> might specified by the policy in place at the time between the
> client and the server/service.  Break any one of those
> assumptions and one can't assert invalid.  Hence we need
> unknown.
>
> Mike
>
>
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[e-mail]]
> > Sent: Wednesday, April 24, 2002 11:33 AM
> > To: Michael Myers; PKIX
> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> >
> >
> > Mike,
> > I realise there has been several mailing on this
> > topic, but so far no
> > consensus.
> > Apart form references to 2560, I have not seen much
> > in the way of
> > reasoned justification as to why we need another
> > return code in DPV/DPD.
> > All this additional return value is indicating is
> > some kind of failure
> > on the part of the server. We have defined the
> requirement for
> > additional information on the error to be returned by
> > the server to
> > clarify the nature of the failure to the client. If
> > you want to refine
> > the defined list of sub-status reasons when we get to
> > define the
> > protocol then I am sure we can debate this more
> > meaningfully then.
> > However since one of the goals of the DPV protocol is
> > to address
> > constrained clients, then we have to be hard core on
> > not complication
> > the protocol.
> >
> > Trevor
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3P0l2l29963 for ietf-pkix-bks; Wed, 24 Apr 2002 17:47:02 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3P0l1a29959 for <[e-mail]>; Wed, 24 Apr 2002 17:47:01 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3P0l2Tt003811; Wed, 24 Apr 2002 17:47:02 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, "PKIX " <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Wed, 24 Apr 2002 17:44:09 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Trevor,

No, what I'm saying is that valid and invalid have precise
technical meanings that could be potentially relevant to an
arbitration panel if not a court of law.  The unknown state
affords a service provider or enterprise deploying a server the
means to escape out of binding itself into a situation that
could possibly put it at financial risk.

I could be totally wrong in that perception, but that's what I
think.  Several years ago it was just crypto and toolkits.
Today there's laws and regulations and jurisdictional forums
considering how this technology applies to societal factors.  I
for one think we need to be responsible in this regard.

Else maybe what you're talking about is more aligned with Peter
Gutman's certOK proposal.

Mike



Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com

> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 4:44 PM
> To: Michael Myers; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
> Mike,
> All you are saying is that the server needs to
> clarity the reason for
> the inability to validate the certificate. You
> objection seems to be
> wording of the return state in the requirement
> document implying more
> than is intended. Rather that naming them in the
> requirements document
> valid and invalid, we can name them success and
> failure. Success means
> the server was able to complete the client request,
> and failure means it
> did not.
>
> Trevor
> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 3:54 PM
> To: Trevor Freeman; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
> Trevor,
>
> I agree with you and Russ that from a state machine
> perspective,
> a client will probably take the same action in both
> the unknown
> and invalid cases.  However, from a server, or more
> importantly
> a service perspective, I suspect there exists an appreciable
> semantic difference  in a legal or liability sense
> between these
> two states.
>
> I've had the pleasure over the past few years of abundant
> exposure to lawyers, bankers, regulators and other such types
> regarding these and related issues.  I'm sure many of us share
> that experience in one form or another.
>
> Now, I'm no lawyer but given that exposure it seems
> to me that a
> service (i.e. that which runs a server) is setting
> itself up for
> disaster by asserting a digitally signed "invalid"
> when in point
> of fact that service hasn't the data, jurisdiction or
> delegation
> to make such an unequivocal assertion.
>
> As a hypothetical, consider a party seeking damages
> to which an
> invalid assertion is useful as evidence even though the
> certificate in question is provably valid given access to the
> relevant data.  That plaintiff could arguably find
> some service
> that doesn't know diddly about the certificate to issue a
> digitally signed "invalid" and there you go.  That
> TTP may have
> just stuck its neck out.
>
> I know that's probably a stretch, but not inconceivable given
> some the purposes to which certs and sigs are today being
> applied.  Better it seems by far to enable an "out"
> via unknown
> even if at the other end, the client does nothing differently.
>
> Valid and Invalid mean something very precise to my way of
> thinking.  It means data was accumulated, a path was
> successfully constructed, revocation information was
> checked and
> the entire dataset checked according to 2459 and whatever else
> might specified by the policy in place at the time between the
> client and the server/service.  Break any one of those
> assumptions and one can't assert invalid.  Hence we need
> unknown.
>
> Mike
>
>
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[e-mail]]
> > Sent: Wednesday, April 24, 2002 11:33 AM
> > To: Michael Myers; PKIX
> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> >
> >
> > Mike,
> > I realise there has been several mailing on this
> > topic, but so far no
> > consensus.
> > Apart form references to 2560, I have not seen much
> > in the way of
> > reasoned justification as to why we need another
> > return code in DPV/DPD.
> > All this additional return value is indicating is
> > some kind of failure
> > on the part of the server. We have defined the
> requirement for
> > additional information on the error to be returned by
> > the server to
> > clarify the nature of the failure to the client. If
> > you want to refine
> > the defined list of sub-status reasons when we get to
> > define the
> > protocol then I am sure we can debate this more
> > meaningfully then.
> > However since one of the goals of the DPV protocol is
> > to address
> > constrained clients, then we have to be hard core on
> > not complication
> > the protocol.
> >
> > Trevor
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3ONm9i28854 for ietf-pkix-bks; Wed, 24 Apr 2002 16:48:09 -0700 (PDT)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ONm8a28850 for <[e-mail]>; Wed, 24 Apr 2002 16:48:08 -0700 (PDT)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Apr 2002 16:48:06 -0700
Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Apr 2002 16:48:06 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Apr 2002 16:48:06 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 24 Apr 2002 16:48:05 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 24 Apr 2002 16:44:24 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Wed, 24 Apr 2002 16:44:23 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Thread-Index: AcHr4smZWCdxtQAFQ9iOm/CEGTBsiAABpW2A
From: "Trevor Freeman" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "PKIX " <[e-mail]>
X-OriginalArrivalTime: 24 Apr 2002 23:44:24.0049 (UTC) FILETIME=[F69D3610:01C1EBE9]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3ONm8a28851
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>

Mike,
All you are saying is that the server needs to clarity the reason for
the inability to validate the certificate. You objection seems to be
wording of the return state in the requirement document implying more
than is intended. Rather that naming them in the requirements document
valid and invalid, we can name them success and failure. Success means
the server was able to complete the client request, and failure means it
did not.

Trevor
-----Original Message-----
From: Michael Myers [mailto:[e-mail]] 
Sent: Wednesday, April 24, 2002 3:54 PM
To: Trevor Freeman; PKIX 
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt

Trevor,

I agree with you and Russ that from a state machine perspective,
a client will probably take the same action in both the unknown
and invalid cases.  However, from a server, or more importantly
a service perspective, I suspect there exists an appreciable
semantic difference  in a legal or liability sense between these
two states.

I've had the pleasure over the past few years of abundant
exposure to lawyers, bankers, regulators and other such types
regarding these and related issues.  I'm sure many of us share
that experience in one form or another.

Now, I'm no lawyer but given that exposure it seems to me that a
service (i.e. that which runs a server) is setting itself up for
disaster by asserting a digitally signed "invalid" when in point
of fact that service hasn't the data, jurisdiction or delegation
to make such an unequivocal assertion.

As a hypothetical, consider a party seeking damages to which an
invalid assertion is useful as evidence even though the
certificate in question is provably valid given access to the
relevant data.  That plaintiff could arguably find some service
that doesn't know diddly about the certificate to issue a
digitally signed "invalid" and there you go.  That TTP may have
just stuck its neck out.

I know that's probably a stretch, but not inconceivable given
some the purposes to which certs and sigs are today being
applied.  Better it seems by far to enable an "out" via unknown
even if at the other end, the client does nothing differently.

Valid and Invalid mean something very precise to my way of
thinking.  It means data was accumulated, a path was
successfully constructed, revocation information was checked and
the entire dataset checked according to 2459 and whatever else
might specified by the policy in place at the time between the
client and the server/service.  Break any one of those
assumptions and one can't assert invalid.  Hence we need
unknown.

Mike


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 11:33 AM
> To: Michael Myers; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
> Mike,
> I realise there has been several mailing on this
> topic, but so far no
> consensus.
> Apart form references to 2560, I have not seen much
> in the way of
> reasoned justification as to why we need another
> return code in DPV/DPD.
> All this additional return value is indicating is
> some kind of failure
> on the part of the server. We have defined the requirement for
> additional information on the error to be returned by
> the server to
> clarify the nature of the failure to the client. If
> you want to refine
> the defined list of sub-status reasons when we get to
> define the
> protocol then I am sure we can debate this more
> meaningfully then.
> However since one of the goals of the DPV protocol is
> to address
> constrained clients, then we have to be hard core on
> not complication
> the protocol.
>
> Trevor



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3ONBYp27885 for ietf-pkix-bks; Wed, 24 Apr 2002 16:11:34 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ONBXa27879 for <[e-mail]>; Wed, 24 Apr 2002 16:11:33 -0700 (PDT)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g3ON7kD25296; Wed, 24 Apr 2002 16:07:47 -0700 (PDT)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <G4SDJMHN>; Wed, 24 Apr 2002 16:12:57 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, Trevor Freeman <[e-mail]>, PKIX  <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Wed, 24 Apr 2002 16:12:13 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
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 Mike, I agree 100%.  In addition, the definition of an unknown status
maps well to the unknown status defined in 2560.  

Alex


> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 3:54 PM
> To: Trevor Freeman; PKIX 
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> 
> 
> 
> Trevor,
> 
> I agree with you and Russ that from a state machine perspective,
> a client will probably take the same action in both the unknown
> and invalid cases.  However, from a server, or more importantly
> a service perspective, I suspect there exists an appreciable
> semantic difference  in a legal or liability sense between these
> two states.
> 
> I've had the pleasure over the past few years of abundant
> exposure to lawyers, bankers, regulators and other such types
> regarding these and related issues.  I'm sure many of us share
> that experience in one form or another.
> 
> Now, I'm no lawyer but given that exposure it seems to me that a
> service (i.e. that which runs a server) is setting itself up for
> disaster by asserting a digitally signed "invalid" when in point
> of fact that service hasn't the data, jurisdiction or delegation
> to make such an unequivocal assertion.
> 
> As a hypothetical, consider a party seeking damages to which an
> invalid assertion is useful as evidence even though the
> certificate in question is provably valid given access to the
> relevant data.  That plaintiff could arguably find some service
> that doesn't know diddly about the certificate to issue a
> digitally signed "invalid" and there you go.  That TTP may have
> just stuck its neck out.
> 
> I know that's probably a stretch, but not inconceivable given
> some the purposes to which certs and sigs are today being
> applied.  Better it seems by far to enable an "out" via unknown
> even if at the other end, the client does nothing differently.
> 
> Valid and Invalid mean something very precise to my way of
> thinking.  It means data was accumulated, a path was
> successfully constructed, revocation information was checked and
> the entire dataset checked according to 2459 and whatever else
> might specified by the policy in place at the time between the
> client and the server/service.  Break any one of those
> assumptions and one can't assert invalid.  Hence we need
> unknown.
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: Trevor Freeman [mailto:[e-mail]]
> > Sent: Wednesday, April 24, 2002 11:33 AM
> > To: Michael Myers; PKIX
> > Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
> >
> >
> > Mike,
> > I realise there has been several mailing on this
> > topic, but so far no
> > consensus.
> > Apart form references to 2560, I have not seen much
> > in the way of
> > reasoned justification as to why we need another
> > return code in DPV/DPD.
> > All this additional return value is indicating is
> > some kind of failure
> > on the part of the server. We have defined the requirement for
> > additional information on the error to be returned by
> > the server to
> > clarify the nature of the failure to the client. If
> > you want to refine
> > the defined list of sub-status reasons when we get to
> > define the
> > protocol then I am sure we can debate this more
> > meaningfully then.
> > However since one of the goals of the DPV protocol is
> > to address
> > constrained clients, then we have to be hard core on
> > not complication
> > the protocol.
> >
> > Trevor
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3OMue927562 for ietf-pkix-bks; Wed, 24 Apr 2002 15:56:40 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OMuca27558 for <[e-mail]>; Wed, 24 Apr 2002 15:56:38 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3OMubTt024069; Wed, 24 Apr 2002 15:56:38 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, "PKIX " <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Wed, 24 Apr 2002 15:53:46 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Trevor,

I agree with you and Russ that from a state machine perspective,
a client will probably take the same action in both the unknown
and invalid cases.  However, from a server, or more importantly
a service perspective, I suspect there exists an appreciable
semantic difference  in a legal or liability sense between these
two states.

I've had the pleasure over the past few years of abundant
exposure to lawyers, bankers, regulators and other such types
regarding these and related issues.  I'm sure many of us share
that experience in one form or another.

Now, I'm no lawyer but given that exposure it seems to me that a
service (i.e. that which runs a server) is setting itself up for
disaster by asserting a digitally signed "invalid" when in point
of fact that service hasn't the data, jurisdiction or delegation
to make such an unequivocal assertion.

As a hypothetical, consider a party seeking damages to which an
invalid assertion is useful as evidence even though the
certificate in question is provably valid given access to the
relevant data.  That plaintiff could arguably find some service
that doesn't know diddly about the certificate to issue a
digitally signed "invalid" and there you go.  That TTP may have
just stuck its neck out.

I know that's probably a stretch, but not inconceivable given
some the purposes to which certs and sigs are today being
applied.  Better it seems by far to enable an "out" via unknown
even if at the other end, the client does nothing differently.

Valid and Invalid mean something very precise to my way of
thinking.  It means data was accumulated, a path was
successfully constructed, revocation information was checked and
the entire dataset checked according to 2459 and whatever else
might specified by the policy in place at the time between the
client and the server/service.  Break any one of those
assumptions and one can't assert invalid.  Hence we need
unknown.

Mike


> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 11:33 AM
> To: Michael Myers; PKIX
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
> Mike,
> I realise there has been several mailing on this
> topic, but so far no
> consensus.
> Apart form references to 2560, I have not seen much
> in the way of
> reasoned justification as to why we need another
> return code in DPV/DPD.
> All this additional return value is indicating is
> some kind of failure
> on the part of the server. We have defined the requirement for
> additional information on the error to be returned by
> the server to
> clarify the nature of the failure to the client. If
> you want to refine
> the defined list of sub-status reasons when we get to
> define the
> protocol then I am sure we can debate this more
> meaningfully then.
> However since one of the goals of the DPV protocol is
> to address
> constrained clients, then we have to be hard core on
> not complication
> the protocol.
>
> Trevor



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3OMHPU27076 for ietf-pkix-bks; Wed, 24 Apr 2002 15:17:25 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OMHOa27070 for <[e-mail]>; Wed, 24 Apr 2002 15:17:24 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3OMHLTt020015; Wed, 24 Apr 2002 15:17:24 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: "'PKIX '" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Wed, 24 Apr 2002 15:14:29 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Russ,

Will take up the "unknown" thread via Trevor's recent posting.
Good to hear you interpret the text as I do re: DPD server auth,
namely there's no prejudice against lower layer mechanisms.

I'm still though trying to understand what needs policy
discovery truly addresses.  What might be called the use cases.
To my way of thinking about this, a client is interested in
*its* policy or the one or ones it is constrained to use, static
or otherwise, implicit default or directly signalled in its
request.  Would a discovery query prove this?  Certainly.  But
so would an unsupportedPolicy response back from the server.

I can see that policy discovery could be useful to the
initialization of a freshly installed client, especially from an
enterprise perspective, but then there's a trust issue there.  A
policy discovery function might also be useful in developing an
Internet-wide profile of which servers do which things, but I'm
not sure that's the intent.  Or is it?

As I said, I'm just trying to understand the driver behind the
discovery piece.  Maybe like the roots issue, I'm overlooking
something obvious.

Mike


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 11:21 AM
> To: Michael Myers
> Cc: 'PKIX '
> Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
>
>
> Mike:
>
> > > DPV REQUIREMENTS
> > > ****************
> > >
> > > Editorial
> > > ---------
> > > "Unless an error is reported, the DPV response MUST
> > > indicate one
> > > of the following two status alternatives:"
> > >
> > > MM3: Change "two" to "three" to reflect {valid, invalid,
> > > unknown}
> > >
> > > [RH] I am having a real problem differentiating
> > > invalid and unknown. To my way of thinking, the
> > > actions taken by a client will be the same in
> > > either case.
> >
> >{valid, invalid, unknown} is the resolution of record and
> >defined in the text.  My comment was just pointing out an
> >editorial wrinkle that needs smoothing out.
>
> [RH] I agree that a change was made to add the
> "unknown" response in draft
> -04.  I am not convinced that we did anything useful
> for the client.  I
> think the client will treat "invalid" and "unknown"
> exactly the same.
>
>
> > > Signing DPD responses an option
> > > -------------------------------
> > > "For the client to be confident that the response
> originates
> > > from the expected DPD server, the server MAY provide an
> > > authenticated response. For example, the server
> might sign the
> > > response."
> > >
> > > And,
> > >
> > > "The DPD server MAY require client
> authentication, therefore,
> > > the DPD request MUST be able to be authenticated."
> > >
> > > MM14:  Signing is an example, not a requirement, correct?
> > > Lower-layer security protocols could equally
> address server auth
> > > needs.  Suggest appending to the last sentence of
> the first
> > > requirement " . . . or the client could invoke a
> lower-layer
> > > security protocol that authenticates the server
> (e.g. TLS)."
> > > This also folds in well with the MUST regarding
> support for
> > > client auth.
> > >
> > > [RH] DPV requires signature on the response.  Why
> not allow
> > > some consistency?
> >
> >I see no needs-based driver for signed DPD responses.  A DPD
> >server is simply acting as an aggregation point for access to
> >signed data produced by others.   As I said before,
> one of the
> >potential features of DPD over DPV is that a DPD
> server arguably
> >need not be trusted in a certification sense while a
> DPV server
> >clearly must (assuming of course that server does not combine
> >both functions).  A non-normative statement that where DPD
> >server auth is relevant lower layer protocols can
> suffice would
> >preserve this quality with no loss of security assurance.
>
> [RH] Just rereading the text, I think that the text
> in draft -04 allows
> either lower layer mechanisms or signatures within
> the DPD protocol.  I do
> not think that there is a need to change anything here.
>
>
> > > POLICY DISCOVERY REQUIREMENT
> > > ****************************
> > >
> > > Thought we got rid of PDP-type requirements
> > > -------------------------------------------
> > > "The client MUST be able to obtain references for
> the default
> > > policy or for all of the policies supported by
> the server by
> > > using an additional request/response pair. The
> response can
> > > include references to previously defined policies or
> > > to a priori
> > > known policies."
> > >
> > > MM15:  I thought we got rid of all PDP-type
> requirements in this
> > > DPV/DPD requirements document.  The above text
> seems to mandate
> > > that any protocol responsive to this document
> MUST define a
> > > request/response pair for policy discovery.
> > >
> > > [RH] We want the client to be able to get a list
> of the policies.
> > > PDP (in a future document) will address the
> definition of said
> > > policies.
> >
> >A DPV or DPD server can iterate through its list of policy
> >definitions and either execute accordingly or send back
> >unsupportedPolicy.  What's important to the client
> is that the
> >server either does or does not support the policy the client
> >specifies in its request.
>
> The requirement says that the client can ask the
> server for a list of
> policy identifiers that it is currently supporting.
> This does not mean
> that they were dynamically defined policies.
>
> Russ
>

Mike



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3OIb4R22692 for ietf-pkix-bks; Wed, 24 Apr 2002 11:37:04 -0700 (PDT)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OIb2a22688 for <[e-mail]>; Wed, 24 Apr 2002 11:37:02 -0700 (PDT)
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Apr 2002 11:36:59 -0700
Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 24 Apr 2002 11:36:59 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Apr 2002 11:36:56 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 24 Apr 2002 11:36:58 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 24 Apr 2002 11:33:17 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Wed, 24 Apr 2002 11:33:19 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Thread-Index: AcHrP8A+HVauIVKeQuu3KfwQr/YwtwAfVwNA
From: "Trevor Freeman" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "PKIX " <[e-mail]>
X-OriginalArrivalTime: 24 Apr 2002 18:33:17.0223 (UTC) FILETIME=[80519B70:01C1EBBE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3OIb2a22689
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>

Mike,
I realise there has been several mailing on this topic, but so far no
consensus. 
Apart form references to 2560, I have not seen much in the way of
reasoned justification as to why we need another return code in DPV/DPD.
All this additional return value is indicating is some kind of failure
on the part of the server. We have defined the requirement for
additional information on the error to be returned by the server to
clarify the nature of the failure to the client. If you want to refine
the defined list of sub-status reasons when we get to define the
protocol then I am sure we can debate this more meaningfully then.
However since one of the goals of the DPV protocol is to address
constrained clients, then we have to be hard core on not complication
the protocol.

Trevor

-----Original Message-----
From: Michael Myers [mailto:[e-mail]] 
Sent: Tuesday, April 23, 2002 8:19 PM
To: PKIX 
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt


Trevor,

Regarding the existence of the "unknown" state as the resolution
of record, the following WG list-based dialogs exist on this
point. These yeilded the list-based consensus reflected in -04
modulo that one word I referred to earlier.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Tuesday, February 26, 2002 1:51 AM
>
> So I would propose the following fix:
>
> The DPV response MAY indicate one of three status
> alternatives:
>
> 1) the certificate is valid according to the
> validation policy.
>
> 2) the certificate is invalid according to the
> validation policy. A secondary status MAY indicate
> that the certificate is definitively invalid or
> potentially valid.
>
> In the former case, if another request was made
> later on, the certificate will still be determined
> as invalid.
>
> In the later case, if another request could
> made later on, the certificate could possibly
> be determined as valid. This condition will
> occur before a certificate validity period has
> begun, while a certificate is suspended, or
> when, at the time the server generated the
> response, all conditions of the
> validation policy could not be met.
>
> 3) the server cannot determine the validity of the
> certificate. This condition will occur when a
> certification path cannot be constructed or
> some revocation information is unavailable.
>
> Denis


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Wednesday, February 27, 2002 5:19 AM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: "Potentially valid" response state in
> DPV/DPD rqmts I-D
>
>
>
> Michael,
>
> > Denis,
> >
> > Okay, if I may summarize at a high level my current
> > understanding:
> >
> > We are now effectively back to {valid, invalid,
> > unknown}.  All responses MUST indicate the relevant
> > validation policy. This policy MAY be established out
> > of band.  An "invalid" response MAY contain reason
> > codes or similar information that aids a client in
> > determining the likelihood that the same request sent
> > at a later time would return "valid". An "unknown"
> > response MAY contain reason codes or similar information
> > that indicates a failure to acquire all relevant data.
> >
> > Is that a fair summary?
>
> Yes, indeed it is.



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Tuesday, February 26, 2002 3:04 AM
> To: Peter Sylvester
> Cc: [e-mail]; [e-mail]
> Subject: Re: "Potentially valid" response state in
> DPV/DPD rqmts I-D
>
>
>
> Peter,
>
> > > The DPV response MAY indicate one of three status
> > > alternatives:
> > >
> > >  1) the certificate is valid according to the
> > >     validation policy.
> > >
> > >  2) the certificate is invalid according to the
> > >     validation policy. A secondary status MAY
> > >     indicate that the certificate is
> > >     definitively invalid or potentially valid.
> > >
> > >     In the former case, if another request was
> > >     made later on, the certificate will still
> > >     be determined as invalid.
> > >
> > >     In the later case, if another request could
> > >     made later on, the certificate could possibly
> > >     be determined as valid. This condition will
> > >     occur before a certificate validity period has
> > >     begun, while a certificate is suspended, or
> > >     when, at the time the server generated the
> > >     response, all conditions of the validation
> > >     policy could not be met.
> > >
> > >   3) the server cannot determine the validity of
> > >      the certificate.  This condition will occur
> > >      when a certification path cannot be constructed
> > >      or some revocation information  is unavailable.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3OIMDk22397 for ietf-pkix-bks; Wed, 24 Apr 2002 11:22:13 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3OIM7a22393 for <[e-mail]>; Wed, 24 Apr 2002 11:22:07 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Apr 2002 18:20:50 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA07122 for <[e-mail]>; Wed, 24 Apr 2002 14:20:33 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3OIM4X22663 for <[e-mail]>; Wed, 24 Apr 2002 14:22:04 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1W24N>; Wed, 24 Apr 2002 14:19:31 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.133]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1W242; Wed, 24 Apr 2002 14:19:23 -0400
From: "Housley, Russ" <[e-mail]>
To: Michael Myers <[e-mail]>
Cc: "'PKIX '" <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 24 Apr 2002 14:20:48 -0400
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
In-Reply-To: <[e-mail]>
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>

Mike:

> > DPV REQUIREMENTS
> > ****************
> >
> > Editorial
> > ---------
> > "Unless an error is reported, the DPV response MUST
> > indicate one
> > of the following two status alternatives:"
> >
> > MM3: Change "two" to "three" to reflect {valid, invalid,
> > unknown}
> >
> > [RH] I am having a real problem differentiating
> > invalid and unknown. To my way of thinking, the
> > actions taken by a client will be the same in
> > either case.
>
>{valid, invalid, unknown} is the resolution of record and
>defined in the text.  My comment was just pointing out an
>editorial wrinkle that needs smoothing out.

[RH] I agree that a change was made to add the "unknown" response in draft 
-04.  I am not convinced that we did anything useful for the client.  I 
think the client will treat "invalid" and "unknown" exactly the same.


> > Signing DPD responses an option
> > -------------------------------
> > "For the client to be confident that the response originates
> > from the expected DPD server, the server MAY provide an
> > authenticated response. For example, the server might sign the
> > response."
> >
> > And,
> >
> > "The DPD server MAY require client authentication, therefore,
> > the DPD request MUST be able to be authenticated."
> >
> > MM14:  Signing is an example, not a requirement, correct?
> > Lower-layer security protocols could equally address server auth
> > needs.  Suggest appending to the last sentence of the first
> > requirement " . . . or the client could invoke a lower-layer
> > security protocol that authenticates the server (e.g. TLS)."
> > This also folds in well with the MUST regarding support for
> > client auth.
> >
> > [RH] DPV requires signature on the response.  Why not allow
> > some consistency?
>
>I see no needs-based driver for signed DPD responses.  A DPD
>server is simply acting as an aggregation point for access to
>signed data produced by others.   As I said before, one of the
>potential features of DPD over DPV is that a DPD server arguably
>need not be trusted in a certification sense while a DPV server
>clearly must (assuming of course that server does not combine
>both functions).  A non-normative statement that where DPD
>server auth is relevant lower layer protocols can suffice would
>preserve this quality with no loss of security assurance.

[RH] Just rereading the text, I think that the text in draft -04 allows 
either lower layer mechanisms or signatures within the DPD protocol.  I do 
not think that there is a need to change anything here.


> > POLICY DISCOVERY REQUIREMENT
> > ****************************
> >
> > Thought we got rid of PDP-type requirements
> > -------------------------------------------
> > "The client MUST be able to obtain references for the default
> > policy or for all of the policies supported by the server by
> > using an additional request/response pair. The response can
> > include references to previously defined policies or
> > to a priori
> > known policies."
> >
> > MM15:  I thought we got rid of all PDP-type requirements in this
> > DPV/DPD requirements document.  The above text seems to mandate
> > that any protocol responsive to this document MUST define a
> > request/response pair for policy discovery.
> >
> > [RH] We want the client to be able to get a list of the policies.
> > PDP (in a future document) will address the definition of said
> > policies.
>
>A DPV or DPD server can iterate through its list of policy
>definitions and either execute accordingly or send back
>unsupportedPolicy.  What's important to the client is that the
>server either does or does not support the policy the client
>specifies in its request.

The requirement says that the client can ask the server for a list of 
policy identifiers that it is currently supporting.  This does not mean 
that they were dynamically defined policies.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3OHHtH19703 for ietf-pkix-bks; Wed, 24 Apr 2002 10:17:55 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OHHsa19699 for <[e-mail]>; Wed, 24 Apr 2002 10:17:54 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 24 Apr 2002 10:14:29 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 24 Apr 2002 10:14:29 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <JQL5APFA>; Wed, 24 Apr 2002 10:17:31 -0700
Content-return: allowed
Date: Wed, 24 Apr 2002 10:17:30 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: roadmap
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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 Peter,
    The "small minor syntax changes" are not quite so small and
minor. I don't know who else supports them or which subset of them
are supported.

Getting OCSP through interop testing took an non-trivial amount of
time. I would hate to need to go through that work again for
changes that don't benefit the OCSP spec at all.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 9:28 AM
> To: [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: RE: roadmap
> 
> 
> 
> "Michael Myers" <[e-mail]> writes:
> 
> >v2's status mostly tracks that of the DPV and DPD 
> requirements, which have
> >only recently settled down after about a year's worth of 
> effort.  As I said
> >before, it didn't make much sense to track that moving 
> target with incremental
> >I-Ds.  I once had three separate I-Ds but that got so hard 
> to manage and work
> >due to syntatic and editorial overlap (not to mention 
> review) that I put them
> >all in one.  I prefer to keep that structure together while 
> we see how things
> >shake out re: DPV/DPD.  Since 2560bis is pretty well on its 
> way, I think we
> >should let that go forward cleanly rather than force a reset 
> due to adding new
> >syntax.
> 
> The problem with this is that it ties a small and very 
> trivial change to 2560
> (a few more IDs added to the CHOICE) to a complex, 
> controversial, and likely-
> to-take-ages-to-sort-out new protocol (DPV/DPD), which more 
> or less dooms the
> small change to 2560 to a completion date of about 2005 or 
> so.  Is it possible
> to break out the minor-2560-tweaks (rather than the 
> completely new protocol
> bits) into a small draft of its own?  There's probably not 
> more than a page of
> text in there (not counting the usual boilerplate).
> 
> Peter.
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3OGjqL17423 for ietf-pkix-bks; Wed, 24 Apr 2002 09:45:52 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OGjpa17417 for <[e-mail]>; Wed, 24 Apr 2002 09:45:51 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3OGjdTt015366; Wed, 24 Apr 2002 09:45:45 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: roadmap
Date: Wed, 24 Apr 2002 09:42:47 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Peter,

That's certainly a rational proposal and one well-founded by
empirical evidence:  break out the v2-ness of v2, which is
essentially the cert id stuff, from the proposed definition of
extensions that support DPV and DPD.  I'll have a chat with my
co-authors on this.

Mike


> -----Original Message-----
> From: Peter Gutmann [mailto:[e-mail]]
> Sent: Wednesday, April 24, 2002 9:28 AM
> To: [e-mail]; [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: RE: roadmap
>
>
> "Michael Myers" <[e-mail]> writes:
>
> >v2's status mostly tracks that of the DPV and DPD
> requirements, which have
> >only recently settled down after about a year's
> worth of effort.  As I said
> >before, it didn't make much sense to track that
> moving target with incremental
> >I-Ds.  I once had three separate I-Ds but that got
> so hard to manage and work
> >due to syntatic and editorial overlap (not to
> mention review) that I put them
> >all in one.  I prefer to keep that structure
> together while we see how things
> >shake out re: DPV/DPD.  Since 2560bis is pretty well
> on its way, I think we
> >should let that go forward cleanly rather than force
> a reset due to adding new
> >syntax.
>
> The problem with this is that it ties a small and
> very trivial change to 2560
> (a few more IDs added to the CHOICE) to a complex,
> controversial, and likely-
> to-take-ages-to-sort-out new protocol (DPV/DPD),
> which more or less dooms the
> small change to 2560 to a completion date of about
> 2005 or so.  Is it possible
> to break out the minor-2560-tweaks (rather than the
> completely new protocol
> bits) into a small draft of its own?  There's
> probably not more than a page of
> text in there (not counting the usual boilerplate).
>
> Peter.
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3OGSDq16208 for ietf-pkix-bks; Wed, 24 Apr 2002 09:28:13 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OGSBa16203 for <[e-mail]>; Wed, 24 Apr 2002 09:28:11 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.2/8.12.2) with ESMTP id g3OGRwK4026180; Thu, 25 Apr 2002 04:27:58 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id EAA254512; Thu, 25 Apr 2002 04:27:58 +1200 (NZST) (sender [e-mail])
Date: Thu, 25 Apr 2002 04:27:58 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: roadmap
Cc: [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>

"Michael Myers" <[e-mail]> writes:

>v2's status mostly tracks that of the DPV and DPD requirements, which have
>only recently settled down after about a year's worth of effort.  As I said
>before, it didn't make much sense to track that moving target with incremental
>I-Ds.  I once had three separate I-Ds but that got so hard to manage and work
>due to syntatic and editorial overlap (not to mention review) that I put them
>all in one.  I prefer to keep that structure together while we see how things
>shake out re: DPV/DPD.  Since 2560bis is pretty well on its way, I think we
>should let that go forward cleanly rather than force a reset due to adding new
>syntax.

The problem with this is that it ties a small and very trivial change to 2560
(a few more IDs added to the CHOICE) to a complex, controversial, and likely-
to-take-ages-to-sort-out new protocol (DPV/DPD), which more or less dooms the
small change to 2560 to a completion date of about 2005 or so.  Is it possible
to break out the minor-2560-tweaks (rather than the completely new protocol
bits) into a small draft of its own?  There's probably not more than a page of
text in there (not counting the usual boilerplate).

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g3OGDWN15538 for ietf-pkix-bks; Wed, 24 Apr 2002 09:13:32 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OGDUa15534 for <[e-mail]>; Wed, 24 Apr 2002 09:13:30 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3OGD3Tt011889; Wed, 24 Apr 2002 09:13:09 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: roadmap
Date: Wed, 24 Apr 2002 09:10:12 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Peter,

v2's status mostly tracks that of the DPV and DPD requirements,
which have only recently settled down after about a year's worth
of effort.  As I said before, it didn't make much sense to track
that moving target with incremental I-Ds.  I once had three
separate I-Ds but that got so hard to manage and work due to
syntatic and editorial overlap (not to mention review) that I
put them all in one.  I prefer to keep that structure together
while we see how things shake out re: DPV/DPD.  Since 2560bis is
pretty well on its way, I think we should let that go forward
cleanly rather than force a reset due to adding new syntax.

Mike



Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Peter Gutmann
> Sent: Tuesday, April 23, 2002 8:33 PM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: roadmap
>
>
>
> Peter Sylvester <[e-mail]> writes:
>
> >Thus, it is not just a question of whether OCSP v2
> being alive or not.
>
> Can I also add a general complaint about the vague
> status of OCSPv2, there's
> already software deployed which uses the extended
> range of cert IDs in the v2
> draft, which makes it annoying to have it fading in
> and out of consciousness
> every few months.  Perhaps the new cert IDs (which
> are a trivial change) could
> be moved into 2560-bis, without requiring all the
> extra stuff which was added
> in the rest of the v2 draft.
>
> Peter.
>



Received: by above.proper.com (8.11.6/8.11.3) id g3OC4Yg18529 for ietf-pkix-bks; Wed, 24 Apr 2002 05:04:34 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OC4Ya18525 for <[e-mail]>; Wed, 24 Apr 2002 05:04:34 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00704; Wed, 24 Apr 2002 08:04:26 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-asn1-01.txt
Date: Wed, 24 Apr 2002 08:04:25 -0400
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		: Update for Appendix A in 
                          draft-ietf-pkix-new-part1-12.txt
	Author(s)	: R. Housley, W. Polk
	Filename	: draft-ietf-pkix-new-part1-asn1-01.txt
	Pages		: 24
	Date		: 23-Apr-02
	
As all members of the PKIX Working Group know, draft-ietf-pkix-new-
part1-12.txt is with the RFC Editor.  However, an error in the ASN.1
modules was discovered.  The authors are working with the RFC Editor
to ensure that the corrected ASN.1 modules are included in the final
text, and we are publishing this Internet-Draft to distribute the
corrected ASN.1 modules as quickly as possible.
This Internet-Draft contains only the updated Appendix.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-asn1-01.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-new-part1-asn1-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-new-part1-asn1-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-new-part1-asn1-01.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g3OC4X418524 for ietf-pkix-bks; Wed, 24 Apr 2002 05:04:33 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3OC4Wa18519 for <[e-mail]>; Wed, 24 Apr 2002 05:04:32 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00722; Wed, 24 Apr 2002 08:04:30 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-pkalgs-asn1-00.txt
Date: Wed, 24 Apr 2002 08:04:30 -0400
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		: Update for Section 3 in       
                          draft-ietf-pkix-ipki-pkalgs-05.txt
	Author(s)	: R. Housley, W. Polk
	Filename	: draft-ietf-pkix-new-pkalgs-asn1-00.txt
	Pages		: 8
	Date		: 23-Apr-02
	
As all members of the PKIX Working Group know, draft-ietf-pkix-ipki-
pkalgs-05.txt is with the RFC Editor.  However, an error in the ASN.1
modules was discovered.  The authors are working with the RFC Editor
to ensure that the corrected ASN.1 modules are included in the final
text, and we are publishing this Internet-Draft to distribute the
corrected ASN.1 module as quickly as possible.
This Internet-Draft contains only the updated ASN.1 module.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-pkalgs-asn1-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-new-pkalgs-asn1-00.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-new-pkalgs-asn1-00.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-new-pkalgs-asn1-00.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g3O3Xh827125 for ietf-pkix-bks; Tue, 23 Apr 2002 20:33:43 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3O3Xfa27121 for <[e-mail]>; Tue, 23 Apr 2002 20:33:41 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.2/8.12.2) with ESMTP id g3O3WwK4014310; Wed, 24 Apr 2002 15:32:58 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA248493; Wed, 24 Apr 2002 15:32:57 +1200 (NZST) (sender [e-mail])
Date: Wed, 24 Apr 2002 15:32:57 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: roadmap
Cc: [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 <[e-mail]> writes:

>Thus, it is not just a question of whether OCSP v2 being alive or not.

Can I also add a general complaint about the vague status of OCSPv2, there's
already software deployed which uses the extended range of cert IDs in the v2
draft, which makes it annoying to have it fading in and out of consciousness
every few months.  Perhaps the new cert IDs (which are a trivial change) could
be moved into 2560-bis, without requiring all the extra stuff which was added
in the rest of the v2 draft.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3O3M5326913 for ietf-pkix-bks; Tue, 23 Apr 2002 20:22:05 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3O3M4a26909 for <[e-mail]>; Tue, 23 Apr 2002 20:22:04 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3O3M5Tt029625 for <[e-mail]>; Tue, 23 Apr 2002 20:22:05 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "PKIX " <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Tue, 23 Apr 2002 20:19:14 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Trevor,

Regarding the existence of the "unknown" state as the resolution
of record, the following WG list-based dialogs exist on this
point. These yeilded the list-based consensus reflected in -04
modulo that one word I referred to earlier.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Tuesday, February 26, 2002 1:51 AM
>
> So I would propose the following fix:
>
> The DPV response MAY indicate one of three status
> alternatives:
>
> 1) the certificate is valid according to the
> validation policy.
>
> 2) the certificate is invalid according to the
> validation policy. A secondary status MAY indicate
> that the certificate is definitively invalid or
> potentially valid.
>
> In the former case, if another request was made
> later on, the certificate will still be determined
> as invalid.
>
> In the later case, if another request could
> made later on, the certificate could possibly
> be determined as valid. This condition will
> occur before a certificate validity period has
> begun, while a certificate is suspended, or
> when, at the time the server generated the
> response, all conditions of the
> validation policy could not be met.
>
> 3) the server cannot determine the validity of the
> certificate. This condition will occur when a
> certification path cannot be constructed or
> some revocation information is unavailable.
>
> Denis


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Wednesday, February 27, 2002 5:19 AM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: "Potentially valid" response state in
> DPV/DPD rqmts I-D
>
>
>
> Michael,
>
> > Denis,
> >
> > Okay, if I may summarize at a high level my current
> > understanding:
> >
> > We are now effectively back to {valid, invalid,
> > unknown}.  All responses MUST indicate the relevant
> > validation policy. This policy MAY be established out
> > of band.  An "invalid" response MAY contain reason
> > codes or similar information that aids a client in
> > determining the likelihood that the same request sent
> > at a later time would return "valid". An "unknown"
> > response MAY contain reason codes or similar information
> > that indicates a failure to acquire all relevant data.
> >
> > Is that a fair summary?
>
> Yes, indeed it is.



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Tuesday, February 26, 2002 3:04 AM
> To: Peter Sylvester
> Cc: [e-mail]; [e-mail]
> Subject: Re: "Potentially valid" response state in
> DPV/DPD rqmts I-D
>
>
>
> Peter,
>
> > > The DPV response MAY indicate one of three status
> > > alternatives:
> > >
> > >  1) the certificate is valid according to the
> > >     validation policy.
> > >
> > >  2) the certificate is invalid according to the
> > >     validation policy. A secondary status MAY
> > >     indicate that the certificate is
> > >     definitively invalid or potentially valid.
> > >
> > >     In the former case, if another request was
> > >     made later on, the certificate will still
> > >     be determined as invalid.
> > >
> > >     In the later case, if another request could
> > >     made later on, the certificate could possibly
> > >     be determined as valid. This condition will
> > >     occur before a certificate validity period has
> > >     begun, while a certificate is suspended, or
> > >     when, at the time the server generated the
> > >     response, all conditions of the validation
> > >     policy could not be met.
> > >
> > >   3) the server cannot determine the validity of
> > >      the certificate.  This condition will occur
> > >      when a certification path cannot be constructed
> > >      or some revocation information  is unavailable.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3O1oRx24571 for ietf-pkix-bks; Tue, 23 Apr 2002 18:50:27 -0700 (PDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3O1oPa24567 for <[e-mail]>; Tue, 23 Apr 2002 18:50:25 -0700 (PDT)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Apr 2002 18:50:23 -0700
Received: from 157.54.8.155 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Tue, 23 Apr 2002 18:50:23 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Apr 2002 18:50:23 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 23 Apr 2002 18:50:19 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Tue, 23 Apr 2002 18:46:39 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Tue, 23 Apr 2002 18:46:38 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Thread-Index: AcHrFa6SdDKEtx4sSVK/iEbI2Tpd+wAFo8Bg
From: "Trevor Freeman" <[e-mail]>
To: "Michael Myers" <[e-mail]>, "Housley, Russ" <[e-mail]>, "PKIX " <[e-mail]>
X-OriginalArrivalTime: 24 Apr 2002 01:46:39.0909 (UTC) FILETIME=[E0B6DD50:01C1EB31]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3O1oPa24568
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 Mike,
I don't see that this is the resolution of record. 

2560 defines unknown as 'The "unknown" state indicates that the
responder doesn't know about the certificate being requested.'

The requirements document states that "The certificate to be validated
MUST either be directly provided in the request or unambiguously
referenced". If the client gives the server an unambiguous reference to
the certificate to be validated, then unknown is not an appropriate
response. The server was either able to establish the validity of the
certificate - or it did not and returns invalid with a sub status with
further explanation. If you prefer we can change the working of the two
states to "valid" and "error".

Editorial note: the reference to the client providing an unambiguous
reference to the certificate needs to be moved to the common
requirements section.

Trevor

>
> MM3: Change "two" to "three" to reflect {valid, invalid,
> unknown}
>
> [RH] I am having a real problem differentiating
> invalid and unknown. To my way of thinking, the
> actions taken by a client will be the same in
> either case.

{valid, invalid, unknown} is the resolution of record and
defined in the text.  My comment was just pointing out an
editorial wrinkle that needs smoothing out.





Received: by above.proper.com (8.11.6/8.11.3) id g3NNdW319882 for ietf-pkix-bks; Tue, 23 Apr 2002 16:39:32 -0700 (PDT)
Received: from tweety (pool-151-200-26-46.res.east.verizon.net [151.200.26.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3NNdUa19875 for <[e-mail]>; Tue, 23 Apr 2002 16:39:30 -0700 (PDT)
Received: from [192.168.0.12] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Tue, 23 Apr 2002 19:38:02 -0400
Message-ID: <[e-mail]>
Date: Tue, 23 Apr 2002 19:38:01 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: PKIX <[e-mail]>
Subject: Re: roadmap
References: <[e-mail]> <[e-mail]> <p05100316b8ea532e5e63@[128.89.88.34]>
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>

Stephen Kent wrote:

> At 9:47 AM -0400 4/22/02, Sean P. Turner wrote:
> >Peter,
> >
> >I'll make the changes noted below.
> >
> >To put the "is SCVP THE protocol" issue to bed.  Can we say that
> >that was the plan
> >before we heard that "OCSPv2 will not be pushed to informational and
> >hence we are not in
> >the situation to have a defined set of requirements that enables
> >selection of one from
> >among potentially several technical approaches." (words from Mike Myers)?
> >
> >spt
> >
>
> Sean,
>
> SCVP and OCSPv2 were both put forth as candidates for providing
> DPV/DVD services, but before we developed suitable requirements for
> these services. So, the WG elected to first develop a requirements
> document, and then choose a protocol to satisfy those agreed-upon
> requirements. I laid out a plan for this process last year, but the
> requirements development took longer than expected. This is probably
> not so bad, as it has allowed us to focus more on getting agreement
> on the requirements, without the added confusion of arguing over a
> specific protocol. Nonetheless, I agree with Peter that it is
> inappropriate to label SCVP as the protocol at this time. We agreed
> to allow competing protocol submissions which would be evaluated
> against the requirements. Even if OCSPv2 were not a competitor, there
> is no prohibition from another protocol being considered relative to
> the requirements doc.
>
> Steve

Steve,

Thanks for the input.  I'll make sure to change the phrasing so that it
doesn't say the SCVP was "the" protocol and positively spin the situation
we're in now.  This is the problem with the draft that is documenting a moving
target - it's just about always wrong.

Cheers,

spt

P.S. Nice job on CNN.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3NMIiP16343 for ietf-pkix-bks; Tue, 23 Apr 2002 15:18:44 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3NMIha16339 for <[e-mail]>; Tue, 23 Apr 2002 15:18:43 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3NMIgTt002668; Tue, 23 Apr 2002 15:18:43 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "'PKIX '" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Tue, 23 Apr 2002 15:15:50 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Russ,

That was quick.  Thanks.  A few responses below, else I concur.

Mike

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
>
>
> DPV REQUIREMENTS
> ****************
>
> Editorial
> ---------
> "Unless an error is reported, the DPV response MUST
> indicate one
> of the following two status alternatives:"
>
> MM3: Change "two" to "three" to reflect {valid, invalid,
> unknown}
>
> [RH] I am having a real problem differentiating
> invalid and unknown. To my way of thinking, the
> actions taken by a client will be the same in
> either case.

{valid, invalid, unknown} is the resolution of record and
defined in the text.  My comment was just pointing out an
editorial wrinkle that needs smoothing out.


> DPD REQUIREMENTS
> ****************
>
>
> Multiple paths issue
> --------------------
> MM12:  This subset of DPD requirements seems to be leading
> towards a sub-optimal system design.  To be addressed in a
> separate email.
>
> [RH] I will wait for the mail to reply ...

Forthcoming.

> Signing DPD responses an option
> -------------------------------
> "For the client to be confident that the response originates
> from the expected DPD server, the server MAY provide an
> authenticated response. For example, the server might sign the
> response."
>
> And,
>
> "The DPD server MAY require client authentication, therefore,
> the DPD request MUST be able to be authenticated."
>
> MM14:  Signing is an example, not a requirement, correct?
> Lower-layer security protocols could equally address
> server auth
> needs.  Suggest appending to the last sentence of the first
> requirement " . . . or the client could invoke a lower-layer
> security protocol that authenticates the server (e.g. TLS)."
> This also folds in well with the MUST regarding support for
> client auth.
>
> [RH] DPV requires signature on the response.  Why not allow
> some consistency?

I see no needs-based driver for signed DPD responses.  A DPD
server is simply acting as an aggregation point for access to
signed data produced by others.   As I said before, one of the
potential features of DPD over DPV is that a DPD server arguably
need not be trusted in a certification sense while a DPV server
clearly must (assuming of course that server does not combine
both functions).  A non-normative statement that where DPD
server auth is relevant lower layer protocols can suffice would
preserve this quality with no loss of security assurance.



> POLICY DISCOVERY REQUIREMENT
> ****************************
>
> Thought we got rid of PDP-type requirements
> -------------------------------------------
> "The client MUST be able to obtain references for the default
> policy or for all of the policies supported by the server by
> using an additional request/response pair. The response can
> include references to previously defined policies or
> to a priori
> known policies."
>
> MM15:  I thought we got rid of all PDP-type
> requirements in this
> DPV/DPD requirements document.  The above text seems
> to mandate
> that any protocol responsive to this document MUST define a
> request/response pair for policy discovery.
>
> [RH] We want the client to be able to get a list of
> the policies.
> PDP (in a future document) will address the definition of said
> policies.

A DPV or DPD server can iterate through its list of policy
definitions and either execute accordingly or send back
unsupportedPolicy.  What's important to the client is that the
server either does or does not support the policy the client
specifies in its request.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3NLLUe15420 for ietf-pkix-bks; Tue, 23 Apr 2002 14:21:30 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3NLLSa15416 for <[e-mail]>; Tue, 23 Apr 2002 14:21:28 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 23 Apr 2002 21:20:13 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id RAA17545; Tue, 23 Apr 2002 17:20:00 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3NLLXM06812; Tue, 23 Apr 2002 17:21:33 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1V7NM>; Tue, 23 Apr 2002 17:19:00 -0400
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: "'Michael Myers '" <[e-mail]>, "'PKIX '" <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Tue, 23 Apr 2002 17:21:07 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Content-Type: text/plain; charset="ISO-8859-1"
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>

Mike:

Thanks for the comprehensive review.

See my responses below.  They are prefixed by [RH].

Russ

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


DPV REQUIREMENTS
****************

ESS and ES-F are not rqmts, or are they?
----------------------------------------
"The certificate to be validated MUST either be directly
provided in the request or unambiguously referenced, such as the
CA distinguished name, certificate serial number, and the hash
of the certificate, like ESSCertID as defined in [ESS] or
OtherSigningCertificate as defined in [ES-F]."

MM1:  The text seems to want to suggest that ESS or ES-F are
requirements but doesn't come out and say so.  I suggest
amending the text to provide absolute clarity that these
citations are examples of unambiguous referencing mechanisms,
NOT requirements.

[RH] I think that the word "like" makes it clear that ESS and ES-F
are ways to meet the requirement.  There are other acceptable ways.


Are these obvious operational facts, or rqmts?
----------------------------------------------
"The DPV server MUST have the full certificate to be validated.
When the certificate is not provided in the request, the server
MUST verify that the certificate is indeed the one being
unambiguous[ly] referenced by the client."

MM2:  These two sentences read more like statements of obvious
operational facts rather than BOTW protocol requirements.
Suggest using words other than the normative MUST.

[RH] I think that the MUST is appropriate.  Denis and I had a 
dialogue that was resolved by realizing that this was needed.


Editorial
---------
"Unless an error is reported, the DPV response MUST indicate one
of the following two status alternatives:"

MM3: Change "two" to "three" to reflect {valid, invalid,
unknown}

[RH] I am having a real problem differentiating invalid and unknown.
To my way of thinking, the actions taken by a client will be the
same in either case.


Clarify minimal set of invalidity reasons
-----------------------------------------
"When the certificate is not valid according to the validation
policy, then the reason MUST also be indicated. Invalidity
reasons include:  [bad path, invalid path, not yet valid]."

MM4: Are these three reasons normative or exemplary?  It makes
sense to presume the former.  If so, the text should be amended
to ensure ample clarity regarding the intent.  More to the
point, establish a minimally compliant set of reasons for
invalid.

[RH] Can this wait for protocol specification?  I think it can.


How to distinguish "invalid" from "not yet valid"?
--------------------------------------------------
"c) the certificate is not yet valid at this time. If another
request could be made later on, the certificate could possibly
be determined as valid. This condition may occur before a
certificate validity period has begun or while a certificate is
suspended."

MM5:  This requirement can be eliminated with no loss of
functionality.  To the extent that the two cases cited above
define the totality of what it means for a certificate to be
potentially valid, then if a certificate is suspended, I suspect
most RPs would prefer "invalid" over "not yet valid" especially
since suspension may equally result in permanent revocation. In
the second case, why is the RP even attempting to rely on the
certificate prior to the onset of the certificate's validity
period?  Or are we assuming the certificate-as-blob model where
RP software (possibly a thin client), just throws the blob to a
DPV server without even looking at the cert other than to
extract the public key and so it doesn't even bother to consider
the validity period?

[RH] Denis is the proponent for this requirement.


Additional info:  rqmts or examples?
------------------------------------
"The DPV request MUST allow the client to request the server to
include in its response additional information which will allow
relying parties not trusting the requested DPV server to be
confident that the certificate validation has correctly been
performed. Such information may (not necessarily exclusively)
consist of [several examples]."

MM6:  Are the examples normative or exemplary?  The use of
lower-case "may" suggests the latter but if normative then an
iterated list defining a minimal set of such information and
corresponding normative language is needed.

[RH] I do not think it is unclear. The may is in lower case.


Does a signed response meet the server auth rqmt?
-------------------------------------------------
"For the client to be confident that the certificate validation
was handled by the expected DPV server, the DPV response MUST be
authenticated, unless an error is reported."

and

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

MM7:  Maybe I'm missing something obvious, but under what
circumstances would a client be unable to conclude from a signed
response that a certificate validation was NOT handled by the
expected DPV server?

[RH] If an error is reported, the response does not have to
be signed.  Otherwise, the response does have to be signed.


Support for client auth.
------------------------
"The DPV server MAY require client authentication, therefore,
the DPV request MUST be able to be authenticated."

MM8:  Is is safe to assume that the client-auth feature of TLS
or similar lower-layer security protocol is responsive to this
rqmt?  In that design scenario, there's no need for a specific
client-auth feature in a DPV protocol other than to point to
such means.

[RH] A lower layer protocol authentication scheme could be used,
or a signature on the request could be used.


Clarification of support for optional relay, etc.
-------------------------------------------------
"Protocols designed to satisfy [DPV&DPD-REQ] MAY include
optional fields and/or extensions to support relaying,
re-direction or multicasting."

MM9:  I think this means that a protocol responsive to
[DPV&DPD-REQ] MAY have these features, but is not required to.
Correct?

[RH] Yep.


DPD REQUIREMENTS
****************

Make exclusion of root more normative.
--------------------------------------
"If the trust anchor is a self-signed certificate, that
self-signed certificate is not included."

MM10:  An obvious place for a MUST NOT or a SHALL NOT.

[RH] Fine.


Revocation info rqmt duplicated
-------------------------------
"In addition, if requested, the revocation information
associated with each certificate in the path MUST also be
returned."

preceding requirement:

"Clients MUST be able to specify whether they want . . .
revocation information associated with the path . . ."

MM11:  Seems to be a duplication here.

[RH] Okay, duplication is not necessarily bad.  But, one
could be deleted.


Multiple paths issue
--------------------
MM12:  This subset of DPD requirements seems to be leading
towards a sub-optimal system design.  To be addressed in a
separate email.

[RH] I will wait for the mail to reply ...


Which path discovery policy?
----------------------------
"Path discovery MUST be performed according to the path
discovery policy."

MM13:  Suggest appending ". . . in effect at the time between
the client and the server.  Means by which this policy is
established are out of scope of this document."

[RH] I do not like this text.  If a particular client can make
use of more than one policy, then the request needs to include
a specification of the policy.


Signing DPD responses an option
-------------------------------
"For the client to be confident that the response originates
from the expected DPD server, the server MAY provide an
authenticated response. For example, the server might sign the
response."

And,

"The DPD server MAY require client authentication, therefore,
the DPD request MUST be able to be authenticated."

MM14:  Signing is an example, not a requirement, correct?
Lower-layer security protocols could equally address server auth
needs.  Suggest appending to the last sentence of the first
requirement " . . . or the client could invoke a lower-layer
security protocol that authenticates the server (e.g. TLS)."
This also folds in well with the MUST regarding support for
client auth.

[RH] DPV requires signature on the response.  Why not allow
some consistency?


POLICY DISCOVERY REQUIREMENT
****************************

Thought we got rid of PDP-type requirements
-------------------------------------------
"The client MUST be able to obtain references for the default
policy or for all of the policies supported by the server by
using an additional request/response pair. The response can
include references to previously defined policies or to a priori
known policies."

MM15:  I thought we got rid of all PDP-type requirements in this
DPV/DPD requirements document.  The above text seems to mandate
that any protocol responsive to this document MUST define a
request/response pair for policy discovery.

[RH] We want the client to be able to get a list of the policies.
PDP (in a future document) will address the definition of said
policies.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3NKUAh12483 for ietf-pkix-bks; Tue, 23 Apr 2002 13:30:10 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3NKU8a12477 for <[e-mail]>; Tue, 23 Apr 2002 13:30:08 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3NKU7Tt022170 for <[e-mail]>; Tue, 23 Apr 2002 13:30:08 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "PKIX" <[e-mail]>
Subject: Comments on draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Tue, 23 Apr 2002 13:27:15 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Russ, Denis:

Good work.  My detailed parse of -04 into discrete rqmts
statements yielded several comments, included below.  These are
identified by [MMn].  Most are minor to only mildly aggravating.
I do have an issue with DPD client-side max path specification
which I'll take up in a separate email.

Mike


DPV REQUIREMENTS
****************

ESS and ES-F are not rqmts, or are they?
----------------------------------------
"The certificate to be validated MUST either be directly
provided in the request or unambiguously referenced, such as the
CA distinguished name, certificate serial number, and the hash
of the certificate, like ESSCertID as defined in [ESS] or
OtherSigningCertificate as defined in [ES-F]."

MM1:  The text seems to want to suggest that ESS or ES-F are
requirements but doesn't come out and say so.  I suggest
amending the text to provide absolute clarity that these
citations are examples of unambiguous referencing mechanisms,
NOT requirements.


Are these obvious operational facts, or rqmts?
----------------------------------------------
"The DPV server MUST have the full certificate to be validated.
When the certificate is not provided in the request, the server
MUST verify that the certificate is indeed the one being
unambiguous[ly] referenced by the client."

MM2:  These two sentences read more like statements of obvious
operational facts rather than BOTW protocol requirements.
Suggest using words other than the normative MUST.


Editorial
---------
"Unless an error is reported, the DPV response MUST indicate one
of the
following two status alternatives:"

MM3: Change "two" to "three" to reflect {valid, invalid,
unknown}


Clarify minimal set of invalidity reasons
-----------------------------------------
"When the certificate is not valid according to the validation
policy, then the reason MUST also be indicated. Invalidity
reasons include:  [bad path, invalid path, not yet valid]."

MM4: Are these three reasons normative or exemplary?  It makes
sense to presume the former.  If so, the text should be amended
to ensure ample clarity regarding the intent.  More to the
point, establish a minimally compliant set of reasons for
invalid.


How to distinguish "invalid" from "not yet valid"?
--------------------------------------------------
"c) the certificate is not yet valid at this time. If another
request could be made later on, the certificate could possibly
be determined as valid. This condition may occur before a
certificate validity period has begun or while a certificate is
suspended."

MM5:  This requirement can be eliminated with no loss of
functionality.  To the extent that the two cases cited above
define the totality of what it means for a certificate to be
potentially valid, then if a certificate is suspended, I suspect
most RPs would prefer "invalid" over "not yet valid" especially
since suspension may equally result in permanent revocation. In
the second case, why is the RP even attempting to rely on the
certificate prior to the onset of the certificate's validity
period?  Or are we assuming the certificate-as-blob model where
RP software (possibly a thin client), just throws the blob to a
DPV server without even looking at the cert other than to
extract the public key and so it doesn't even bother to consider
the validity period?


Additional info:  rqmts or examples?
------------------------------------
"The DPV request MUST allow the client to request the server to
include in its response additional information which will allow
relying parties not trusting the requested DPV server to be
confident that the certificate validation has correctly been
performed. Such information may (not necessarily exclusively)
consist of [several examples]."

MM6:  Are the examples normative or exemplary?  The use of
lower-case "may" suggests the latter but if normative then an
iterated list defining a minimal set of such information and
corresponding normative language is needed.


Does a signed response meet the server auth rqmt?
-------------------------------------------------
"For the client to be confident that the certificate validation
was handled by the expected DPV server, the DPV response MUST be
authenticated, unless an error is reported."

and

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

MM7:  Maybe I'm missing something obvious, but under what
circumstances would a client be unable to conclude from a signed
response that a certificate validation was NOT handled by the
expected DPV server?


Support for client auth.
------------------------
"The DPV server MAY require client authentication, therefore,
the DPV request MUST be able to be authenticated."

MM8:  Is is safe to assume that the client-auth feature of TLS
or similar lower-layer security protocol is responsive to this
rqmt?  In that design scenario, there's no need for a specific
client-auth feature in a DPV protocol other than to point to
such means.


Clarification of support for optional relay, etc.
-------------------------------------------------
"Protocols designed to satisfy [DPV&DPD-REQ] MAY include
optional fields and/or extensions to support relaying,
re-direction or multicasting."

MM9:  I think this means that a protocol responsive to
[DPV&DPD-REQ] MAY have these features, but is not required to.
Correct?


DPD REQUIREMENTS
****************

Make exclusion of root more normative.
--------------------------------------
"If the trust anchor is a self-signed certificate, that
self-signed certificate is not included."

MM10:  An obvious place for a MUST NOT or a SHALL NOT.


Revocation info rqmt duplicated
-------------------------------
"In addition, if requested, the revocation information
associated with each certificate in the path MUST also be
returned."

preceding requirement:

"Clients MUST be able to specify whether they want . . .
revocation information associated with the path . . ."

MM11:  Seems to be a duplication here.


Multiple paths issue
--------------------
MM12:  This subset of DPD requirements seems to be leading
towards a sub-optimal system design.  To be addressed in a
separate email.


Which path discovery policy?
----------------------------
"Path discovery MUST be performed according to the path
discovery policy."

MM13:  Suggest appending ". . . in effect at the time between
the client and the server.  Means by which this policy is
established are out of scope of this document."


Signing DPD responses an option
-------------------------------
"For the client to be confident that the response originates
from the expected DPD server, the server MAY provide an
authenticated response. For example, the server might sign the
response."

And,

"The DPD server MAY require client authentication, therefore,
the DPD request MUST be able to be authenticated."

MM14:  Signing is an example, not a requirement, correct?
Lower-layer security protocols could equally address server auth
needs.  Suggest appending to the last sentence of the first
requirement " . . . or the client could invoke a lower-layer
security protocol that authenticates the server (e.g. TLS)."
This also folds in well with the MUST regarding support for
client auth.


POLICY DISCOVERY REQUIREMENT
****************************

Thought we got rid of PDP-type requirements
-------------------------------------------
"The client MUST be able to obtain references for the default
policy or for all of the policies supported by the server by
using an additional request/response pair. The response can
include references to previously defined policies or to a priori
known policies."

MM15:  I thought we got rid of all PDP-type requirements in this
DPV/DPD requirements document.  The above text seems to mandate
that any protocol responsive to this document MUST define a
request/response pair for policy discovery.



Received: by above.proper.com (8.11.6/8.11.3) id g3MNvr914571 for ietf-pkix-bks; Mon, 22 Apr 2002 16:57:53 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MNvqa14567 for <[e-mail]>; Mon, 22 Apr 2002 16:57:52 -0700 (PDT)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA07967; Mon, 22 Apr 2002 19:57:42 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100316b8ea532e5e63@[128.89.88.34]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Mon, 22 Apr 2002 19:59:30 -0400
To: "Sean P. Turner" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: roadmap
Cc: PKIX <[e-mail]>
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>

At 9:47 AM -0400 4/22/02, Sean P. Turner wrote:
>Peter,
>
>I'll make the changes noted below.
>
>To put the "is SCVP THE protocol" issue to bed.  Can we say that 
>that was the plan
>before we heard that "OCSPv2 will not be pushed to informational and 
>hence we are not in
>the situation to have a defined set of requirements that enables 
>selection of one from
>among potentially several technical approaches." (words from Mike Myers)?
>
>spt
>

Sean,

SCVP and OCSPv2 were both put forth as candidates for providing 
DPV/DVD services, but before we developed suitable requirements for 
these services. So, the WG elected to first develop a requirements 
document, and then choose a protocol to satisfy those agreed-upon 
requirements. I laid out a plan for this process last year, but the 
requirements development took longer than expected. This is probably 
not so bad, as it has allowed us to focus more on getting agreement 
on the requirements, without the added confusion of arguing over a 
specific protocol. Nonetheless, I agree with Peter that it is 
inappropriate to label SCVP as the protocol at this time. We agreed 
to allow competing protocol submissions which would be evaluated 
against the requirements. Even if OCSPv2 were not a competitor, there 
is no prohibition from another protocol being considered relative to 
the requirements doc.

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g3MM7tl11303 for ietf-pkix-bks; Mon, 22 Apr 2002 15:07:55 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MM7sa11299 for <[e-mail]>; Mon, 22 Apr 2002 15:07:54 -0700 (PDT)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id SAA00241; Mon, 22 Apr 2002 18:07:50 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510030db8ea38520ef7@[128.89.88.34]>
In-Reply-To: <000201c1e004$5425f7f0$020aff0c@tsg1>
References:  <[e-mail]> <001901c1dd74$8d26a730$020aff0c@tsg1> <p05100300b8d76b579027@[128.33.238.74]> <000201c1e004$5425f7f0$020aff0c@tsg1>
Date: Mon, 22 Apr 2002 18:04:49 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: NEW THREAD: Too Complex - WAS - Re: Open issue: DPV relay
Cc: <[e-mail]>
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>

At 1:18 PM -0700 4/9/02, todd glassey wrote:
>----- Original Message -----
>From: "Stephen Kent" <[e-mail]>
>To: "todd glassey" <[e-mail]>
>Cc: <[e-mail]>
>Sent: Monday, April 08, 2002 9:05 PM
>Subject: Re: NEW THREAD: Too Complex - WAS - Re: Open issue: DPV relay
>
>
>>
>>  Todd,
>>
>>  >Peter - All - I agree with you to some extent but let me also that there
>is
>>  >another side and its about a bigger picture.  And in this bigger picture
>>  >PKIX is way out of control. What it really needs is to have a thread of
>>  >commonality drawn through all that PKIX produces. What I mean by that is
>>  >that the entire process of  complex-decision-support and evidentiary
>>  >processing of x.509 certs is out of control.
>>
>>  As noted in my immediate, previous message, not all the PKI standards
>>  we address are in support of NR. This it is not reasonable to insist
>>  that all of these standards have an "evidentiary" flavor to them.
>
>Why not Stephen?  NR is something that only a set of practices can
>establish.

Your comment above makes no sense relative to my text immediately 
above. It's not a good use of my time, or of this mailing list, to 
continue with this thread.  And, as Hal observed, if you believe that 
100% of Internet traffic is "transaction processing," you are 
obviously imagining some other Internet, perhaps in some parallel 
universe ...

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MLbv609797 for ietf-pkix-bks; Mon, 22 Apr 2002 14:37:57 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MLbua09793 for <[e-mail]>; Mon, 22 Apr 2002 14:37:56 -0700 (PDT)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA27632; Mon, 22 Apr 2002 17:37:56 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100308b8ea318575de@[128.89.88.34]>
In-Reply-To: <004e01c1e4ee$5e51e7e0$020aff0a@tsg1>
References: <[e-mail]> <[e-mail]> <004e01c1e4ee$5e51e7e0$020aff0a@tsg1>
Date: Mon, 22 Apr 2002 17:33:10 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Two  more nits re: DPV/DPD rqmts
Cc: <[e-mail]>
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>

At 7:01 PM -0700 4/15/02, todd glassey wrote:
>----- Original Message -----
>From: "Denis Pinkas" <[e-mail]>
>To: "Michael Myers" <[e-mail]>
>Cc: <[e-mail]>
>Sent: Monday, April 15, 2002 10:05 AM
>Subject: Re: Two more nits re: DPV/DPD rqmts
>
>
>>
>>  Mike,
>>
>>  > Russ, Denis:
>>  >
>>  > Section 4, Delegated Path Validation Protocol Requirements
>>  > begins with:
>>  > "The Delegated Path Validation (DPV) protocol allows . . ."
>>  >
>>  > Similarly, Section 5 Delegated Path Discovery Protocol
>>  > Requirements begins with:
>>  > "The Delegated Path Discovery (DPD) protocol allows . . ."
>>  >
>>  > Since we're defining requirements and not protocols in this I-D,
>>  > you may wish to consider amending both these phrases towards
>>  > something along the lines of "DPV protocols allow . . ." and
>>  > "DPD protocols allow . . ." respectively.
>>
>>  Are we really defining multiple protocols ?
>>  I was assuming that we would like only one.
>>  I prefer to keep the current text.
>
>Denis - are you saying that it is PKIX's operating rule to only allow one of
>each protocol type its working on? Is this true Tim and Steve Kent?
>
>Todd

Todd,

In the case of DPV and DPD, the WG discussed the matter some time ago 
and agreed that it would be highly desirable to have just one 
standard protocol satisfying the requirements we agree upon.  We 
failed to do this in the case of CMC and CMP and the user and vendor 
community suffered as a result. So, yes, the intent in this case is 
to have just one standard for DPV and DPD.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MLANv07565 for ietf-pkix-bks; Mon, 22 Apr 2002 14:10:23 -0700 (PDT)
Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MLAKa07559 for <[e-mail]>; Mon, 22 Apr 2002 14:10:21 -0700 (PDT)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA06477; Mon, 22 Apr 2002 14:10:18 -0700 (PDT)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id RAA06798; Mon, 22 Apr 2002 17:10:16 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Mon, 22 Apr 2002 17:07:11 -0400
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: IETF Transport Layer Security WG <[e-mail]>, PKIX List <[e-mail]>
Subject: Re: [ietf-tls] Re: Proposed MIME type application/pkix-pkipath
References: <LISTMANAGER-3448442-30940-2002.04.17-09.41.03--steve.hanna#[e-mail]>
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>

The off-line discussion about how to reference X.509 (2000) and
X.509 (2000) TC 1 has been completed. The recommendation is to
go with David Hopwood's earlier text, but change the references
to the ISO/ITU documents to this:

  [X509-4th] ITU-T Recommendation X.509(2000) | ISO/IEC 9594-8:2001, 
             Information Technology - Open Systems Interconnection - 
             The Directory: Public-key and attribute certificate 
             frameworks. 

  [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001)
                 | ISO/IEC 9594-8:2001/Cor.1:2002, Technical
                 Corrigendum 1 to ISO/IEC 9594:8:2001.

I have included a full copy of the revised version of David's text
at the end of this message. The only changes here are to include
the full titles of the documents and change the reference markers
from [X509-2000] to [X509-4th] and from [X509-TC1] to
[X509-4th-TC1]. Basically, David had everything right in his
original text. These are just minor changes to the form of the
references.

Why make these changes? First, it's best to include the full titles
of these documents so that people can be sure they have the right
document if they want to download it from ITU or ISO. Second, it's
better to refer to the 4th edition of X.509 than to call it X.509
(2000), since the ISO version appeared in 2001 and this can cause
confusion. The content of the ITU and ISO versions is exactly the
same. Third, it's important to be clear that we mean X.509 (2000)
TC 1, not X.509 (1997) TC 1.

I apologize for any confusion. I guess that ISO and ITU sometimes
have the same sort of last-minute corrections to specs and resulting
confusion that the IETF sometimes has.

Thanks for your patience,

Steve Hanna

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

To: [e-mail]
Subject: Registration of MIME media type application/pkix-pkipath

MIME media type name: application

MIME subtype name: pkix-pkipath

Required parameters: none

Optional parameters: version (default value is "1")

Encoding considerations:
   This is the DER-encoded ASN.1 type PkiPath, which is defined in
   [X509-4th-TC1] as follows:

      PkiPath ::= SEQUENCE OF Certificate

      PkiPath is used to represent a certification path. Within the
      sequence, the order of certificates is such that the subject of
      the first certificate is the issuer of the second certificate,
      etc.

   All Certificates MUST conform to [PKIX] (an update to [PKIX] is
   in preparation, and should be followed when it is published).
   DER (as opposed to BER) encoding MUST be used. If this type is
   sent over a 7-bit transport, base64 encoding SHOULD be used.

Security considerations:
   The security considerations of [X509-4th] and [PKIX] (or any
   update to it) apply, as well as those of any protocol that uses
   this type (e.g. TLS).

   Note that this type only specifies a certificate chain that can
   be assessed for validity according to the relying party's existing
   configuration of trusted CAs; it is not intended to be used to
   specify any change to that configuration.

Interoperability considerations:
   No specific interoperability problems are known with this type, but
   for recommendations relating to X.509 certificates in general, see
   [PKIX].

Published specification: <draft-ietf-tls-extensions-04.txt>,
   [X509-4th-TC1], and [PKIX].

Applications which use this media type: TLS. It may also be used by
   other protocols, or for general interchange of PKIX certificate
   chains.

Additional information:
   Magic number(s): DER-encoded ASN.1 can be easily recognised (further
      parsing is required to distinguish from other ASN.1 types)
   File extension(s): .pkipath
   Macintosh File Type Code(s): not specified

Person & email address to contact for further information:
   Magnus Nystrom <[e-mail]>

Intended usage: COMMON

Author/Change controller:
   Magnus Nystrom <[e-mail]>

References:
  [PKIX]         R. Housley, W. Ford, W. Polk, and D. Solo, "Internet
                 Public Key Infrastructure: Part I: X.509 Certificate and CRL
                 Profile", IETF RFC 2459, January 1999.

  [X509-4th]     ITU-T Recommendation X.509(2000) | ISO/IEC 9594-8:2001, 
                 Information Technology - Open Systems Interconnection - 
                 The Directory: Public-key and attribute certificate 
                 frameworks. 

  [X509-4th-TC1] ITU-T Recommendation X.509(2000) Corrigendum 1(2001)
                 | ISO/IEC 9594-8:2001/Cor.1:2002, Technical
                 Corrigendum 1 to ISO/IEC 9594:8:2001.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MF3WJ16340 for ietf-pkix-bks; Mon, 22 Apr 2002 08:03:32 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MF3Ua16336 for <[e-mail]>; Mon, 22 Apr 2002 08:03:30 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA03573; Mon, 22 Apr 2002 17:03:26 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Mon, 22 Apr 2002 17:03:26 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA22987; Mon, 22 Apr 2002 17:03:24 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA11165; Mon, 22 Apr 2002 17:03:24 +0200 (MET DST)
Date: Mon, 22 Apr 2002 17:03:24 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: roadmap
Cc: [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>

> 
> Peter,
> 
> I'll make the changes noted below.

Good. 

> 
> To put the "is SCVP THE protocol" issue to bed.  Can we say that that was the plan
> before we heard that "OCSPv2 will not be pushed to informational and hence we are not in
> the situation to have a defined set of requirements that enables selection of one from
> among potentially several technical approaches." (words from Mike Myers)?

Somehow everybody seems to have forgotten DVCS as a potential protocol
for "DPV". Thus, it is not just a question of whether OCSP v2 being
alive or not. 

There may have been 'a plan' by some people, but 'the plan' 
agreed by the WG?  It seems that Mike also had complained about 
the document being  somewhat misleading.

The second issue is that DVCS was not mentioned in the history concerning
this 'problem space of certificate validation'. The text below tries to
remedy this describing the three existing protocol specifications that
address more or less different aspects.  The definitions of the
protocols is necessarily incomplete since only the overlapping
parts are outlined.  

> In order to more correctly reflect history I propose on page 7:
>
>
>    protocol. [OCSP] was developed to address concerns that not all
>    relying parties want to go through the process checking CRLs from
>    every CA in the certification path. It defines an on-line mechanism
>    to determine the status of a given certificate, which may provide
>    more timely revocation information than is possible with CRLs.
>
>    [DVCS] also contains a service to determine the validity of
>    public key certificate using a TTP permitting to present the result
>    of the verification as evidence in a non repudiation context.
>
>    Another approach allowing relying parties to off-load all of
>    their certification verification to another entity is with the
>    Simple Certification Verification Protocol (SCVP), for which a
>    draft exists [SCVP].


Peter




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3MDmrq12707 for ietf-pkix-bks; Mon, 22 Apr 2002 06:48:53 -0700 (PDT)
Received: from tweety (pool-151-200-26-46.res.east.verizon.net [151.200.26.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3MDmoa12703 for <[e-mail]>; Mon, 22 Apr 2002 06:48:50 -0700 (PDT)
Received: from [192.168.0.12] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Mon, 22 Apr 2002 09:47:21 -0400
Message-ID: <[e-mail]>
Date: Mon, 22 Apr 2002 09:47:15 -0400
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], PKIX <[e-mail]>
Subject: Re: roadmap
References: <[e-mail]>
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>

Peter,

I'll make the changes noted below.

To put the "is SCVP THE protocol" issue to bed.  Can we say that that was the plan
before we heard that "OCSPv2 will not be pushed to informational and hence we are not in
the situation to have a defined set of requirements that enables selection of one from
among potentially several technical approaches." (words from Mike Myers)?

spt

Peter Sylvester wrote:

> >>
> > Peter,
> >
> >     (Sorry for the delay in responding.  I work for a fairly small company,
> > and when the boss wants the next version of the product shipped, he's not
> > overly fond of hearing things like "but I gotta keep up on PKIX stuff.)
> Thanks for the fast answer. I am well aware of such a situation
> of highly volunteer work. (which just happened to change for me since
> the beginning of April). :-)
>
> >
> > AWA:  That was put in there after the London meeting last August. At that
> > time Michael Myers, the "leader" of the OCSP faction, indicated that his
> > approach to solving the DPV/DPD - SCVP vs. OCSP battles was to let SCVP
> > continue along the standards track, and make the next OCSP version (that
> > handled the full DPD/DPV functions) go to experimental status.  (This would
> > be similar to the PKIX vs SPKI situation.)  So, it seemed like SCVP had
> > "won".  Since then, however, the WG has dropped back to going through the
> > entire DPD/DPV requirements discussions; AND Michael has been told (by Steve
> > Bellovin) that the IESG will not support pushing OCSPv2 to experimental with
> > SCVP being standards track.  I guess you're right; this makes the London
> > "conclusions" no longer valid and the wording will have to be changed.
>
> Ok. Just to inform you, as far as I remember there has not been any discussion
> in London about *the* protocol. I was there and would have certainly made a comment.
> of course, there might have been the usual 'corridor' and 'bar' meetings. :-)
>
> > >
> > > ?   specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating
> > > ?   (though in [TSP] request for a time stamp are not required to use
> > > ?   [CMS]).
> > >
> > > encapsulating what?
> > >
> >
> > AWA:  Oops - editing error.  That should say "... as an encapsulating
> > protocol ..." (or maybe encapsulating mechanism, if you don't consider CMS
> > to be a full protocol).
>
> Indeed, I consider CMS as a 'document format', but that was not
> really the point: There is one word missing,  'mechanism' would be fine.
> But my proposal 'unfolds' the combined statement into
> two independant sentences concenrning the two "protocols" and
> clarifies one (because in DVCS everything is optional).
>
> > >    Both [DVCS] and [TSP] define CMS contenttypes to transport protocol
> > >    information. [TSP] optionally uses CMS SignedData and an encapsulatin
> > >    security envelope as an option for the requests, and mandatory for
> > >    the resulting tokens. [DVCS] allow the optional usage of CMS security
> > >    envelopes permitting to authenticate requests and responses.
> > >
>
> > > I have the feeling that something is wrong in the following:
> > >
> > >      - PKC holders that are issued certificates and can sign digital
> > >        documents and encrypt documents;
> > >
> > >      - Clients that validate digital signatures and their certification
> > >        paths from a known public key of a trusted CA;
>
> Here some idea to clarify: feel free to change this.
>
> PKC holders are issued certificates and can sign
> digital documents and decrypt documents using private keys.
>
> Clients that validate digital signatures and their certification
> paths from a known public key of a trusted CA and that encrypt
> document using public key from certificates of PKC holders.
> (or should one call them 'relying parties').
>
> Regards and thanks again for the response.
>
> Peter




Received: by above.proper.com (8.11.6/8.11.3) id g3L4URI26495 for ietf-pkix-bks; Sat, 20 Apr 2002 21:30:27 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3L4UG326487 for <[e-mail]>; Sat, 20 Apr 2002 21:30:25 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.2/8.12.2) with ESMTP id g3L4U8uc020816; Sun, 21 Apr 2002 16:30:08 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA71658; Sun, 21 Apr 2002 16:30:02 +1200 (NZST) (sender [e-mail])
Date: Sun, 21 Apr 2002 16:30:02 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
Cc: [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>

"Housley, Russ" <[e-mail]> writes:

>At 03:30 PM 4/19/2002 +1200, Peter Gutmann wrote:
>>"Housley, Russ" <[e-mail]> writes:
>>
>>>What maximum size do you suggest?
>>
>>I would say 320x200 *minimum*, for the MPEGs :-).
>
>We have not allowed MPEGs, just static images in JPEG or GIF format.

Actually that was a dual-purpose comment, firstly to reference Bob Jueneman's
joke about putting MPEGs in the DN, and secondly to point out that setting
arbitrary limits on image sizes is probably pointless given that companies are
going to use whatever size and format they feel like, no matter what the spec
says.  Can you imagine KPMGCoopersPriceLybrandWaterhouseAnderson distributing a
single cert without the Official Corporate Logo(tm) with Official Corporate
Animation(tm) and Official Corporate Song(tm) playing in the background?.

You only need to look at the cert policy text size limit set in RFC 2459 as an
example.  I used to check the size limit given in the RFC, but after finding
the first dozen or so CAs who went way over the limit (some texts were five
times the size allowed by the RFC) I changed my code to use 5x the max size as
the upper limit.  After still getting complaints that certs were being
rejected, I removed the check altogether, since no-one seems to pay any
attention to the size limits.  So I think that while a comment that N x M is a
good upper limit would be useful, you'd have to accept that it's going to be
ignored by anyone who feels their Corporate Image would be slighted by such a
constraint (or, more likely, who doesn't bother to read RFCs).

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3K9DZ504642 for ietf-pkix-bks; Sat, 20 Apr 2002 02:13:35 -0700 (PDT)
Received: from smtp3.arnet.com.ar (smtp3.arnet.com.ar [200.45.191.14]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3K9DVb04637 for <[e-mail]>; Sat, 20 Apr 2002 02:13:33 -0700 (PDT)
Received: (qmail 27129 invoked from network); 20 Apr 2002 09:12:42 -0000
Received: from unknown (HELO mail2.arnet.com.ar) (200.45.0.5) by smtp3.arnet.com.ar with SMTP; 20 Apr 2002 09:12:42 -0000
Received: from mail pickup service by mail2.arnet.com.ar with Microsoft SMTPSVC; Sat, 20 Apr 2002 06:10:02 -0300
Received: from mx1.arnet.com.ar ([200.45.0.2]) by mail2.arnet.com.ar  with Microsoft SMTPSVC(5.5.1877.677.67); Thu, 18 Apr 2002 11:20:54 -0300
Received: from smtp-mx-02.ti.local ([200.45.48.21]) by mx1.arnet.com.ar  with Microsoft SMTPSVC(5.5.1877.357.35); Thu, 18 Apr 2002 11:20:59 -0300
Received: from loki.ietf.org ([132.151.1.177]) by smtp-mx-02.ti.local with Microsoft SMTPSVC(5.0.2195.4905); Thu, 18 Apr 2002 11:15:51 -0300
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id KAA20363 for [e-mail]; Thu, 18 Apr 2002 10:15:01 -0400 (EDT)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id IAA19171 for <[e-mail]>; Thu, 18 Apr 2002 08:01:01 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02041; Thu, 18 Apr 2002 08:00:56 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-asn1-00.txt
Date: Thu, 18 Apr 2002 08:00:56 -0400
X-OriginalArrivalTime: 18 Apr 2002 14:15:56.0281 (UTC) FILETIME=[8E525690:01C1E6E3]
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		: Update for Appendix A in 
                          draft-ietf-pkix-new-part1-12.txt
	Author(s)	: R. Housley, W. Polk
	Filename	: draft-ietf-pkix-new-part1-asn1-00.txt
	Pages		: 24
	Date		: 17-Apr-02
	
As all members of the PKIX Working Group know, draft-ietf-pkix-new-
part1-12.txt is with the RFC Editor.  However, an error in the ASN.1
modules was discovered.  The authors are working with the RFC Editor
to ensure that the corrected ASN.1 modules are included in the final
text, and we are publishing this Internet-Draft to distribute the
corrected ASN.1 modules as quickly as possible.
This Internet-Draft contains only the updated Appendix.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-asn1-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-new-part1-asn1-00.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-new-part1-asn1-00.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-new-part1-asn1-00.txt

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

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

--OtherAccess--

--NextPart--



Received: by above.proper.com (8.11.6/8.11.3) id g3JMMHw22690 for ietf-pkix-bks; Fri, 19 Apr 2002 15:22:17 -0700 (PDT)
Received: from smtp-1.llnl.gov (smtp-1.llnl.gov [128.115.250.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JMMGb22686 for <[e-mail]>; Fri, 19 Apr 2002 15:22:16 -0700 (PDT)
Received: from poptop.llnl.gov (localhost [127.0.0.1]) by smtp-1.llnl.gov (8.9.3/8.9.3/LLNL-gateway-1.0) with ESMTP id PAA16058; Fri, 19 Apr 2002 15:22:14 -0700 (PDT)
Received: from catalyst.llnl.gov (catalyst.llnl.gov [128.115.222.68]) by poptop.llnl.gov (8.8.8/LLNL-3.0.2/pop.llnl.gov-5.1) with ESMTP id PAA13505; Fri, 19 Apr 2002 15:22:13 -0700 (PDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Fri, 19 Apr 2002 15:33:49 -0800
To: "Housley, Russ" <[e-mail]>, [e-mail]
From: Tony Bartoletti <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
Cc: [e-mail], [e-mail]
In-Reply-To: <[e-mail] .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>

What about audible (wav,midi) logotypes for the sight-impaired?

____tony____


At 02:55 PM 4/19/02 -0400, Housley, Russ wrote:

>Peter:
>
>We have not allowed MPEGs, just static images in JPEG or GIF format.
>
>Russ
>
>At 03:30 PM 4/19/2002 +1200, Peter Gutmann wrote:
>>"Housley, Russ" <[e-mail]> writes:
>>
>> >What maximum size do you suggest?
>>
>>I would say 320x200 *minimum*, for the MPEGs :-).
>>
>>Peter.



Tony Bartoletti 925-422-3881 <[e-mail]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JLbGb21146 for ietf-pkix-bks; Fri, 19 Apr 2002 14:37:16 -0700 (PDT)
Received: from dymwsm13.mailwatch.com (dymwsm13.mailwatch.com [204.253.83.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JLbFb21142 for <[e-mail]>; Fri, 19 Apr 2002 14:37:15 -0700 (PDT)
Received: from MWSC0208.MW4.MAILWATCH.COM (mwsc0208.mw4.mailwatch.com [204.253.83.244]) by dymwsm13.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3JLaw001900 for <[e-mail]>; Fri, 19 Apr 2002 17:36:58 -0400
Received: from mail pickup service by MWSC0208.MW4.MAILWATCH.COM with Microsoft SMTPSVC; Fri, 19 Apr 2002 17:36:57 -0400
Received: from 204.253.83.26 ([204.253.83.26]) by MWSC0208 with SMTP id 0002000878da9616-18a3-4a8a-bd88-85cc6bbf515d;	 Fri, 19 Apr 2002 17:36:57 -0500
Received: from bigbird.entegrity.com (bigbird.gradient.com [192.92.110.50])	by dymwsm11.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3JLavh07628;	Fri, 19 Apr 2002 17:36:57 -0400
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10)	id <JC4CCTPB>; Fri, 19 Apr 2002 17:33:37 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, [e-mail]
Cc: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
Date: Fri, 19 Apr 2002 17:33:29 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: multipart/alternative;	boundary="----_=_NextPart_001_01C1E7E9.DCDE3692"
HOP-COUNT: 1
X-MAILWATCH-INSTANCEID: 0102000878da9616-18a3-4a8a-bd88-85cc6bbf515d
X-OriginalArrivalTime: 19 Apr 2002 21:36:57.0849 (UTC) FILETIME=[550EEE90:01C1E7EA]
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_01C1E7E9.DCDE3692
Content-Type: text/plain;
	charset="ISO-8859-1"

This is a reference to a historic joke made by Bob Juneneman. 

See: http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt

Hal

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Friday, April 19, 2002 2:55 PM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]
> Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
> 
> 
> 
> Peter:
> 
> We have not allowed MPEGs, just static images in JPEG or GIF format.
> 
> Russ
> 
> At 03:30 PM 4/19/2002 +1200, Peter Gutmann wrote:
> >"Housley, Russ" <[e-mail]> writes:
> >
> > >What maximum size do you suggest?
> >
> >I would say 320x200 *minimum*, for the MPEGs :-).
> >
> >Peter.
> 

------_=_NextPart_001_01C1E7E9.DCDE3692
Content-Type: text/html;
	charset="ISO-8859-1"
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=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>This is a reference to a historic joke made by Bob =
Juneneman. </FONT>
</P>

<P><FONT SIZE=3D2>See: <A =
HREF=3D"http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.txt" =
TARGET=3D"_blank">http://www.cs.auckland.ac.nz/~pgut001/pubs/x509guide.t=
xt</A></FONT>
</P>

<P><FONT SIZE=3D2>Hal</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Friday, April 19, 2002 2:55 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [e-mail]; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: I-D =
ACTION:draft-ietf-pkix-logotypes-02.txt</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Peter:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; We have not allowed MPEGs, just static images =
in JPEG or GIF format.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Russ</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At 03:30 PM 4/19/2002 +1200, Peter Gutmann =
wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&quot;Housley, Russ&quot; =
&lt;[e-mail]&gt; writes:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;What maximum size do you =
suggest?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;I would say 320x200 *minimum*, for the =
MPEGs :-).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Peter.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1E7E9.DCDE3692--


Received: by above.proper.com (8.11.6/8.11.3) id g3JItET10764 for ietf-pkix-bks; Fri, 19 Apr 2002 11:55:14 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3JItCb10757 for <[e-mail]>; Fri, 19 Apr 2002 11:55:12 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 19 Apr 2002 18:54:02 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA05535; Fri, 19 Apr 2002 14:53:50 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3JItHG23047; Fri, 19 Apr 2002 14:55:17 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX14T4B>; Fri, 19 Apr 2002 14:52:47 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.179]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX14TT8; Fri, 19 Apr 2002 14:52:42 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 19 Apr 2002 14:55:02 -0400
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
In-Reply-To: <[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>

Peter:

We have not allowed MPEGs, just static images in JPEG or GIF format.

Russ

At 03:30 PM 4/19/2002 +1200, Peter Gutmann wrote:
>"Housley, Russ" <[e-mail]> writes:
>
> >What maximum size do you suggest?
>
>I would say 320x200 *minimum*, for the MPEGs :-).
>
>Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JHafP07631 for ietf-pkix-bks; Fri, 19 Apr 2002 10:36:41 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JHaab07625 for <[e-mail]>; Fri, 19 Apr 2002 10:36:36 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA23696; Fri, 19 Apr 2002 19:36:27 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 19 Apr 2002 19:36:27 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA15434; Fri, 19 Apr 2002 19:36:22 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA10168; Fri, 19 Apr 2002 19:36:21 +0200 (MET DST)
Date: Fri, 19 Apr 2002 19:36:21 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: roadmap
Cc: [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>

Since I have not had a response from the editors of the roadmap, I'll
repeat some questions thta I have with the raodmap, propose some
textual changes, and some small nit-picking. 



I wonder which writing of Als name is correct. 

PKIX Working Group                                        A. Aresenault

OCSP and CMP are mentioned as 'draft standard', I guess this
should be 'proposed standard'

In order to more correctly reflect history I propose on page 7:


   protocol. [OCSP] was developed to address concerns that not all 
   relying parties want to go through the process checking CRLs from 
   every CA in the certification path. It defines an on-line mechanism 
   to determine the status of a given certificate, which may provide 
   more timely revocation information than is possible with CRLs. 

   [DVCS] also contains a service to determine the validity of 
   public key certificate using a TTP permitting to present the result
   of the verification as evidence in a non repudiation context.

   Another approach allowing relying parties to off-load all of
   their certification verification to another entity is the
   Simple Certification Verification Protocol (SCVP), for which a
   draft exist actually [SCVP]. 

I repeat my question to give a reference indicating where SCVP
has been selected as "THE" protocol. 

?   After considerable debate, 
?   the WG selected SCVP as the PKIX protocol for delegated path 
?   validation and delegated path discovery. A requirements document has 
?   been developed, and is currently under WG review. [DPREQ] Upon 
?   completion of [DPREQ], the SCVP protocol will be completed. 




?   specified time. Both [DVCS] and [TSP] use [CMS] as an encapsulating 
?   (though in [TSP] request for a time stamp are not required to use 
?   [CMS]). 

encapsulating what? 

   Both [DVCS] and [TSP] define CMS contenttypes to transport protocol
   information. [TSP] optionally uses CMS SignedData and an encapsulatin
   security envelope as an option for the requests, and mandatory for
   the resulting tokens. [DVCS] allow the optional usage of CMS security 
   envelopes permitting to authenticate requests and responses. 




           A draft for extending trust in tokens in time was developed 
   to use [DCVS] to maintain the trust in a token issued by a non- 
           DVCS
   repudiation Trusted Third Party (NR TTP) after the key initially used 
   to establish trust in the token expires; however, this draft has 
   expired. The [TRNRS] draft was developed to describe those features 
   of a service which processes signed documents that must be present in 
   order for that service to constitute a "technical non- repudiation" 
   service. 


I have the feeling that something is wrong in the following: 

     - PKC holders that are issued certificates and can sign digital 
       documents and encrypt documents; 
      
     - Clients that validate digital signatures and their certification 
       paths from a known public key of a trusted CA; 


Is an OCSP or DPV service part of a PKI? 


In a previous mail I have proposed an updated descrition of DVCS
reflecting the actual status of RFC 3029. 


     DESCRIPTION: This specification builds on the Online Certificate 
     Status Protocol (OSCP) framework's extensibility by defining an 
                      OCSP 
                     


"The lifetime of the object being singed."
                                  signed.


In the acknowledge list there is "Ed Greck', it should be 'Ed Gerck'
as far as I remember.

Very interesting alphabetic order :-)

please use ASCII characters instead of "ö" several occurences in
the References list. 

some examples:

   [TECHNR] Gindin, T., ôInternet X.509 Public Key Infrastructure 
   Technical Requirements for a non-Repudiation Service,ö <draft-ietf- 
   pkix-technr-01.txt>, July 2000. 


   [TPCMP] Kapoor , A., Tschal, R., ôTransport Protocols for CMP,ö


Received: by above.proper.com (8.11.6/8.11.3) id g3JFghG28319 for ietf-pkix-bks; Fri, 19 Apr 2002 08:42:43 -0700 (PDT)
Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JFggb28315 for <[e-mail]>; Fri, 19 Apr 2002 08:42:42 -0700 (PDT)
Received: from [128.89.89.113] (dhcp089-113.bbn.com [128.89.89.113]) by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id LAA11325; Fri, 19 Apr 2002 11:42:35 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05001932b8e5ed01657e@[128.89.89.113]>
Date: Fri, 19 Apr 2002 11:52:27 -0400
To: <[e-mail]>
From: Karen Seo <[e-mail]>
Subject: Re: draft-ietf-pkix-x509-ipaddr-as-extn-00.txt
Cc: [e-mail], [e-mail]
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 just added me to the pkix mailing list so that I could 
cc: this to you...


>  >From owner-ietf-pkix Fri Apr 19 07:02:12 2002
>Received: from gto-mailer1.bbn.com (cam-mailer1.bbn.com [128.33.0.36])
>	by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JE2Bb23080
>	for <[e-mail]>; Fri, 19 Apr 2002 07:02:11 -0700 (PDT)
>Received: from [128.89.89.113] (dhcp089-113.bbn.com [128.89.89.113])
>	by gto-mailer1.bbn.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10777;
>	Fri, 19 Apr 2002 10:01:24 -0400 (EDT)
>Mime-Version: 1.0
>X-Sender: [e-mail]
>Message-Id: <p0500192cb8e5d5c6f039@[128.89.89.113]>
>Date: Fri, 19 Apr 2002 10:11:16 -0400
>To: "Sanjaya" <[e-mail]>
>From: Karen Seo <[e-mail]>
>Subject: Re: draft-ietf-pkix-x509-ipaddr-as-extn-00.txt
>Cc: <[e-mail]>, [e-mail], [e-mail]
>Content-Type: text/plain; charset="us-ascii" ; format="flowed"
>
>Hello Sanjaya,
>
>Please accept my apologies for taking so long to reply.  Steve
>forwarded this to me and first I missed it, then I was sidelined by a
>rush proposal...
>
>>I'd like to make 2 comments on this draft:
>>
>>1. The term 'ownership of address space' is not used in RIR community.
>>      It implies that the address space is permanently given to somebody,
>>while
>>      in fact it is only temporarily allocated/assigned while the user still
>>has
>>      a relation with the registry (contract with an ISP or a membership with
>>RIR).
>>      Could we replace it with 'delegated to', 'allocated to', or 'assigned
>>to'?
>>      Also 'stewardship' is probably better than 'ownership' (it implies
>>responsibility
>>      as well).
>
>	Good point.  We'll revise the document to reflect this.
>
>>2. The use of attribute certificate (AC) for this purpose is also
>>appropriate.
>>      We can just add an attribute certificate whenever a new allocation is
>>      made, rather than revoking the PKC and create a new one with
>>      the new allocation added in the extension.
>>      However, for practical purpose (speed of authentication and authori-
>>      sation, for example), it make sense to attach the extension in an PKC.
>>      With this consideration, I propose that we add a profile of an AC as
>>part
>>      of this draft to ensure consistency in both approach, and to allow
>>flexibility
>>      in the implementation.
>
>	We are considering this.  One question that arises is where
>	to put the IP address and AS number information -- in an
>	"extension"  or as "attributes"?  If the latter, what would
>	we do about the "critical" field?  What are your thoughts
>	on this matter?
>
>Thank you,
Karen


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JEOHp24092 for ietf-pkix-bks; Fri, 19 Apr 2002 07:24:17 -0700 (PDT)
Received: from mail.utfors.se (mail.utfors.se [195.58.103.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JEOFb24086 for <[e-mail]>; Fri, 19 Apr 2002 07:24:16 -0700 (PDT)
Received: from arport ([62.119.75.13]) by mail.utfors.se (8.8.8/8.8.8) with SMTP id QAA01819; Fri, 19 Apr 2002 16:23:18 +0200 (MET DST)
Message-ID: <079801c1e7b5$ca4cc450$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, "Housley, Russ" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: "Olle Mulmo" <[e-mail]>, <[e-mail]>
References: <Your message of "Thu, 18 Apr 2002 15:57:39 -0400." <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-02.txt 
Date: Fri, 19 Apr 2002 17:20:45 +0200
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 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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,
During the 3039 process I suggested using mime-tags instead
of inventing new schemes.

http://www.imc.org/ietf-pkix/old-archive-99/msg00462.html

It seems that the idea has popped up again.
Then you may use PNG, AVI whatever.

If 3039 is to be revised I would look over this as well.

Anders

----- Original Message ----- 
From: "Stefan Santesson" <[e-mail]>
To: <[e-mail]>; "Housley, Russ" <[e-mail]>
Cc: "Olle Mulmo" <[e-mail]>; <[e-mail]>
Sent: Friday, April 19, 2002 14:48
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-02.txt 



Thank you for many useful comments,

Just one quick remark for now:
The logos are not intended for subjects (i.e. photos). They are intended 
exclusively for organizational and service branding logos.
An image of the subject (photo) can be attached and certified in the cert 
by using the biometric info extension defined in RFC 3039.

The image sizes suggested in the draft was not proposed out of science. It 
was an initial input to start the discussion.

/Stefan

At 10:59 2002-04-19 +1000, [e-mail] wrote:

> >Recall that there are two uses of the logos.  One use aids in the selection
> >of your own certificate from a portfolio. In this case, I envision the logo
> >being used as an icon to select a particular certificate.  The other use
> >provides a logo along with other information about a valid
> >certificate.  For example, the logo might be displayed along with other
> >information for a Web server.  In neither case should the logo dominate the
> >display.
> >
> >What maximum size do you suggest?
>
>Yes but you don't describe the other use which is to aid identification of
>the subject.  In this case 150x50 may well be insufficient for some uses
>(i.e identification of humans). There doesn't seem to be any good reason to
>limit the size of the external image.  For the use you describe, what is
>probably more important is the aspect-ratio, as the application can scale
>the image to any size.  Also the recommend for a black border seems to be
>unnecessary (is there a good reason for this?).  Lastly
>150x50 (I am assuming this is XxY) seems like a pretty odd aspect-ratio to
>pick.  I would of thought 100x100 made more sense.  A recommended size/
>aspect-ratio for logos with a SHOULD here seems more appropriate.
>
>Also I would prefer to see a statement in the draft to say "Applications
>SHOULD NOT use the embedded version unless offline processing of the
>certificate is required".  Adding an embedded image will roughly double
>the size of the cert, so we want to make sure implementers think carefully
>before they do it.  The draft should be worded to encourage the use of
>external images, and discourage the use of embedded images.
>
>Also I think the fields highRes and lowRes should be called externalImage and
>embeddedImage for this reason.
>
>Minor nit: In section 3, cashing -> caching
>
> >>Also, IMHO it would be better to identify GIF & JPEG pictures by their
> >>corresponding MIME types than to invent your own way of doing this. Also,
> >>if I read it all correctly, you actually require the that the referenced
> >>logotype file must have an uppercase suffix?
> >
> >We should update the file suffix part to indicate that either case is
> >acceptable.
> >
> >We do not want to point to a MIME encoded object.  Rather we want to point
> >to the GIF or JPEG binary object.  In this manner, one could use the same
> >file for many different purposes, including display on the organization's
> >web page.  This size seems appropriate for a logo in a header.
> >
>
>I think what Olle was trying to say was that rather than use the file
>extension to identify the image, we should be using the mime type (i.e.
>"image/gif", "image/jpeg" instead of GIF, JPG, JPEG).  I think this is a
>good idea as it means that the images are identified by a managed
>identifier.  Otherwise how do we define new image formats?  All this
>requires is changing imageFileExtn to imageMimeType and some words to that
>effect.
>
>Note that this means the reference to the external image should also
>contain this mime type.  This has the benefit of being an explicit
>statement about the image format, rather than an implicit interpretation
>of the file extension.  Text also should be added to say that the
>application should make sure that the retrieved image matches the expected
>image format.  It is quite easy for a browser to tell you the file with
>the extension JPG has the mime type image/gif.  Yet another reason to
>explicitly use the mime type.
>
>It may be worth adding a statement to security considerations about why it
>is important to include the image format in the certificate (either by mime
>type or file extension). The reason is that if the image format is not part
>of the signature it may be possible for an attacker to coerce the user into
>viewing the image in a different image format (but with the same binary
>image).  You can conceive that it would possible (but of course difficult)
>to construct an image that would view differently in two different image
>formats (especially with the various extension and options in image formats
>these days) and trick the CA into signing one of them.
>
>Also note that the specification MANDATES the support of GIF which is
>covered by a Unisys patent.  I don't think this will fly in the IETF.
>At the very least a patent statement is required.  A patent free
>alternative is PNG which is widely supported.
>
>Because both JPEG and GIF are allowed for the embedded image maybe wording
>should be added to the effect that "an application SHOULD use which ever
>image format is smaller"). (GIF is often smaller for simple images with
>not many colors, whereas JPEG usually does better on photo type images with
>lots of colors).
>
>Lastly, I think a good restriction to add would be that the images should be
>static (i.e. not use any of the animated extensions).
>--
>Dean Povey,              |em: [e-mail] |  JCSI: Java security 
>toolkit
>Senior S/W Developer     |ph:  [phone]    | uPKI: Embedded/C PKI 
>toolkit
>Wedgetail Communications |fax: [phone]    | uSSL: Embedded/C SSL 
>toolkit
>Brisbane, Australia      |www: www.wedgetail.com  | XML Security: XML 
>Signatures




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JDuGV22261 for ietf-pkix-bks; Fri, 19 Apr 2002 06:56:16 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JDu4b22241 for <[e-mail]>; Fri, 19 Apr 2002 06:56:05 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g3JDtvvV027846; Fri, 19 Apr 2002 09:55:57 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 19 Apr 2002 09:54:02 -0400
To: [e-mail], [e-mail]
From: Tim Polk <[e-mail]>
Subject: Request for IESG consideration: CP/CPS Framework
Cc: [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>

Jeff & Steve,

The PKIX working group has achieved rough consensus and completed WG Last 
Call 
for 
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-01.txt, 
  "Internet X.509 Public Key Infrastructure Certificate Policy and 
ertification Practices Framework".  Please consider this specification for 
submission to the IESG for advancement to RFC status.

This specification is an update to, and obsoletes, the current 
Informational Standard RFC 2527 (which has the same name). As with the 
specification it obsoletes, we believe that informational track would be 
appropriate for this specification.

Thanks,

Tim Polk






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JDRLA19269 for ietf-pkix-bks; Fri, 19 Apr 2002 06:27:21 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JDRJb19262 for <[e-mail]>; Fri, 19 Apr 2002 06:27:19 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA22157 for <[e-mail]>; Fri, 19 Apr 2002 15:27:18 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Fri, 19 Apr 2002 15:27:18 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA14576 for <[e-mail]>; Fri, 19 Apr 2002 15:27:17 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA10070 for [e-mail]; Fri, 19 Apr 2002 15:27:17 +0200 (MET DST)
Date: Fri, 19 Apr 2002 15:27:17 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: <draft-ietf-pkix-dpv-dpd-req-04.txt>
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 proposals for a text change. 



> 
> The client can request that the server determine the certificate
> validity at a time other than the current time. The DPV server MUST
> obtain revocation status information for the validation time
> in the client request.
> In order to obtain the revocation status information of any
> certificate from the certification path, the DPV server might use, in
> accordance with the validation policy, different sources of revocation
> information, e.g. a combination of OCSP responses, CRLs, or delta-CRLs.
> If the revocation status information for the requested validation time
> is unavailable, then the DPV server MUST return a status indicating
> that the certificate is invalid.
replace by: 

The DPV server MUST produce certificate status information for
the validation time in the client request. In order to do this,
the server might use, in accordance with the validation policy,
different sources of external information concerning revocation 
information, e.g., a combination of OCSP responses, CRLs, or
delta-CRLs, or other status information from other DPV servers. 

If the certificate status information for the requested validation
time is cannot be created, then the DPV server MUST return a status 
indicating that the certificate is invalid.

> 
> The DPV client MUST be able to provide to the validation server,
> associated with each certificate to be validated, "useful
> certificates", as well as "useful revocation information". Revocation
> information includes OCSP responses, CRLs, and delta-CRLs.
replace by: 

The DPV client MUST be able to provide to the validation server,
associated with each certificate to be validated, "useful
certificates", as well as "useful information" e.g., revocation
information of OCSP responses, CRLs, and delta-CRLs, or status
information from other DPV servers.
 
> The DPV response MUST be bound to the DPV request. This can be
> accomplished by repeating the important components from the request in
> the response or by including a one-way hash of the request in the
> response.
add:

In some environments it may be necessary to present only a response
to another relying party without the corresponding request. 
In this case the response MUST be sufficient self contained.  

> 
> 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
> (e.g. a badly formatted request, etc.). The certificate from the DPV
> server SHALL be used to identify the DPV server.

Replace 'identify' with 'authenticate'.


> another DPV server. Unlike the original client, the DPV server is
> expected to have moderate computing and memory resources, enabling the
                   sufficient ???



----- End Included Message -----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3JCnNB17934 for ietf-pkix-bks; Fri, 19 Apr 2002 05:49:23 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JCnHb17927 for <[e-mail]>; Fri, 19 Apr 2002 05:49:21 -0700 (PDT)
Received: from stsIBMT20.addtrust.com ([192.168.101.122]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 19 Apr 2002 14:48:48 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 19 Apr 2002 14:48:47 +0200
To: [e-mail], "Housley, Russ" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-02.txt 
Cc: Olle Mulmo <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
References: <Your message of "Thu, 18 Apr 2002 15:57:39 -0400." <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-OriginalArrivalTime: 19 Apr 2002 12:48:48.0565 (UTC) FILETIME=[8CC5EE50:01C1E7A0]
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>

Thank you for many useful comments,

Just one quick remark for now:
The logos are not intended for subjects (i.e. photos). They are intended 
exclusively for organizational and service branding logos.
An image of the subject (photo) can be attached and certified in the cert 
by using the biometric info extension defined in RFC 3039.

The image sizes suggested in the draft was not proposed out of science. It 
was an initial input to start the discussion.

/Stefan

At 10:59 2002-04-19 +1000, [e-mail] wrote:

> >Recall that there are two uses of the logos.  One use aids in the selection
> >of your own certificate from a portfolio. In this case, I envision the logo
> >being used as an icon to select a particular certificate.  The other use
> >provides a logo along with other information about a valid
> >certificate.  For example, the logo might be displayed along with other
> >information for a Web server.  In neither case should the logo dominate the
> >display.
> >
> >What maximum size do you suggest?
>
>Yes but you don't describe the other use which is to aid identification of
>the subject.  In this case 150x50 may well be insufficient for some uses
>(i.e identification of humans). There doesn't seem to be any good reason to
>limit the size of the external image.  For the use you describe, what is
>probably more important is the aspect-ratio, as the application can scale
>the image to any size.  Also the recommend for a black border seems to be
>unnecessary (is there a good reason for this?).  Lastly
>150x50 (I am assuming this is XxY) seems like a pretty odd aspect-ratio to
>pick.  I would of thought 100x100 made more sense.  A recommended size/
>aspect-ratio for logos with a SHOULD here seems more appropriate.
>
>Also I would prefer to see a statement in the draft to say "Applications
>SHOULD NOT use the embedded version unless offline processing of the
>certificate is required".  Adding an embedded image will roughly double
>the size of the cert, so we want to make sure implementers think carefully
>before they do it.  The draft should be worded to encourage the use of
>external images, and discourage the use of embedded images.
>
>Also I think the fields highRes and lowRes should be called externalImage and
>embeddedImage for this reason.
>
>Minor nit: In section 3, cashing -> caching
>
> >>Also, IMHO it would be better to identify GIF & JPEG pictures by their
> >>corresponding MIME types than to invent your own way of doing this. Also,
> >>if I read it all correctly, you actually require the that the referenced
> >>logotype file must have an uppercase suffix?
> >
> >We should update the file suffix part to indicate that either case is
> >acceptable.
> >
> >We do not want to point to a MIME encoded object.  Rather we want to point
> >to the GIF or JPEG binary object.  In this manner, one could use the same
> >file for many different purposes, including display on the organization's
> >web page.  This size seems appropriate for a logo in a header.
> >
>
>I think what Olle was trying to say was that rather than use the file
>extension to identify the image, we should be using the mime type (i.e.
>"image/gif", "image/jpeg" instead of GIF, JPG, JPEG).  I think this is a
>good idea as it means that the images are identified by a managed
>identifier.  Otherwise how do we define new image formats?  All this
>requires is changing imageFileExtn to imageMimeType and some words to that
>effect.
>
>Note that this means the reference to the external image should also
>contain this mime type.  This has the benefit of being an explicit
>statement about the image format, rather than an implicit interpretation
>of the file extension.  Text also should be added to say that the
>application should make sure that the retrieved image matches the expected
>image format.  It is quite easy for a browser to tell you the file with
>the extension JPG has the mime type image/gif.  Yet another reason to
>explicitly use the mime type.
>
>It may be worth adding a statement to security considerations about why it
>is important to include the image format in the certificate (either by mime
>type or file extension). The reason is that if the image format is not part
>of the signature it may be possible for an attacker to coerce the user into
>viewing the image in a different image format (but with the same binary
>image).  You can conceive that it would possible (but of course difficult)
>to construct an image that would view differently in two different image
>formats (especially with the various extension and options in image formats
>these days) and trick the CA into signing one of them.
>
>Also note that the specification MANDATES the support of GIF which is
>covered by a Unisys patent.  I don't think this will fly in the IETF.
>At the very least a patent statement is required.  A patent free
>alternative is PNG which is widely supported.
>
>Because both JPEG and GIF are allowed for the embedded image maybe wording
>should be added to the effect that "an application SHOULD use which ever
>image format is smaller"). (GIF is often smaller for simple images with
>not many colors, whereas JPEG usually does better on photo type images with
>lots of colors).
>
>Lastly, I think a good restriction to add would be that the images should be
>static (i.e. not use any of the animated extensions).
>--
>Dean Povey,              |em: [e-mail] |  JCSI: Java security 
>toolkit
>Senior S/W Developer     |ph:  [phone]    | uPKI: Embedded/C PKI 
>toolkit
>Wedgetail Communications |fax: [phone]    | uSSL: Embedded/C SSL 
>toolkit
>Brisbane, Australia      |www: www.wedgetail.com  | XML Security: XML 
>Signatures



Received: by above.proper.com (8.11.6/8.11.3) id g3JBN7M13023 for ietf-pkix-bks; Fri, 19 Apr 2002 04:23:07 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3JBN5b13015 for <[e-mail]>; Fri, 19 Apr 2002 04:23:06 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16015; Fri, 19 Apr 2002 07:23:04 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-warranty-extn-00.txt
Date: Fri, 19 Apr 2002 07:23:04 -0400
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		: Warranty Certificate Extension
	Author(s)	: D. Linsenbardt, S. Pontius
	Filename	: draft-ietf-pkix-warranty-extn-00.txt
	Pages		: 7
	Date		: 18-Apr-02
	
This document describes a certificate extension to explicitly state
the warranty offered by a Certificate Authority (CA) for a the
certificate containing the extension.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-warranty-extn-00.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-warranty-extn-00.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-warranty-extn-00.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g3J3Us124200 for ietf-pkix-bks; Thu, 18 Apr 2002 20:30:54 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J3Uqb24195 for <[e-mail]>; Thu, 18 Apr 2002 20:30:52 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.2/8.12.2) with ESMTP id g3J3Upuc006072; Fri, 19 Apr 2002 15:30:51 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA45483; Fri, 19 Apr 2002 15:30:49 +1200 (NZST) (sender [e-mail])
Date: Fri, 19 Apr 2002 15:30:49 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
Cc: [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>

"Housley, Russ" <[e-mail]> writes:

>What maximum size do you suggest?

I would say 320x200 *minimum*, for the MPEGs :-).

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3J1sEZ20434 for ietf-pkix-bks; Thu, 18 Apr 2002 18:54:14 -0700 (PDT)
Received: from mailo.vtcif.telstra.com.au (mailo.vtcif.telstra.com.au [202.12.144.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J1sC720430 for <[e-mail]>; Thu, 18 Apr 2002 18:54:12 -0700 (PDT)
Received: (from uucp@localhost) by mailo.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA09721 for <[e-mail]>; Fri, 19 Apr 2002 11:54:09 +1000 (EST)
Received: from maili.vtcif.telstra.com.au(202.12.142.17) via SMTP by mailo.vtcif.telstra.com.au, id smtpdxa_1h_; Fri Apr 19 11:53:30 2002
Received: (from uucp@localhost) by maili.vtcif.telstra.com.au (8.8.2/8.6.9) id LAA03844 for <[e-mail]>; Fri, 19 Apr 2002 11:53:29 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpd0xjSxj; Fri Apr 19 11:52:54 2002
Received: from ntmsg0028.corpmail.telstra.com.au (ntmsg0028.corpmail.telstra.com.au [192.168.174.24]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id LAA15649 for <[e-mail]>; Fri, 19 Apr 2002 11:52:53 +1000 (EST)
Received: by ntmsg0028.corpmail.telstra.com.au with Internet Mail Service (5.5.2655.55) id <JGFYXZTP>; Fri, 19 Apr 2002 11:52:53 +1000
Message-ID: <[e-mail]>
From: "Manger, James H" <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
Date: Fri, 19 Apr 2002 11:52:44 +1000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain
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>

A referenced logo WILL be identified by a MIME-type.  Dereferencing the URI
will (presumably) result in something like the following (with various other
header fields omitted):

	HTTP/1.1 200 OK
	Content-Length: 177
	Last-Modified: Thu, 18 Sep 1997 04:22:02 GMT
	Content-Type: image/gif

	GIF89aJH&^%&^b6TB^(&...

A ".gif" extension in the URL may suggest a "image/gif" MIME-type will be
returned, but a web server is actually free to return any MIME-type it
wants.  I think browsers will (and should) process the result based on the
MIME-type instead of the URI extension.

So perhaps it would be better for the 'imageFileExtn' field to be
'imageContentType' and hold a MIME-type.  (might you ever what to include
other MIME header fields? in which case a 'imageMIMEHeaders' field might be
needed instead.)


There is no description of the 'logotypeHash' field.  I suspect the authors
intention is to hash the bytes of the *.gif (or *.jpeg) file, excluding any
MIME or HTTP headers fields delivered with the image.  Presumably any
transfer encoding (but not Content-Encoding?) is also removed before
hashing?

Such a hash does not bind the content to the MIME-type.  This maybe
acceptable, though it might warrant a paragraph in the security
considerations section.


Change the 'highRes' and 'lowRes' field names to, say, 'reference' and
'embedded' (or 'indirect' and 'direct').  Which resolutions are appropriate
is a matter of judgement, policy, environment or best practise -- so it
should be discussed in the document, but not hard-wired into the syntax.



> ----------
> From:	Housley, Russ [SMTP:[e-mail]]
> Sent:	Friday, 19 April 2002 5:58 am
> 
> >..Also, IMHO it would be better to identify GIF & JPEG pictures by their 
> >corresponding MIME types than to invent your own way of doing this..
> 
	..We do not want to point to a MIME encoded object.  Rather we want
to point 
> to the GIF or JPEG binary object.  In this manner, one could use the same 
> file for many different purposes, including display on the organization's 
> web page.  This size seems appropriate for a logo in a header.
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3J0xrS19428 for ietf-pkix-bks; Thu, 18 Apr 2002 17:59:53 -0700 (PDT)
Received: from osprey.wedgetail.com (starling.wedgetail.com [202.83.95.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3J0xp719424 for <[e-mail]>; Thu, 18 Apr 2002 17:59:51 -0700 (PDT)
Received: from wedgetail.com (coot.wedgetail.com [10.10.10.4]) by osprey.wedgetail.com (8.12.2/8.12.2) with ESMTP id g3J0xl5a022714; Fri, 19 Apr 2002 10:59:48 +1000 (EST)
Message-Id: <[e-mail]>
X-Mailer: exmh exmh 2.5 (2001-07-13) with nmh-1.0.4
From: [e-mail]
To: "Housley, Russ" <[e-mail]>
cc: Olle Mulmo <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-02.txt 
In-reply-to: Your message of "Thu, 18 Apr 2002 15:57:39 -0400." <[e-mail]> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 19 Apr 2002 10:59:47 +1000
X-Scanned-By: MIMEDefang 2.6 (www dot roaringpenguin dot com slash 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>

>Recall that there are two uses of the logos.  One use aids in the selection 
>of your own certificate from a portfolio. In this case, I envision the logo 
>being used as an icon to select a particular certificate.  The other use 
>provides a logo along with other information about a valid 
>certificate.  For example, the logo might be displayed along with other 
>information for a Web server.  In neither case should the logo dominate the 
>display.
>
>What maximum size do you suggest?

Yes but you don't describe the other use which is to aid identification of
the subject.  In this case 150x50 may well be insufficient for some uses
(i.e identification of humans). There doesn't seem to be any good reason to
limit the size of the external image.  For the use you describe, what is
probably more important is the aspect-ratio, as the application can scale
the image to any size.  Also the recommend for a black border seems to be
unnecessary (is there a good reason for this?).  Lastly
150x50 (I am assuming this is XxY) seems like a pretty odd aspect-ratio to
pick.  I would of thought 100x100 made more sense.  A recommended size/
aspect-ratio for logos with a SHOULD here seems more appropriate.

Also I would prefer to see a statement in the draft to say "Applications 
SHOULD NOT use the embedded version unless offline processing of the 
certificate is required".  Adding an embedded image will roughly double 
the size of the cert, so we want to make sure implementers think carefully 
before they do it.  The draft should be worded to encourage the use of 
external images, and discourage the use of embedded images.

Also I think the fields highRes and lowRes should be called externalImage and 
embeddedImage for this reason.

Minor nit: In section 3, cashing -> caching 

>>Also, IMHO it would be better to identify GIF & JPEG pictures by their 
>>corresponding MIME types than to invent your own way of doing this. Also, 
>>if I read it all correctly, you actually require the that the referenced 
>>logotype file must have an uppercase suffix?
>
>We should update the file suffix part to indicate that either case is 
>acceptable.
>
>We do not want to point to a MIME encoded object.  Rather we want to point 
>to the GIF or JPEG binary object.  In this manner, one could use the same 
>file for many different purposes, including display on the organization's 
>web page.  This size seems appropriate for a logo in a header.
>

I think what Olle was trying to say was that rather than use the file 
extension to identify the image, we should be using the mime type (i.e.
"image/gif", "image/jpeg" instead of GIF, JPG, JPEG).  I think this is a 
good idea as it means that the images are identified by a managed 
identifier.  Otherwise how do we define new image formats?  All this 
requires is changing imageFileExtn to imageMimeType and some words to that 
effect.

Note that this means the reference to the external image should also
contain this mime type.  This has the benefit of being an explicit 
statement about the image format, rather than an implicit interpretation 
of the file extension.  Text also should be added to say that the 
application should make sure that the retrieved image matches the expected 
image format.  It is quite easy for a browser to tell you the file with 
the extension JPG has the mime type image/gif.  Yet another reason to 
explicitly use the mime type.

It may be worth adding a statement to security considerations about why it
is important to include the image format in the certificate (either by mime
type or file extension). The reason is that if the image format is not part
of the signature it may be possible for an attacker to coerce the user into
viewing the image in a different image format (but with the same binary
image).  You can conceive that it would possible (but of course difficult)
to construct an image that would view differently in two different image
formats (especially with the various extension and options in image formats
these days) and trick the CA into signing one of them. 

Also note that the specification MANDATES the support of GIF which is 
covered by a Unisys patent.  I don't think this will fly in the IETF.  
At the very least a patent statement is required.  A patent free 
alternative is PNG which is widely supported.

Because both JPEG and GIF are allowed for the embedded image maybe wording
should be added to the effect that "an application SHOULD use which ever
image format is smaller"). (GIF is often smaller for simple images with 
not many colors, whereas JPEG usually does better on photo type images with 
lots of colors).

Lastly, I think a good restriction to add would be that the images should be 
static (i.e. not use any of the animated extensions).
-- 
Dean Povey,              |em: [e-mail] |  JCSI: Java security toolkit
Senior S/W Developer     |ph:  [phone]    | uPKI: Embedded/C PKI toolkit
Wedgetail Communications |fax: [phone]    | uSSL: Embedded/C SSL toolkit
Brisbane, Australia      |www: www.wedgetail.com  | XML Security: XML Signatures 






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3IJvpm05614 for ietf-pkix-bks; Thu, 18 Apr 2002 12:57:51 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3IJvo705608 for <[e-mail]>; Thu, 18 Apr 2002 12:57:50 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 18 Apr 2002 19:56:40 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA09653 for <[e-mail]>; Thu, 18 Apr 2002 15:56:28 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3IJvsT02999 for <[e-mail]>; Thu, 18 Apr 2002 15:57:54 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX14G27>; Thu, 18 Apr 2002 15:55:24 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.60]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX14G26; Thu, 18 Apr 2002 15:55:22 -0400
From: "Housley, Russ" <[e-mail]>
To: Olle Mulmo <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 18 Apr 2002 15:57:39 -0400
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
In-Reply-To: <[e-mail] m>
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>

Olle:

>I couldn't help but noticing the logotype "format restrictions" table... I 
>don't think a Marketing dept will ever be satisfied with a 150x50 
>limitation on a "hi-resolution" logotype: especially not those that have 
>circular logos... From where does this limit originate? Is there any 
>deeper reasoning or motivation behind, or is it there just to give me a 
>good laugh?

I am glad you got a good laugh, but it was not intended as a joke.

Recall that there are two uses of the logos.  One use aids in the selection 
of your own certificate from a portfolio. In this case, I envision the logo 
being used as an icon to select a particular certificate.  The other use 
provides a logo along with other information about a valid 
certificate.  For example, the logo might be displayed along with other 
information for a Web server.  In neither case should the logo dominate the 
display.

What maximum size do you suggest?

>Also, IMHO it would be better to identify GIF & JPEG pictures by their 
>corresponding MIME types than to invent your own way of doing this. Also, 
>if I read it all correctly, you actually require the that the referenced 
>logotype file must have an uppercase suffix?

We should update the file suffix part to indicate that either case is 
acceptable.

We do not want to point to a MIME encoded object.  Rather we want to point 
to the GIF or JPEG binary object.  In this manner, one could use the same 
file for many different purposes, including display on the organization's 
web page.  This size seems appropriate for a logo in a header.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3IHahs26741 for ietf-pkix-bks; Thu, 18 Apr 2002 10:36:43 -0700 (PDT)
Received: from mail.smarttrust.com ([213.212.5.232]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IHafm26737 for <[e-mail]>; Thu, 18 Apr 2002 10:36:41 -0700 (PDT)
Received: from sek43.smarttrust.com ([172.16.0.43]) by mail.smarttrust.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 18 Apr 2002 19:36:37 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Subject: RE: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
Date: Thu, 18 Apr 2002 19:36:37 +0200
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
Thread-Index: AcHm31F5Jt321iSBS6GuAH72U89viwAHeJbA
From: "Olle Mulmo" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 18 Apr 2002 17:36:37.0243 (UTC) FILETIME=[974B54B0:01C1E6FF]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3IHafm26738
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 authors,

I couldn't help but noticing the logotype "format restrictions" table... I don't think a Marketing dept will ever be satisfied with a 150x50 limitation on a "hi-resolution" logotype: especially not those that have circular logos... From where does this limit originate? Is there any deeper reasoning or motivation behind, or is it there just to give me a good laugh?

Also, IMHO it would be better to identify GIF & JPEG pictures by their corresponding MIME types than to invent your own way of doing this. Also, if I read it all correctly, you actually require the that the referenced logotype file must have an uppercase suffix?

I sincerely hope for a (heavily) revised update of this draft.

Regards,

/Olle


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Thursday, April 18, 2002 2:01 PM
Cc: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-02.txt


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 Logotypes in 
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-02.txt
	Pages		: 16
	Date		: 17-Apr-02
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [e-mail]
mailing list.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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


Received: by above.proper.com (8.11.6/8.11.3) id g3IJEUZ03237 for ietf-pkix-bks; Thu, 18 Apr 2002 12:14:30 -0700 (PDT)
Received: from edelweb.fr ([212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IJEH703212 for <[e-mail]>; Thu, 18 Apr 2002 12:14:18 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id VAA18148; Thu, 18 Apr 2002 21:13:55 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.4); Thu, 18 Apr 2002 21:13:56 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id VAA11256; Thu, 18 Apr 2002 21:13:47 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id VAA09759; Thu, 18 Apr 2002 21:13:47 +0200 (MET DST)
Date: Thu, 18 Apr 2002 21:13:47 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Open issue: DPV additional information
Cc: [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>

> Currently, there are assumed models and/or
> statements about the relationships. If
> they stay, they must become more coherent.
> 
> Currently a DPV server is a mystical NR-supporting
> server (Denis), that (somehow) will enforce a CA 
> authorization over CRL and OCSP issuers (Denis), but
> will itself will not be authorized by a CA (Denis), but
> the service may be provided by a CA using a CAs cert/CRL
> signing key (Mike) that uses validation policies of 
> unknown rules (not limited to trust-anchors and X.509 path
> processing parameters) to indicate to a relying party
> that a given chain is valid under the policy, and will
> supply its sources of asurnace (certs, CRLS, OCSP responses) to the RP to
> maintain
> as evidence alongside the DPV response.
> 
> And somewhere in all this, there is something
> about signature policies.

Is this so mystical? One could also resume some functions of DPV like:

A DPV server is a Trusted Third Party (TTP) providing a validation
service, asserting validity of public key certificates.
As a result of the validation, a DPV generates a DPV attestation.

The DPV attestation can be used for constructing evidence of 
non-repudiation related to the validity of an entity's public
key certificate. 

The presence of a DPV attestation supports non-repudiation by providing 
evidence that a public key certificate was valid at the time indicated in
the DPV attestation.

A DPV response can for example be used even after the public key certificate
expires and its revocation information is no longer or not easily available.


Received: by above.proper.com (8.11.6/8.11.3) id g3IC10Z06459 for ietf-pkix-bks; Thu, 18 Apr 2002 05:01:00 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IC0xm06455 for <[e-mail]>; Thu, 18 Apr 2002 05:00:59 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02041; Thu, 18 Apr 2002 08:00:56 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-asn1-00.txt
Date: Thu, 18 Apr 2002 08:00:56 -0400
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		: Update for Appendix A in 
                          draft-ietf-pkix-new-part1-12.txt
	Author(s)	: R. Housley, W. Polk
	Filename	: draft-ietf-pkix-new-part1-asn1-00.txt
	Pages		: 24
	Date		: 17-Apr-02
	
As all members of the PKIX Working Group know, draft-ietf-pkix-new-
part1-12.txt is with the RFC Editor.  However, an error in the ASN.1
modules was discovered.  The authors are working with the RFC Editor
to ensure that the corrected ASN.1 modules are included in the final
text, and we are publishing this Internet-Draft to distribute the
corrected ASN.1 modules as quickly as possible.
This Internet-Draft contains only the updated Appendix.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-new-part1-asn1-00.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-new-part1-asn1-00.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-new-part1-asn1-00.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-new-part1-asn1-00.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g3IC0to06451 for ietf-pkix-bks; Thu, 18 Apr 2002 05:00:55 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IC0sm06447 for <[e-mail]>; Thu, 18 Apr 2002 05:00:54 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02025; Thu, 18 Apr 2002 08:00:52 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-logotypes-02.txt
Date: Thu, 18 Apr 2002 08:00:51 -0400
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 Logotypes in 
                          X.509 certificates
	Author(s)	: S. Santesson, R. Housley, T. Freeman
	Filename	: draft-ietf-pkix-logotypes-02.txt
	Pages		: 16
	Date		: 17-Apr-02
	
This document specifies a certificate extension for including
logotypes in public key certificates and attribute certificates.
Please send comments on this document to the [e-mail]
mailing list.

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

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-logotypes-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-logotypes-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-logotypes-02.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g3IC0l906436 for ietf-pkix-bks; Thu, 18 Apr 2002 05:00:47 -0700 (PDT)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3IC0km06430 for <[e-mail]>; Thu, 18 Apr 2002 05:00:46 -0700 (PDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA02009; Thu, 18 Apr 2002 08:00:44 -0400 (EDT)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-04.txt
Date: Thu, 18 Apr 2002 08:00:44 -0400
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		: Delegated Path Validation and Delegated Path Discovery
                          Protocol Requirements (DPV&DPD-REQ)
	Author(s)	: D. Pinkas, R. Housley
	Filename	: draft-ietf-pkix-dpv-dpd-req-04.txt
	Pages		: 12
	Date		: 17-Apr-02
	
This document specifies the requirements for Delegated Path Validation 
(DPV) and Delegated Path Discovery (DPD) for Public Key Certificates. 
It also specifies the requirements for DPV and DPD policy management.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-04.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

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-dpv-dpd-req-04.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-dpv-dpd-req-04.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-dpv-dpd-req-04.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HMdF307018 for ietf-pkix-bks; Wed, 17 Apr 2002 15:39:15 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HMdEm07014 for <[e-mail]>; Wed, 17 Apr 2002 15:39:14 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3HMd4Pm024951; Wed, 17 Apr 2002 15:39:04 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Peter Williams" <[e-mail]>
Cc: "pkix" <[e-mail]>, "Denis Pinkas" <[e-mail]>
Subject: CAs as DPV responders
Date: Wed, 17 Apr 2002 15:36:16 -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
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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,

I believe we should segregate this discussion from the
progression of the requirements document since to my knowledge
there exists no normative requirement or advisory text on this
point.  So I changed the subject line.  A few comments below.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Peter Williams
> Sent: Wednesday, April 17, 2002 12:41 PM
> To: 'Michael Myers'
> Cc: pkix; Denis Pinkas
> Subject: RE: Open issue: DPV additional information
>
>
>
> Mike,
>
> What Denis is apparently saying is:
>
> - unlike OCSP (and OCSPv2) which standardizes an
>   authorization model for CA-authorized "responders",
>   and a non-CA "local-trust" model for "local responders"
>
> - DPV requirements do NOT call for standardization
>   of these two issues (authorization and local trust)
>   in the DPV protocol to be specified
>

This is because the DPV/DPD requirements I-D (at least as
I see it) is a systems-level requirements document.  It
defines the boundary conditions.  Within that envelope,
there's still a lot of wiggle room.  That in my mind is
the very definition of a good systems requirement document.

> - He makes various broad-ranging assumptions on these
>   very issues, however, that we are determining from
>   the thread what the assumptions are.

This thread will go on for a while I think, in one form
or another.  But as Hal pointed out, it's possible Denis
and I are talking past each other.  I accept this as likely.

> I think the only 2 substantive points that PeterW, PeterS, and
> Denis and others are discussing, include
>
> 1) Whether the DPV requirements *should* specify means
> to address the DPV dependent-services authorization and
> trust issues (e.g. these issues as they affect path processing
> supporting CRL handling, these issues as they affect OCSP
> response acceptance handling, and these issues as they affect
> OCSP response chain's own path processing)

In my opinion, many of these issues are deployment
related and thus out of scope of the specification
of a technical protocol, which is where we're headed.

> 2) We seek to flush out Denis' assumption about his model
> of the authorization and local-trust relations between
> CA/AAs, DPV servers, and EE relying-parties, and find out
> which entity and protocol state will be responsible for
> enforcing the authorization and local-trust rules, once
> we get to protocol specification.

Somewhat disagree.  We ultimately seek the *WG's* consensus
on these points.  At least that's how I'm approaching it.

> If we use your OSCP v2 work as a guide, we can reason thus:
>
> My (and implicitely your) suggestion is that DPV
> handle authorization and local-trust issues in the
> way that OCSP does - as the OCSP standard had pragmatically
> suceeded to balance both CA-focussed and RP-focussed
> relationship models between the CA/AA, OCSP responder, and
> EE-RP parties.

Well, thank you I guess.  I figure our work on OCSP might have
had a clue or two, but we shall see.

> The OCSP solution to the issues would obviously
> come built into DPV, if we specify a DPV using
> OCSPv2, lets note. AS Denis seems to deny, however,
> the legltimacy of the OCSP way of handling these issues
> for DPV needs, we cannot simply do OCSP v2, as is, to
> perform a DPV protocol: Why not, as OCSP's standardization
> per se contradicts Denis' model of the relationships
> between the players.
>
> Im not saying I agree with Denis. But if I translate his
> aphorisms, this is what he seems to be actually stating. My
> statement of the implications for OCSP (v2) or any
> other protocol design following the OCSP heritage, then
> follow.
>
> Peter.
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HM4k506313 for ietf-pkix-bks; Wed, 17 Apr 2002 15:04:46 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HM4jm06309 for <[e-mail]>; Wed, 17 Apr 2002 15:04:45 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 17 Apr 2002 15:01:57 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 17 Apr 2002 15:01:57 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <JACGZTD2>; Wed, 17 Apr 2002 15:04:39 -0700
Content-return: allowed
Date: Wed, 17 Apr 2002 15:04:38 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Open issue: DPV additional information
To: "'Hal Lockhart'" <[e-mail]>, "'Michael Myers'" <[e-mail]>, Denis Pinkas <[e-mail]>, [e-mail]
Cc: pkix <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative; boundary="Boundary_(ID_oAPiua89CznGsrhj404/Fw)"
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.

--Boundary_(ID_oAPiua89CznGsrhj404/Fw)
Content-type: text/plain; charset="iso-8859-1"

At Mike's suggestion, Ive looked to your mail as a way of exiting
the thread.
 
Im happy  with your (very informal) statement about one important issue, and
agree
that it represents what Denis and the requirements document should be
conveying.
 
Providing that Denisand Russ both agree the DPV requirements entail the
following
matter (informally expressed), I am happy to proceed, on this issue:
 
Without prejudice to other modes of operation, 
a DPV server can use an OCSP response issued by an OCSP
responder that is locally trusted by the DPV client through a validation
policy rule) and that the DPV server will accept the OCSP response on the
client's behalf 
in a manner conforming to the rules of OCSP standard.
 
Given every opportunity to confirm this entailment, todate, Denis
has not done so. With confirmation, we can proceed.

-----Original Message-----
From: Hal Lockhart [mailto:[e-mail]]
Sent: Wednesday, April 17, 2002 10:23 AM
To: 'Michael Myers'; Denis Pinkas; [e-mail]
Cc: pkix
Subject: RE: Open issue: DPV additional information



As entertaining as it is to watch you guys talk past each other, this thread
is getting tiresome. Let me take a crack at why I don't think there is any
real disagreement here.

I think what Denis is saying is that if an entity is a CA, by definition
they are trusted to issue and revoke the certificates they issue, by virture
of being a CA. They can also delegate someone else to do the revocation,
also by virtue of being a CA. If a RP decides to trust their certs, they
must also trust their revocation arrangements.

In contrast, when somebody sets up a DPV server, whether or not they also
run a CA, there is an independant decision to trust the DPV server. It does
not follow as an automatic consequence of the fact thet the same
organization (or key even) may have issued one or more of the certs in the
chain in question.

In other words, a CA may run a DPV server, but the server will be trusted
because RPs choose to do so, not because they have previously chosen to
trust certs issued by the CA.

Everybody agree? ;-) 

Hal 

> -----Original Message----- 
> From: Michael Myers [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, April 17, 2002 11:22 AM 
> To: Denis Pinkas; [e-mail] 
> Cc: pkix 
> Subject: RE: Open issue: DPV additional information 
> 
> 
> 
> Denis, 
> 
> It is precisely that issue of responsibility, in a broader 
> sense.  I'm quite certain that organizational entities who 
> create, issue and maintain the reliability of public key 
> certificates will will be the first to claim jursidiction 
> regarding their validity. Who is going to claim otherwise? 
> 
> Mike 
> 
> 
> > -----Original Message----- 
> > From: Denis Pinkas [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> > Sent: Wednesday, April 17, 2002 8:02 AM 
> > > Extract from the road map document: 
> > 
> > Certification Authority (CA) - An authority 
> > trusted by one or more users to create and assign 
> > public key certificates. Optionally the CA may 
> > create the user's keys. It is important to 
> > note that the CA is responsible for the public key 
>                       ^^^^^^^^^^^^^^^ 
> > certificates during their whole lifetime, not just 
> > for issuing them. 
> 


--Boundary_(ID_oAPiua89CznGsrhj404/Fw)
Content-type: text/html; charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: Open issue: DPV additional information</TITLE>

<META content="MSHTML 6.00.2715.400" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=397075221-17042002>At 
Mike's suggestion, Ive looked to your mail as a way of 
exiting</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=397075221-17042002>the 
thread.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=397075221-17042002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=397075221-17042002>Im 
happy&nbsp; with your (very informal) statement about one important issue, and 
agree</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=397075221-17042002>that 
it represents what Denis and the requirements document should be 
conveying.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=397075221-17042002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=397075221-17042002>Providing </SPAN></FONT><FONT face=Arial color=#0000ff 
size=2><SPAN class=397075221-17042002>that </SPAN></FONT><FONT face=Arial 
color=#0000ff size=2><SPAN class=397075221-17042002>Denisand Russ both agree the 
DPV requirements entail the following</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=397075221-17042002>matter 
(informally expressed), I </SPAN></FONT><FONT face=Arial color=#0000ff 
size=2><SPAN class=397075221-17042002>am happy to proceed, on this 
issue:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=397075221-17042002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=397075221-17042002>Without prejudice to other modes of operation, 
</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=397075221-17042002>a&nbsp;DPV server can use an OCSP response issued by an 
OCSP</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=397075221-17042002>responder that is locally trusted by 
</SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN 
class=397075221-17042002>the DPV client through a validation</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=397075221-17042002>policy 
rule) and </SPAN></FONT><FONT face=Arial color=#0000ff size=2><SPAN 
class=397075221-17042002>that the DPV server </SPAN></FONT><FONT face=Arial 
color=#0000ff size=2><SPAN class=397075221-17042002>will accept the OCSP 
response on the client's behalf </SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=397075221-17042002>in a 
manner conforming to the rules of OCSP </SPAN></FONT><FONT face=Arial 
color=#0000ff size=2><SPAN 
class=397075221-17042002>standard.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=397075221-17042002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=397075221-17042002>Given 
every opportunity to confirm this entailment, todate, Denis</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=397075221-17042002>has 
not done so. With confirmation, we can proceed.</SPAN></FONT></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Hal Lockhart 
  [mailto:[e-mail]]<BR><B>Sent:</B> Wednesday, April 17, 2002 
  10:23 AM<BR><B>To:</B> 'Michael Myers'; Denis Pinkas; 
  [e-mail]<BR><B>Cc:</B> pkix<BR><B>Subject:</B> RE: Open 
  issue: DPV additional information<BR><BR></FONT></DIV>
  <P><FONT size=2>As entertaining as it is to watch you guys talk past each 
  other, this thread is getting tiresome. Let me take a crack at why I don't 
  think there is any real disagreement here.</FONT></P>
  <P><FONT size=2>I think what Denis is saying is that if an entity is a CA, by 
  definition they are trusted to issue and revoke the certificates they issue, 
  by virture of being a CA. They can also delegate someone else to do the 
  revocation, also by virtue of being a CA. If a RP decides to trust their 
  certs, they must also trust their revocation arrangements.</FONT></P>
  <P><FONT size=2>In contrast, when somebody sets up a DPV server, whether or 
  not they also run a CA, there is an independant decision to trust the DPV 
  server. It does not follow as an automatic consequence of the fact thet the 
  same organization (or key even) may have issued one or more of the certs in 
  the chain in question.</FONT></P>
  <P><FONT size=2>In other words, a CA may run a DPV server, but the server will 
  be trusted because RPs choose to do so, not because they have previously 
  chosen to trust certs issued by the CA.</FONT></P>
  <P><FONT size=2>Everybody agree? ;-)</FONT> </P>
  <P><FONT size=2>Hal</FONT> </P>
  <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
  From: Michael Myers [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>&gt; Sent: Wednesday, April 17, 2002 11:22 AM</FONT> 
  <BR><FONT size=2>&gt; To: Denis Pinkas; [e-mail]</FONT> 
  <BR><FONT size=2>&gt; Cc: pkix</FONT> <BR><FONT size=2>&gt; Subject: RE: Open 
  issue: DPV additional information</FONT> <BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Denis,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  It is precisely that issue of responsibility, in a broader</FONT> <BR><FONT 
  size=2>&gt; sense.&nbsp; I'm quite certain that organizational entities 
  who</FONT> <BR><FONT size=2>&gt; create, issue and maintain the reliability of 
  public key</FONT> <BR><FONT size=2>&gt; certificates will will be the first to 
  claim jursidiction</FONT> <BR><FONT size=2>&gt; regarding their validity. Who 
  is going to claim otherwise?</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
  size=2>&gt; Mike</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
  </FONT><BR><FONT size=2>&gt; &gt; -----Original Message-----</FONT> <BR><FONT 
  size=2>&gt; &gt; From: Denis Pinkas [<A 
  href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
  <BR><FONT size=2>&gt; &gt; Sent: Wednesday, April 17, 2002 8:02 AM</FONT> 
  <BR><FONT size=2>&gt; &gt; &gt; Extract from the road map document:</FONT> 
  <BR><FONT size=2>&gt; &gt;</FONT> <BR><FONT size=2>&gt; &gt; Certification 
  Authority (CA) - An authority</FONT> <BR><FONT size=2>&gt; &gt; trusted by one 
  or more users to create and assign</FONT> <BR><FONT size=2>&gt; &gt; public 
  key certificates. Optionally the CA may</FONT> <BR><FONT size=2>&gt; &gt; 
  create the user's keys. It is important to</FONT> <BR><FONT size=2>&gt; &gt; 
  note that the CA is responsible for the public key</FONT> <BR><FONT 
  size=2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
  ^^^^^^^^^^^^^^^</FONT> <BR><FONT size=2>&gt; &gt; certificates during their 
  whole lifetime, not just</FONT> <BR><FONT size=2>&gt; &gt; for issuing 
  them.</FONT> <BR><FONT size=2>&gt; </FONT></P></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_oAPiua89CznGsrhj404/Fw)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HLciU05482 for ietf-pkix-bks; Wed, 17 Apr 2002 14:38:44 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HLchm05478 for <[e-mail]>; Wed, 17 Apr 2002 14:38:43 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3HLcTPm018625; Wed, 17 Apr 2002 14:38:30 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Peter Williams" <[e-mail]>, "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Open issue: DPV additional information
Date: Wed, 17 Apr 2002 14:35:41 -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
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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,

I think your #2 is about right: state the rqmts and hold designs
against them.  IMHO, further debates on abstract trust issues
only make sense once the technical path forward has been
established.  I see no reason to continue this thread.  Hal
Lockhart laid it to rest quite well.  Let's save our cycles for
what is to come.

Mike


> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Wednesday, April 17, 2002 2:12 PM
> To: 'Michael Myers'; Peter Sylvester; [e-mail];
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: Open issue: DPV additional information
>
>
> You seem to be saying: "The requirements document
> doesnt need to address
> the fundamental relationship between the parties, that
> will be built into the protocol design."
>
>
> We have two choices.
>
> (1) we can agree that DPV requirements
> do not address the issues raised: and the design
> of the protocol is free to do what
> the designers see approriate
>
> Or
>
> (2) we can state the requirements,
> and hold the protocol designs
> to the requirements.
>
> Currently, there are assumed models and/or
> statements about the relationships. If
> they stay, they must become more coherent.
>
> Currently a DPV server is a mystical NR-supporting
> server (Denis), that (somehow) will enforce a CA
> authorization over CRL and OCSP issuers (Denis), but
> will itself will not be authorized by a CA (Denis), but
> the service may be provided by a CA using a CAs cert/CRL
> signing key (Mike) that uses validation policies of
> unknown rules (not limited to trust-anchors and X.509 path
> processing parameters) to indicate to a relying party
> that a given chain is valid under the policy, and will
> supply its sources of asurnace (certs, CRLS, OCSP
> responses) to the RP to
> maintain
> as evidence alongside the DPV response.
>
> And somewhere in all this, there is something
> about signature policies.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HLC4g03753 for ietf-pkix-bks; Wed, 17 Apr 2002 14:12:04 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HLC1m03749 for <[e-mail]>; Wed, 17 Apr 2002 14:12:01 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 17 Apr 2002 14:09:13 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 17 Apr 2002 14:09:12 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <JACGZS6H>; Wed, 17 Apr 2002 14:11:55 -0700
Content-return: allowed
Date: Wed, 17 Apr 2002 14:11:54 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Open issue: DPV additional information
To: "'Michael Myers'" <[e-mail]>, Peter Sylvester <[e-mail]>, [e-mail], [e-mail], [e-mail]
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="iso-8859-1"
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>

You seem to be saying: "The requirements document doesnt need to address
the fundamental relationship between the parties, that
will be built into the protocol design."


We have two choices.

(1) we can agree that DPV requirements
do not address the issues raised: and the design
of the protocol is free to do what
the designers see approriate

Or

(2) we can state the requirements,
and hold the protocol designs
to the requirements.

Currently, there are assumed models and/or
statements about the relationships. If
they stay, they must become more coherent.

Currently a DPV server is a mystical NR-supporting
server (Denis), that (somehow) will enforce a CA 
authorization over CRL and OCSP issuers (Denis), but
will itself will not be authorized by a CA (Denis), but
the service may be provided by a CA using a CAs cert/CRL
signing key (Mike) that uses validation policies of 
unknown rules (not limited to trust-anchors and X.509 path
processing parameters) to indicate to a relying party
that a given chain is valid under the policy, and will
supply its sources of asurnace (certs, CRLS, OCSP responses) to the RP to
maintain
as evidence alongside the DPV response.

And somewhere in all this, there is something
about signature policies.

>>>>-----Original Message-----
>>>>From: Michael Myers [mailto:[e-mail]]
>>>>Sent: Wednesday, April 17, 2002 1:08 PM
>>>>To: Peter Sylvester; [e-mail];
>>>>[e-mail]; [e-mail]
>>>>Cc: [e-mail]
>>>>Subject: RE: Open issue: DPV additional information
>>>>
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail]
>>>>> [mailto:[e-mail]]On Behalf Of
>>>>> Michael Myers
>>>>> Sent: Wednesday, April 17, 2002 11:09 AM
>>>>>
>>>>> Hal,
>>>>>
>>>>> This works for me.  Thanks for stepping in.
>>>>>
>>>>> Mike
>>>>
>>>>
>>>>However, Peter Sylvester does make some good points. But since
>>>>this debate doesn't affect the requirements document Russ and
>>>>Denis are working to finalize (at least, I hope it doesn't) we
>>>>should probably reserve these cycles for the main event.
>>>>
>>>>Mike
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: Peter Sylvester [mailto:[e-mail]]
>>>>> Sent: Wednesday, April 17, 2002 12:54 PM
>>>>> To: [e-mail]; [e-mail];
>>>>> [e-mail]; [e-mail]
>>>>> Cc: [e-mail]
>>>>> Subject: RE: Open issue: DPV additional information
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> > As entertaining as it is to watch you guys talk
>>>>> past each other, this thread
>>>>> > is getting tiresome. Let me take a crack at why I
>>>>> don't think there is any
>>>>> > real disagreement here.
>>>>>
>>>>> Thanks also for trying to find the core of the
>>>>> 'debate'. Debates are
>>>>> currently entertainment in France :-)
>>>>>
>>>>> As far as I remember the claim was 'A CA cannot sign
>>>>> DPV responses'.
>>>>> And Mike and I disagree with that statement.
>>>>>
>>>>> I am not sure whether there is a disagreement in your
>>>>> following
>>>>> description. It may be a language problem, but I
>>>>> think there are
>>>>> some logical relations which seem inversed or unclear.
>>>>> My commenst may even lead to more obscurity.
>>>>>
>>>>> >
>>>>> > I think what Denis is saying is that if an entity
>>>>> is a CA, by definition
>>>>> > they are trusted to issue and revoke the
>>>>> certificates they issue, by virture
>>>>> > of being a CA. They can also delegate someone else
>>>>> to do the revocation,
>>>>> > also by virtue of being a CA. If a RP decides to
>>>>> trust their certs, they
>>>>> > must also trust their revocation arrangements.
>>>>>
>>>>> To me, the question is not whether RPs 'MUST' trust
>>>>> but whether the CA has set up
>>>>> some service for which it can be held responsible. For OCSP,
>>>>> the CA can sign the responses itself or delegate to
>>>>> an authorised responder
>>>>> to assume this responsibility.
>>>>>
>>>>> Now, since just by adding for example a certificate
>>>>> as an extension in an OCSP
>>>>> response, you immediately turn an 'revocation
>>>>> information' into a
>>>>> 'positive status information', I call this  a
>>>>> particular case of DPV
>>>>> (the request consists to ask the status of the cert relative
>>>>> to the CA that signed it, no intermediate certs involved).
>>>>>
>>>>> > In contrast, when somebody sets up a DPV server,
>>>>> whether or not they also
>>>>> > run a CA, there is an independant decision to trust
>>>>> the DPV server. It does
>>>>>
>>>>> Where is the difference betwwen OCSP and DPV? (OCSP
>>>>> trusted responders
>>>>> are something set up by 'somebody'.
>>>>>
>>>>> > not follow as an automatic consequence of the fact
>>>>> thet the same
>>>>> > organization (or key even) may have issued one or
>>>>> more of the certs in the
>>>>> > chain in question.
>>>>>
>>>>> Right, it is not automatic. If the CA itself has
>>>>> signed the DPV/OCSP response
>>>>> for a directly issued cert, why is is a different
>>>>> PROBLEM to trust the CA for
>>>>> an OCSP response or for a DPV response for this case.
>>>>>
>>>>> There is an issue with intermediate CAs for which
>>>>> indeed the higher CA
>>>>> is generally not responsible.
>>>>>
>>>>> > In other words, a CA may run a DPV server, but the
>>>>> server will be trusted
>>>>> > because RPs choose to do so, not because they have
>>>>> previously chosen to
>>>>> > trust certs issued by the CA.
>>>>>
>>>>> Well, a RP may always choose whatever it wants to do,
>>>>> but IMO t
>>>>> for direct subordinate CAs an OCSP or DPV service is
>>>>> almost identical.
>>>>> if there is a DPV response signed by the CA, why
>>>>> should one not believe
>>>>> that this is not an authorised statement from the CA
>>>>> as soon as the CA
>>>>> has indicated in some policy/practise that it
>>>>> provides CRLs, OCSP and/or DPV?
>>>>>
>>>>> For the general case, there may be more
>>>>> constellations of trust relations
>>>>> for DPV services than just the two defined for OCSP.
>>>>>
>>>>> Regards
>>>>> Peter
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HKBCf28845 for ietf-pkix-bks; Wed, 17 Apr 2002 13:11:12 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HKB5m28838 for <[e-mail]>; Wed, 17 Apr 2002 13:11:05 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3HKAtPm010050; Wed, 17 Apr 2002 13:10:56 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Open issue: DPV additional information
Date: Wed, 17 Apr 2002 13:08:07 -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
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Michael Myers
> Sent: Wednesday, April 17, 2002 11:09 AM
>
> Hal,
>
> This works for me.  Thanks for stepping in.
>
> Mike


However, Peter Sylvester does make some good points. But since
this debate doesn't affect the requirements document Russ and
Denis are working to finalize (at least, I hope it doesn't) we
should probably reserve these cycles for the main event.

Mike


> -----Original Message-----
> From: Peter Sylvester [mailto:[e-mail]]
> Sent: Wednesday, April 17, 2002 12:54 PM
> To: [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: Open issue: DPV additional information
>
>
>
>
> > As entertaining as it is to watch you guys talk
> past each other, this thread
> > is getting tiresome. Let me take a crack at why I
> don't think there is any
> > real disagreement here.
>
> Thanks also for trying to find the core of the
> 'debate'. Debates are
> currently entertainment in France :-)
>
> As far as I remember the claim was 'A CA cannot sign
> DPV responses'.
> And Mike and I disagree with that statement.
>
> I am not sure whether there is a disagreement in your
> following
> description. It may be a language problem, but I
> think there are
> some logical relations which seem inversed or unclear.
> My commenst may even lead to more obscurity.
>
> >
> > I think what Denis is saying is that if an entity
> is a CA, by definition
> > they are trusted to issue and revoke the
> certificates they issue, by virture
> > of being a CA. They can also delegate someone else
> to do the revocation,
> > also by virtue of being a CA. If a RP decides to
> trust their certs, they
> > must also trust their revocation arrangements.
>
> To me, the question is not whether RPs 'MUST' trust
> but whether the CA has set up
> some service for which it can be held responsible. For OCSP,
> the CA can sign the responses itself or delegate to
> an authorised responder
> to assume this responsibility.
>
> Now, since just by adding for example a certificate
> as an extension in an OCSP
> response, you immediately turn an 'revocation
> information' into a
> 'positive status information', I call this  a
> particular case of DPV
> (the request consists to ask the status of the cert relative
> to the CA that signed it, no intermediate certs involved).
>
> > In contrast, when somebody sets up a DPV server,
> whether or not they also
> > run a CA, there is an independant decision to trust
> the DPV server. It does
>
> Where is the difference betwwen OCSP and DPV? (OCSP
> trusted responders
> are something set up by 'somebody'.
>
> > not follow as an automatic consequence of the fact
> thet the same
> > organization (or key even) may have issued one or
> more of the certs in the
> > chain in question.
>
> Right, it is not automatic. If the CA itself has
> signed the DPV/OCSP response
> for a directly issued cert, why is is a different
> PROBLEM to trust the CA for
> an OCSP response or for a DPV response for this case.
>
> There is an issue with intermediate CAs for which
> indeed the higher CA
> is generally not responsible.
>
> > In other words, a CA may run a DPV server, but the
> server will be trusted
> > because RPs choose to do so, not because they have
> previously chosen to
> > trust certs issued by the CA.
>
> Well, a RP may always choose whatever it wants to do,
> but IMO t
> for direct subordinate CAs an OCSP or DPV service is
> almost identical.
> if there is a DPV response signed by the CA, why
> should one not believe
> that this is not an authorised statement from the CA
> as soon as the CA
> has indicated in some policy/practise that it
> provides CRLs, OCSP and/or DPV?
>
> For the general case, there may be more
> constellations of trust relations
> for DPV services than just the two defined for OCSP.
>
> Regards
> Peter
>
>
>
>
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HJsQO28383 for ietf-pkix-bks; Wed, 17 Apr 2002 12:54:26 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HJsOm28377 for <[e-mail]>; Wed, 17 Apr 2002 12:54:24 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id VAA11382; Wed, 17 Apr 2002 21:54:12 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 17 Apr 2002 21:54:12 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id VAA06494; Wed, 17 Apr 2002 21:54:11 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id VAA09381; Wed, 17 Apr 2002 21:54:10 +0200 (MET DST)
Date: Wed, 17 Apr 2002 21:54:10 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: Open issue: DPV additional information
Cc: [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>

> As entertaining as it is to watch you guys talk past each other, this thread
> is getting tiresome. Let me take a crack at why I don't think there is any
> real disagreement here.

Thanks also for trying to find the core of the 'debate'. Debates are
currently entertainment in France :-)

As far as I remember the claim was 'A CA cannot sign DPV responses'. 
And Mike and I disagree with that statement.

I am not sure whether there is a disagreement in your following
description. It may be a language problem, but I think there are
some logical relations which seem inversed or unclear. 
My commenst may even lead to more obscurity.  

> 
> I think what Denis is saying is that if an entity is a CA, by definition
> they are trusted to issue and revoke the certificates they issue, by virture
> of being a CA. They can also delegate someone else to do the revocation,
> also by virtue of being a CA. If a RP decides to trust their certs, they
> must also trust their revocation arrangements.

To me, the question is not whether RPs 'MUST' trust but whether the CA has set up
some service for which it can be held responsible. For OCSP,
the CA can sign the responses itself or delegate to an authorised responder
to assume this responsibility.

Now, since just by adding for example a certificate as an extension in an OCSP
response, you immediately turn an 'revocation information' into a 
'positive status information', I call this  a particular case of DPV 
(the request consists to ask the status of the cert relative
to the CA that signed it, no intermediate certs involved). 

> In contrast, when somebody sets up a DPV server, whether or not they also
> run a CA, there is an independant decision to trust the DPV server. It does

Where is the difference betwwen OCSP and DPV? (OCSP trusted responders
are something set up by 'somebody'.  

> not follow as an automatic consequence of the fact thet the same
> organization (or key even) may have issued one or more of the certs in the
> chain in question.

Right, it is not automatic. If the CA itself has signed the DPV/OCSP response
for a directly issued cert, why is is a different PROBLEM to trust the CA for
an OCSP response or for a DPV response for this case. 

There is an issue with intermediate CAs for which indeed the higher CA 
is generally not responsible.     

> In other words, a CA may run a DPV server, but the server will be trusted
> because RPs choose to do so, not because they have previously chosen to
> trust certs issued by the CA.

Well, a RP may always choose whatever it wants to do, but IMO t
for direct subordinate CAs an OCSP or DPV service is almost identical.
if there is a DPV response signed by the CA, why should one not believe 
that this is not an authorised statement from the CA as soon as the CA
has indicated in some policy/practise that it provides CRLs, OCSP and/or DPV?

For the general case, there may be more constellations of trust relations 
for DPV services than just the two defined for OCSP. 

Regards
Peter
 






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HJrwt28362 for ietf-pkix-bks; Wed, 17 Apr 2002 12:53:58 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3HJrrm28357 for <[e-mail]>; Wed, 17 Apr 2002 12:53:57 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Apr 2002 19:52:44 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA04772 for <[e-mail]>; Wed, 17 Apr 2002 15:52:33 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3HJrwH00643 for <[e-mail]>; Wed, 17 Apr 2002 15:53:58 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1TWNF>; Wed, 17 Apr 2002 15:51:28 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.49]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1TWND; Wed, 17 Apr 2002 15:51:24 -0400
From: "Housley, Russ" <[e-mail]>
To: David Hopwood <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 17 Apr 2002 15:42:56 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
In-Reply-To: <[e-mail]>
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>

David:

Everywhere else in a certificate, URIs are encoded using the GeneralName 
construct:

       GeneralName ::= CHOICE {
            otherName                       [0]     OtherName,
            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}

Thus, the URI is encode in ASCII.

Do you think that URIs should be encoded differently in this one extension?

Russ


At 01:02 AM 4/17/2002 +0000, David Hopwood wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>
>At 12:35 PM 4/10/2002 -0400, Tom Gindin wrote:
> >Second, I have reviewed draft-ietf-idn-uri-01.txt (by Martin Duerst) and
> >it recommends that internationalized URI strings be converted to UTF-8
> >but then escaped using %HH, so UTF8String is unnecessary.
>
><draft-masinter-url-i18n-08.txt> is more applicable:
>
># In case the current handling in an API or protocol is based on
># US-ASCII, UTF-8 is recommended as the encoding for IRIs, because
># this is compatible with US-ASCII, is in accordance with the
># recommendations of [RFC 2277], and makes it easy to convert to URIs
># where necessary. [...]
>...
># While it might be possible to define IRI references and IRIs merely by
># their transformation to URIs, IRI references and IRIs can also be
># accepted and processed directly.
>...
># Also, it is expected that all relevant new W3C formats and protocols
># will be required to handle IRIs [CharMod].
>
>I.e. the intent is that escaping using %HH must be done for existing
>protocols where URIs are specified as ASCII; not that specifying URIs as
>ASCII is desirable for *new* protocols.
>
>- --
>David Hopwood <[e-mail]>
>
>Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
>RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
>Nothing in this message is intended to be legally binding. If I revoke a
>public key but refuse to specify why, it is because the private key has been
>seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: 2.6.3i
>Charset: noconv
>
>iQEVAwUBPLzJYzkCAxeYt5gVAQG4LQf/fVKpiwbvc12r65934MfogBA6S2lOcr+f
>ffNIPy76iMHJ3/Z+YWHQLyYPJKebtlpN1rfbPuoaU6LRSqb6r/xWfg6LLoAuHBO/
>+vtJn/oo0YY5L4bZzqDkTle1rjz1cA0lDzZL8FeZ1ZMxN7++PNOupkC23j/TqYrw
>7Wf2y/mpgghjZ8Un5b1aaPUtE2yOn87TH/QX2hRytsQTIAe9o2Z53eOvWYoQ3i2I
>sUQ9llCtln7kbu03jPUmpr2MduLFPY6KouZ9Mq1gs9j/0w0fJwLcdPFQ3TMGvl2L
>lWtc620m4YgsqvXWQR6WluCUi1dxeL+zZSOGvx/mnmFanKc2O22fXQ==
>=V/pC
>-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HJfCJ27665 for ietf-pkix-bks; Wed, 17 Apr 2002 12:41:12 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HJfAm27655 for <[e-mail]>; Wed, 17 Apr 2002 12:41:10 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 17 Apr 2002 12:38:08 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 17 Apr 2002 12:38:07 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <JACGZSM5>; Wed, 17 Apr 2002 12:40:50 -0700
Content-return: allowed
Date: Wed, 17 Apr 2002 12:40:49 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Open issue: DPV additional information
To: "'Michael Myers'" <[e-mail]>
Cc: pkix <[e-mail]>, Denis Pinkas <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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>

Mike,

What Denis is apparently saying is:

- unlike OCSP (and OCSPv2) which standardizes an authorization model
for CA-authorized "responders", and a non-CA "local-trust" model 
for "local responders"

- DPV requirements do NOT call for standardization
of these two issues (authorization and local trust)
in the DPV protocol to be specified

- He makes various broad-ranging assumptions on these 
very issues, however, that we are determining from the thread what the
assumptions are.

I think the only 2 substantive points that PeterW, PeterS, and
Denis and others are discussing, include

1) Whether the DPV
requirements *should* specify means to address the DPV
dependent-services authorization and trust issues (e.g. 
these issues as they affect path processing supporting CRL handling, 
these issues as they affect OCSP response acceptance
handling, and these issues as they affect OCSP response chain's 
own path processing)

2) We seek to flush out Denis' assumption about his model of 
the authorization and local-trust relations between CA/AAs, DPV
servers, and EE relying-parties, and find out which entity and
protocol state will be responsible for enforcing the authorization 
and local-trust rules, once we get to protocol specification.

If we use your OSCP v2 work as a guide, we can reason thus:

My (and implicitely your) suggestion is that DPV handle authorization 
and local-trust issues in the way that OCSP does - as the OCSP standard
had pragmatically suceeded to balance both CA-focussed and RP-focussed
relationship models between the CA/AA, OCSP responder, and
EE-RP parties. The OCSP solution to the issues would obviously
come built into DPV, if we specify a DPV using OCSPv2, lets note. AS Denis
seems to deny, however, the legltimacy of the OCSP way of handling 
these issues for DPV needs, we cannot simply do OCSP v2, as is, to perform a
DPV protocol: Why not, as OCSP's standardization per se contradicts 
Denis' model of the relationships between the players.

Im not saying I agree with Denis. But if I translate his
aphorisms, this is what he seems to be actually stating. My
statement of the implications for OCSP (v2) or any
other protocol design following the OCSP heritage, then
follow.

Peter.

>>>>-----Original Message-----
>>>>From: Michael Myers [mailto:[e-mail]]
>>>>Sent: Wednesday, April 17, 2002 7:01 AM
>>>>To: Denis Pinkas
>>>>Cc: pkix
>>>>Subject: RE: Open issue: DPV additional information
>>>>
>>>>
>>>>
>>>>Denis,
>>>>
>>>>Even as explanations, I disagree with the assertions.
>>>>
>>>>A CA can most certainly sign DPV responses, especially relating
>>>>to its own certificates.  A CA can also delegate that function
>>>>(i.e. authorize a DPV server) to another trusted party.  That
>>>>party could conceivably itself be a CA.  Thus a CA can sign DPV
>>>>responses even with respect to certificates it didn't issue.
>>>>
>>>>In my view, these are deployment and operational issues relating
>>>>to specific policies, practices and perhaps even contracts, all
>>>>of which seem to be well out of scope of our technical
>>>>considerations.  But maybe that's just me.
>>>>
>>>>Mike
>>>>
>>>>> -----Original Message-----
>>>>> From: [e-mail]
>>>>> [mailto:[e-mail]]On Behalf Of Denis Pinkas
>>>>> Sent: Wednesday, April 17, 2002 2:42 AM
>>>>> To: Michael Myers
>>>>> Cc: pkix
>>>>> Subject: Re: Open issue: DPV additional information
>>>>>
>>>>>
>>>>>
>>>>> Michael,
>>>>>
>>>>> The text you mention is *not* going to be placed in
>>>>> the requirement
>>>>> document, but was only explanations.
>>>>>
>>>>> Since there has been many small changes since version
>>>>> 03, I will re-issue
>>>>> a draft shortly so that everybody can see the result
>>>>> of the more than
>>>>> * 300 e-mails * that have been exchanged.
>>>>>
>>>>> Denis
>>>>>
>>>>> > > -----Original Message-----
>>>>> > > From: [e-mail]
>>>>> > > [mailto:[e-mail]]On Behalf Of
>>>>> Denis Pinkas
>>>>> > >
>>>>> > > . . .
>>>>> > >
>>>>> > > No. DPV servers are never authorized by CAs. They
>>>>> are either :
>>>>> > >
>>>>> > >  - locally trusted by their requesting clients for any
>>>>> > >    policy, or/and
>>>>> > >  - trusted under a given validation policy.
>>>>> > >
>>>>> > > . . .
>>>>> > >
>>>>> > > A CA cannot sign DPV responses.
>>>>> >
>>>>> > Denis,
>>>>> >
>>>>> > A while back I quite carefully parsed the -03
>>>>> version of the I-D
>>>>> > into requirements statements.  Nowhere did I see
>>>>> these negative
>>>>> > requirements asserted.  Had they been there, I'm
>>>>> quite certain I
>>>>> > would've raised an issue on the list.  Do you
>>>>> really mean to say
>>>>> > that a CA can neither directly affirm the validity
>>>>> of its own
>>>>> > certificates nor delegate that obvious right to
>>>>> another party?
>>>>> >
>>>>> > Mike
>>>>>
>>>>


Received: by above.proper.com (8.11.6/8.11.3) id g3HIT1i22842 for ietf-pkix-bks; Wed, 17 Apr 2002 11:29:01 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HIT0m22837 for <[e-mail]>; Wed, 17 Apr 2002 11:29:00 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3HISvPm028957; Wed, 17 Apr 2002 11:29:00 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: RE: Future of OCSP V2
Date: Wed, 17 Apr 2002 11:26:08 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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 V5.50.4133.2400
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>

The OCSPv2 I-D will be updated and submitted for the WG's
consideration now that the DPV and DPD requirements work appears
to be coming to a close.  It didn't make much sense to update it
while the requirements were in flux.

By the way, the only v2-ness about OCSPv2 has to do with the
expansion of the certificate identification syntax to
accomodate, among other options, the full certificate or a
certificate hash.  The extensions for DPV and DPD, which were
always there even before all this hoo-hah started, can work
equally well within the v1 framework, at least to the extent the
v1 certID structure is acceptable.

The definition of these extensions will of course be amended
according the released version of the requirements document.  A
premliminary analysis against the -03 requirements showed that
very little if any change will be needed.

Of course, discussions concerning their acceptability as the
technical path forward will doubtless prove lively.

Mike




> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> [e-mail]
> Sent: Wednesday, April 17, 2002 7:24 AM
> To: [e-mail]
> Subject: Future of OCSP V2
>
>
>
> Hi PKIXers,
>
> I would like to know what is the future of OCSP V2,
> since the last draft has already expired and I couldn
> t find any recent document about it. I m not
> following the discussions on this list, so excuse the
> fact that I may have missed something. So
> -Will there be an OCSP V2 protocol?
> -If yes will it be VERY different from the (expired)
> draft currently available?
> -If no what will happen with DPD and DPV? Will they
> possibly be defined as independant protocols?
>
> Thank you
>
> WY
>
> ______________________________________________________
> ________________________
> Für alle, die nicht genug WEB.DE bekommen können. 100
> MB Speicher, SMS Preisvorteil
> und noch mehr Kommunikation unter
> http://club.web.de/?mc=021101
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HIFbH22456 for ietf-pkix-bks; Wed, 17 Apr 2002 11:15:37 -0700 (PDT)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HIFZm22452 for <[e-mail]>; Wed, 17 Apr 2002 11:15:35 -0700 (PDT)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g3HIBqO21464 for <[e-mail]>; Wed, 17 Apr 2002 11:11:52 -0700 (PDT)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <G4TAR04H>; Wed, 17 Apr 2002 11:16:58 -0700
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: [e-mail]
Subject: Comments on the OKID draft
Date: Wed, 17 Apr 2002 11:16:40 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
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>

While I like the overall idea I think it can be substantially improved as
follows:

1) The initial string is 2 characters, yet the argument is made that we are
so short of space that we cannot afford any form of parity check.

I suggest that we change this so that the first charater represents the type
of OKID and the second is a parity check. This leaves us room for up to 32
different OKID types, and that before we start using bits in the data
portion.

I suggest that we form the parity check as follows:

Let the OKID be

WW-XXXX-XXXX-XXXX-XXXX-XXXX
WP-AAAA-BBBB-CCCC-DDDD-EEEE

W = E, C, A, B as before
    L to stand for license activation
    R to stand for one time authentication code

P = a 5 bit parity check formed as follows

Bit 0 = Parity of W AAAA
Bit 1 = Parity of W AAAA BBBB
Bit 2 = Parity of W AAAA BBBB CCCC
Bit 3 = Parity of W AAAA BBBB CCCC DDDD
Bit 4 = Parity of W AAAA BBBB CCCC DDDD EEEE

This mechanism gives a 50% chance that an error will be caught in any given
block as it is typed
and failing that a 50% chance it will be caught in the next block, etc.

2) The format described in the first part of the draft is for a 100 bit
OKID, the example describes an 80 bit OKID

I prefer the 100 bit format, in fact I would like to have the option of
specifying as many blocks as I like, up to 8 if necessary.


3) The use of the OKID in the manner of a PGP fingerprint should be
explicitly considered under security considerations.

4) I would suggest that the registry concept should be unnecessary if the
hash is large enough. There should be a means of re-using exisitng IANA
identifiers, e.g. by combining a hash of an IANA mime type and the hash of
the data... H ( H (type), H (data) )

5) I would also suggest that we try to avoid unnecessary dependence on PKIX
data formats here, the probability of collision should be negligible and so
the option of using an OKID for PGP or SPKI or PKIX keys is attractive.

6) This technology could provide a means to address the one remaining
objection voiced of PGP over S/MIME, the ability to generate short key
signing lists. I do not propose the draft address this, but someone should. 

		Phill


Received: by above.proper.com (8.11.6/8.11.3) id g3HIBf922339 for ietf-pkix-bks; Wed, 17 Apr 2002 11:11:41 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HIBdm22334 for <[e-mail]>; Wed, 17 Apr 2002 11:11:39 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3HIBVPm027113; Wed, 17 Apr 2002 11:11:31 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Hal Lockhart" <[e-mail]>, "Denis Pinkas" <[e-mail]>, <[e-mail]>
Cc: "pkix" <[e-mail]>
Subject: RE: Open issue: DPV additional information
Date: Wed, 17 Apr 2002 11:08:44 -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)
In-Reply-To: <[e-mail]>
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Hal,

This works for me.  Thanks for stepping in.

Mike

-----Original Message-----
From: Hal Lockhart [mailto:[e-mail]]
Sent: Wednesday, April 17, 2002 10:23 AM
To: 'Michael Myers'; Denis Pinkas; [e-mail]
Cc: pkix
Subject: RE: Open issue: DPV additional information


As entertaining as it is to watch you guys talk past each other,
this thread is getting tiresome. Let me take a crack at why I
don't think there is any real disagreement here.
I think what Denis is saying is that if an entity is a CA, by
definition they are trusted to issue and revoke the certificates
they issue, by virture of being a CA. They can also delegate
someone else to do the revocation, also by virtue of being a CA.
If a RP decides to trust their certs, they must also trust their
revocation arrangements.
In contrast, when somebody sets up a DPV server, whether or not
they also run a CA, there is an independant decision to trust
the DPV server. It does not follow as an automatic consequence
of the fact thet the same organization (or key even) may have
issued one or more of the certs in the chain in question.
In other words, a CA may run a DPV server, but the server will
be trusted because RPs choose to do so, not because they have
previously chosen to trust certs issued by the CA.
Everybody agree? ;-)
Hal
> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, April 17, 2002 11:22 AM
> To: Denis Pinkas; [e-mail]
> Cc: pkix
> Subject: RE: Open issue: DPV additional information
>
>
>
> Denis,
>
> It is precisely that issue of responsibility, in a broader
> sense.  I'm quite certain that organizational entities who
> create, issue and maintain the reliability of public key
> certificates will will be the first to claim jursidiction
> regarding their validity. Who is going to claim otherwise?
>
> Mike
>
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, April 17, 2002 8:02 AM
> > > Extract from the road map document:
> >
> > Certification Authority (CA) - An authority
> > trusted by one or more users to create and assign
> > public key certificates. Optionally the CA may
> > create the user's keys. It is important to
> > note that the CA is responsible for the public key
>                       ^^^^^^^^^^^^^^^
> > certificates during their whole lifetime, not just
> > for issuing them.
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HHQWd20705 for ietf-pkix-bks; Wed, 17 Apr 2002 10:26:32 -0700 (PDT)
Received: from dymwsm17.mailwatch.com (dymwsm17.mailwatch.com [204.253.83.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HHQUm20699 for <[e-mail]>; Wed, 17 Apr 2002 10:26:31 -0700 (PDT)
Received: from MWSC0208.MW4.MAILWATCH.COM (mwsc0208.mw4.mailwatch.com [204.253.83.244]) by dymwsm17.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3HHQCp16075 for <[e-mail]>; Wed, 17 Apr 2002 13:26:12 -0400
Received: from mail pickup service by MWSC0208.MW4.MAILWATCH.COM with Microsoft SMTPSVC; Wed, 17 Apr 2002 13:26:12 -0400
Received: from 204.253.83.39 ([204.253.83.39]) by MWSC0208 with SMTP id 000200087ec4b76d-541a-4b15-870a-73de57bc4454;	 Wed, 17 Apr 2002 13:26:11 -0500
Received: from bigbird.entegrity.com (bigbird.gradient.com [192.92.110.50])	by dymwsm15.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3HHQAE19292;	Wed, 17 Apr 2002 13:26:10 -0400
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10)	id <JC4CCNRR>; Wed, 17 Apr 2002 13:22:54 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, Denis Pinkas	 <[e-mail]>, [e-mail]
Cc: pkix <[e-mail]>
Subject: RE: Open issue: DPV additional information
Date: Wed, 17 Apr 2002 13:22:52 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: multipart/alternative;	boundary="----_=_NextPart_001_01C1E634.818E8B18"
HOP-COUNT: 1
X-MAILWATCH-INSTANCEID: 010200087ec4b76d-541a-4b15-870a-73de57bc4454
X-OriginalArrivalTime: 17 Apr 2002 17:26:12.0319 (UTC) FILETIME=[F865BEF0:01C1E634]
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_01C1E634.818E8B18
Content-Type: text/plain;
	charset="ISO-8859-1"

As entertaining as it is to watch you guys talk past each other, this thread
is getting tiresome. Let me take a crack at why I don't think there is any
real disagreement here.

I think what Denis is saying is that if an entity is a CA, by definition
they are trusted to issue and revoke the certificates they issue, by virture
of being a CA. They can also delegate someone else to do the revocation,
also by virtue of being a CA. If a RP decides to trust their certs, they
must also trust their revocation arrangements.

In contrast, when somebody sets up a DPV server, whether or not they also
run a CA, there is an independant decision to trust the DPV server. It does
not follow as an automatic consequence of the fact thet the same
organization (or key even) may have issued one or more of the certs in the
chain in question.

In other words, a CA may run a DPV server, but the server will be trusted
because RPs choose to do so, not because they have previously chosen to
trust certs issued by the CA.

Everybody agree? ;-)

Hal

> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, April 17, 2002 11:22 AM
> To: Denis Pinkas; [e-mail]
> Cc: pkix
> Subject: RE: Open issue: DPV additional information
> 
> 
> 
> Denis,
> 
> It is precisely that issue of responsibility, in a broader
> sense.  I'm quite certain that organizational entities who
> create, issue and maintain the reliability of public key
> certificates will will be the first to claim jursidiction
> regarding their validity. Who is going to claim otherwise?
> 
> Mike
> 
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, April 17, 2002 8:02 AM
> > > Extract from the road map document:
> >
> > Certification Authority (CA) - An authority
> > trusted by one or more users to create and assign
> > public key certificates. Optionally the CA may
> > create the user's keys. It is important to
> > note that the CA is responsible for the public key
>                       ^^^^^^^^^^^^^^^
> > certificates during their whole lifetime, not just
> > for issuing them.
> 

------_=_NextPart_001_01C1E634.818E8B18
Content-Type: text/html;
	charset="ISO-8859-1"
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=3DISO-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2448.0">
<TITLE>RE: Open issue: DPV additional information</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>As entertaining as it is to watch you guys talk past =
each other, this thread is getting tiresome. Let me take a crack at why =
I don't think there is any real disagreement here.</FONT></P>

<P><FONT SIZE=3D2>I think what Denis is saying is that if an entity is =
a CA, by definition they are trusted to issue and revoke the =
certificates they issue, by virture of being a CA. They can also =
delegate someone else to do the revocation, also by virtue of being a =
CA. If a RP decides to trust their certs, they must also trust their =
revocation arrangements.</FONT></P>

<P><FONT SIZE=3D2>In contrast, when somebody sets up a DPV server, =
whether or not they also run a CA, there is an independant decision to =
trust the DPV server. It does not follow as an automatic consequence of =
the fact thet the same organization (or key even) may have issued one =
or more of the certs in the chain in question.</FONT></P>

<P><FONT SIZE=3D2>In other words, a CA may run a DPV server, but the =
server will be trusted because RPs choose to do so, not because they =
have previously chosen to trust certs issued by the CA.</FONT></P>

<P><FONT SIZE=3D2>Everybody agree? ;-)</FONT>
</P>

<P><FONT SIZE=3D2>Hal</FONT>
</P>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Michael Myers [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, April 17, 2002 11:22 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Denis Pinkas; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: pkix</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: Open issue: DPV additional =
information</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; It is precisely that issue of responsibility, =
in a broader</FONT>
<BR><FONT SIZE=3D2>&gt; sense.&nbsp; I'm quite certain that =
organizational entities who</FONT>
<BR><FONT SIZE=3D2>&gt; create, issue and maintain the reliability of =
public key</FONT>
<BR><FONT SIZE=3D2>&gt; certificates will will be the first to claim =
jursidiction</FONT>
<BR><FONT SIZE=3D2>&gt; regarding their validity. Who is going to claim =
otherwise?</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Mike</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Wednesday, April 17, 2002 8:02 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Extract from the road map =
document:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Certification Authority (CA) - An =
authority</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; trusted by one or more users to create and =
assign</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; public key certificates. Optionally the CA =
may</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; create the user's keys. It is important =
to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; note that the CA is responsible for the =
public key</FONT>
<BR><FONT =
SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp=
; ^^^^^^^^^^^^^^^</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; certificates during their whole lifetime, =
not just</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; for issuing them.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1E634.818E8B18--


Received: by above.proper.com (8.11.6/8.11.3) id g3HGlY517095 for ietf-pkix-bks; Wed, 17 Apr 2002 09:47:34 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HGlWm17087 for <[e-mail]>; Wed, 17 Apr 2002 09:47:32 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA10426; Wed, 17 Apr 2002 18:47:33 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 17 Apr 2002 18:47:33 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA05645; Wed, 17 Apr 2002 18:47:32 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA09329; Wed, 17 Apr 2002 18:47:31 +0200 (MET DST)
Date: Wed, 17 Apr 2002 18:47:31 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
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>

> >
> >1. The requestor MUST be able, upon request, to have a field to be copied
> >    in the response.
> >
> >2. When the request is authenticated, the requestor SHOULD be able, upon
> >    request, to have an identifier to be included in the response. How this
> >    identifier is derived from the authenticated identity depends on local
> >    server conditions. The server MAY choose to refuse to include an
> >    identitier in the response.
> >
> >Opinions ?
> 
> I think that the first alternative is too vague to be useful.  I nonce 
> mechanism that might be included to detect reply would fulfill the requirement.
> 
> I think that the second is acceptable.  I could live with it in order to 
> reach closure, but I do not think that it is necessary.

1: 
   Actually Denis has added a new requirement here which is something that
   I had in mind but forgotten during the other discussions.

   'a field' could mean 'a textual description identifying the nature or reason
   of the request/response'. 

   This is not nonce processing, I have some tendency to avoid to encourage
   people to hide something necessary in a nonce.
   
2:
   What about:   
   
   When the request is authenticated, the requestor SHOULD be able, upon
   request, to indicate an identifier to be included in the response. How this
   identifier is matched with the authenticated identity depends on local
   server conditions and/or the validation policy. 
   The server MAY choose to refuse to include an identitier in the response,
   or MAY refuse to create a response. 

> 
> Russ
> 
Peter


Received: by above.proper.com (8.11.6/8.11.3) id g3HGTf715088 for ietf-pkix-bks; Wed, 17 Apr 2002 09:29:41 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HGTdm15084 for <[e-mail]>; Wed, 17 Apr 2002 09:29:39 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA10295 for <[e-mail]>; Wed, 17 Apr 2002 18:29:31 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 17 Apr 2002 18:29:31 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA05547 for <[e-mail]>; Wed, 17 Apr 2002 18:29:30 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA09319 for [e-mail]; Wed, 17 Apr 2002 18:29:30 +0200 (MET DST)
Date: Wed, 17 Apr 2002 18:29:30 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: raodmap
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 roadmap draft contains the following text:


   Another long debated topic in the WG dealt with certificate 
   revocation. Numerous drafts have been developed to address different 
   issues related certificate revocations. CMP supports revocation 
   request, response, revocation announcement, and requests for CRL 
   messages. CMC defines revocation request, revocation response, and 
   requests for CRL messages, but uses CMS as the encapsulating 
   protocol. [OCSP] was developed to address concerns that not all 
   relying parties want to go through the process checking CRLs from 
   every CA in the certification path. It defines an on-line mechanism 
   to determine the status of a given certificate, which may provide 
   more timely revocation information than is possible with CRLs. The 
   Simple Certification Verification Protocol (SCVP) was produced to 
   allow relying parties to off-load all of their certification 
   verification to another entity [SCVP]. The WG was arguably split over 
   whether such a function should be supported and whether it should be 
   its own protocol or included in OCSP. In response, a draft defining 
   OCSP Extensions was produced to include the functions of SCVP. [OCSP] 
   has been a draft standard for more than six months and is in the 
   process of being revised [OCSPv2]. To capture the work from the OCSP 
   Extensions, two drafts were developed: Delegated Path Validation 
   [DPV] and Delegated Path Discovery [DPD]. After considerable debate, 
   the WG selected SCVP as the PKIX protocol for delegated path 
   validation and delegated path discovery. A requirements document has 
   been developed, and is currently under WG review. [DPREQ] Upon 
   completion of [DPREQ], the SCVP protocol will be completed. 

I am somewhat surprised about this vision of online status protocol
history and future. 

1 - Since its initial draft in June 4 1998, DVCS has always included
certificate validation as one it its service. 

2 - At the time when OCSP was discussed DVCS was already mentioned
as a protocol to provide certificate 'positive' status information. 

1 - The first drafts of SCVP was produced June 25, 1999. At that time
the first notary draft from Carlisle was already more than one year old. 
and DCS and DVCS have always included the function of validation of
a public key certificate. 

3 - Does someone can tell me in which meeting or decision the working
group 'selected' SCVP as the PKIX protocol? Was this a reaction of
some information that OCSP-V2 was somehow considered abandoned?

4 - As far as I know, and as far as it is regularily reminded by
the editors of the requirements drafts, we are not yet talking about
a particular protocol. Why is there a statement that SCVP will be 
completed?

Peter. 






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HFsib12860 for ietf-pkix-bks; Wed, 17 Apr 2002 08:54:44 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3HFsbm12844 for <[e-mail]>; Wed, 17 Apr 2002 08:54:37 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Apr 2002 15:53:28 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA11399 for <[e-mail]>; Wed, 17 Apr 2002 11:53:17 -0400 (EDT)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3HFsgn02838 for <[e-mail]>; Wed, 17 Apr 2002 11:54:42 -0400 (EDT)
Received: by exeu00.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <2KMJXJJR>; Wed, 17 Apr 2002 16:54:54 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.146]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1TS19; Wed, 17 Apr 2002 11:52:04 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 17 Apr 2002 11:54:24 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: Open issue: requester identifier in DPV response
In-Reply-To: <[e-mail]>
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>

Hi.

My comments are at the bottom ....

> > > The text proposal was as follows:
> > >
> > >  "When the request is authenticated, the requestor MUST be able, upon
> > >  request, to have an identifier to be included in the response. Whether
> > >  and how the communicated identification(s) are validated against 
> identities
> > >  derived by some authentication method depends on local configurations.
> > >  Depending on that, the server MAY choose to copy, ignore, or replace
> > >  the identities by some other in the response, or to refuse the
> > >  request."
> > >
> > > You said: I did not ask for "when the request is authenticated".
> > >
> > > In such a case it means that you wanted a field to be sent by the 
> requestor
> > > and to be blindly copied and pasted by the server in the response. In 
> that
> > > case the semantics of this field cannot be verified by the server and 
> thus
> > > cannot bear more semantics than "this is the data that I copied and 
> pasted
> > > from the request".
>
> > My request is to remove the part "when .. authenticated'
> > You still have the second and thrd sentence which cover
> > the possibilities that may occur.
> > To avoid a misunderstanding, replace "local configurations" by
> > "the validation policy".
>
>This does not help. There is no relationship with the validation policy,
>but this has to do with the access conditions to the DPV server.
>
> > In the following you are combining three actions, the
> > indication of what the user specified, a potential authentication,
> > what the server sends. You take only one case where the policy says
> > no authentication necessary, and just blindly copy.
>
>The problem is the following: when *another* client sees the DPV response
>how can it interpret the semantics of that field ? If there is more than one
>interpretation, no one will have the same understanding of the semantics of
>that field.
>
>Unless we provide an unambiguous semantics of that field, no requirement
>can be added.
>
> > > Capturing this requirement would lead to:
> > >
> > > "The requestor MUST be able, upon request, to have a field to be 
> copied in
> > > the response."
> >
> > The proposed text allows a server to modify or reject the request
> > in whatever way desired. The indication of a requestor identity by
> > the client does not mean that the client has an absolute (MUST) right
> > to get this back unmodified or untreated.
>
>This means multiple semantics.
>
> > > We do not have such a similar facility in an OCSP response and I 
> wonder why
> > > we should support it.
> >
> > If your question would be 'why do we want this' I'd answer that similar
> > features exist in real life, when you ask for some kind of attestation
> > given explicitly to you and you are more or less authenticated.
> >
> > "In reply of your (id of requester) demand from
> > date, we certifiy today that you are still alive and can vote".
>
>In that real life example, the id of requester is verified and is
>thus copied from a dully authenticated identifier.
>
> > "This is an invoice for item XXX for company mycorp".
>
>In that real life example, the item XX is a field that is blindly copied by
>the server.
>
> > But, if others believe that the first half-sentence should remain
> > in order to achieve consensus, I can live with that, too.
>
>Either a choice has to be made between the various alternatives ... or two
>requirements should be incorporated. This would lead to the following text:
>
>1. The requestor MUST be able, upon request, to have a field to be copied
>    in the response.
>
>2. When the request is authenticated, the requestor SHOULD be able, upon
>    request, to have an identifier to be included in the response. How this
>    identifier is derived from the authenticated identity depends on local
>    server conditions. The server MAY choose to refuse to include an
>    identitier in the response.
>
>Opinions ?

I think that the first alternative is too vague to be useful.  I nonce 
mechanism that might be included to detect reply would fulfill the requirement.

I think that the second is acceptable.  I could live with it in order to 
reach closure, but I do not think that it is necessary.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id g3HFQL911590 for ietf-pkix-bks; Wed, 17 Apr 2002 08:26:21 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HFQKm11586 for <[e-mail]>; Wed, 17 Apr 2002 08:26:20 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3HFP1Pm010304; Wed, 17 Apr 2002 08:25:01 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Cc: "pkix" <[e-mail]>
Subject: RE: Open issue: DPV additional information
Date: Wed, 17 Apr 2002 08:22:12 -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)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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 precisely that issue of responsibility, in a broader
sense.  I'm quite certain that organizational entities who
create, issue and maintain the reliability of public key
certificates will will be the first to claim jursidiction
regarding their validity. Who is going to claim otherwise?

Mike


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, April 17, 2002 8:02 AM
> > Extract from the road map document:
>
> Certification Authority (CA) - An authority
> trusted by one or more users to create and assign
> public key certificates. Optionally the CA may
> create the user's keys. It is important to
> note that the CA is responsible for the public key
                      ^^^^^^^^^^^^^^^
> certificates during their whole lifetime, not just
> for issuing them.



Received: by above.proper.com (8.11.6/8.11.3) id g3HFMZc11461 for ietf-pkix-bks; Wed, 17 Apr 2002 08:22:35 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3HFMXm11457 for <[e-mail]>; Wed, 17 Apr 2002 08:22:33 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Apr 2002 15:21:24 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA07744 for <[e-mail]>; Wed, 17 Apr 2002 11:21:12 -0400 (EDT)
Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3HFMXG28399 for <[e-mail]>; Wed, 17 Apr 2002 11:22:34 -0400 (EDT)
Received: by exno02.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <JB1WNQ2F>; Wed, 17 Apr 2002 17:22:25 +0200
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.83]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1TRSK; Wed, 17 Apr 2002 11:19:57 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 17 Apr 2002 11:14:15 -0400
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Fixing ASN.1 module error in PKIX-new-part1-12
In-Reply-To: <[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>

Many thanks to Rich Nicholas for detecting a mistake in the ASN.1 modules 
before Son-of-2459 was published as an RFC.  The problem is described in 
the attached message, and only impacts certificates that include the X.400 
ORAddress as an alterative name.  I have been working with the RFC Editor 
to correct this before publication.

I am not moving the definition.  If I did, then each module would 
have  IMPORTs from the other, and I am not sure that all of the tools could 
handle this circular situation.  At this late date, I did not want to 
create a third module, so the solution is to insert "IMPLICIT" in each of 
the tagged definitions associated with the ORAddress.

The resulting ASN.1 has been compiled with two different compilers, so I am 
quite confident that additional errors have not been introduced.  One of 
the compilers reports no errors.  The compiler complains about the 
specification of UNIVERSAL tags.  This is not unexpected, as discussed in 
the introduction to Appendix A.

I have submitted a new Internet-Draft 
(draft-ietf-pkix-new-part1-asn1-00.txt) that contains the updated ASN.1 
modules in order to distribute the corrections widely and quickly.

Russ

At 12:34 PM 2/28/2002 -0500, Nicholas, Richard wrote:
>Russ & Tim,
>
>The ORAddress syntax (and the syntax for its members) included in Appendix A
>should have been included in the PKIXImplicit88 module (A.2), rather than
>the PKIXExplicit88 module (A.1).
>
>ORAddress is defined in the MTSAbstractService module from X.411, which uses
>IMPLICIT tagging.
>
>- Rich


Received: by above.proper.com (8.11.6/8.11.3) id g3HF2U410387 for ietf-pkix-bks; Wed, 17 Apr 2002 08:02:30 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HF2Sm10382 for <[e-mail]>; Wed, 17 Apr 2002 08:02:28 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA17730; Wed, 17 Apr 2002 17:05:05 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041717021731:632 ; Wed, 17 Apr 2002 17:02:17 +0200 
Message-ID: <[e-mail]>
Date: Wed, 17 Apr 2002 17:02:14 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: Michael Myers <[e-mail]>, pkix <[e-mail]>
Subject: Re: Open issue: DPV additional information
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/04/2002 17:02:17, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/04/2002 17:02:23, Serialize complete at 17/04/2002 17:02:23
Content-Transfer-Encoding: 7bit
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>

Stephen,

> Denis,
> 
> > The concept and the functions of a CA and of a DPV server are not related.
> 
> What's the benefit of being (IMO) as pedantic as this?
> 
> Most people are happy enough for the term CA to mean either
> the system that does X.509 things or the authority that
> runs that system (and can therefore also be properly said
> to be doing things like DPV).

> Extract from the road map document:

   Certification Authority (CA) - An authority trusted by one or 
   more users to create and assign public key certificates. 
   Optionally the CA may create the user's keys. It is important to 
   note that the CA is responsible for the public key certificates 
   during their whole lifetime, not just for issuing them. 

Denis

 
> Stephen.
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com


Received: by above.proper.com (8.11.6/8.11.3) id g3HEluD09261 for ietf-pkix-bks; Wed, 17 Apr 2002 07:47:56 -0700 (PDT)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HElsm09256 for <[e-mail]>; Wed, 17 Apr 2002 07:47:54 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3HElsb27619 for <[e-mail]>; Wed, 17 Apr 2002 15:47:54 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Wed, 17 Apr 2002 15:42:26 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA16115; Wed, 17 Apr 2002 15:47:43 +0100
Message-ID: <[e-mail]>
Date: Wed, 17 Apr 2002 15:47:54 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Michael Myers <[e-mail]>, pkix <[e-mail]>
Subject: Re: Open issue: DPV additional information
References: <[e-mail]> <[e-mail]>
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>

Denis,

> The concept and the functions of a CA and of a DPV server are not related.

What's the benefit of being (IMO) as pedantic as this?

Most people are happy enough for the term CA to mean either
the system that does X.509 things or the authority that 
runs that system (and can therefore also be properly said
to be doing things like DPV).

Stephen.


-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HEO9B08492 for ietf-pkix-bks; Wed, 17 Apr 2002 07:24:09 -0700 (PDT)
Received: from mailgate5.cinetic.de (mailgate5.cinetic.de [217.72.192.165]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HEO7m08486 for <[e-mail]>; Wed, 17 Apr 2002 07:24:07 -0700 (PDT)
Received: from web.de (fmomail02.dlan.cinetic.de [172.20.1.46]) by mailgate5.cinetic.de (8.11.2/8.11.2/SuSE Linux 8.11.0-0.4) with SMTP id g3HENqv03151 for [e-mail]; Wed, 17 Apr 2002 16:23:52 +0200
Date: Wed, 17 Apr 2002 16:23:52 +0200
Message-Id: <[e-mail]>
MIME-Version: 1.0
Organization: http://freemail.web.de/
From: <[e-mail]>
To: [e-mail]
Subject: Future of OCSP V2
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3HEO8m08489
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 PKIXers,

I would like to know what is the future of OCSP V2,
since the last draft has already expired and I couldn t find any recent document about it. I m not following the discussions on this list, so excuse the fact that I may have missed something. So
-Will there be an OCSP V2 protocol?
-If yes will it be VERY different from the (expired) draft currently available?
-If no what will happen with DPD and DPV? Will they possibly be defined as independant protocols?

Thank you

WY

______________________________________________________________________________
Für alle, die nicht genug WEB.DE bekommen können. 100 MB Speicher, SMS Preisvorteil 
und noch mehr Kommunikation unter http://club.web.de/?mc=021101



Received: by above.proper.com (8.11.6/8.11.3) id g3HEAMO07836 for ietf-pkix-bks; Wed, 17 Apr 2002 07:10:22 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HEALm07832 for <[e-mail]>; Wed, 17 Apr 2002 07:10:21 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA26080; Wed, 17 Apr 2002 16:13:01 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041716101290:622 ; Wed, 17 Apr 2002 16:10:12 +0200 
Message-ID: <[e-mail]>
Date: Wed, 17 Apr 2002 16:10:11 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Open issue: DPV additional information
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/04/2002 16:10:13, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/04/2002 16:10:19, Serialize complete at 17/04/2002 16:10:19
Content-Transfer-Encoding: 7bit
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>

Michael,

> Denis,
> 
> Even as explanations, I disagree with the assertions.
> 
> A CA can most certainly sign DPV responses, especially relating
> to its own certificates.  A CA can also delegate that function
> (i.e. authorize a DPV server) to another trusted party.  That
> party could conceivably itself be a CA.  Thus a CA can sign DPV
> responses even with respect to certificates it didn't issue.

I respectfully disagree with you.

The concept and the functions of a CA and of a DPV server are not related.

There is no notion of "designated DPV responder" by a CA and we are not
going to define new certificate formats for that purpose.

Denis

> In my view, these are deployment and operational issues relating
> to specific policies, practices and perhaps even contracts, all
> of which seem to be well out of scope of our technical
> considerations.  But maybe that's just me.
> 
> Mike
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Denis Pinkas
> > Sent: Wednesday, April 17, 2002 2:42 AM
> > To: Michael Myers
> > Cc: pkix
> > Subject: Re: Open issue: DPV additional information
> >
> >
> >
> > Michael,
> >
> > The text you mention is *not* going to be placed in
> > the requirement
> > document, but was only explanations.
> >
> > Since there has been many small changes since version
> > 03, I will re-issue
> > a draft shortly so that everybody can see the result
> > of the more than
> > * 300 e-mails * that have been exchanged.
> >
> > Denis
> >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]]On Behalf Of
> > Denis Pinkas
> > > >
> > > > . . .
> > > >
> > > > No. DPV servers are never authorized by CAs. They
> > are either :
> > > >
> > > >  - locally trusted by their requesting clients for any
> > > >    policy, or/and
> > > >  - trusted under a given validation policy.
> > > >
> > > > . . .
> > > >
> > > > A CA cannot sign DPV responses.
> > >
> > > Denis,
> > >
> > > A while back I quite carefully parsed the -03
> > version of the I-D
> > > into requirements statements.  Nowhere did I see
> > these negative
> > > requirements asserted.  Had they been there, I'm
> > quite certain I
> > > would've raised an issue on the list.  Do you
> > really mean to say
> > > that a CA can neither directly affirm the validity
> > of its own
> > > certificates nor delegate that obvious right to
> > another party?
> > >
> > > Mike
> >


Received: by above.proper.com (8.11.6/8.11.3) id g3HE3Q507644 for ietf-pkix-bks; Wed, 17 Apr 2002 07:03:26 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HE3Pm07636 for <[e-mail]>; Wed, 17 Apr 2002 07:03:25 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3HE3LPm004314; Wed, 17 Apr 2002 07:03:21 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "pkix" <[e-mail]>
Subject: RE: Open issue: DPV additional information
Date: Wed, 17 Apr 2002 07:00:33 -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]>
Importance: Normal
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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,

Even as explanations, I disagree with the assertions.

A CA can most certainly sign DPV responses, especially relating
to its own certificates.  A CA can also delegate that function
(i.e. authorize a DPV server) to another trusted party.  That
party could conceivably itself be a CA.  Thus a CA can sign DPV
responses even with respect to certificates it didn't issue.

In my view, these are deployment and operational issues relating
to specific policies, practices and perhaps even contracts, all
of which seem to be well out of scope of our technical
considerations.  But maybe that's just me.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Wednesday, April 17, 2002 2:42 AM
> To: Michael Myers
> Cc: pkix
> Subject: Re: Open issue: DPV additional information
>
>
>
> Michael,
>
> The text you mention is *not* going to be placed in
> the requirement
> document, but was only explanations.
>
> Since there has been many small changes since version
> 03, I will re-issue
> a draft shortly so that everybody can see the result
> of the more than
> * 300 e-mails * that have been exchanged.
>
> Denis
>
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]]On Behalf Of
> Denis Pinkas
> > >
> > > . . .
> > >
> > > No. DPV servers are never authorized by CAs. They
> are either :
> > >
> > >  - locally trusted by their requesting clients for any
> > >    policy, or/and
> > >  - trusted under a given validation policy.
> > >
> > > . . .
> > >
> > > A CA cannot sign DPV responses.
> >
> > Denis,
> >
> > A while back I quite carefully parsed the -03
> version of the I-D
> > into requirements statements.  Nowhere did I see
> these negative
> > requirements asserted.  Had they been there, I'm
> quite certain I
> > would've raised an issue on the list.  Do you
> really mean to say
> > that a CA can neither directly affirm the validity
> of its own
> > certificates nor delegate that obvious right to
> another party?
> >
> > Mike
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HDA5F02778 for ietf-pkix-bks; Wed, 17 Apr 2002 06:10:05 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HDA2m02772 for <[e-mail]>; Wed, 17 Apr 2002 06:10:03 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA14476; Wed, 17 Apr 2002 15:12:44 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041715092992:611 ; Wed, 17 Apr 2002 15:09:29 +0200 
Message-ID: <[e-mail]>
Date: Wed, 17 Apr 2002 15:09:29 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/04/2002 15:09:29, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/04/2002 15:10:01, Serialize complete at 17/04/2002 15:10:01
Content-Transfer-Encoding: 7bit
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>

Peter,

> > Peter,
> >
> > The text proposal was as follows:
> >
> >  "When the request is authenticated, the requestor MUST be able, upon
> >  request, to have an identifier to be included in the response. Whether
> >  and how the communicated identification(s) are validated against identities
> >  derived by some authentication method depends on local configurations.
> >  Depending on that, the server MAY choose to copy, ignore, or replace
> >  the identities by some other in the response, or to refuse the
> >  request."
> >
> > You said: I did not ask for "when the request is authenticated".
> >
> > In such a case it means that you wanted a field to be sent by the requestor
> > and to be blindly copied and pasted by the server in the response. In that
> > case the semantics of this field cannot be verified by the server and thus
> > cannot bear more semantics than "this is the data that I copied and pasted
> > from the request".
 
> My request is to remove the part "when .. authenticated'
> You still have the second and thrd sentence which cover
> the possibilities that may occur.
> To avoid a misunderstanding, replace "local configurations" by
> "the validation policy".

This does not help. There is no relationship with the validation policy, 
but this has to do with the access conditions to the DPV server.
 
> In the following you are combining three actions, the
> indication of what the user specified, a potential authentication,
> what the server sends. You take only one case where the policy says
> no authentication necessary, and just blindly copy.

The problem is the following: when *another* client sees the DPV response
how can it interpret the semantics of that field ? If there is more than one
interpretation, no one will have the same understanding of the semantics of
that field.

Unless we provide an unambiguous semantics of that field, no requirement
can be added.

> > Capturing this requirement would lead to:
> >
> > "The requestor MUST be able, upon request, to have a field to be copied in
> > the response."
> 
> The proposed text allows a server to modify or reject the request
> in whatever way desired. The indication of a requestor identity by
> the client does not mean that the client has an absolute (MUST) right
> to get this back unmodified or untreated.

This means multiple semantics.

> > We do not have such a similar facility in an OCSP response and I wonder why
> > we should support it.
> 
> If your question would be 'why do we want this' I'd answer that similar
> features exist in real life, when you ask for some kind of attestation
> given explicitly to you and you are more or less authenticated.
> 
> "In reply of your (id of requester) demand from
> date, we certifiy today that you are still alive and can vote".

In that real life example, the id of requester is verified and is
thus copied from a dully authenticated identifier.

> "This is an invoice for item XXX for company mycorp".

In that real life example, the item XX is a field that is blindly copied by
the server.

> But, if others believe that the first half-sentence should remain
> in order to achieve consensus, I can live with that, too.

Either a choice has to be made between the various alternatives ... or two 
requirements should be incorporated. This would lead to the following text:

1. The requestor MUST be able, upon request, to have a field to be copied 
   in the response.

2. When the request is authenticated, the requestor SHOULD be able, upon
   request, to have an identifier to be included in the response. How this 
   identifier is derived from the authenticated identity depends on local 
   server conditions. The server MAY choose to refuse to include an
   identitier in the response.

Opinions ?
   
Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3HCsTQ02274 for ietf-pkix-bks; Wed, 17 Apr 2002 05:54:29 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3HCsNm02268 for <[e-mail]>; Wed, 17 Apr 2002 05:54:27 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Apr 2002 12:53:14 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA20180 for <[e-mail]>; Wed, 17 Apr 2002 08:53:03 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3HCsQQ07119 for <[e-mail]>; Wed, 17 Apr 2002 08:54:26 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1T3JX>; Wed, 17 Apr 2002 08:51:57 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.83]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1T3JV; Wed, 17 Apr 2002 08:51:50 -0400
From: "Housley, Russ" <[e-mail]>
To: vivek saraf <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 17 Apr 2002 08:53:54 -0400
Subject: Re: refine ment to question :Where does the certificate go?
In-Reply-To: <[e-mail]>
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>

Vivek:

He said PER, which is the Packed Encoding Rules.
He was not talking about the PEM file format.

Russ

At 10:05 PM 4/16/2002 -0700, vivek saraf wrote:

>hello,
>
>You can use both DER or PEM, the application in which
>you are going to use the sertificates that should
>support that. The IE accepts both DER and PEM formats.
>
>If you want to give the user certificates along with
>the CA certificate you must use pkcs #7.
>
>If you are have generated the private and public key
>pairs for the end user you must use pkcs #12, in this
>you can even put CA certificate also along with user
>private key and certificate.
>
>For open source for CA you can refer openca.
>
>vivek
>
>--- osama farook <[e-mail]> wrote:
> > ask about format
> > is it base64-encoded or der-encoded or pkcs#7 or
> > pkcs#12
> > Another question:?
> > If there are any project that has been like mine and
> > available on internet it is very kind of you to tell
> > me about it.
> > if there is any resources (not standards or rfcs)
> > I'm so tired of RFC and standards.I make like who
> > run in a circle.
> > I do my project using C#>
> >
>
>
>__________________________________________________
>Do You Yahoo!?
>Yahoo! Tax Center - online filing with TurboTax
>http://taxes.yahoo.com/


Received: by above.proper.com (8.11.6/8.11.3) id g3HBx1K29402 for ietf-pkix-bks; Wed, 17 Apr 2002 04:59:01 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HBx0m29396 for <[e-mail]>; Wed, 17 Apr 2002 04:59:00 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA26612 for <[e-mail]>; Wed, 17 Apr 2002 14:01:42 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041713585278:592 ; Wed, 17 Apr 2002 13:58:52 +0200 
Message-ID: <[e-mail]>
Date: Wed, 17 Apr 2002 13:58:52 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: DPV&DPD-REQ document update
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/04/2002 13:58:53, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/04/2002 13:59:00, Serialize complete at 17/04/2002 13:59:00
Content-Transfer-Encoding: 7bit
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>

Dear all,

I have issued the next version of DPV&DPD-REQ document, i.e.
draft-ietf-pkix-dpv-dpd-req-04.txt, after reading more than 200 e-mails 
and responding with more than 90 e-mails. The new version should be placed
shortly on the web server.

At this time, I believe/hope that I have updated the document in accordance
with the discussion.

The single remaining issue is a request from Peter Sylvester about the
inclusion of an additional field that would be inserted in the
response. At the present time, since we have not reached an agreement on
that last isssue, the document does not include a requirement along that
last issue.

Denis


Received: by above.proper.com (8.11.6/8.11.3) id g3HBDvM25606 for ietf-pkix-bks; Wed, 17 Apr 2002 04:13:57 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3HBDsm25595 for <[e-mail]>; Wed, 17 Apr 2002 04:13:55 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA08626; Wed, 17 Apr 2002 13:13:46 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 17 Apr 2002 13:13:46 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA04148; Wed, 17 Apr 2002 13:13:46 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA09233; Wed, 17 Apr 2002 13:13:45 +0200 (MET DST)
Date: Wed, 17 Apr 2002 13:13:45 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
Cc: [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,
> 
> The text proposal was as follows:
> 
>  "When the request is authenticated, the requestor MUST be able, upon
>  request, to have an identifier to be included in the response. Whether
>  and how the communicated identification(s) are validated against identities
>  derived by some authentication method depends on local configurations.
>  Depending on that, the server MAY choose to copy, ignore, or replace
>  the identities by some other in the response, or to refuse the
>  request."
> 
> You said: I did not ask for "when the request is authenticated".
> 
> In such a case it means that you wanted a field to be sent by the requestor
> and to be blindly copied and pasted by the server in the response. In that
> case the semantics of this field cannot be verified by the server and thus
> cannot bear more semantics than "this is the data that I copied and pasted
> from the request".


My request is to remove the part "when .. authenticated' 
You still have the second and thrd sentence which cover
the possibilities that may occur.
To avoid a misunderstanding, replace "local configurations" by
"the validation policy". 

In the following you are combining three actions, the 
indication of what the user specified, a potential authentication,
what the server sends. You take only one case where the policy says
no authentication necessary, and just blindly copy. 

> Capturing this requirement would lead to:
> 
> "The requestor MUST be able, upon request, to have a field to be copied in
> the response."

The proposed text allows a server to modify or reject the request
in whatever way desired. The indication of a requestor identity by
the client does not mean that the client has an absolute (MUST) right
to get this back unmodified or untreated.  

> 
> We do not have such a similar facility in an OCSP response and I wonder why
> we should support it.

If your question would be 'why do we want this' I'd answer that similar
features exist in real life, when you ask for some kind of attestation
given explicitly to you and you are more or less authenticated.

"In reply of your (id of requester) demand from
date, we certifiy today that you are still alive and can vote". 

"This is an invoice for item XXX for company mycorp". 

But, if others believe that the first half-sentence should remain
in order to achieve consensus, I can live with that, too.





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3H9iGP17816 for ietf-pkix-bks; Wed, 17 Apr 2002 02:44:16 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3H9iEm17811 for <[e-mail]>; Wed, 17 Apr 2002 02:44:14 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA26172; Wed, 17 Apr 2002 11:46:53 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041711433990:571 ; Wed, 17 Apr 2002 11:43:39 +0200 
Message-ID: <[e-mail]>
Date: Wed, 17 Apr 2002 11:43:39 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/04/2002 11:43:39, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/04/2002 11:44:11, Serialize complete at 17/04/2002 11:44:11
Content-Transfer-Encoding: 7bit
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>

Peter,

The text proposal was as follows:

 "When the request is authenticated, the requestor MUST be able, upon
 request, to have an identifier to be included in the response. Whether
 and how the communicated identification(s) are validated against identities
 derived by some authentication method depends on local configurations.
 Depending on that, the server MAY choose to copy, ignore, or replace
 the identities by some other in the response, or to refuse the
 request."

You said: I did not ask for "when the request is authenticated".

In such a case it means that you wanted a field to be sent by the requestor
and to be blindly copied and pasted by the server in the response. In that
case the semantics of this field cannot be verified by the server and thus
cannot bear more semantics than "this is the data that I copied and pasted
from the request".

Capturing this requirement would lead to:

"The requestor MUST be able, upon request, to have a field to be copied in
the response."

We do not have such a similar facility in an OCSP response and I wonder why
we should support it.

Opinions ?

Denis

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

> >       Denis, Peter:
> >
> >       I have one question about this proposal.  Is the object to be placed
> > into the response a transaction identifier or the RP's identifier?  If it's
> > the RP's identifier, IMO it should be called something like "requestor's
> > claimed identity" and it should not be permitted to be altered by the
> > server, although it might be permitted to be dropped.
> 
> "claimed identity" means that you concentrate in some way to
> authentication. I rarher see it: The identities which are
> destined to be able to present the result.
> A relay could ask 'on behalf of another client'.
> 
> Agreed that 'climed identity' may be one of the usage cases defined
> in a policy.
> 
> I may agree with something like
> 'a server SHOULD not alter arbitrarily the identities'.
> 
> >
> > [The DPV server MAY require client authentication, therefore, the DPV
> > request MUST be able to be authenticated].
> >
> > "When the request is authenticated, the requestor MUST be able, upon
> > request, to have an identifier to be included in the response. Whether
> > and how the communicated identification(s) are validated against identities
> > derived by some authentication method depends on local configurations.
> > Depending on that, the server MAY choose to copy, ignore, or replace
> > the identities by some other in the response, or to refuse the
> > request."
> 
> I did not ask for "when the request is authenticated".
> 
> >
> > My personal opinion is that since the server policy (which has nothing to do
> > with a validation policy) will be unkown (i.e. not visible in the response
> > and not fixed by the protocol), this field would have no value.
> 'server policy'? What would this be?
> 
> The point is that the server indicates the 'intended recipient'
> of the response. It determines this information using some explicit
> information from the client in combination with wahtever should be
> necessary as authentication.
>


Received: by above.proper.com (8.11.6/8.11.3) id g3H9gnv17775 for ietf-pkix-bks; Wed, 17 Apr 2002 02:42:49 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3H9glm17771 for <[e-mail]>; Wed, 17 Apr 2002 02:42:47 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA26162; Wed, 17 Apr 2002 11:45:23 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041711421302:570 ; Wed, 17 Apr 2002 11:42:13 +0200 
Message-ID: <[e-mail]>
Date: Wed, 17 Apr 2002 11:42:12 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Open issue: DPV additional information
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/04/2002 11:42:13, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 17/04/2002 11:42:44, Serialize complete at 17/04/2002 11:42:44
Content-Transfer-Encoding: 7bit
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>

Michael,

The text you mention is *not* going to be placed in the requirement
document, but was only explanations.

Since there has been many small changes since version 03, I will re-issue
a draft shortly so that everybody can see the result of the more than 
* 300 e-mails * that have been exchanged.

Denis

> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Denis Pinkas
> >
> > . . .
> >
> > No. DPV servers are never authorized by CAs. They are either :
> >
> >  - locally trusted by their requesting clients for any
> >    policy, or/and
> >  - trusted under a given validation policy.
> >
> > . . .
> >
> > A CA cannot sign DPV responses.
> 
> Denis,
> 
> A while back I quite carefully parsed the -03 version of the I-D
> into requirements statements.  Nowhere did I see these negative
> requirements asserted.  Had they been there, I'm quite certain I
> would've raised an issue on the list.  Do you really mean to say
> that a CA can neither directly affirm the validity of its own
> certificates nor delegate that obvious right to another party?
> 
> Mike


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3H55bY09815 for ietf-pkix-bks; Tue, 16 Apr 2002 22:05:37 -0700 (PDT)
Received: from web20006.mail.yahoo.com (web20006.mail.yahoo.com [216.136.225.69]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3H55am09809 for <[e-mail]>; Tue, 16 Apr 2002 22:05:36 -0700 (PDT)
Message-ID: <[e-mail]>
Received: from [202.144.45.2] by web20006.mail.yahoo.com via HTTP; Tue, 16 Apr 2002 22:05:40 PDT
Date: Tue, 16 Apr 2002 22:05:40 -0700 (PDT)
From: vivek saraf <[e-mail]>
Subject: Re: refine ment to question :Where does the certificate go?
To: osama farook <[e-mail]>, [e-mail]
In-Reply-To: <[e-mail]>
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>

hello,

You can use both DER or PEM, the application in which
you are going to use the sertificates that should
support that. The IE accepts both DER and PEM formats.

If you want to give the user certificates along with
the CA certificate you must use pkcs #7.

If you are have generated the private and public key
pairs for the end user you must use pkcs #12, in this
you can even put CA certificate also along with user
private key and certificate.

For open source for CA you can refer openca.

vivek
 
--- osama farook <[e-mail]> wrote:
> ask about format
> is it base64-encoded or der-encoded or pkcs#7 or
> pkcs#12
> Another question:?
> If there are any project that has been like mine and
> available on internet it is very kind of you to tell
> me about it.
> if there is any resources (not standards or rfcs)
> I'm so tired of RFC and standards.I make like who
> run in a circle.
> I do my project using C#>
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Tax Center - online filing with TurboTax
http://taxes.yahoo.com/


Received: by above.proper.com (8.11.6/8.11.3) id g3H0uuE03950 for ietf-pkix-bks; Tue, 16 Apr 2002 17:56:56 -0700 (PDT)
Received: from zetnet.co.uk ([e-mail] [194.247.47.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3H0usm03946 for <[e-mail]>; Tue, 16 Apr 2002 17:56:54 -0700 (PDT)
Received: from zetnet.co.uk (bts-0220.dialup.zetnet.co.uk [194.247.48.220]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g3H0ujo26825 for <[e-mail]>; Wed, 17 Apr 2002 01:56:46 +0100
Message-ID: <[e-mail]>
Date: Wed, 17 Apr 2002 01:02:15 +0000
From: David Hopwood <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
References: <[e-mail]>
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-----

At 12:35 PM 4/10/2002 -0400, Tom Gindin wrote:
>Second, I have reviewed draft-ietf-idn-uri-01.txt (by Martin Duerst) and
>it recommends that internationalized URI strings be converted to UTF-8
>but then escaped using %HH, so UTF8String is unnecessary.

<draft-masinter-url-i18n-08.txt> is more applicable:

# In case the current handling in an API or protocol is based on
# US-ASCII, UTF-8 is recommended as the encoding for IRIs, because
# this is compatible with US-ASCII, is in accordance with the
# recommendations of [RFC 2277], and makes it easy to convert to URIs
# where necessary. [...]
...
# While it might be possible to define IRI references and IRIs merely by
# their transformation to URIs, IRI references and IRIs can also be
# accepted and processed directly.
...
# Also, it is expected that all relevant new W3C formats and protocols
# will be required to handle IRIs [CharMod].

I.e. the intent is that escaping using %HH must be done for existing
protocols where URIs are specified as ASCII; not that specifying URIs as
ASCII is desirable for *new* protocols.

- -- 
David Hopwood <[e-mail]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPLzJYzkCAxeYt5gVAQG4LQf/fVKpiwbvc12r65934MfogBA6S2lOcr+f
ffNIPy76iMHJ3/Z+YWHQLyYPJKebtlpN1rfbPuoaU6LRSqb6r/xWfg6LLoAuHBO/
+vtJn/oo0YY5L4bZzqDkTle1rjz1cA0lDzZL8FeZ1ZMxN7++PNOupkC23j/TqYrw
7Wf2y/mpgghjZ8Un5b1aaPUtE2yOn87TH/QX2hRytsQTIAe9o2Z53eOvWYoQ3i2I
sUQ9llCtln7kbu03jPUmpr2MduLFPY6KouZ9Mq1gs9j/0w0fJwLcdPFQ3TMGvl2L
lWtc620m4YgsqvXWQR6WluCUi1dxeL+zZSOGvx/mnmFanKc2O22fXQ==
=V/pC
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3H00PZ03069 for ietf-pkix-bks; Tue, 16 Apr 2002 17:00:25 -0700 (PDT)
Received: from hudson.vtr.net (mail.vtr.net [164.77.245.136]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3H00Nm03064 for <[e-mail]>; Tue, 16 Apr 2002 17:00:23 -0700 (PDT)
Received: from casa ([200.83.44.187]) by hudson.vtr.net with SMTP id <20020416235935.RWLF817.hudson@casa> for <[e-mail]>; Tue, 16 Apr 2002 19:59:35 -0400
From: "Juan Carlos Perez A." <[e-mail]>
To: "pkix" <[e-mail]>
Subject: RE: refine ment to question :Where does the certificate go?
Date: Tue, 16 Apr 2002 20:02:20 -0400
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C1E581.9DAFF1A0"
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]>
Importance: Normal
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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_0003_01C1E581.9DAFF1A0
Content-Type: text/plain;
	charset="windows-1256"
Content-Transfer-Encoding: 7bit

The certificate is in pkcs#7. BAse-64 is a tex-format representation of any
binary, as pkcs#7 too.

I suggest to you visit: www.pki-page.org, www.sourceforge.net,
www.freshmeat.net . and the Getronics's free certificate library
http://www.getronicsgov.com/hot/cml_lib.htm

regsrds

j.c.


  -----Mensaje original-----
  De: [e-mail] [mailto:[e-mail]]En
nombre de osama farook
  Enviado el: martes, 16 de abril de 2002 17:23
  Para: [e-mail]
  Asunto: refine ment to question :Where does the certificate go?


  ask about format
  is it base64-encoded or der-encoded or pkcs#7 or pkcs#12
  Another question:?
  If there are any project that has been like mine and available on internet
it is very kind of you to tell me about it.
  if there is any resources (not standards or rfcs)
  I'm so tired of RFC and standards.I make like who run in a circle.
  I do my project using C#>

------=_NextPart_000_0003_01C1E581.9DAFF1A0
Content-Type: text/html;
	charset="windows-1256"
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=3Dwindows-1256">
<META content=3D"MSHTML 6.00.2715.400" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><SPAN class=3D434245423-16042002><FONT color=3D#0000ff size=3D2>The =
certificate=20
is in pkcs#7. BAse-64 is a tex-format representation of any binary, as =
pkcs#7=20
too.</FONT></SPAN></DIV>
<DIV><SPAN class=3D434245423-16042002><FONT color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D434245423-16042002><FONT color=3D#0000ff size=3D2>I =
suggest to you=20
visit: <A href=3D"http://www.pki-page.org">www.pki-page.org</A>, <A=20
href=3D"http://www.sourceforge.net">www.sourceforge.net</A>, <A=20
href=3D"http://www.freshmeat.net">www.freshmeat.net</A> . and the =
Getronics's free=20
certificate library <A=20
href=3D"http://www.getronicsgov.com/hot/cml_lib.htm">http://www.getronics=
gov.com/hot/cml_lib.htm</A></FONT></SPAN></DIV>
<DIV><SPAN class=3D434245423-16042002><FONT color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D434245423-16042002><FONT color=3D#0000ff=20
size=3D2>regsrds</FONT></SPAN></DIV>
<DIV><SPAN class=3D434245423-16042002><FONT color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D434245423-16042002><FONT color=3D#0000ff=20
size=3D2>j.c.</FONT></SPAN></DIV>
<DIV><SPAN class=3D434245423-16042002><FONT color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D434245423-16042002><FONT color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Mensaje original-----<BR><B>De:</B> =
[e-mail]=20
  [mailto:[e-mail]]<B>En nombre de </B>osama=20
  farook<BR><B>Enviado el:</B> martes, 16 de abril de 2002 =
17:23<BR><B>Para:</B>=20
  [e-mail]<BR><B>Asunto:</B> refine ment to question :Where =
does the=20
  certificate go?<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial size=3D2>ask about format<BR>is it =
base64-encoded or=20
  der-encoded or pkcs#7 or pkcs#12<BR>Another question:?<BR>If there are =
any=20
  project that has been like mine and available on internet it is very =
kind of=20
  you to tell me about it.<BR>if there is any resources (not standards =
or=20
  rfcs)<BR>I'm so tired of RFC and standards.I make like who run in a=20
  circle.<BR>I do my project using =
C#&gt;</FONT></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0003_01C1E581.9DAFF1A0--




Received: by above.proper.com (8.11.6/8.11.3) id g3GLNUb26855 for ietf-pkix-bks; Tue, 16 Apr 2002 14:23:30 -0700 (PDT)
Received: from hotmail.com (dav34.sea1.hotmail.com [207.68.162.91]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GLNTm26851 for <[e-mail]>; Tue, 16 Apr 2002 14:23:29 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 16 Apr 2002 14:23:27 -0700
X-Originating-IP: [217.139.55.152]
From: "osama farook" <[e-mail]>
To: <[e-mail]>
Subject: refine ment to question :Where does the certificate go?
Date: Tue, 16 Apr 2002 23:23:19 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_006B_01C1E59D.B1D0EC90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 16 Apr 2002 21:23:27.0005 (UTC) FILETIME=[F284B4D0:01C1E58C]
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_006B_01C1E59D.B1D0EC90
Content-Type: text/plain;
	charset="windows-1256"
Content-Transfer-Encoding: quoted-printable

ask about format
is it base64-encoded or der-encoded or pkcs#7 or pkcs#12
Another question:?
If there are any project that has been like mine and available on =
internet it is very kind of you to tell me about it.
if there is any resources (not standards or rfcs)
I'm so tired of RFC and standards.I make like who run in a circle.
I do my project using C#>

------=_NextPart_000_006B_01C1E59D.B1D0EC90
Content-Type: text/html;
	charset="windows-1256"
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=3Dwindows-1256">
<META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>ask about format<BR>is it =
base64-encoded or=20
der-encoded or pkcs#7 or pkcs#12<BR>Another question:?<BR>If there are =
any=20
project that has been like mine and available on internet it is very =
kind of you=20
to tell me about it.<BR>if there is any resources (not standards or =
rfcs)<BR>I'm=20
so tired of RFC and standards.I make like who run in a circle.<BR>I do =
my=20
project using C#&gt;</FONT></DIV></BODY></HTML>

------=_NextPart_000_006B_01C1E59D.B1D0EC90--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GKaxi22865 for ietf-pkix-bks; Tue, 16 Apr 2002 13:36:59 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GKavm22861 for <[e-mail]>; Tue, 16 Apr 2002 13:36:57 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3GKaWms368010; Tue, 16 Apr 2002 16:36:34 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3GKaT535078; Tue, 16 Apr 2002 16:36:29 -0400
Importance: Normal
Sensitivity: 
Subject: RE: Open issue: DPV relay
To: Peter Sylvester <[e-mail]>
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 16 Apr 2002 16:36:31 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/16/2002 04:36:30 PM
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>

      Peter:

      First, if you don't need an external party to validate the
certificate, you don't need to worry about any weaknesses in DPV.  Second,
unless you can prove that either a TTP or a party with closer links to the
signer than to the RP is the actual source of your DPV response, it
probably won't help much as evidence.

            Tom Gindin

Peter Sylvester <[e-mail]> on 04/16/2002 08:02:03 AM

To:    [e-mail], Tom Gindin/Watson/IBM@IBMUS
cc:    [e-mail], [e-mail]
Subject:    RE: Open issue: DPV relay


Tom,


One question is: 'to prove vis-a-vis which entity':

A work flow component may just need a confirmation
of the companies internal work flow. If the
company needs to prove this vis-a-vis other
potential external entities, it sets up
a policy ccording to that to do:

This may for example include a DPV service operated
by 'the other company' in order to prove that
'we have asked you (the other compnay), and your
compnay server asserted that the certificate
of person XYZ is useful to policy P, and we
have validated the status of your servers
certificate at our commonly agreed CA validation
service.

It is up to the 'local DPV service' to ensure to
which extend the answer can be considered more
or less globally binding.

Peter S.

>
>       Peter:
>
>       If nobody disagrees with your statement about an RP providing its
own
> DPV service, I think that you have provided the conclusive argument
against
> using DPV responses in NR.  After all, in many NR scenarios the RP is
> trying to prove that his reliance on a signature was justified.  If the
RP
> provides its own DPV service, the only answer to the question "why did
you
> consider the signing certificate valid?" which it provides is "because I
> thought so at the time".  If you assume that single RP's rarely provide
DPV
> in practice but that organizations which employ many RP's may do so, the
> answer is "because my employer thought so at the time".
>       This does not mean that DPV is not valuable, but it would mean that
> it (as opposed to DPD) is not useful for NR.
>
>             Tom Gindin
>
>
> Peter Williams <[e-mail]>@mail.imc.org on 04/11/2002 01:00:53
PM
>
> Sent by:    [e-mail]
>
>
> To:    "'Peter Sylvester '" <[e-mail]>
> cc:    "'[e-mail] '" <[e-mail]>
> Subject:    RE: Open issue: DPV relay
>
>
>
>
> Peter.
>
> OCSP has always envisioned and practised a relying party
> authorizing an OCSP Responder: no CA/AA involvement
> is required and no certificate need be issued, in this
> case.
>
> Carry over this conformance requirement from OCSP to DPV:
>
> An OCSP client (which includes a client that is a DPV server)
> must potentially accept an OCSP response according to ALL the
> rules of 4.2.2.2. There are three cases: (1) (2) and (3).
>
> Lets remember, a relying party can operate its
> own DPV service for its own benefit. The relying party
> needs no authority from a CA to do so. The operator
> of a DPV server is not necessarily a TTP, and
> need have no relationship to the cert or CRL
> issuer, other than that of performing
> relying party obligations or (less stringent) user
> obligations according to the CP.
>
> -----Original Message-----
> From: Denis Pinkas
> To: Peter Sylvester
> Cc: [e-mail]
> Sent: 4/11/02 3:18 AM
> Subject: Re: Open issue: DPV relay
>
>
> > See the second point and also read 4.2.2.2
>
> Which says:
>
>    It is necessary however to ensure that the entity signing this
>    information is authorized to do so.  Therefore, a certificate's
>    issuer MUST either sign the OCSP responses itself or it MUST
>    explicitly designate this authority to another entity.
>
> > Or: You may want a requirement that the DPV responder must ensure
> > that the OCSP responses are signed by a CA or an authorised responder
> > and not by some locally trusted OCSP responder in order to
> > be sure that an 'evidence verifier' finds trustworthy information.
>
> This is correct. However, it is not necesssary to add this requirement
> in
> the DPV requirements document since this requirement is already in
> section
> 4.2.2.2 from RFC 2560 (OCSP).
>
> > > > To make the simple case, if a DPV response is signed directly by
> the CA
> > > > (or by an authorised responder), you have the same situation.
> > >
> > > No. A CA can only assert information about what it is directly
> responsible.
>
> > So, the DPV response made by the CA just talks about the certificates
> > it has directly issued.
>
> No. Talking about the certificates that a DPV server may have issued
> does
> not make sense. Certificates are only issued by CAs, AFAIK. Once again,
> a DPV server MUST answer for one (or more) certificates and must verify
> an entire chain of certificates, whoever has issued them. A DPV server
> is
> *not* a CA. A DPV server can be *any* service provider. An organization
> running a CA may also run a DPV server, in the same way as an
> organization
> running a CA may also provide a Time-Stamping service.
>
> > > No CA is responsible for all the certifiactes from one path. An OCSP
> query
> > > is for ONE certificate, while a DPV query involves a CHAIN of
> certificates.
> >
> > The text says:
> >
> >    The Delegated Path Validation (DPV) protocol allows a server to
> >    validate one or more public key certificates according to a
> validation
> >    policy.
> >
> >    In order to validate a certificate, a chain of multiple
> certificates,
> >    called a certification path, may be needed, comprising a
> certificate
> >    of the public key owner (the end entity) signed by one CA, and zero
> or
> >    more additional certificates of CAs signed by other CAs.
>
> > In the simple case of only one CA, an OCSP response signed by the CA
> > concerning the certificate in question does not say anything the
> > validity of the CA cert since when it was signed with the same key.
>
> > You thus just have on certificate.
>
> > In a case of one intermediate CA, the DPV response may for example
> > contain two OCSP responses, one signed by the intermediate CA
> > concerning the revocation status of the end user and another
> > concerning the statius of the intermediate CA signed by the
> > top CA.
>
> > If both CAs provide a DPV service instead of an OCSP service
>
> You mean "If the organisation hosting a CA also provides a DPV service
> ... "
>
> > in the same way, you have exactly the same situation except
> > that this is a positive status information.
> >
> > For example, the initial client asks for a combined status,
> > it asks his own trusted service, this server asks the intermediate
> > CA either to provide an OCSP status or a DPV status of the
> > cert in question and then asks the top CA to provide a status of
> > the intermediate CA's cert, and well, even three other OCSP
> > responders to provide statement that the top level
> > CA's cert is good.
>
> I believe that you have mis-understood one idea behind DPV. DPV verifies
> the
> whole path processing. A DPV status about one intermediate certificate
> of
> the chain does not make sense. The validation policy is not about that
> intermediate certificate but about a given certificate and a whole chain
> above it. Applying the validation policy on an intermediate certificate
> only
> does not make sense.
>
> > DPV would allow to combine the responses differently.
> > It can well be that the intermediate CA/DPV responder
> > itself asks for a DPV response from the top CA/DPV
> > and include this in his DPV response to the initial server.
> >
> > >
> > > There are no similarities.
> > "Ok, let's talk."
> >
> > > > I think that there must be a language problem somewhere because I
> > > > fail to see what *not* you are referring, i.e. to see where we are
> > > > in disagreement.  I have not said that it is necessary for the
> client
> > > > to gather all information. I have said that the protocol must
> provide
> > > > a method to allow a client to ask and the server to respond with
> that
> > > > information.
> > >
> > > Maybe, since we possibly interpreted diffrently "what has
> contributed to the
> > > final decision".
> > >
> > > > > In case of a dispute, testing again the certificate validity,
> means that
> > > > > certificates, CRLs and OCSP responses must be available.
> Anything else is
> > > > > useless.
> > >
> > > > I think that this may be the core of our disagreement.
> > >
> > > > This is because you only accept that CA can create assertions
> about the
> > > > validity of their certificates using CRLs and OCSP.
> > >
> > > Correct.
> >
> > Unfortunately we may be both wrong.
> >
> > > > As soon as you would
> > > > admit that some new protocol or service is provided that enhances
> and in
> > > > particular replaces them, the statements obtained via that service
> are
> > > > necessary.
> > >
> > > > I would like to know what you would have said 5 years ago when
> only
> > > > CRLs existed.
> > >
> > > Basicaly the chain must be verified and no element fom the chain
> must be
> > > revoked.
> > >
> > > Five years ago this information was provided off-line, i.e. via
> CRLs. OCSP
> > > allows to obtain the same information on-line. Between on-line and
> off-line
> > > I currently see no other mechanism.
>
> > But you can have different protocols for these characteristics.
> Offline
> > you could use trees, online you can have DPV,
>
> No. On-line, to know the revocation status of a single certificate we
> only
> have OCSP. RFC 2560 states:
>
>    It is necessary however to ensure that the entity signing this
>    information is authorized to do so.  Therefore, a certificate's
>    issuer MUST either sign the OCSP responses itself or it MUST
>    explicitly designate this authority to another entity.
>
> Note that this is true as well for CRLs. Either the CA signs the CRL
> directly or designate another authority.
>
> RFC 2459 RECOMMENDS for the support of the CRL distribution points
> extension
> which then contains a cRLIssuer field. "If the certificate issuer is not
> the
> CRL issuer, then the cRLIssuer field MUST be present and contain the
> Name of
> the CRL issuer. If the certificate issuer is also the CRL issuer, then
> the
> cRLIssuer field MUST be omitted ..."
>
> > or other techniques like
> > timestamps over CRLs and OCSP responses to have a proof that the
> server
> > has provided the OCSPresp/CRL at a current date.
>
> Time-stamping is not needed to prove that the server has provided the
> OCSPresp/CRL at a current date. An OCSP response includes such a date.
> CRL
> checking uses thisUpdate and nextUpdate. Time-stamping may however be
> useful
> for other reasons. An informational RFC (i.e. RFC 3126 - Electronic
> Signature Formats for long term electronic signatures) does however
> indicate
> such a format in the context of a signature policy. Another format could
> be
> derived from it in the context of a validation policy.
>
> > > The basic question is whether first-hand information and second-hand
> > > information should be used. In case of a dispute, only first-hand
> > > information is useful (certificates and revocation status
> information from
> > > the CAs responsible for every certificate from the chain). DPV
> responses
> > > (i.e. the signed "yes" answers) are useless, unless the plaintiff
> and the
> > > defendant both trust the same DPV server.
>
> > OCSP responses may also be useless, unless the plaintiff and the
> > defendant both trust the same OCSP server.
>
> Wrong. RFC 2560 sates:
>
>    It is necessary however to ensure that the entity signing this
>    information is authorized to do so.  Therefore, a certificate's
>    issuer MUST either sign the OCSP responses itself or it MUST
>    explicitly designate this authority to another entity.
>
> In either of these cases, the plaintiff and the defendant cannot argue
> that
> the OCSP response is not valid (unless the OCSP responder has been
> revoked
> by the CA). They cannot argue that such responses are useless, or if
> they
> do,
> this argumentation will be rejected.
>
> I have made my best efforts to explain all the rational behind DPV
> responses,
> which are very different from OCSP responses. I have also made my best
> efforts to explain why in the general case a DPV response from a given
> server is not necessarilly trusted by all clients, and thus would be
> useless
> in front of a court.
>
> The security consideration section is very explicit on this issue:
>
> "A DPV client must trust a DPV server to provide the correct answer.
> However, this does not mean that all DPV clients will trust the same
> DPV servers. While a positive answer might be sufficient for one DPV
> client, that same positive answer will not necessarily convince
> another DPV client."
>
> Can we finally close this issue ?
>
> Denis
>
> > Peter
>
>
>
>
>






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GK8NE20218 for ietf-pkix-bks; Tue, 16 Apr 2002 13:08:23 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3GK8Lm20213 for <[e-mail]>; Tue, 16 Apr 2002 13:08:22 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 16 Apr 2002 20:07:14 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA18893 for <[e-mail]>; Tue, 16 Apr 2002 09:58:09 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3GDxU911070 for <[e-mail]>; Tue, 16 Apr 2002 09:59:30 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1TA1A>; Tue, 16 Apr 2002 09:57:01 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.169]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1TADX; Tue, 16 Apr 2002 09:56:52 -0400
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 16 Apr 2002 09:52:22 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
In-Reply-To: <[e-mail]>
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>

Denis:

Many issues have been raised and resolved.  The problem is that the remain 
ones cannot be discussed efficiently without updating the document.  In 
this way, we will all have the same context for the next phase of the 
discussion.  I think that some of your issues are resolved.  I know that 
others are not.

Russ


At 10:15 AM 4/16/2002 +0200, Denis Pinkas wrote:
>Russ,
>
> > Tom:
>
> > We are about to post an update to the draft.  Expect to see it in the next
> > day or so.
>
>Isn't it premature ?
>
>I am still expecting responses to my set of comments and questions.
>
>Regards,
>
>Denis
>
> > I recognize the severe memory constraints of smartcards.
> >
> > Russ
> >
> > At 12:35 PM 4/10/2002 -0400, Tom Gindin wrote:
> >
> > >       Russ:
> > >
> > >       Most of the following concerns the data structures of the current
> > >draft and of my last posting.  First, should the URI really be optional in
> > >cases where the binary component is a hash?  What good is the logotype
> > >field with a hash but no way to reference the image?  Second, I have
> > >reviewed draft-ietf-idn-uri-01.txt (by Martin Duerst) and it recommends
> > >that internationalized URI strings be converted to UTF-8 but then escaped
> > >using %HH, so UTF8String is unnecessary.  Therefore, we should simplify
> > >VerifiedReference as follows:
> > >       VerifiedReference ::= SEQUENCE {
> > >             hashAlgorithm     AlgorithmIdentifier,
> > >             dataHash    OCTET STRING,
> > >             uri          IA5String,
> > >       }
> > >
> > >       On a different topic, smart cards and other tokens have the least
> > >space of any place certificates are likely to be put, so if in-line
> > >logotypes are OK there they're OK anywhere.
> > >
> > >             Tom Gindin
> > >
> > >
> > >"Housley, Russ" <[e-mail]> on 04/08/2002 01:17:11 PM
> > >
> > >To:    Tom Gindin/Watson/IBM@IBMUS
> > >cc:    [e-mail]
> > >Subject:    Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
> > >
> > >
> > >Tom:
> > >
> > > >The following is just a personal opinion, but one based on fairly
> > > >well-understood trends.  I don't think that in-line logotypes are
> > >CURRENTLY
> > > >worth the space that they'd take up on a smart card, but I would guess
> > >that
> > > >they will be in two more smart-card generations and perhaps only one.
> > > >Given the amount of time between standard proposal and deployment, it's
> > >not
> > > >premature to standardize it.
> > >
> > >I tend to agree with your assessment of storage on smart 
> cards.  Today, all
> > >
> > >of the certificates stored on one smart card are likely to be associated
> > >with one community.  Therefore, a logo will like appear on the smart card
> > >itself.
> > >
> > >Of course, there are other places that certificates and private keys are
> > >stored....
> > >
> > > >       However, I also have a question about the current data structure.
> > > >First, why is the URI optional (assuming that the only binary value 
> is the
> > > >digest, as at present)?  Second, why would we not permit in-line 
> logotypes
> > > >(in which case the URI is suppressed)?  This would require some edits to
> > > >LogotypeData, but nothing very difficult.  One possibility would be:
> > > >       LogotypeData ::= SEQUENCE {
> > > >           typeOfLogotype       TypeOfLogotype,
> > > >           hashAlgorithm        AlgorithmIdentifier,   -- might be
> > >OPTIONAL,
> > > >it's not meaningful for GIF's
> > > >           CHOICE  {
> > > >             logotypeDataHash     OCTET STRING,
> > > >       gif   [0]         IMPLICIT OCTET STRING
> > > >       },
> > > >           logotypeDataUri      IA5String OPTIONAL }
> > > >
> > > >       Another would be:
> > > >       LogotypeData ::= SEQUENCE {
> > > >           typeOfLogotype       TypeOfLogotype,
> > > >           CHOICE  {
> > > >             logotypeReference VerifiedReference,
> > > >       gif               OCTET STRING
> > > >       }
> > > >           }
> > > >       VerifiedReference ::= SEQUENCE {
> > > >             hashAlgorithm     AlgorithmIdentifier,
> > > >             dataHash    OCTET STRING,
> > > >             CHOICE      {
> > > >                   uri          IA5String,
> > > >                   intlUri           UTF8String  }
> > > >       }
> > > >
> > > >
> > > >       IMO VerifiedReference is a generally useful type, so its names do
> > >not
> > > >contain reference to logotypes.  My understanding of COMPONENTS OF, 
> which
> > > >may be faulty, is that defining LogotypeData using COMPONENTS OF
> > > >VerifiedReference as an element of a CHOICE would not produce a useful
> > > >result because each of the elements of VerifiedReference would show 
> up in
> > > >the CHOICE rather than merely hashAlgorithm going into the CHOICE 
> with the
> > > >other fields added to LogotypeData's SEQUENCE.
> > >
> > >We are in the final steps of an updated I-D.  It addresses some of these
> > >issues, but not all.
> > >
> > >Is there a reference for UTF8String URI?
> > >
> > >Russ


Received: by above.proper.com (8.11.6/8.11.3) id g3GIcnN14065 for ietf-pkix-bks; Tue, 16 Apr 2002 11:38:49 -0700 (PDT)
Received: from texas.pobox.com (texas.pobox.com [64.49.223.111]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GIcmm14058 for <[e-mail]>; Tue, 16 Apr 2002 11:38:48 -0700 (PDT)
Received: from gnosis (12-230-145-100.client.attbi.com [12.230.145.100]) by texas.pobox.com (Postfix) with ESMTP id 4AF7945389 for <[e-mail]>; Tue, 16 Apr 2002 14:38:49 -0400 (EDT)
From: "L Williams" <[e-mail]>
To: <[e-mail]>
Subject: Inconsistency in certificate extension profiles leads to deployment nightmares
Date: Tue, 16 Apr 2002 11:38:56 -0700
Message-ID: <000201c1e575$f832fcf0$6401a8c0@gnosis>
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, Build 10.0.3416
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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>

I've spent the last few years heavily involved in the architecture and
deployment of PKI in a wide variety of environments. Recently, I've been
running into more and more problems with trying to define certificate
profiles that meet the current needs and have a modicum of a chance of
being useful for the foreseeable future.

I wanted to share some of the issues I'm running into and get people's
thoughts and opinions on how we can perhaps standardize a few extension
profiles for general end entity use.

Most of the customers want to use certificates for some combination of
the following:
- digital signature
- encryption
- authentication

There is a degenerative case, but it is rare (was asked about it a few
times):
- non-repudiation certificates

This means that if they want a single end-entity profile, it should
cover all of these uses. This ends up being the simplest case, although
there can be issues with encoding types (e.g., MS requires the UPN value
in the subject alternative name field be encoded as UTF8, if you want to
be compatible with some of their features).

Dual certificates are where we begin to see problems. Something as
simple as key usage can be complicated. Take this example:
- Certificate 1, Encryption - Should key usage be keyEncipherment, or
both keyEncipherment and dataEncipherment? I realize in most
implementations keyEncipherment is fine, but I've begun to see eCommerce
implementations where database field-level encryption is done using the
public key directly.
-Certificate 2, Signature verification and Authentication - Since some
authentication implementations encrypt keys, should key usage be
digitalSignature and keyEncipherment? In a dual certificate environment
this can cause applications to break (two certificates with
keyEncipherment set)

There are many other similar issues. I keep finding that every time I
think I have this ironed out, something gets proven wrong. Simply using
a "PKIX compliant" profile is usually not enough.

So here is the challenge. What do you recommend? Any thoughts on
extension profiles that meet the following common business requirements:
- Can be generally used for encryption, digital signature and
authentication
- Since most companies use MS desktops, add support for EFS, AD name
mapping (include the UPN value, etc), and potentially PKINIT (MS
compatible or not)
- Full S/MIME support
- Full support as a client-side SSL certificate
- Forward looking and future compatible


Thanks for any thoughts or input.

-Laudon Williams



Received: by above.proper.com (8.11.6/8.11.3) id g3GIaUN13705 for ietf-pkix-bks; Tue, 16 Apr 2002 11:36:30 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GIaSm13697 for <[e-mail]>; Tue, 16 Apr 2002 11:36:28 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA04522; Tue, 16 Apr 2002 20:36:26 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 16 Apr 2002 20:36:26 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA01012; Tue, 16 Apr 2002 20:36:23 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA08931; Tue, 16 Apr 2002 20:36:23 +0200 (MET DST)
Date: Tue, 16 Apr 2002 20:36:23 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: requester identifier in DPV response
Cc: [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>

>       Denis, Peter:
> 
>       I have one question about this proposal.  Is the object to be placed
> into the response a transaction identifier or the RP's identifier?  If it's
> the RP's identifier, IMO it should be called something like "requestor's
> claimed identity" and it should not be permitted to be altered by the
> server, although it might be permitted to be dropped.

"claimed identity" means that you concentrate in some way to
authentication. I rarher see it: The identities which are
destined to be able to present the result. 
A relay could ask 'on behalf of another client'.

Agreed that 'climed identity' may be one of the usage cases defined
in a policy.   

I may agree with something like 
'a server SHOULD not alter arbitrarily the identities'.


> 
> [The DPV server MAY require client authentication, therefore, the DPV
> request MUST be able to be authenticated].
> 
> "When the request is authenticated, the requestor MUST be able, upon
> request, to have an identifier to be included in the response. Whether
> and how the communicated identification(s) are validated against identities
> derived by some authentication method depends on local configurations.
> Depending on that, the server MAY choose to copy, ignore, or replace
> the identities by some other in the response, or to refuse the
> request."

I did not ask for "when the request is authenticated".

> 
> My personal opinion is that since the server policy (which has nothing to do
> with a validation policy) will be unkown (i.e. not visible in the response
> and not fixed by the protocol), this field would have no value.
'server policy'? What would this be? 

The point is that the server indicates the 'intended recipient'
of the response. It determines this information using some explicit
information from the client in combination with wahtever should be 
necessary as authentication. 

 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GFe3901921 for ietf-pkix-bks; Tue, 16 Apr 2002 08:40:03 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GFe2m01916 for <[e-mail]>; Tue, 16 Apr 2002 08:40:02 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3GFdJms158138; Tue, 16 Apr 2002 11:39:20 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3GFdG539496; Tue, 16 Apr 2002 11:39:16 -0400
Importance: Normal
Sensitivity: 
Subject: Re: Open issue: requester identifier in DPV response
To: Denis Pinkas <[e-mail]>
Cc: Peter Sylvester <[e-mail]>, pkix <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 16 Apr 2002 11:39:16 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/16/2002 11:39:16 AM
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>

      Denis, Peter:

      I have one question about this proposal.  Is the object to be placed
into the response a transaction identifier or the RP's identifier?  If it's
the RP's identifier, IMO it should be called something like "requestor's
claimed identity" and it should not be permitted to be altered by the
server, although it might be permitted to be dropped.

            Tom Gindin


Denis Pinkas <[e-mail]>@mail.imc.org on 04/16/2002 10:42:18 AM

Sent by:    [e-mail]


To:    Peter Sylvester <[e-mail]>
cc:    pkix <[e-mail]>
Subject:    Re: Open issue: requester identifier in DPV response



Peter and the list,

I have changed the name of the thread into "requester identifier in DPV
response" to reflect the issue.

I also believe that it is time to return to the list.

Peter is asking to add the following:

[The DPV server MAY require client authentication, therefore, the DPV
request MUST be able to be authenticated].

"When the request is authenticated, the requestor MUST be able, upon
request, to have an identifier to be included in the response. Whether
and how the communicated identification(s) are validated against identities
derived by some authentication method depends on local configurations.
Depending on that, the server MAY choose to copy, ignore, or replace
the identities by some other in the response, or to refuse the
request."

My personal opinion is that since the server policy (which has nothing to
do
with a validation policy) will be unkown (i.e. not visible in the response
and not fixed by the protocol), this field would have no value.

Opinions ?

Denis






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GFPom01171 for ietf-pkix-bks; Tue, 16 Apr 2002 08:25:50 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GFPnm01167 for <[e-mail]>; Tue, 16 Apr 2002 08:25:49 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3GFPePm017682; Tue, 16 Apr 2002 08:25:40 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Peter Sylvester" <[e-mail]>
Cc: "pkix" <[e-mail]>
Subject: RE: Open issue: DPV additional information
Date: Tue, 16 Apr 2002 08:22:52 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
>
> . . .
>
> No. DPV servers are never authorized by CAs. They are either :
>
>  - locally trusted by their requesting clients for any
>    policy, or/and
>  - trusted under a given validation policy.
>
> . . .
>
> A CA cannot sign DPV responses.

Denis,

A while back I quite carefully parsed the -03 version of the I-D
into requirements statements.  Nowhere did I see these negative
requirements asserted.  Had they been there, I'm quite certain I
would've raised an issue on the list.  Do you really mean to say
that a CA can neither directly affirm the validity of its own
certificates nor delegate that obvious right to another party?

Mike



Received: by above.proper.com (8.11.6/8.11.3) id g3GFJui00952 for ietf-pkix-bks; Tue, 16 Apr 2002 08:19:56 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GFJrm00947 for <[e-mail]>; Tue, 16 Apr 2002 08:19:54 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA03412; Tue, 16 Apr 2002 17:19:52 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 16 Apr 2002 17:19:52 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA29911; Tue, 16 Apr 2002 17:19:51 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA08889; Tue, 16 Apr 2002 17:19:50 +0200 (MET DST)
Date: Tue, 16 Apr 2002 17:19:50 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV additional information
Cc: [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,
> 
> We need to agree on a common text. So, please focuss on the text.
> 
> Since you made no proposal, but only provided a "hint", what about the new
> text below ?
I am not sure whether your intend is to give a complete list of all possibilities,
or just an example of what can currently be considered as possible
responses. If it is the latter, that's ok. 

To avoid some misunderstanding , I propose: 

.. Such information may (not necessarily exclusively) consist of a certification path ...





Received: by above.proper.com (8.11.6/8.11.3) id g3GFGQn00829 for ietf-pkix-bks; Tue, 16 Apr 2002 08:16:26 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GFGOm00824 for <[e-mail]>; Tue, 16 Apr 2002 08:16:24 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3GFFVms285500; Tue, 16 Apr 2002 11:15:33 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3GFFS535070; Tue, 16 Apr 2002 11:15:28 -0400
Importance: Normal
Sensitivity: 
Subject: Re: Open issue: DPV relay
To: Denis Pinkas <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 16 Apr 2002 11:15:31 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/16/2002 11:15:28 AM
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>

      Denis:

      My point was that a DPV response was probably insufficient to support
certificate validation in NR.  Obviously, it doesn't imply signature
verification - but neither does an OCSP response.
      There is no reason for this issue to hold up sending DPV to the IESG,
since the majority of certificate validation does not have the same
requirements as NR.

            Tom Gindin


Denis Pinkas <[e-mail]> on 04/16/2002 09:32:29 AM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    "'[e-mail] '" <[e-mail]>
Subject:    Re: Open issue: DPV relay


Tom,

>       Peter:
>
>       If nobody disagrees with your statement about an RP providing its
own
> DPV service, I think that you have provided the conclusive argument
against
> using DPV responses in NR.

The argumentation from Peter (William) has nothing to do with your
conclusion.

The question is different: can DPV be used for signature validation ?

The answer is the following:

A DPV response alone will be insufficient, so why there is a need for
signature validation.

This debate will NOT start before the DPV document is sent to the IESG for
last call.

Denis

> After all, in many NR scenarios the RP is
> trying to prove that his reliance on a signature was justified.  If the
RP
> provides its own DPV service, the only answer to the question "why did
you
> consider the signing certificate valid?" which it provides is "because I
> thought so at the time".  If you assume that single RP's rarely provide
DPV
> in practice but that organizations which employ many RP's may do so, the
> answer is "because my employer thought so at the time".
>       This does not mean that DPV is not valuable, but it would mean that
> it (as opposed to DPD) is not useful for NR.
>
>             Tom Gindin
(snip)




Received: by above.proper.com (8.11.6/8.11.3) id g3GEgS328406 for ietf-pkix-bks; Tue, 16 Apr 2002 07:42:28 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GEgQm28402 for <[e-mail]>; Tue, 16 Apr 2002 07:42:26 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA17820; Tue, 16 Apr 2002 16:45:07 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041616421905:512 ; Tue, 16 Apr 2002 16:42:19 +0200 
Message-ID: <[e-mail]>
Date: Tue, 16 Apr 2002 16:42:18 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Open issue: requester identifier in DPV response
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 16:42:19, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 16:42:26, Serialize complete at 16/04/2002 16:42:26
Content-Transfer-Encoding: 7bit
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>

Peter and the list,

I have changed the name of the thread into "requester identifier in DPV
response" to reflect the issue.

I also believe that it is time to return to the list.

Peter is asking to add the following:

[The DPV server MAY require client authentication, therefore, the DPV 
request MUST be able to be authenticated]. 

"When the request is authenticated, the requestor MUST be able, upon 
request, to have an identifier to be included in the response. Whether 
and how the communicated identification(s) are validated against identities
derived by some authentication method depends on local configurations. 
Depending on that, the server MAY choose to copy, ignore, or replace 
the identities by some other in the response, or to refuse the
request."

My personal opinion is that since the server policy (which has nothing to do
with a validation policy) will be unkown (i.e. not visible in the response
and not fixed by the protocol), this field would have no value.

Opinions ?

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GEQSq27766 for ietf-pkix-bks; Tue, 16 Apr 2002 07:26:28 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GEQQm27756 for <[e-mail]>; Tue, 16 Apr 2002 07:26:26 -0700 (PDT)
Received: from tsg1 ([12.81.64.7]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020416142620.UQJE28245.mtiwmhc23.worldnet.att.net@tsg1>; Tue, 16 Apr 2002 14:26:20 +0000
Message-ID: <008b01c1e552$8340de30$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Tim Polk" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Open issue: DPV relay
Date: Tue, 16 Apr 2002 07:25:01 -0700
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 5.50.4522.1200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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: "Denis Pinkas" <[e-mail]>
To: "Tim Polk" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, April 16, 2002 1:31 AM
Subject: Re: Open issue: DPV relay


>
> Tim,
>
> I will be leaving my office tomorrow evening for one full week
> (both holidays then business), so we had better solve this rapidly
> so that I can post a new draft before leaving. :-)
>
> See my comments embedded.
>
> > Folks,
> >
> > Here is my take on the relay/referral fracas, in two parts.
> >
> > The first part addresses DPV relay includes (1) my assumptions about
DPV,
> > (2) a little rationale, and (3) a proposed "solution" for DPV replay.
The
> > second part amounts to four complaints about the impact of adding
> > referrals, and my belief that it should not be supported.
> >
> >                                                          Part 1: DPV
Relay
> > Proposal
> >
> > Assumption #1:
> >
> > DPV relay is irrelevant to DPV clients.  They request answers from a
> > trusted DPV server X, and server X MUST stand behind the response.
(That
> > is, X can't say "I don't know, but Server Y says this certificate is
> > okay."  It is up to X whether it can trust that answer.)
>
> Fine.
>
> > Assumption #2:
> >
> > Many DPV servers will not relay requests.
> >
> > Tim's Theory and what it is, too:
> >
> > DPV servers that do not relay requests do not care if the request has
been
> > relayed before they received it.

A DPV server that does not relay requests will never see input from another
DPV server unless it is the "victim" of a relayed DPV proofing request. This
problem-mode is real since this definition this DPV server probably cannot
allow its response to be knowingly relayed either... so how does it, a
non-relaying server, respond to the relayed request?

>
> True.
>
> > That only matters for loop detection/relay limits, etc.
>
> Wrong. If they do not relay, a loop can never occur.

>
> > DPV servers that do relay requests MUST be able to detect whether or not
> > the request has been previously relayed,

So a relay-history list and policy OID or indicator is needed.

>
> Correct.
>
> > and the request MUST have the complete list of servers that have
received the request.
>
> No. You are specifying a solution, which would work but there are other
> solutions to this problem: a list of servers is not the single way to
solve
> this issue. Since we are writing requirements we should not impose a
> solution.

OK, then how could you tell retrospectively where the decision in the DPV
chain was made? This is the problem with the current model. No real
auditing.

>
> I believe that this requirement can be captured by the following sentence:
>
>    When a server supports a relay mechanism, a mechanism to detect
>    loops or repetition MUST be provided.

I am more worried about the logging of DPV events which as far as I can tell
is still missing from the Drafts.

>
> Now, to explain in more details:
>
> When a DPV server relays a request to another DPV server:
>
>     1) it must copy already present relay history information (if any),
>
>     2) it must add relay history information in the relayed request.
>
> As an example, the added information can simply be a nonce and thus no
> server name needs to be ever used. A sequence of nonces would thus do the
> job nicely and avoid naming problems or naming conventions. Practically
> speaking, a sequence of INTEGER would do the job.
>
> > So, the conformance requirements:
> >
> > Support for DPV relay is OPTIONAL for DPV servers.  DPV servers that do
not
> > relay requests do not need to process or recognize the relay history
> > information.
>
> Correct.
>
> > DPV servers that relay requests MUST satisfy all the following
conditions:
> >            (1) recognize and process relay history if present in a DPV
request;
> >            (2) able to generate a relay history
>
>  .. information. Full stop.
>
> > including the complete list of servers that have already forwarded this
request;
>
> No. As said earlier, the received relay information is blindly copied.

Then there is no way to deal with the auditing of the DPV process. Denis
would you be willing to build a bridge between the DPV Server's operations
and that of a local RFC3161 Server??? If  a DPV process could use a TST as a
staged proofing model and include a set of or single event histriy token
with the response - you have killed two birds with one stone.

>
> >            (3) before relaying a request, the DPV server MUST verify
that
> > the chosen DPV server
> >            has not already seen the message.  (That is loop detection
> > occurs at the requester,

Or already responded. Look at a matrix of say 10 DPV servers in a chain. So
Server #1 gets a request that it cannot answer so it hands the request off
to #4, who in turn passes it to #5, 6, and 7 which is configured to refer
back to #2 who then refers to #4 for the second time this "event
verification action". So is this a loop? How would you log these actions?

> >            not the recipient).
>
> Correct.
>
> > This proposal does not impact clients, it simplifies the most common DPV
> > servers, and it places *all* the burden on DPV servers that relay
> > requests.  (As it should be, in my opinion.)

there is a rudimentary question here as to whether a Trust Provider (the DPV
Server) needs to disclose its trust processes in normal uses. If it does not
need to then this anonymous model is OK, but otherwise there is some serious
logging and query processing to be added here.

>
> Correct.
>
> >                                                       Part 2: DPV
Referrals
> >
> > Complaint A
> >
> > Referrals impact *all* DPV clients, significantly increasing their
> > complexity.  Currently, the requirements indicate whether or not the
server
> > could build a satisfactory path.  It seems to me that referrals force
all
> > DPV clients to interpret a new class of answers: "I don't know but ask
> > Server B".  (By itself, this isn't that compelling, I admit.  They get
> > stronger, IMHO.)
>
> No. The idea is to send back the referral in a non-critical extension so
> that it can be ignored by a client. Clients must be ready to support
> extension fields, but are not mandated to understand any non-critical
> extension.

I think what you have here is actually two (2) different client types.
Lightweight and Heavywieght. The lightweight ones dont care about relaying
and maybe optionally can say they will or will not accept the relayed and
history-embellished CPV sessions, and the heavyweight ones do.

This is the easiest way to let the market decide which one is better.

>
> > Complaint B
> >
> > One of the nice features of DPV is a single "proof" for archival.  This
> > feature is broken by the introduction of DPV referrals.

Not true if a TST is included at each step of the way and would make me feel
better about the RFC3161 use models.

>  > Assume Alice is
> > trusts Server A, but she receives a referral indicating that Server A
> > trusts Server B to validate this certificate.
>
> No. It is not the meaning of the referral. Assume Alice trusts Server A,
but
> she receives a referral from server A indicating that Server B
> might be able to validate this certificate. Alice has to make its own
> decision whether she can trust or not server B.
>
> > Alice will need to maintain both the referral from Server A and the
> > answer from Server B.
>
> No. See above.
>
> > Complaint C
> >
> > Referrals for DPV are a very different animal than LDAP referrals.

Once again a further justification for the call to simplify PKIX into a
standard user interface anc service calling model.

> > Once
> > again, assume Alice is trusts Server A but she receives a referral
> > indicating that Server A trusts Server B to validate this
> > certificate.  Alice will need to authenticate the identity of Server B
> > using information from Server A.  I think that means that Server A needs
to
> > identify Server B by including Server B's public key in the referral.
If
> > that is true, we just created a parallel key management infrastructure
and
> > increased the complexity of our universe.
>
> Not with the trust model that I indicated.
>
> > Complaint D
> >
> > If LDAP is any indicator, nobody does referrals anyway.  Since DPV
> > referrals will be significantly more complex, wouldn't it be better to
put
> > the load on the server?

This is non-sequitor. LDAP is not an Audit Authentication or Event
Processing Protocol like the trust services of a DPV server. It is a
Directory Access Protocol and that's that.

>
> The load will be on the servers. Clients may fully ignore that field.
>
> Denis
>
>
> > Alright, I'm off my soapbox.  Flame suit is zipped.  What do you all
think
> > of these proposals?

Flaming!

> >
> > Thanks,
> >
> > Tim Polk



Received: by above.proper.com (8.11.6/8.11.3) id g3GENmw27649 for ietf-pkix-bks; Tue, 16 Apr 2002 07:23:48 -0700 (PDT)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GENlm27645 for <[e-mail]>; Tue, 16 Apr 2002 07:23:47 -0700 (PDT)
Received: from tsg1 ([12.81.64.7]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020416142342.DTCN28991.mtiwmhc22.worldnet.att.net@tsg1>; Tue, 16 Apr 2002 14:23:42 +0000
Message-ID: <008a01c1e552$253c1ca0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Open issue: DPV relay
Date: Tue, 16 Apr 2002 06:56:00 -0700
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 5.50.4522.1200
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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 is the problem - Loops in the processing mode or loops in the reporting
model - they are not necessarily the same and both could have serious
effects on the outcome or transactions in a legal stance.

Todd

----- Original Message -----
From: "Peter Sylvester" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, April 16, 2002 6:05 AM
Subject: Re: Open issue: DPV relay


>
> >
> > Please read again the message. The proposal is to add one sentence
> > (i.e. two lines), no more:
> >
> >     When a server supports a relay mechanism, a mechanism to detect
> >     loops or repetition MUST be provided.
>
> I fully agree with this. I just wanted to be sure that your
> describing text just outlines some possible (mechanisms/ideas of)
solutions.
>
>
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GEEhe27329 for ietf-pkix-bks; Tue, 16 Apr 2002 07:14:43 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GEEgm27324 for <[e-mail]>; Tue, 16 Apr 2002 07:14:42 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA19936; Tue, 16 Apr 2002 16:17:14 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041616140670:508 ; Tue, 16 Apr 2002 16:14:06 +0200 
Message-ID: <[e-mail]>
Date: Tue, 16 Apr 2002 16:14:06 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV additional information
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 16:14:06, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 16:14:34, Serialize complete at 16/04/2002 16:14:34
Content-Transfer-Encoding: 7bit
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>

Peter,

We need to agree on a common text. So, please focuss on the text.

Since you made no proposal, but only provided a "hint", what about the new
text below ?

The DPV request MUST allow the client to request the server to include 
in its response additional information which will allow relying parties 
not trusting the requested DPV server to be confident that the 
certificate validation has correctly been performed. Such information 
may consist of a certification path, revocation status information from 
authorised CRL issuers or authorised OCSP responders, revocation status 
information from CRL issuers or OCSP responders trusted under the 
validation policy, time-stamp tokens from TSAs responders trusted under 
the validation policy, or a DPV response from a DPV server that is 
trusted under the validation policy.  When the certificate is valid 
according to the validation policy, the server MUST, upon request, 
include that information in the response. However, the server MAY omit 
that information when the certificate is invalid or when it cannot 
determine the validity.

Denis

> > A CA cannot sign DPV responses.
> 
> Is this a statement like 'there is no requirement for relaying'?
> 
> Why is it impossible for a CA to sign DPV responses for the certificates
> it has issued, or to delegate this to an 'authorised DPV service'?
> 
> > DPV servers are either :
> 
> >  - locally trusted by their requesting clients for any policy, or/and
> >  - trusted under a given validation policy.
> 
> And nothing prohibits you to have DPV servers that are 'authorised
> by a CA'. This is an independant category.
> 
> But since the only reason for this comparisons was to convince you
> that a DPV response may also contain a DPV response, and since
> you finally agreed with this, I do not really think that it absolutely
> necssary at that point to discuss our possible disagreements about
> the operational scenarios of OCSP and DPV servers, so you might
> ignore to comment the previous questions.
> 
> Thus:
> 
> I don't think that it is necessary in the following to have the
> 'authorised' restrictions for OCSP and CRLs.
> 
> Besides you, nobody has asked for this, as far as I remember.
> 
> 
> > I would propose the following :
> >
> > The DPV request MUST allow the client to request the server to include
> > in its response additional information which will allow relying parties
> > not trusting the requested DPV server to be confident that the
> > certificate validation has correctly been performed. Such information
> > may consist of a certification path, revocation status
> > information from authorised CRL issuers or authorised OCSP responders,
> > time-stamp tokens, or a DPV response from a DPV server that is trusted
> > under the validation policy.  When the certificate is valid according
> > to the validation policy, the server MUST, upon request, include that
> > information in the response. However, the server MAY omit that
> > information when the certificate is invalid or when it cannot determine
> > the validity.
> >
> > Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GE3Z026945 for ietf-pkix-bks; Tue, 16 Apr 2002 07:03:35 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GE3Xm26935 for <[e-mail]>; Tue, 16 Apr 2002 07:03:33 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA02884; Tue, 16 Apr 2002 16:03:31 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 16 Apr 2002 16:03:31 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA29540; Tue, 16 Apr 2002 16:03:30 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA08864; Tue, 16 Apr 2002 16:03:30 +0200 (MET DST)
Date: Tue, 16 Apr 2002 16:03:30 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV additional information
Cc: [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>

> A CA cannot sign DPV responses.

Is this a statement like 'there is no requirement for relaying'? 
 
Why is it impossible for a CA to sign DPV responses for the certificates 
it has issued, or to delegate this to an 'authorised DPV service'?

> DPV servers are either :

>  - locally trusted by their requesting clients for any policy, or/and
>  - trusted under a given validation policy.

And nothing prohibits you to have DPV servers that are 'authorised
by a CA'. This is an independant category. 

But since the only reason for this comparisons was to convince you
that a DPV response may also contain a DPV response, and since
you finally agreed with this, I do not really think that it absolutely 
necssary at that point to discuss our possible disagreements about 
the operational scenarios of OCSP and DPV servers, so you might
ignore to comment the previous questions. 

Thus:   

I don't think that it is necessary in the following to have the 
'authorised' restrictions for OCSP and CRLs.

Besides you, nobody has asked for this, as far as I remember.

 
> I would propose the following :
> 
> The DPV request MUST allow the client to request the server to include 
> in its response additional information which will allow relying parties 
> not trusting the requested DPV server to be confident that the 
> certificate validation has correctly been performed. Such information 
> may consist of a certification path, revocation status 
> information from authorised CRL issuers or authorised OCSP responders, 
> time-stamp tokens, or a DPV response from a DPV server that is trusted 
> under the validation policy.  When the certificate is valid according 
> to the validation policy, the server MUST, upon request, include that 
> information in the response. However, the server MAY omit that 
> information when the certificate is invalid or when it cannot determine 
> the validity.
> 
> Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GDpZf26532 for ietf-pkix-bks; Tue, 16 Apr 2002 06:51:35 -0700 (PDT)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GDoDm26473 for <[e-mail]>; Tue, 16 Apr 2002 06:50:14 -0700 (PDT)
Received: from stsIBMT20.addtrust.com ([192.168.101.122]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Tue, 16 Apr 2002 15:49:53 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 16 Apr 2002 15:49:52 +0200
To: Denis Pinkas <[e-mail]>, "Housley, Russ" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
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-OriginalArrivalTime: 16 Apr 2002 13:49:53.0291 (UTC) FILETIME=[95E17DB0:01C1E54D]
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,

At 10:15 2002-04-16 +0200, Denis Pinkas wrote:

>Russ,
>
> > Tom:
>
> > We are about to post an update to the draft.  Expect to see it in the next
> > day or so.
>
>Isn't it premature ?

I don't think so. I do believe that I announced at PKIX that a new draft 
would be generated that would include the ad-hoc suggestions.

>I am still expecting responses to my set of comments and questions.

I don't know which questions that you consider not answered. I do believe 
though that the new draft is a better base for discussions, and just maybe 
it will make some of your questions go away.

I'm however still interested in your general view, with respect to the new 
draft, whether you think we are solving the wrong problem or if you think 
we are solving the right problem but in a wrong way.

If we can settle that, I belive it will be much easier to sort out the 
technical issues.

/Stefan


>Regards,
>
>Denis
>
> > I recognize the severe memory constraints of smartcards.
> >
> > Russ
> >
> > At 12:35 PM 4/10/2002 -0400, Tom Gindin wrote:
> >
> > >       Russ:
> > >
> > >       Most of the following concerns the data structures of the current
> > >draft and of my last posting.  First, should the URI really be optional in
> > >cases where the binary component is a hash?  What good is the logotype
> > >field with a hash but no way to reference the image?  Second, I have
> > >reviewed draft-ietf-idn-uri-01.txt (by Martin Duerst) and it recommends
> > >that internationalized URI strings be converted to UTF-8 but then escaped
> > >using %HH, so UTF8String is unnecessary.  Therefore, we should simplify
> > >VerifiedReference as follows:
> > >       VerifiedReference ::= SEQUENCE {
> > >             hashAlgorithm     AlgorithmIdentifier,
> > >             dataHash    OCTET STRING,
> > >             uri          IA5String,
> > >       }
> > >
> > >       On a different topic, smart cards and other tokens have the least
> > >space of any place certificates are likely to be put, so if in-line
> > >logotypes are OK there they're OK anywhere.
> > >
> > >             Tom Gindin
> > >
> > >
> > >"Housley, Russ" <[e-mail]> on 04/08/2002 01:17:11 PM
> > >
> > >To:    Tom Gindin/Watson/IBM@IBMUS
> > >cc:    [e-mail]
> > >Subject:    Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
> > >
> > >
> > >Tom:
> > >
> > > >The following is just a personal opinion, but one based on fairly
> > > >well-understood trends.  I don't think that in-line logotypes are
> > >CURRENTLY
> > > >worth the space that they'd take up on a smart card, but I would guess
> > >that
> > > >they will be in two more smart-card generations and perhaps only one.
> > > >Given the amount of time between standard proposal and deployment, it's
> > >not
> > > >premature to standardize it.
> > >
> > >I tend to agree with your assessment of storage on smart 
> cards.  Today, all
> > >
> > >of the certificates stored on one smart card are likely to be associated
> > >with one community.  Therefore, a logo will like appear on the smart card
> > >itself.
> > >
> > >Of course, there are other places that certificates and private keys are
> > >stored....
> > >
> > > >       However, I also have a question about the current data structure.
> > > >First, why is the URI optional (assuming that the only binary value 
> is the
> > > >digest, as at present)?  Second, why would we not permit in-line 
> logotypes
> > > >(in which case the URI is suppressed)?  This would require some edits to
> > > >LogotypeData, but nothing very difficult.  One possibility would be:
> > > >       LogotypeData ::= SEQUENCE {
> > > >           typeOfLogotype       TypeOfLogotype,
> > > >           hashAlgorithm        AlgorithmIdentifier,   -- might be
> > >OPTIONAL,
> > > >it's not meaningful for GIF's
> > > >           CHOICE  {
> > > >             logotypeDataHash     OCTET STRING,
> > > >       gif   [0]         IMPLICIT OCTET STRING
> > > >       },
> > > >           logotypeDataUri      IA5String OPTIONAL }
> > > >
> > > >       Another would be:
> > > >       LogotypeData ::= SEQUENCE {
> > > >           typeOfLogotype       TypeOfLogotype,
> > > >           CHOICE  {
> > > >             logotypeReference VerifiedReference,
> > > >       gif               OCTET STRING
> > > >       }
> > > >           }
> > > >       VerifiedReference ::= SEQUENCE {
> > > >             hashAlgorithm     AlgorithmIdentifier,
> > > >             dataHash    OCTET STRING,
> > > >             CHOICE      {
> > > >                   uri          IA5String,
> > > >                   intlUri           UTF8String  }
> > > >       }
> > > >
> > > >
> > > >       IMO VerifiedReference is a generally useful type, so its names do
> > >not
> > > >contain reference to logotypes.  My understanding of COMPONENTS OF, 
> which
> > > >may be faulty, is that defining LogotypeData using COMPONENTS OF
> > > >VerifiedReference as an element of a CHOICE would not produce a useful
> > > >result because each of the elements of VerifiedReference would show 
> up in
> > > >the CHOICE rather than merely hashAlgorithm going into the CHOICE 
> with the
> > > >other fields added to LogotypeData's SEQUENCE.
> > >
> > >We are in the final steps of an updated I-D.  It addresses some of these
> > >issues, but not all.
> > >
> > >Is there a reference for UTF8String URI?
> > >
> > >Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GDX6d24240 for ietf-pkix-bks; Tue, 16 Apr 2002 06:33:06 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GDX4m24236 for <[e-mail]>; Tue, 16 Apr 2002 06:33:04 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA30130; Tue, 16 Apr 2002 15:35:40 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041615322941:496 ; Tue, 16 Apr 2002 15:32:29 +0200 
Message-ID: <[e-mail]>
Date: Tue, 16 Apr 2002 15:32:29 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: "'[e-mail] '" <[e-mail]>
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 15:32:29, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 15:33:00, Serialize complete at 16/04/2002 15:33:00
Content-Transfer-Encoding: 7bit
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>

Tom,

>       Peter:
> 
>       If nobody disagrees with your statement about an RP providing its own
> DPV service, I think that you have provided the conclusive argument against
> using DPV responses in NR.  

The argumentation from Peter (William) has nothing to do with your
conclusion.

The question is different: can DPV be used for signature validation ? 

The answer is the following:

A DPV response alone will be insufficient, so why there is a need for
signature validation.

This debate will NOT start before the DPV document is sent to the IESG for
last call.

Denis

> After all, in many NR scenarios the RP is
> trying to prove that his reliance on a signature was justified.  If the RP
> provides its own DPV service, the only answer to the question "why did you
> consider the signing certificate valid?" which it provides is "because I
> thought so at the time".  If you assume that single RP's rarely provide DPV
> in practice but that organizations which employ many RP's may do so, the
> answer is "because my employer thought so at the time".
>       This does not mean that DPV is not valuable, but it would mean that
> it (as opposed to DPD) is not useful for NR.
> 
>             Tom Gindin
> 
> Peter Williams <[e-mail]>@mail.imc.org on 04/11/2002 01:00:53 PM
> 
> Sent by:    [e-mail]
> 
> To:    "'Peter Sylvester '" <[e-mail]>
> cc:    "'[e-mail] '" <[e-mail]>
> Subject:    RE: Open issue: DPV relay
> 
> Peter.
> 
> OCSP has always envisioned and practised a relying party
> authorizing an OCSP Responder: no CA/AA involvement
> is required and no certificate need be issued, in this
> case.
> 
> Carry over this conformance requirement from OCSP to DPV:
> 
> An OCSP client (which includes a client that is a DPV server)
> must potentially accept an OCSP response according to ALL the
> rules of 4.2.2.2. There are three cases: (1) (2) and (3).
> 
> Lets remember, a relying party can operate its
> own DPV service for its own benefit. The relying party
> needs no authority from a CA to do so. The operator
> of a DPV server is not necessarily a TTP, and
> need have no relationship to the cert or CRL
> issuer, other than that of performing
> relying party obligations or (less stringent) user
> obligations according to the CP.
> 
> -----Original Message-----
> From: Denis Pinkas
> To: Peter Sylvester
> Cc: [e-mail]
> Sent: 4/11/02 3:18 AM
> Subject: Re: Open issue: DPV relay
> 
> > See the second point and also read 4.2.2.2
> 
> Which says:
> 
>    It is necessary however to ensure that the entity signing this
>    information is authorized to do so.  Therefore, a certificate's
>    issuer MUST either sign the OCSP responses itself or it MUST
>    explicitly designate this authority to another entity.
> 
> > Or: You may want a requirement that the DPV responder must ensure
> > that the OCSP responses are signed by a CA or an authorised responder
> > and not by some locally trusted OCSP responder in order to
> > be sure that an 'evidence verifier' finds trustworthy information.
> 
> This is correct. However, it is not necesssary to add this requirement
> in
> the DPV requirements document since this requirement is already in
> section
> 4.2.2.2 from RFC 2560 (OCSP).
> 
> > > > To make the simple case, if a DPV response is signed directly by
> the CA
> > > > (or by an authorised responder), you have the same situation.
> > >
> > > No. A CA can only assert information about what it is directly
> responsible.
> 
> > So, the DPV response made by the CA just talks about the certificates
> > it has directly issued.
> 
> No. Talking about the certificates that a DPV server may have issued
> does
> not make sense. Certificates are only issued by CAs, AFAIK. Once again,
> a DPV server MUST answer for one (or more) certificates and must verify
> an entire chain of certificates, whoever has issued them. A DPV server
> is
> *not* a CA. A DPV server can be *any* service provider. An organization
> running a CA may also run a DPV server, in the same way as an
> organization
> running a CA may also provide a Time-Stamping service.
> 
> > > No CA is responsible for all the certifiactes from one path. An OCSP
> query
> > > is for ONE certificate, while a DPV query involves a CHAIN of
> certificates.
> >
> > The text says:
> >
> >    The Delegated Path Validation (DPV) protocol allows a server to
> >    validate one or more public key certificates according to a
> validation
> >    policy.
> >
> >    In order to validate a certificate, a chain of multiple
> certificates,
> >    called a certification path, may be needed, comprising a
> certificate
> >    of the public key owner (the end entity) signed by one CA, and zero
> or
> >    more additional certificates of CAs signed by other CAs.
> 
> > In the simple case of only one CA, an OCSP response signed by the CA
> > concerning the certificate in question does not say anything the
> > validity of the CA cert since when it was signed with the same key.
> 
> > You thus just have on certificate.
> 
> > In a case of one intermediate CA, the DPV response may for example
> > contain two OCSP responses, one signed by the intermediate CA
> > concerning the revocation status of the end user and another
> > concerning the statius of the intermediate CA signed by the
> > top CA.
> 
> > If both CAs provide a DPV service instead of an OCSP service
> 
> You mean "If the organisation hosting a CA also provides a DPV service
> ... "
> 
> > in the same way, you have exactly the same situation except
> > that this is a positive status information.
> >
> > For example, the initial client asks for a combined status,
> > it asks his own trusted service, this server asks the intermediate
> > CA either to provide an OCSP status or a DPV status of the
> > cert in question and then asks the top CA to provide a status of
> > the intermediate CA's cert, and well, even three other OCSP
> > responders to provide statement that the top level
> > CA's cert is good.
> 
> I believe that you have mis-understood one idea behind DPV. DPV verifies
> the
> whole path processing. A DPV status about one intermediate certificate
> of
> the chain does not make sense. The validation policy is not about that
> intermediate certificate but about a given certificate and a whole chain
> above it. Applying the validation policy on an intermediate certificate
> only
> does not make sense.
> 
> > DPV would allow to combine the responses differently.
> > It can well be that the intermediate CA/DPV responder
> > itself asks for a DPV response from the top CA/DPV
> > and include this in his DPV response to the initial server.
> >
> > >
> > > There are no similarities.
> > "Ok, let's talk."
> >
> > > > I think that there must be a language problem somewhere because I
> > > > fail to see what *not* you are referring, i.e. to see where we are
> > > > in disagreement.  I have not said that it is necessary for the
> client
> > > > to gather all information. I have said that the protocol must
> provide
> > > > a method to allow a client to ask and the server to respond with
> that
> > > > information.
> > >
> > > Maybe, since we possibly interpreted diffrently "what has
> contributed to the
> > > final decision".
> > >
> > > > > In case of a dispute, testing again the certificate validity,
> means that
> > > > > certificates, CRLs and OCSP responses must be available.
> Anything else is
> > > > > useless.
> > >
> > > > I think that this may be the core of our disagreement.
> > >
> > > > This is because you only accept that CA can create assertions
> about the
> > > > validity of their certificates using CRLs and OCSP.
> > >
> > > Correct.
> >
> > Unfortunately we may be both wrong.
> >
> > > > As soon as you would
> > > > admit that some new protocol or service is provided that enhances
> and in
> > > > particular replaces them, the statements obtained via that service
> are
> > > > necessary.
> > >
> > > > I would like to know what you would have said 5 years ago when
> only
> > > > CRLs existed.
> > >
> > > Basicaly the chain must be verified and no element fom the chain
> must be
> > > revoked.
> > >
> > > Five years ago this information was provided off-line, i.e. via
> CRLs. OCSP
> > > allows to obtain the same information on-line. Between on-line and
> off-line
> > > I currently see no other mechanism.
> 
> > But you can have different protocols for these characteristics.
> Offline
> > you could use trees, online you can have DPV,
> 
> No. On-line, to know the revocation status of a single certificate we
> only
> have OCSP. RFC 2560 states:
> 
>    It is necessary however to ensure that the entity signing this
>    information is authorized to do so.  Therefore, a certificate's
>    issuer MUST either sign the OCSP responses itself or it MUST
>    explicitly designate this authority to another entity.
> 
> Note that this is true as well for CRLs. Either the CA signs the CRL
> directly or designate another authority.
> 
> RFC 2459 RECOMMENDS for the support of the CRL distribution points
> extension
> which then contains a cRLIssuer field. "If the certificate issuer is not
> the
> CRL issuer, then the cRLIssuer field MUST be present and contain the
> Name of
> the CRL issuer. If the certificate issuer is also the CRL issuer, then
> the
> cRLIssuer field MUST be omitted ..."
> 
> > or other techniques like
> > timestamps over CRLs and OCSP responses to have a proof that the
> server
> > has provided the OCSPresp/CRL at a current date.
> 
> Time-stamping is not needed to prove that the server has provided the
> OCSPresp/CRL at a current date. An OCSP response includes such a date.
> CRL
> checking uses thisUpdate and nextUpdate. Time-stamping may however be
> useful
> for other reasons. An informational RFC (i.e. RFC 3126 - Electronic
> Signature Formats for long term electronic signatures) does however
> indicate
> such a format in the context of a signature policy. Another format could
> be
> derived from it in the context of a validation policy.
> 
> > > The basic question is whether first-hand information and second-hand
> > > information should be used. In case of a dispute, only first-hand
> > > information is useful (certificates and revocation status
> information from
> > > the CAs responsible for every certificate from the chain). DPV
> responses
> > > (i.e. the signed "yes" answers) are useless, unless the plaintiff
> and the
> > > defendant both trust the same DPV server.
> 
> > OCSP responses may also be useless, unless the plaintiff and the
> > defendant both trust the same OCSP server.
> 
> Wrong. RFC 2560 sates:
> 
>    It is necessary however to ensure that the entity signing this
>    information is authorized to do so.  Therefore, a certificate's
>    issuer MUST either sign the OCSP responses itself or it MUST
>    explicitly designate this authority to another entity.
> 
> In either of these cases, the plaintiff and the defendant cannot argue
> that
> the OCSP response is not valid (unless the OCSP responder has been
> revoked
> by the CA). They cannot argue that such responses are useless, or if
> they
> do,
> this argumentation will be rejected.
> 
> I have made my best efforts to explain all the rational behind DPV
> responses,
> which are very different from OCSP responses. I have also made my best
> efforts to explain why in the general case a DPV response from a given
> server is not necessarilly trusted by all clients, and thus would be
> useless
> in front of a court.
> 
> The security consideration section is very explicit on this issue:
> 
> "A DPV client must trust a DPV server to provide the correct answer.
> However, this does not mean that all DPV clients will trust the same
> DPV servers. While a positive answer might be sufficient for one DPV
> client, that same positive answer will not necessarily convince
> another DPV client."
> 
> Can we finally close this issue ?
> 
> Denis
> 
> > Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GDRGG23745 for ietf-pkix-bks; Tue, 16 Apr 2002 06:27:16 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GDREm23734 for <[e-mail]>; Tue, 16 Apr 2002 06:27:14 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA10040; Tue, 16 Apr 2002 15:29:52 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041615264068:495 ; Tue, 16 Apr 2002 15:26:40 +0200 
Message-ID: <[e-mail]>
Date: Tue, 16 Apr 2002 15:26:40 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Open issue: DPV additional information
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 15:26:40, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 15:27:12, Serialize complete at 16/04/2002 15:27:12
Content-Transfer-Encoding: 7bit
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>

Peter,

I changed the name of this thread, since this is not related to DPV relay,
but to DPV additional information.

Foreword: If you want to save time you can go directly to the end of this
(too long) e-mail.

> > I agree that there is a difference between an authorized responder
> > and a server trusted under a given policy.
> >
> > So in order to solve this last issue, I propose to replace the current text
> > which is:
> 
> The reason why I discussed this was to explain that regarding trust
> issues there is no fundamental difference between a DPV responder
> and an OCSP responder.

There is. See below.
 
> As we see, OCSP responders come in two flavors, either they
> are authorised by the CA (respses signed by the CA or
> an athorised responder), or are locally trusted.

No. DPV servers are never authorized by CAs. They are either :

 - locally trusted by their requesting clients for any policy, or/and
 - trusted under a given validation policy.

> I do not see why DPV responders are essentially different: It
> may be that there are *more* DPV responders that are locally trusted
> but I do not see why a CA cannot sign DPV responses for all its
> client certs or designate a responders in exactly the same way
> as for OCSP.

A CA cannot sign DPV responses.
 
> Denis mentioned that a DPV responder indicates the validity of
> a path: I slightly disagree: If one does not return the path
> and no other information, the DPV responder only indicates the
> validity of the cert according to a policy, like OCSP indicates

> the "invalidity status".

Not exactly, but the "revocation status from a single certificate".
 
> Even, assumung that DPV indicates the validity of a path, I
> do not see why it creates harm to include such responses in
> DPV responses.

The DPV response may include *in addition* to the validity status, 
all the information that yield to prove that this validity. 

> For example, a DPV responder that would return OCSP status info for
> all certs in the chain (except the top one?) could just return
> one DPV response of the first CA chain.

A DPV server is a function that shall *not* be confused with the function 
from another server, like an OCSP server.
 
> Denis replied to Peter;
> > > So, the DPV response made by the CA just talks about the certificates
> > > it has directly issued.
> 
> > No. Talking about the certificates that a DPV server may have issued does
> > not make sense.
> It = the CA.
> 
> > Certificates are only issued by CAs, AFAIK. Once again,
> > a DPV server MUST answer for one (or more) certificates and must verify
> > an entire chain of certificates, whoever has issued them.

> No, I claim taht the only thing a DPV server MUST tell is whether the cert is
> valid against a validation policy, everything else is optional.

The argument from your last sentence is correct and does not contradict my
sentences. So it does not explain the "No" placed in front.

> > A DPV server is
> > *not* a CA. A DPV server can be *any* service provider. An organization
> > running a CA may also run a DPV server, in the same way as an organization
> > running a CA may also provide a Time-Stamping service.

> The agument was, whether this is different to OCSP. It is *NOT* as we
> all just found out. 

As mentioned earlier, OCSP responders come in two flavors: 

 - either they are authorised by the CA, 
 - or are locally trusted.

DPV servers are either :

 - locally trusted by their requesting clients for any policy, or/and
 - trusted under a given validation policy.

> An OCSP respoinder can be *any* service provider.
 
> Denis said:
> > > If both CAs provide a DPV service instead of an OCSP service
> > You mean "If the organisation hosting a CA also provides a DPV service ... "

> I won't tell you whether you attempt to make a telepathic intrusion
> test was successful or not. :-)
> 
> Denis said:
> > I believe that you have mis-understood one idea behind DPV. DPV verifies the
> > whole path processing. A DPV status about one intermediate certificate of
> > the chain does not make sense. The validation policy is not about that
> > intermediate certificate but about a given certificate and a whole chain
> > above it. Applying the validation policy on an intermediate certificate only
> > does not make sense.

> Thank you for reminding me:
> 
> The rationale paragraph 2 says:
> 
>      DPV allows a server to perform a real time certificate validation for
>      a validation time T, where T may be the current time or a time in the
>      recent past.
> no word about PATH. The next paragraph says
> 
>      In order to validate a certificate, a chain of multiple certificates,
>      called a certification path, may be needed, comprising a certificate
>      of the public key owner (the end entity) signed by one CA, and zero or
>      more additional certificates of CAs signed by other CAs.
> "may be needed"
> 
> The next paragraphs talk about path validation, BUT: The server is allowed
> to return a good/bad answer without giving any information about the path
> used, and trusted roots as input are optional.
> 
> But anyway: Where did I say that the same validation policy MUST be used
> to validate an intermediate certificates. The question is only that
> the actual texts prohibits any other information to be returned.

Wrong. There is text to support other information, in particular a DPV
response. A proposal to improve that text was included in that same e-mail. 

> > > But you can have different protocols for these characteristics. Offline
> > > you could use trees, online you can have DPV,
> > No. On-line, to know the revocation status of a single certificate we only
> > have OCSP. RFC 2560 states:
> 
> RFC 3029 for example also provides a service to provide certificate status.
> 
> But your argumentation is completely unacceptable for another reason.
> You are completely ignoring that one can make progress in the future.
> It is like the people about 100 years ago that argued that the only way
> to solve a dangerous problem of horse shit on streets was to create more
> services to remove it (completely igoring the arivale of cars .. which created
> other problems, but that's another story).

> You require that nothing else than OCSP responses and CRL MUST be returned.
> never, ever.

Next time, please read the whole e-mail before responding or posting. 
Your assertion is incorrect. See the end of the e-mail you responded to.

 
> IN the following you mention thet time stamps *MAY* be useful for
> *other reasons*. Thus, it may be useful to create a time stamp
> of the OCSP responses and CRL responses in order to indicate when
> the information have been verified. This is just one example of
> why other and different information could be returned by a DPV responder.
> This information may not dbe directly destined to the DPV client but
> to some other relying party.

Correct.
 
> > > OCSP responses may also be useless, unless the plaintiff and the
> > > defendant both trust the same OCSP server.
> 
> > Wrong. RFC 2560 sates:

> I think it is not necessary to repeat why the argumentation that follows
> is wrong, in particular the following sentence is true as well for OCSP:
> 
>   "A DPV client must trust a DPV server to provide the correct answer.
>    However, this does not mean that all DPV clients will trust the same
>    DPV servers. While a positive answer might be sufficient for one DPV
>    client, that same positive answer will not necessarily convince
>    another DPV client."
> 
> > The DPV request MUST allow the client to request that the response
> > include the certification path and revocation status information used
> > by the DPV server to process the request. When requested, the DPV
> > server MUST include the certification path and revocation status
> > information in the response when the certificate is valid according to
> > the validation policy. However, the server MAY omit the certification
> > path and revocation status information when the certificate is invalid.
> >
> > by the following text:
> >
> > The DPV request MUST allow the client to request the response to
> > include either the certification path and the revocation status
> > information from authorised CRL issuers or authorised OCSP responders,
> > or a DPV response from a DPV server that is trusted under the
> > validation policy. This information may allow other clients, not
> > trusting the requested DPV server to be confident that the certificate
> > validation has correctly be performed. When the certificate is valid
> > according to the validation policy, the server MUST, upon request,
> > include that information in the response. However, the server MAY
> > omit that information when the certificate is invalid or when it
> > cannot determine the validity.
> 
> You are turning around a  necessary and sufficient  property:

> Requiring *authorised* issuers may not be necessary in some
> circumstances, e.g., when the relying parties are a known
> group that trust the same responders.

How can it be known the relying parties are a known group that trust the
same responder ?

Since a DPV responder can support multiple validation policies, this notion
depends from the validation policy and the validation policy may thus
include the set of trusted DPV responders under that policy. This set may be
different from one policy to another.

This means that the valid response may include in addition to the response
from the *locally* trusted DPV server the response from a *policy* trusted
DPV server. This is exactly what the text above was attempting to say.

> To summarize: I just repeat my request that :
> 
> ' A DPV responder may return additional information concerning the
>   status of the certificate in question, such a the selected
>   certification paths, OCSP responses, CRL responses and other
>   information about the validity of the certificate, or parts
>   of the parts. etc., examples are DPV responses, time stamps, ..
>   which are necessary in order to allow relying parties
>   (not necessarily the initial DPV client) to determine the
>   status of the certificate. '

We are not that far. A DPV response was already present in the text.
Time-stamp tokens can be added:

I would propose the following :

The DPV request MUST allow the client to request the server to include 
in its response additional information which will allow relying parties 
not trusting the requested DPV server to be confident that the 
certificate validation has correctly been performed. Such information 
may consist of a certification path, revocation status 
information from authorised CRL issuers or authorised OCSP responders, 
time-stamp tokens, or a DPV response from a DPV server that is trusted 
under the validation policy.  When the certificate is valid according 
to the validation policy, the server MUST, upon request, include that 
information in the response. However, the server MAY omit that 
information when the certificate is invalid or when it cannot determine 
the validity.

Denis

>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GD5Fk22047 for ietf-pkix-bks; Tue, 16 Apr 2002 06:05:15 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GD5Dm22040 for <[e-mail]>; Tue, 16 Apr 2002 06:05:13 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA02465; Tue, 16 Apr 2002 15:05:11 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 16 Apr 2002 15:05:11 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA29243; Tue, 16 Apr 2002 15:05:10 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA08851; Tue, 16 Apr 2002 15:05:10 +0200 (MET DST)
Date: Tue, 16 Apr 2002 15:05:10 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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 read again the message. The proposal is to add one sentence 
> (i.e. two lines), no more:
>     
>     When a server supports a relay mechanism, a mechanism to detect
>     loops or repetition MUST be provided.

I fully agree with this. I just wanted to be sure that your
describing text just outlines some possible (mechanisms/ideas of) solutions.






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GCp8e21665 for ietf-pkix-bks; Tue, 16 Apr 2002 05:51:08 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GCp7m21661 for <[e-mail]>; Tue, 16 Apr 2002 05:51:07 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA17812; Tue, 16 Apr 2002 14:53:46 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041614503506:487 ; Tue, 16 Apr 2002 14:50:35 +0200 
Message-ID: <[e-mail]>
Date: Tue, 16 Apr 2002 14:50:34 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 14:50:35, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 14:51:06, Serialize complete at 16/04/2002 14:51:06
Content-Transfer-Encoding: 7bit
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>

Peter,
 
> Similar to Stephen, I also almost agree with Denis,
 
> just a few nit-pcking remarks.

Please read again the message. The proposal is to add one sentence 
(i.e. two lines), no more:
    
    When a server supports a relay mechanism, a mechanism to detect
    loops or repetition MUST be provided.


Denis

> > > DPV servers that do relay requests MUST be able to detect whether or not
> > > the request has been previously relayed,
> >
> > Correct.
> >
> > > and the request MUST have the complete list of servers that have received the request.
> >
> > No. You are specifying a solution, which would work but there are other
> > solutions to this problem: a list of servers is not the single way to solve
> > this issue. Since we are writing requirements we should not impose a
> > solution.
> >
> > I believe that this requirement can be captured by the following sentence:
> >
> >    When a server supports a relay mechanism, a mechanism to detect
> >    loops or repetition MUST be provided.
> >
> > Now, to explain in more details:
> >
> > When a DPV server relays a request to another DPV server:
> >
> >     1) it must copy already present relay history information (if any),
> >
> >     2) it must add relay history information in the relayed request.
> >
> > As an example, the added information can simply be a nonce and thus no
> > server name needs to be ever used. A sequence of nonces would thus do the
> > job nicely and avoid naming problems or naming conventions. Practically
> > speaking, a sequence of INTEGER would do the job.
> 
> You are also trying to describe a solution which in fact does not
> necessarily work unless the nonces are selected in a correct way,
> they must allow a server that either it had already received the
> request or will send it again.
> 
> So let us stick with the first sentence:
> >
> > > DPV servers that do relay requests MUST be able to detect whether or not
> > > the request has been previously relayed,
> 
> >
> > > DPV servers that relay requests MUST satisfy all the following conditions:
> > >            (1) recognize and process relay history if present in a DPV request;
> > >            (2) able to generate a relay history
> 
> >
> >  .. information. Full stop.
> >
> > > including the complete list of servers that have already forwarded this request;
> >
> > No. As said earlier, the received relay information is blindly copied.
> >
> > >            (3) before relaying a request, the DPV server MUST verify that
> > > the chosen DPV server
> > >            has not already seen the message.  (That is loop detection
> > > occurs at the requester,
> > >            not the recipient).
> 
> Instead of (3) a server may also reject a request because it detects that
> it has already received it before.
> 
> >
> > No. The idea is to send back the referral in a non-critical extension so
> > that it can be ignored by a client. Clients must be ready to support
> > extension fields, but are not mandated to understand any non-critical
> > extension.
> 
> You are specifying a begin of a solution.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GC2EP19204 for ietf-pkix-bks; Tue, 16 Apr 2002 05:02:14 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GC2Bm19198 for <[e-mail]>; Tue, 16 Apr 2002 05:02:11 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA02071; Tue, 16 Apr 2002 14:02:04 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 16 Apr 2002 14:02:04 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA28989; Tue, 16 Apr 2002 14:02:03 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA08833; Tue, 16 Apr 2002 14:02:03 +0200 (MET DST)
Date: Tue, 16 Apr 2002 14:02:03 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Open issue: DPV relay
Cc: [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>

Tom,


One question is: 'to prove vis-a-vis which entity':

A work flow component may just need a confirmation
of the companies internal work flow. If the
company needs to prove this vis-a-vis other
potential external entities, it sets up
a policy ccording to that to do: 

This may for example include a DPV service operated
by 'the other company' in order to prove that
'we have asked you (the other compnay), and your
compnay server asserted that the certificate
of person XYZ is useful to policy P, and we
have validated the status of your servers 
certificate at our commonly agreed CA validation
service.  

It is up to the 'local DPV service' to ensure to
which extend the answer can be considered more
or less globally binding. 

Peter S.

> 
>       Peter:
> 
>       If nobody disagrees with your statement about an RP providing its own
> DPV service, I think that you have provided the conclusive argument against
> using DPV responses in NR.  After all, in many NR scenarios the RP is
> trying to prove that his reliance on a signature was justified.  If the RP
> provides its own DPV service, the only answer to the question "why did you
> consider the signing certificate valid?" which it provides is "because I
> thought so at the time".  If you assume that single RP's rarely provide DPV
> in practice but that organizations which employ many RP's may do so, the
> answer is "because my employer thought so at the time".
>       This does not mean that DPV is not valuable, but it would mean that
> it (as opposed to DPD) is not useful for NR.
> 
>             Tom Gindin
> 
> 
> Peter Williams <[e-mail]>@mail.imc.org on 04/11/2002 01:00:53 PM
> 
> Sent by:    [e-mail]
> 
> 
> To:    "'Peter Sylvester '" <[e-mail]>
> cc:    "'[e-mail] '" <[e-mail]>
> Subject:    RE: Open issue: DPV relay
> 
> 
> 
> 
> Peter.
> 
> OCSP has always envisioned and practised a relying party
> authorizing an OCSP Responder: no CA/AA involvement
> is required and no certificate need be issued, in this
> case.
> 
> Carry over this conformance requirement from OCSP to DPV:
> 
> An OCSP client (which includes a client that is a DPV server)
> must potentially accept an OCSP response according to ALL the
> rules of 4.2.2.2. There are three cases: (1) (2) and (3).
> 
> Lets remember, a relying party can operate its
> own DPV service for its own benefit. The relying party
> needs no authority from a CA to do so. The operator
> of a DPV server is not necessarily a TTP, and
> need have no relationship to the cert or CRL
> issuer, other than that of performing
> relying party obligations or (less stringent) user
> obligations according to the CP.
> 
> -----Original Message-----
> From: Denis Pinkas
> To: Peter Sylvester
> Cc: [e-mail]
> Sent: 4/11/02 3:18 AM
> Subject: Re: Open issue: DPV relay
> 
> 
> > See the second point and also read 4.2.2.2
> 
> Which says:
> 
>    It is necessary however to ensure that the entity signing this
>    information is authorized to do so.  Therefore, a certificate's
>    issuer MUST either sign the OCSP responses itself or it MUST
>    explicitly designate this authority to another entity.
> 
> > Or: You may want a requirement that the DPV responder must ensure
> > that the OCSP responses are signed by a CA or an authorised responder
> > and not by some locally trusted OCSP responder in order to
> > be sure that an 'evidence verifier' finds trustworthy information.
> 
> This is correct. However, it is not necesssary to add this requirement
> in
> the DPV requirements document since this requirement is already in
> section
> 4.2.2.2 from RFC 2560 (OCSP).
> 
> > > > To make the simple case, if a DPV response is signed directly by
> the CA
> > > > (or by an authorised responder), you have the same situation.
> > >
> > > No. A CA can only assert information about what it is directly
> responsible.
> 
> > So, the DPV response made by the CA just talks about the certificates
> > it has directly issued.
> 
> No. Talking about the certificates that a DPV server may have issued
> does
> not make sense. Certificates are only issued by CAs, AFAIK. Once again,
> a DPV server MUST answer for one (or more) certificates and must verify
> an entire chain of certificates, whoever has issued them. A DPV server
> is
> *not* a CA. A DPV server can be *any* service provider. An organization
> running a CA may also run a DPV server, in the same way as an
> organization
> running a CA may also provide a Time-Stamping service.
> 
> > > No CA is responsible for all the certifiactes from one path. An OCSP
> query
> > > is for ONE certificate, while a DPV query involves a CHAIN of
> certificates.
> >
> > The text says:
> >
> >    The Delegated Path Validation (DPV) protocol allows a server to
> >    validate one or more public key certificates according to a
> validation
> >    policy.
> >
> >    In order to validate a certificate, a chain of multiple
> certificates,
> >    called a certification path, may be needed, comprising a
> certificate
> >    of the public key owner (the end entity) signed by one CA, and zero
> or
> >    more additional certificates of CAs signed by other CAs.
> 
> > In the simple case of only one CA, an OCSP response signed by the CA
> > concerning the certificate in question does not say anything the
> > validity of the CA cert since when it was signed with the same key.
> 
> > You thus just have on certificate.
> 
> > In a case of one intermediate CA, the DPV response may for example
> > contain two OCSP responses, one signed by the intermediate CA
> > concerning the revocation status of the end user and another
> > concerning the statius of the intermediate CA signed by the
> > top CA.
> 
> > If both CAs provide a DPV service instead of an OCSP service
> 
> You mean "If the organisation hosting a CA also provides a DPV service
> ... "
> 
> > in the same way, you have exactly the same situation except
> > that this is a positive status information.
> >
> > For example, the initial client asks for a combined status,
> > it asks his own trusted service, this server asks the intermediate
> > CA either to provide an OCSP status or a DPV status of the
> > cert in question and then asks the top CA to provide a status of
> > the intermediate CA's cert, and well, even three other OCSP
> > responders to provide statement that the top level
> > CA's cert is good.
> 
> I believe that you have mis-understood one idea behind DPV. DPV verifies
> the
> whole path processing. A DPV status about one intermediate certificate
> of
> the chain does not make sense. The validation policy is not about that
> intermediate certificate but about a given certificate and a whole chain
> above it. Applying the validation policy on an intermediate certificate
> only
> does not make sense.
> 
> > DPV would allow to combine the responses differently.
> > It can well be that the intermediate CA/DPV responder
> > itself asks for a DPV response from the top CA/DPV
> > and include this in his DPV response to the initial server.
> >
> > >
> > > There are no similarities.
> > "Ok, let's talk."
> >
> > > > I think that there must be a language problem somewhere because I
> > > > fail to see what *not* you are referring, i.e. to see where we are
> > > > in disagreement.  I have not said that it is necessary for the
> client
> > > > to gather all information. I have said that the protocol must
> provide
> > > > a method to allow a client to ask and the server to respond with
> that
> > > > information.
> > >
> > > Maybe, since we possibly interpreted diffrently "what has
> contributed to the
> > > final decision".
> > >
> > > > > In case of a dispute, testing again the certificate validity,
> means that
> > > > > certificates, CRLs and OCSP responses must be available.
> Anything else is
> > > > > useless.
> > >
> > > > I think that this may be the core of our disagreement.
> > >
> > > > This is because you only accept that CA can create assertions
> about the
> > > > validity of their certificates using CRLs and OCSP.
> > >
> > > Correct.
> >
> > Unfortunately we may be both wrong.
> >
> > > > As soon as you would
> > > > admit that some new protocol or service is provided that enhances
> and in
> > > > particular replaces them, the statements obtained via that service
> are
> > > > necessary.
> > >
> > > > I would like to know what you would have said 5 years ago when
> only
> > > > CRLs existed.
> > >
> > > Basicaly the chain must be verified and no element fom the chain
> must be
> > > revoked.
> > >
> > > Five years ago this information was provided off-line, i.e. via
> CRLs. OCSP
> > > allows to obtain the same information on-line. Between on-line and
> off-line
> > > I currently see no other mechanism.
> 
> > But you can have different protocols for these characteristics.
> Offline
> > you could use trees, online you can have DPV,
> 
> No. On-line, to know the revocation status of a single certificate we
> only
> have OCSP. RFC 2560 states:
> 
>    It is necessary however to ensure that the entity signing this
>    information is authorized to do so.  Therefore, a certificate's
>    issuer MUST either sign the OCSP responses itself or it MUST
>    explicitly designate this authority to another entity.
> 
> Note that this is true as well for CRLs. Either the CA signs the CRL
> directly or designate another authority.
> 
> RFC 2459 RECOMMENDS for the support of the CRL distribution points
> extension
> which then contains a cRLIssuer field. "If the certificate issuer is not
> the
> CRL issuer, then the cRLIssuer field MUST be present and contain the
> Name of
> the CRL issuer. If the certificate issuer is also the CRL issuer, then
> the
> cRLIssuer field MUST be omitted ..."
> 
> > or other techniques like
> > timestamps over CRLs and OCSP responses to have a proof that the
> server
> > has provided the OCSPresp/CRL at a current date.
> 
> Time-stamping is not needed to prove that the server has provided the
> OCSPresp/CRL at a current date. An OCSP response includes such a date.
> CRL
> checking uses thisUpdate and nextUpdate. Time-stamping may however be
> useful
> for other reasons. An informational RFC (i.e. RFC 3126 - Electronic
> Signature Formats for long term electronic signatures) does however
> indicate
> such a format in the context of a signature policy. Another format could
> be
> derived from it in the context of a validation policy.
> 
> > > The basic question is whether first-hand information and second-hand
> > > information should be used. In case of a dispute, only first-hand
> > > information is useful (certificates and revocation status
> information from
> > > the CAs responsible for every certificate from the chain). DPV
> responses
> > > (i.e. the signed "yes" answers) are useless, unless the plaintiff
> and the
> > > defendant both trust the same DPV server.
> 
> > OCSP responses may also be useless, unless the plaintiff and the
> > defendant both trust the same OCSP server.
> 
> Wrong. RFC 2560 sates:
> 
>    It is necessary however to ensure that the entity signing this
>    information is authorized to do so.  Therefore, a certificate's
>    issuer MUST either sign the OCSP responses itself or it MUST
>    explicitly designate this authority to another entity.
> 
> In either of these cases, the plaintiff and the defendant cannot argue
> that
> the OCSP response is not valid (unless the OCSP responder has been
> revoked
> by the CA). They cannot argue that such responses are useless, or if
> they
> do,
> this argumentation will be rejected.
> 
> I have made my best efforts to explain all the rational behind DPV
> responses,
> which are very different from OCSP responses. I have also made my best
> efforts to explain why in the general case a DPV response from a given
> server is not necessarilly trusted by all clients, and thus would be
> useless
> in front of a court.
> 
> The security consideration section is very explicit on this issue:
> 
> "A DPV client must trust a DPV server to provide the correct answer.
> However, this does not mean that all DPV clients will trust the same
> DPV servers. While a positive answer might be sufficient for one DPV
> client, that same positive answer will not necessarily convince
> another DPV client."
> 
> Can we finally close this issue ?
> 
> Denis
> 
> > Peter
> 
> 
> 
> 
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GBiCW17851 for ietf-pkix-bks; Tue, 16 Apr 2002 04:44:12 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GBgom17688 for <[e-mail]>; Tue, 16 Apr 2002 04:42:51 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA01968; Tue, 16 Apr 2002 13:42:36 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 16 Apr 2002 13:42:36 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA28908; Tue, 16 Apr 2002 13:42:35 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA08828; Tue, 16 Apr 2002 13:42:34 +0200 (MET DST)
Date: Tue, 16 Apr 2002 13:42:34 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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,
> 
> (modulo typos) I'm fine with this text.
> 
> Stephen.
> 
I second (or third, or forth or minute or hour) that.

I am glad that most my my requests (and some
others, too) concerning relaying seem to get some concensus.

There is still one left, currently stuck in a private
communication among Russ, Denis and me. 

Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GBbsD16955 for ietf-pkix-bks; Tue, 16 Apr 2002 04:37:54 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GBbqm16950 for <[e-mail]>; Tue, 16 Apr 2002 04:37:53 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3GBbhms004206; Tue, 16 Apr 2002 07:37:43 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.1) with ESMTP id g3GBbfR82112; Tue, 16 Apr 2002 07:37:41 -0400
Importance: Normal
Sensitivity: 
Subject: RE: Open issue: DPV relay
To: Peter Williams <[e-mail]>
Cc: "'Peter Sylvester '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 16 Apr 2002 07:35:16 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/16/2002 07:37:42 AM
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>

      Peter:

      If nobody disagrees with your statement about an RP providing its own
DPV service, I think that you have provided the conclusive argument against
using DPV responses in NR.  After all, in many NR scenarios the RP is
trying to prove that his reliance on a signature was justified.  If the RP
provides its own DPV service, the only answer to the question "why did you
consider the signing certificate valid?" which it provides is "because I
thought so at the time".  If you assume that single RP's rarely provide DPV
in practice but that organizations which employ many RP's may do so, the
answer is "because my employer thought so at the time".
      This does not mean that DPV is not valuable, but it would mean that
it (as opposed to DPD) is not useful for NR.

            Tom Gindin


Peter Williams <[e-mail]>@mail.imc.org on 04/11/2002 01:00:53 PM

Sent by:    [e-mail]


To:    "'Peter Sylvester '" <[e-mail]>
cc:    "'[e-mail] '" <[e-mail]>
Subject:    RE: Open issue: DPV relay




Peter.

OCSP has always envisioned and practised a relying party
authorizing an OCSP Responder: no CA/AA involvement
is required and no certificate need be issued, in this
case.

Carry over this conformance requirement from OCSP to DPV:

An OCSP client (which includes a client that is a DPV server)
must potentially accept an OCSP response according to ALL the
rules of 4.2.2.2. There are three cases: (1) (2) and (3).

Lets remember, a relying party can operate its
own DPV service for its own benefit. The relying party
needs no authority from a CA to do so. The operator
of a DPV server is not necessarily a TTP, and
need have no relationship to the cert or CRL
issuer, other than that of performing
relying party obligations or (less stringent) user
obligations according to the CP.

-----Original Message-----
From: Denis Pinkas
To: Peter Sylvester
Cc: [e-mail]
Sent: 4/11/02 3:18 AM
Subject: Re: Open issue: DPV relay


> See the second point and also read 4.2.2.2

Which says:

   It is necessary however to ensure that the entity signing this
   information is authorized to do so.  Therefore, a certificate's
   issuer MUST either sign the OCSP responses itself or it MUST
   explicitly designate this authority to another entity.

> Or: You may want a requirement that the DPV responder must ensure
> that the OCSP responses are signed by a CA or an authorised responder
> and not by some locally trusted OCSP responder in order to
> be sure that an 'evidence verifier' finds trustworthy information.

This is correct. However, it is not necesssary to add this requirement
in
the DPV requirements document since this requirement is already in
section
4.2.2.2 from RFC 2560 (OCSP).

> > > To make the simple case, if a DPV response is signed directly by
the CA
> > > (or by an authorised responder), you have the same situation.
> >
> > No. A CA can only assert information about what it is directly
responsible.

> So, the DPV response made by the CA just talks about the certificates
> it has directly issued.

No. Talking about the certificates that a DPV server may have issued
does
not make sense. Certificates are only issued by CAs, AFAIK. Once again,
a DPV server MUST answer for one (or more) certificates and must verify
an entire chain of certificates, whoever has issued them. A DPV server
is
*not* a CA. A DPV server can be *any* service provider. An organization
running a CA may also run a DPV server, in the same way as an
organization
running a CA may also provide a Time-Stamping service.

> > No CA is responsible for all the certifiactes from one path. An OCSP
query
> > is for ONE certificate, while a DPV query involves a CHAIN of
certificates.
>
> The text says:
>
>    The Delegated Path Validation (DPV) protocol allows a server to
>    validate one or more public key certificates according to a
validation
>    policy.
>
>    In order to validate a certificate, a chain of multiple
certificates,
>    called a certification path, may be needed, comprising a
certificate
>    of the public key owner (the end entity) signed by one CA, and zero
or
>    more additional certificates of CAs signed by other CAs.

> In the simple case of only one CA, an OCSP response signed by the CA
> concerning the certificate in question does not say anything the
> validity of the CA cert since when it was signed with the same key.

> You thus just have on certificate.

> In a case of one intermediate CA, the DPV response may for example
> contain two OCSP responses, one signed by the intermediate CA
> concerning the revocation status of the end user and another
> concerning the statius of the intermediate CA signed by the
> top CA.

> If both CAs provide a DPV service instead of an OCSP service

You mean "If the organisation hosting a CA also provides a DPV service
... "

> in the same way, you have exactly the same situation except
> that this is a positive status information.
>
> For example, the initial client asks for a combined status,
> it asks his own trusted service, this server asks the intermediate
> CA either to provide an OCSP status or a DPV status of the
> cert in question and then asks the top CA to provide a status of
> the intermediate CA's cert, and well, even three other OCSP
> responders to provide statement that the top level
> CA's cert is good.

I believe that you have mis-understood one idea behind DPV. DPV verifies
the
whole path processing. A DPV status about one intermediate certificate
of
the chain does not make sense. The validation policy is not about that
intermediate certificate but about a given certificate and a whole chain
above it. Applying the validation policy on an intermediate certificate
only
does not make sense.

> DPV would allow to combine the responses differently.
> It can well be that the intermediate CA/DPV responder
> itself asks for a DPV response from the top CA/DPV
> and include this in his DPV response to the initial server.
>
> >
> > There are no similarities.
> "Ok, let's talk."
>
> > > I think that there must be a language problem somewhere because I
> > > fail to see what *not* you are referring, i.e. to see where we are
> > > in disagreement.  I have not said that it is necessary for the
client
> > > to gather all information. I have said that the protocol must
provide
> > > a method to allow a client to ask and the server to respond with
that
> > > information.
> >
> > Maybe, since we possibly interpreted diffrently "what has
contributed to the
> > final decision".
> >
> > > > In case of a dispute, testing again the certificate validity,
means that
> > > > certificates, CRLs and OCSP responses must be available.
Anything else is
> > > > useless.
> >
> > > I think that this may be the core of our disagreement.
> >
> > > This is because you only accept that CA can create assertions
about the
> > > validity of their certificates using CRLs and OCSP.
> >
> > Correct.
>
> Unfortunately we may be both wrong.
>
> > > As soon as you would
> > > admit that some new protocol or service is provided that enhances
and in
> > > particular replaces them, the statements obtained via that service
are
> > > necessary.
> >
> > > I would like to know what you would have said 5 years ago when
only
> > > CRLs existed.
> >
> > Basicaly the chain must be verified and no element fom the chain
must be
> > revoked.
> >
> > Five years ago this information was provided off-line, i.e. via
CRLs. OCSP
> > allows to obtain the same information on-line. Between on-line and
off-line
> > I currently see no other mechanism.

> But you can have different protocols for these characteristics.
Offline
> you could use trees, online you can have DPV,

No. On-line, to know the revocation status of a single certificate we
only
have OCSP. RFC 2560 states:

   It is necessary however to ensure that the entity signing this
   information is authorized to do so.  Therefore, a certificate's
   issuer MUST either sign the OCSP responses itself or it MUST
   explicitly designate this authority to another entity.

Note that this is true as well for CRLs. Either the CA signs the CRL
directly or designate another authority.

RFC 2459 RECOMMENDS for the support of the CRL distribution points
extension
which then contains a cRLIssuer field. "If the certificate issuer is not
the
CRL issuer, then the cRLIssuer field MUST be present and contain the
Name of
the CRL issuer. If the certificate issuer is also the CRL issuer, then
the
cRLIssuer field MUST be omitted ..."

> or other techniques like
> timestamps over CRLs and OCSP responses to have a proof that the
server
> has provided the OCSPresp/CRL at a current date.

Time-stamping is not needed to prove that the server has provided the
OCSPresp/CRL at a current date. An OCSP response includes such a date.
CRL
checking uses thisUpdate and nextUpdate. Time-stamping may however be
useful
for other reasons. An informational RFC (i.e. RFC 3126 - Electronic
Signature Formats for long term electronic signatures) does however
indicate
such a format in the context of a signature policy. Another format could
be
derived from it in the context of a validation policy.

> > The basic question is whether first-hand information and second-hand
> > information should be used. In case of a dispute, only first-hand
> > information is useful (certificates and revocation status
information from
> > the CAs responsible for every certificate from the chain). DPV
responses
> > (i.e. the signed "yes" answers) are useless, unless the plaintiff
and the
> > defendant both trust the same DPV server.

> OCSP responses may also be useless, unless the plaintiff and the
> defendant both trust the same OCSP server.

Wrong. RFC 2560 sates:

   It is necessary however to ensure that the entity signing this
   information is authorized to do so.  Therefore, a certificate's
   issuer MUST either sign the OCSP responses itself or it MUST
   explicitly designate this authority to another entity.

In either of these cases, the plaintiff and the defendant cannot argue
that
the OCSP response is not valid (unless the OCSP responder has been
revoked
by the CA). They cannot argue that such responses are useless, or if
they
do,
this argumentation will be rejected.

I have made my best efforts to explain all the rational behind DPV
responses,
which are very different from OCSP responses. I have also made my best
efforts to explain why in the general case a DPV response from a given
server is not necessarilly trusted by all clients, and thus would be
useless
in front of a court.

The security consideration section is very explicit on this issue:

"A DPV client must trust a DPV server to provide the correct answer.
However, this does not mean that all DPV clients will trust the same
DPV servers. While a positive answer might be sufficient for one DPV
client, that same positive answer will not necessarily convince
another DPV client."

Can we finally close this issue ?

Denis

> Peter






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GBWas16474 for ietf-pkix-bks; Tue, 16 Apr 2002 04:32:36 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GBWYm16468 for <[e-mail]>; Tue, 16 Apr 2002 04:32:34 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA01918; Tue, 16 Apr 2002 13:32:31 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 16 Apr 2002 13:32:31 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA28856; Tue, 16 Apr 2002 13:32:30 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA08820; Tue, 16 Apr 2002 13:32:29 +0200 (MET DST)
Date: Tue, 16 Apr 2002 13:32:29 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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>

Similar to Stephen, I also almost agree with Denis, 

just a few nit-pcking remarks.

> 
> > DPV servers that do relay requests MUST be able to detect whether or not
> > the request has been previously relayed, 
> 
> Correct.
> 
> > and the request MUST have the complete list of servers that have received the request.
> 
> No. You are specifying a solution, which would work but there are other
> solutions to this problem: a list of servers is not the single way to solve
> this issue. Since we are writing requirements we should not impose a
> solution.
> 
> I believe that this requirement can be captured by the following sentence:
>    
>    When a server supports a relay mechanism, a mechanism to detect
>    loops or repetition MUST be provided.
> 
> Now, to explain in more details:
> 
> When a DPV server relays a request to another DPV server:
> 
>     1) it must copy already present relay history information (if any),
>     
>     2) it must add relay history information in the relayed request. 
> 
> As an example, the added information can simply be a nonce and thus no
> server name needs to be ever used. A sequence of nonces would thus do the
> job nicely and avoid naming problems or naming conventions. Practically 
> speaking, a sequence of INTEGER would do the job. 

You are also trying to describe a solution which in fact does not 
necessarily work unless the nonces are selected in a correct way,
they must allow a server that either it had already received the
request or will send it again. 

So let us stick with the first sentence: 
> 
> > DPV servers that do relay requests MUST be able to detect whether or not
> > the request has been previously relayed, 

>  
> > DPV servers that relay requests MUST satisfy all the following conditions:
> >            (1) recognize and process relay history if present in a DPV request;
> >            (2) able to generate a relay history 



> 
>  .. information. Full stop.
> 
> > including the complete list of servers that have already forwarded this request; 
> 
> No. As said earlier, the received relay information is blindly copied.
> 
> >            (3) before relaying a request, the DPV server MUST verify that
> > the chosen DPV server
> >            has not already seen the message.  (That is loop detection
> > occurs at the requester,
> >            not the recipient).

Instead of (3) a server may also reject a request because it detects that
it has already received it before. 


> 
> No. The idea is to send back the referral in a non-critical extension so
> that it can be ignored by a client. Clients must be ready to support
> extension fields, but are not mandated to understand any non-critical
> extension.

You are specifying a begin of a solution. 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GBFFK13699 for ietf-pkix-bks; Tue, 16 Apr 2002 04:15:15 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GBFDm13682 for <[e-mail]>; Tue, 16 Apr 2002 04:15:13 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA01874; Tue, 16 Apr 2002 13:15:10 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 16 Apr 2002 13:15:11 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA28824; Tue, 16 Apr 2002 13:15:09 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA08815; Tue, 16 Apr 2002 13:15:09 +0200 (MET DST)
Date: Tue, 16 Apr 2002 13:15:09 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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 agree that there is a difference between an authorized responder 
> and a server trusted under a given policy. 
> 
> So in order to solve this last issue, I propose to replace the current text
> which is:

The reason why I discussed this was to explain that regarding trust
issues there is no fundamental difference between a DPV responder
and an OCSP responder. 

As we see, OCSP responders come in two flavors, either they
are authorised by the CA (respses signed by the CA or 
an athorised responder), or are locally trusted. 

I do not see why DPV responders are essentially different: It
may be that there are *more* DPV responders that are locally trusted
but I do not see why a CA cannot sign DPV responses for all its
client certs or designate a responders in exactly the same way
as for OCSP.

Denis mentioned that a DPV responder indicates the validity of
a path: I slightly disagree: If one does not return the path
and no other information, the DPV responder only indicates the
validity of the cert according to a policy, like OCSP indicates
the "invalidity status".  
 
Even, assumung that DPV indicates the validity of a path, I
do not see why it creates harm to include such responses in
DPV responses. 

For example, a DPV responder that would return OCSP status info for
all certs in the chain (except the top one?) could just return
one DPV response of the first CA chain. 

Denis replied to Peter;
> > So, the DPV response made by the CA just talks about the certificates
> > it has directly issued.

> No. Talking about the certificates that a DPV server may have issued does
> not make sense.
It = the CA. 

> Certificates are only issued by CAs, AFAIK. Once again, 
> a DPV server MUST answer for one (or more) certificates and must verify 
> an entire chain of certificates, whoever has issued them. 
No, I claim taht the only thing a DPV server MUST tell is whether the cert is
valid against a validation policy, everything else is optional. 


> A DPV server is 
> *not* a CA. A DPV server can be *any* service provider. An organization
> running a CA may also run a DPV server, in the same way as an organization
> running a CA may also provide a Time-Stamping service.
The agument was, whether this is different to OCSP. It is *NOT* as we 
all just found out. An OCSP respoinder can be *any* service provider. 



Denis said:
> > If both CAs provide a DPV service instead of an OCSP service
> You mean "If the organisation hosting a CA also provides a DPV service ... "
I won't tell you whether you attempt to make a telepathic intrusion
test was successful or not. :-)


Denis said: 
> I believe that you have mis-understood one idea behind DPV. DPV verifies the
> whole path processing. A DPV status about one intermediate certificate of
> the chain does not make sense. The validation policy is not about that
> intermediate certificate but about a given certificate and a whole chain
> above it. Applying the validation policy on an intermediate certificate only
> does not make sense.
Thank you for reminding me: 

The rationale paragraph 2 says:

     DPV allows a server to perform a real time certificate validation for 
     a validation time T, where T may be the current time or a time in the 
     recent past.
no word about PATH. The next paragraph says

     In order to validate a certificate, a chain of multiple certificates, 
     called a certification path, may be needed, comprising a certificate 
     of the public key owner (the end entity) signed by one CA, and zero or 
     more additional certificates of CAs signed by other CAs.
"may be needed"

The next paragraphs talk about path validation, BUT: The server is allowed
to return a good/bad answer without giving any information about the path
used, and trusted roots as input are optional. 

But anyway: Where did I say that the same validation policy MUST be used
to validate an intermediate certificates. The question is only that
the actual texts prohibits any other information to be returned. 
 
> > But you can have different protocols for these characteristics. Offline
> > you could use trees, online you can have DPV, 
> No. On-line, to know the revocation status of a single certificate we only
> have OCSP. RFC 2560 states:

RFC 3029 for example also provides a service to provide certificate status. 
 
But your argumentation is completely unacceptable for another reason. 
You are completely ignoring that one can make progress in the future. 
It is like the people about 100 years ago that argued that the only way 
to solve a dangerous problem of horse shit on streets was to create more 
services to remove it (completely igoring the arivale of cars .. which created 
other problems, but that's another story). 

You require that nothing else than OCSP responses and CRL MUST be returned.
never, ever. 

IN the following you mention thet time stamps *MAY* be useful for
*other reasons*. Thus, it may be useful to create a time stamp
of the OCSP responses and CRL responses in order to indicate when
the information have been verified. This is just one example of
why other and different information could be returned by a DPV responder.
This information may not dbe directly destined to the DPV client but
to some other relying party. 

> > OCSP responses may also be useless, unless the plaintiff and the
> > defendant both trust the same OCSP server.

> Wrong. RFC 2560 sates:
I think it is not necessary to repeat why the argumentation that follows
is wrong, in particular the following sentence is true as well for OCSP: 

  "A DPV client must trust a DPV server to provide the correct answer. 
   However, this does not mean that all DPV clients will trust the same 
   DPV servers. While a positive answer might be sufficient for one DPV 
   client, that same positive answer will not necessarily convince 
   another DPV client."

> The DPV request MUST allow the client to request that the response 
> include the certification path and revocation status information used 
> by the DPV server to process the request. When requested, the DPV 
> server MUST include the certification path and revocation status 
> information in the response when the certificate is valid according to 
> the validation policy. However, the server MAY omit the certification 
> path and revocation status information when the certificate is invalid.
> 
> by the following text:
> 
> The DPV request MUST allow the client to request the response to 
> include either the certification path and the revocation status 
> information from authorised CRL issuers or authorised OCSP responders, 
> or a DPV response from a DPV server that is trusted under the 
> validation policy. This information may allow other clients, not 
> trusting the requested DPV server to be confident that the certificate 
> validation has correctly be performed. When the certificate is valid 
> according to the validation policy, the server MUST, upon request, 
> include that information in the response. However, the server MAY 
> omit that information when the certificate is invalid or when it 
> cannot determine the validity.

You are turning around a  necessary and sufficient  property: 
Requiring *authorised* issuers may not be necessary in some
circumstances, e.g., when the relying parties are a known
group that trust the same responders. 


To summarize: I just repeat my request that : 

' A DPV responder may return additional information concerning the
  status of the certificate in question, such a the selected
  certification paths, OCSP responses, CRL responses and other
  information about the validity of the certificate, or parts
  of the parts. etc., examples are DPV responses, time stamps, .. 
  which are necessary in order to allow relying parties
  (not necessarily the initial DPV client) to determine the
  status of the certificate. '

  







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GAOWj08047 for ietf-pkix-bks; Tue, 16 Apr 2002 03:24:32 -0700 (PDT)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GAOUm08039 for <[e-mail]>; Tue, 16 Apr 2002 03:24:30 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3GAOUb22876 for <[e-mail]>; Tue, 16 Apr 2002 11:24:30 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Tue, 16 Apr 2002 11:19:02 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA25889; Tue, 16 Apr 2002 11:24:27 +0100
Message-ID: <[e-mail]>
Date: Tue, 16 Apr 2002 11:24:38 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]>
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>

Tim,

I echo almost all of Denis' comments on your mail.

In any case, isn't the latest text from Russ ok with you? If
not what alternative text would you suggest?

Stephen.

Denis Pinkas wrote:
> 
> Tim,
> 
> I will be leaving my office tomorrow evening for one full week
> (both holidays then business), so we had better solve this rapidly
> so that I can post a new draft before leaving. :-)
> 
> See my comments embedded.
> 
> > Folks,
> >
> > Here is my take on the relay/referral fracas, in two parts.
> >
> > The first part addresses DPV relay includes (1) my assumptions about DPV,
> > (2) a little rationale, and (3) a proposed "solution" for DPV replay.  The
> > second part amounts to four complaints about the impact of adding
> > referrals, and my belief that it should not be supported.
> >
> >                                                          Part 1: DPV Relay
> > Proposal
> >
> > Assumption #1:
> >
> > DPV relay is irrelevant to DPV clients.  They request answers from a
> > trusted DPV server X, and server X MUST stand behind the response.  (That
> > is, X can't say "I don't know, but Server Y says this certificate is
> > okay."  It is up to X whether it can trust that answer.)
> 
> Fine.
> 
> > Assumption #2:
> >
> > Many DPV servers will not relay requests.
> >
> > Tim's Theory and what it is, too:
> >
> > DPV servers that do not relay requests do not care if the request has been
> > relayed before they received it.
> 
> True.
> 
> > That only matters for loop detection/relay limits, etc.
> 
> Wrong. If they do not relay, a loop can never occur. :-(
> 
> > DPV servers that do relay requests MUST be able to detect whether or not
> > the request has been previously relayed,
> 
> Correct.
> 
> > and the request MUST have the complete list of servers that have received the request.
> 
> No. You are specifying a solution, which would work but there are other
> solutions to this problem: a list of servers is not the single way to solve
> this issue. Since we are writing requirements we should not impose a
> solution.
> 
> I believe that this requirement can be captured by the following sentence:
> 
>    When a server supports a relay mechanism, a mechanism to detect
>    loops or repetition MUST be provided.
> 
> Now, to explain in more details:
> 
> When a DPV server relays a request to another DPV server:
> 
>     1) it must copy already present relay history information (if any),
> 
>     2) it must add relay history information in the relayed request.
> 
> As an example, the added information can simply be a nonce and thus no
> server name needs to be ever used. A sequence of nonces would thus do the
> job nicely and avoid naming problems or naming conventions. Practically
> speaking, a sequence of INTEGER would do the job.
> 
> > So, the conformance requirements:
> >
> > Support for DPV relay is OPTIONAL for DPV servers.  DPV servers that do not
> > relay requests do not need to process or recognize the relay history
> > information.
> 
> Correct.
> 
> > DPV servers that relay requests MUST satisfy all the following conditions:
> >            (1) recognize and process relay history if present in a DPV request;
> >            (2) able to generate a relay history
> 
>  .. information. Full stop.
> 
> > including the complete list of servers that have already forwarded this request;
> 
> No. As said earlier, the received relay information is blindly copied.
> 
> >            (3) before relaying a request, the DPV server MUST verify that
> > the chosen DPV server
> >            has not already seen the message.  (That is loop detection
> > occurs at the requester,
> >            not the recipient).
> 
> Correct.
> 
> > This proposal does not impact clients, it simplifies the most common DPV
> > servers, and it places *all* the burden on DPV servers that relay
> > requests.  (As it should be, in my opinion.)
> 
> Correct.
> 
> >                                                       Part 2: DPV Referrals
> >
> > Complaint A
> >
> > Referrals impact *all* DPV clients, significantly increasing their
> > complexity.  Currently, the requirements indicate whether or not the server
> > could build a satisfactory path.  It seems to me that referrals force all
> > DPV clients to interpret a new class of answers: "I don't know but ask
> > Server B".  (By itself, this isn't that compelling, I admit.  They get
> > stronger, IMHO.)
> 
> No. The idea is to send back the referral in a non-critical extension so
> that it can be ignored by a client. Clients must be ready to support
> extension fields, but are not mandated to understand any non-critical
> extension.
> 
> > Complaint B
> >
> > One of the nice features of DPV is a single "proof" for archival.  This
> > feature is broken by the introduction of DPV referrals.  Assume Alice is
> > trusts Server A, but she receives a referral indicating that Server A
> > trusts Server B to validate this certificate.
> 
> No. It is not the meaning of the referral. Assume Alice trusts Server A, but
> she receives a referral from server A indicating that Server B
> might be able to validate this certificate. Alice has to make its own
> decision whether she can trust or not server B.
> 
> > Alice will need to maintain both the referral from Server A and the
> > answer from Server B.
> 
> No. See above.
> 
> > Complaint C
> >
> > Referrals for DPV are a very different animal than LDAP referrals.  Once
> > again, assume Alice is trusts Server A but she receives a referral
> > indicating that Server A trusts Server B to validate this
> > certificate.  Alice will need to authenticate the identity of Server B
> > using information from Server A.  I think that means that Server A needs to
> > identify Server B by including Server B's public key in the referral.  If
> > that is true, we just created a parallel key management infrastructure and
> > increased the complexity of our universe.
> 
> Not with the trust model that I indicated.
> 
> > Complaint D
> >
> > If LDAP is any indicator, nobody does referrals anyway.  Since DPV
> > referrals will be significantly more complex, wouldn't it be better to put
> > the load on the server?
> 
> The load will be on the servers. Clients may fully ignore that field.
> 
> Denis
> 
> 
> > Alright, I'm off my soapbox.  Flame suit is zipped.  What do you all think
> > of these proposals?
> >
> > Thanks,
> >
> > Tim Polk

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GAJKn07564 for ietf-pkix-bks; Tue, 16 Apr 2002 03:19:20 -0700 (PDT)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GAHvm07448 for <[e-mail]>; Tue, 16 Apr 2002 03:17:58 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3GAHvb22701 for <[e-mail]>; Tue, 16 Apr 2002 11:17:57 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Tue, 16 Apr 2002 11:12:30 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA25742; Tue, 16 Apr 2002 11:17:54 +0100
Message-ID: <[e-mail]>
Date: Tue, 16 Apr 2002 11:18:05 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, pkix <[e-mail]>
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
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>

Hi Trevor,

Trevor Freeman wrote:
> 
> Stephen,
> There is obviously a relationship between implementation complexity and
> protocol design.

True. My point was simply that the relative complexity of the protocols
that get proposed as meeting these requirements can't be judged yet and,
I believe, isn't impacted by Russ' latest text anyway.

> We are proposing a simple model where the client only has to consider
> two responses from the DPV server, success or failure. 

No change there then. Read Russ' latest text and see if you agree
with it.

> Nothing in that
> model excludes a DPV server for accessing or requesting any resource it
> chooses. 

Good.

> A DPV server can therefore act as a DPC client to other DPV
> servers. What is not clear is why you seem to be so keen for the
> original PDV client to do this work of contacting other DPV servers
> instead of the client's original DPV server. 

I'm not. Once again, the scenario in which I like referrals is the one
I gave in a message back on the 8th:

Alice -> Bob - is this a good key?
    Robert -> Charlie - is this a good key? (relaying)
    Chaz -> Robert - I dunno, ask Denis (re-direct/referral)
    Robbie -> Denis - is this a good key?
    Denis -> Rob - I strongly disagree (with apologies:-)
Robert -> Alice - Nope

> If the DPV server truly
> believes that an answer can be obtained from anther resource - why can't
> it go get that answer for the client? What does the client know that the
> server does not which would make that work? 

See above.

> What piece of information is
> missing from the DPV server that by returning a DPV referral to the
> client, something will be accomplished that it could not do itself?

In the above example, Charlie is a kind of "gateway" server that tells
Bob which of the other servers that exist (with which they can establish
a good answer via the ultimately WG-selected DPV protocol:-). Bob often
won't know that, and sometimes Charlie won't be able to connect to
Denis due to firewalls.

Stephen.

> 
> Trevor
> 
> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Monday, April 15, 2002 6:54 AM
> To: Housley, Russ
> Cc: pkix
> Subject: Re: Open issue: DPV relay
> 
> Russ,
> 
> It seems that essentially you want to change "protocols MAY
> re-direct/m-c"
> into "protocols MUST NOT re-direct/m-c", right?
> 
> - I fail to see how the MAY option adds complexity to clients since
> presumably the protocol you like that meets the requirements won't
> take up the "MAY" option and it won't be an issue for such clients.
> Even if a conforming protocol does include re-direct, the text
> proposed ensures that there is mandatory impact on clients.
> 
> - Allowing re-direct/m-c does allow for some interesting server to
> server interactions (in an IMO clean way) as previously discussed on
> the list. I see no reason to prohibit those or cause vendors to
> re-invent or corrupt their use of a dpv protocol in order to
> support such cases.
> 
> - We can in any case judge relative compexity issues (only?) when
> concrete protocols are being compared against these requirements.
> 
> So, all in all, I see no reason to forbid protocols to support these
> mechcnisms and some reasons to allow protocols to do so and no reason
> at all to make a premature decision on this.
> 
> Regards,
> Stephen.
> 
> "Housley, Russ" wrote:
> >
> > I am strongly opposed to any requirements regarding re-direction
> (a.k.a.
> > referrals) or multicasting.  These services would add considerable
> > complexity to the client side of the interface, making support for
> > lightweight clients more difficult.
> >
> > I have specific comments below...
> >
> > >4.2. Relaying, re-direction and multicasting.
> > >
> > >Protocols designed to conform to these requirements MAY include
> > >optional fields and extensions to support relaying, re-direction or
> > >multicasting features. DPV clients are NOT REQUIRED to support relay,
> > >re-direct or multicast, therefore clients or servers which do not
> > >support such features still conform to the basic set of requirements.
> > >DPV servers are NOT REQUIRED either to support relay, re-direct or
> > >multicast.
> >
> > I can support relaying (a.k.a. chaining) because it does not add
> complexity
> > to the client.
> >
> > These are not protocol requirements.  They are implementation
> requirements,
> > and we are not defining a protocol in this document.
> >
> > I prefer:
> >
> > Protocols designed to satisfy these requirements MAY include
> mechanisms for
> > relaying.  However, such protocols MUST NOT include mechanisms for
> > re-direction or multicasting.  Re-direction or multicasting mechanisms
> > would add considerable complexity to the client side of the interface,
> > making support for lightweight clients more difficult.
> >
> > >1. Where relay or re-direct mechanisms are supported by a server
> > >    a mechanism to detect loops or repetition SHOULD be supported.
> >
> > I think that SHOULD ought to be changed to MUST.
> > I think that re-direct ought to be deleted.
> >
> > >2. Where a DPV server chooses to re-direct the request to another
> > >    DPV server (i.e. chooses to provide a referral), a mechanism to
> > >    provide information to be used for the re-direction SHOULD be
> > >    supported. Note: In case where information to be used for the
> > >    re-direction is sent back, clients are NOT REQUIRED to interpret
> > >    that information (but MAY do so).
> >
> > I think that this should be deleted.
> >
> > >3. These features MAY be supported by using additional parameters
> > >    in the request and/or response. Clients and servers that do not
> > >    support such additional parameters MUST still be able to
> use/offer
> > >    DPV service. In this way, implementers need not understand the
> > >    semantics of any such extensions.
> >
> > I think that additional ought to be changed to optional.
> >
> > Russ
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3GAAdI05516 for ietf-pkix-bks; Tue, 16 Apr 2002 03:10:39 -0700 (PDT)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3GA9Hm05196 for <[e-mail]>; Tue, 16 Apr 2002 03:09:17 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3GA9Hb22464 for <[e-mail]>; Tue, 16 Apr 2002 11:09:17 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Tue, 16 Apr 2002 11:03:49 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA25557; Tue, 16 Apr 2002 11:09:10 +0100
Message-ID: <[e-mail]>
Date: Tue, 16 Apr 2002 11:09:21 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
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>

Russ,

(modulo typos) I'm fine with this text.

Stephen.

"Housley, Russ" wrote:
> 
> All:
> 
> I remain strongly opposed to any requirements that impose re-direction
> (a.k.a. referrals) or multicasting on the client.  After a private e-mail
> exchange with Steve Farrell, I now realize that this is not the
> intention.  This intent was to permit the use of re-direction and
> multicasting between a collection of DPV servers.
> 
> I think that a bit of rationale will greatly help all readers.
> 
> I propose the following text.  Note that the rationale paragraph does not
> include any MUST, SHOULD, or MAY sentences.
> 
> Russ
> 
> = = = = = = = = = =
> 
> 4.2. Relaying, re-direction and multicasting.
> 
> In some network environments, especially ones that include firewalls, a DPV
> server might not be able to obtain all of the information that it needs to
> process a request.  However, the DPV server might be configured to use the
> services of one or more other DPV servers to fulfill all requests.  In such
> cases, the client is unaware that the queried DPV server is using the
> services of other DPV servers.  In such environments, the client-queried
> DPV server acts as a DPV client to another DPV server.  Unlike the original
> client, the DPV server is expected to have moderate computing and memory
> resources, enabling the use of relay, re-direct or multicasting mechanisms.
> The requirements in this section support such mechanisms for DPV
> server-to-DPV server exchanges without imposing them on DPV client-to-DPV
> client exchanges.
> 
> Protocols designed to satisfy these requirements MAY include optional
> fields and/or extensions to support relaying, re-direction or multicasting.
> However, DPV clients are not expected to support relay, re-direct or
> multicast.  If the protocol supports such features, the protocol MUST
> include provisions for DPV clients and DPV servers that do not support such
> features, allowing them to conform to the basic set of requirements.
> 
> 1. When a protocol provides a relay or re-direct mechanism, a companion
> mechanism to detect loops or repetition MUST also be provided.
> 
> 2. When a protocol provides the capability for a DPV server to re-direct a
> request to another DPV server (i.e. the protocol chooses to provide a
> referral mechanism), a mechanism to provide information to be used for the
> re-direction SHOULD be supported.  If such re-direction information   is
> sent back to clients, then the protocol MUST allow conforming clients to
> ignore it.
> 
> 3. Optional parameters in the protocol request and/or response MAY be
> provide support for relaying, re-direction or multicasting. DPV clients
> that ignore any such optional parameters MUST still be able to use the DPV
> service.  DPV servers that ignore any such optional parameters MUST MUST
> still be able to offer the DPV service, although they might not be able to
> overcome the limitations imposed by the network topology. In this way,
> protocol implementors need not understand the syntax or semantics of any
> such optional parameters.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3G8WFd17976 for ietf-pkix-bks; Tue, 16 Apr 2002 01:32:15 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3G8WDm17958 for <[e-mail]>; Tue, 16 Apr 2002 01:32:13 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA26116; Tue, 16 Apr 2002 10:34:52 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041610313912:432 ; Tue, 16 Apr 2002 10:31:39 +0200 
Message-ID: <[e-mail]>
Date: Tue, 16 Apr 2002 10:31:38 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 10:31:39, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 10:32:11, Serialize complete at 16/04/2002 10:32:11
Content-Transfer-Encoding: 7bit
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>

Tim,

I will be leaving my office tomorrow evening for one full week 
(both holidays then business), so we had better solve this rapidly 
so that I can post a new draft before leaving. :-)

See my comments embedded.
 
> Folks,
> 
> Here is my take on the relay/referral fracas, in two parts.
> 
> The first part addresses DPV relay includes (1) my assumptions about DPV,
> (2) a little rationale, and (3) a proposed "solution" for DPV replay.  The
> second part amounts to four complaints about the impact of adding
> referrals, and my belief that it should not be supported.
> 
>                                                          Part 1: DPV Relay
> Proposal
> 
> Assumption #1:
> 
> DPV relay is irrelevant to DPV clients.  They request answers from a
> trusted DPV server X, and server X MUST stand behind the response.  (That
> is, X can't say "I don't know, but Server Y says this certificate is
> okay."  It is up to X whether it can trust that answer.)

Fine.
 
> Assumption #2:
> 
> Many DPV servers will not relay requests.
> 
> Tim's Theory and what it is, too:
> 
> DPV servers that do not relay requests do not care if the request has been
> relayed before they received it.  

True.
 
> That only matters for loop detection/relay limits, etc.

Wrong. If they do not relay, a loop can never occur. :-( 

> DPV servers that do relay requests MUST be able to detect whether or not
> the request has been previously relayed, 

Correct.

> and the request MUST have the complete list of servers that have received the request.

No. You are specifying a solution, which would work but there are other
solutions to this problem: a list of servers is not the single way to solve
this issue. Since we are writing requirements we should not impose a
solution.

I believe that this requirement can be captured by the following sentence:
   
   When a server supports a relay mechanism, a mechanism to detect
   loops or repetition MUST be provided.

Now, to explain in more details:

When a DPV server relays a request to another DPV server:

    1) it must copy already present relay history information (if any),
    
    2) it must add relay history information in the relayed request. 

As an example, the added information can simply be a nonce and thus no
server name needs to be ever used. A sequence of nonces would thus do the
job nicely and avoid naming problems or naming conventions. Practically 
speaking, a sequence of INTEGER would do the job. 

> So, the conformance requirements:
> 
> Support for DPV relay is OPTIONAL for DPV servers.  DPV servers that do not
> relay requests do not need to process or recognize the relay history
> information.

Correct.
 
> DPV servers that relay requests MUST satisfy all the following conditions:
>            (1) recognize and process relay history if present in a DPV request;
>            (2) able to generate a relay history 

 .. information. Full stop.

> including the complete list of servers that have already forwarded this request; 

No. As said earlier, the received relay information is blindly copied.

>            (3) before relaying a request, the DPV server MUST verify that
> the chosen DPV server
>            has not already seen the message.  (That is loop detection
> occurs at the requester,
>            not the recipient).

Correct.
 
> This proposal does not impact clients, it simplifies the most common DPV
> servers, and it places *all* the burden on DPV servers that relay
> requests.  (As it should be, in my opinion.)

Correct.

>                                                       Part 2: DPV Referrals
> 
> Complaint A
> 
> Referrals impact *all* DPV clients, significantly increasing their
> complexity.  Currently, the requirements indicate whether or not the server
> could build a satisfactory path.  It seems to me that referrals force all
> DPV clients to interpret a new class of answers: "I don't know but ask
> Server B".  (By itself, this isn't that compelling, I admit.  They get
> stronger, IMHO.)

No. The idea is to send back the referral in a non-critical extension so
that it can be ignored by a client. Clients must be ready to support
extension fields, but are not mandated to understand any non-critical
extension.

> Complaint B
> 
> One of the nice features of DPV is a single "proof" for archival.  This
> feature is broken by the introduction of DPV referrals.  Assume Alice is
> trusts Server A, but she receives a referral indicating that Server A
> trusts Server B to validate this certificate.  

No. It is not the meaning of the referral. Assume Alice trusts Server A, but
she receives a referral from server A indicating that Server B
might be able to validate this certificate. Alice has to make its own
decision whether she can trust or not server B.  

> Alice will need to maintain both the referral from Server A and the 
> answer from Server B.

No. See above.

> Complaint C
> 
> Referrals for DPV are a very different animal than LDAP referrals.  Once
> again, assume Alice is trusts Server A but she receives a referral
> indicating that Server A trusts Server B to validate this
> certificate.  Alice will need to authenticate the identity of Server B
> using information from Server A.  I think that means that Server A needs to
> identify Server B by including Server B's public key in the referral.  If
> that is true, we just created a parallel key management infrastructure and
> increased the complexity of our universe.

Not with the trust model that I indicated.

> Complaint D
> 
> If LDAP is any indicator, nobody does referrals anyway.  Since DPV
> referrals will be significantly more complex, wouldn't it be better to put
> the load on the server?

The load will be on the servers. Clients may fully ignore that field.

Denis

 
> Alright, I'm off my soapbox.  Flame suit is zipped.  What do you all think
> of these proposals?
> 
> Thanks,
> 
> Tim Polk


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3G8HPn13377 for ietf-pkix-bks; Tue, 16 Apr 2002 01:17:25 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3G8G4m12746 for <[e-mail]>; Tue, 16 Apr 2002 01:16:04 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA26280; Tue, 16 Apr 2002 10:18:40 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041610153658:424 ; Tue, 16 Apr 2002 10:15:36 +0200 
Message-ID: <[e-mail]>
Date: Tue, 16 Apr 2002 10:15:36 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 10:15:36, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 10:15:59, Serialize complete at 16/04/2002 10:15:59
Content-Transfer-Encoding: 7bit
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>

Russ,
 
> Tom:
 
> We are about to post an update to the draft.  Expect to see it in the next
> day or so.

Isn't it premature ?

I am still expecting responses to my set of comments and questions.

Regards,

Denis
 
> I recognize the severe memory constraints of smartcards.
> 
> Russ
> 
> At 12:35 PM 4/10/2002 -0400, Tom Gindin wrote:
> 
> >       Russ:
> >
> >       Most of the following concerns the data structures of the current
> >draft and of my last posting.  First, should the URI really be optional in
> >cases where the binary component is a hash?  What good is the logotype
> >field with a hash but no way to reference the image?  Second, I have
> >reviewed draft-ietf-idn-uri-01.txt (by Martin Duerst) and it recommends
> >that internationalized URI strings be converted to UTF-8 but then escaped
> >using %HH, so UTF8String is unnecessary.  Therefore, we should simplify
> >VerifiedReference as follows:
> >       VerifiedReference ::= SEQUENCE {
> >             hashAlgorithm     AlgorithmIdentifier,
> >             dataHash    OCTET STRING,
> >             uri          IA5String,
> >       }
> >
> >       On a different topic, smart cards and other tokens have the least
> >space of any place certificates are likely to be put, so if in-line
> >logotypes are OK there they're OK anywhere.
> >
> >             Tom Gindin
> >
> >
> >"Housley, Russ" <[e-mail]> on 04/08/2002 01:17:11 PM
> >
> >To:    Tom Gindin/Watson/IBM@IBMUS
> >cc:    [e-mail]
> >Subject:    Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
> >
> >
> >Tom:
> >
> > >The following is just a personal opinion, but one based on fairly
> > >well-understood trends.  I don't think that in-line logotypes are
> >CURRENTLY
> > >worth the space that they'd take up on a smart card, but I would guess
> >that
> > >they will be in two more smart-card generations and perhaps only one.
> > >Given the amount of time between standard proposal and deployment, it's
> >not
> > >premature to standardize it.
> >
> >I tend to agree with your assessment of storage on smart cards.  Today, all
> >
> >of the certificates stored on one smart card are likely to be associated
> >with one community.  Therefore, a logo will like appear on the smart card
> >itself.
> >
> >Of course, there are other places that certificates and private keys are
> >stored....
> >
> > >       However, I also have a question about the current data structure.
> > >First, why is the URI optional (assuming that the only binary value is the
> > >digest, as at present)?  Second, why would we not permit in-line logotypes
> > >(in which case the URI is suppressed)?  This would require some edits to
> > >LogotypeData, but nothing very difficult.  One possibility would be:
> > >       LogotypeData ::= SEQUENCE {
> > >           typeOfLogotype       TypeOfLogotype,
> > >           hashAlgorithm        AlgorithmIdentifier,   -- might be
> >OPTIONAL,
> > >it's not meaningful for GIF's
> > >           CHOICE  {
> > >             logotypeDataHash     OCTET STRING,
> > >       gif   [0]         IMPLICIT OCTET STRING
> > >       },
> > >           logotypeDataUri      IA5String OPTIONAL }
> > >
> > >       Another would be:
> > >       LogotypeData ::= SEQUENCE {
> > >           typeOfLogotype       TypeOfLogotype,
> > >           CHOICE  {
> > >             logotypeReference VerifiedReference,
> > >       gif               OCTET STRING
> > >       }
> > >           }
> > >       VerifiedReference ::= SEQUENCE {
> > >             hashAlgorithm     AlgorithmIdentifier,
> > >             dataHash    OCTET STRING,
> > >             CHOICE      {
> > >                   uri          IA5String,
> > >                   intlUri           UTF8String  }
> > >       }
> > >
> > >
> > >       IMO VerifiedReference is a generally useful type, so its names do
> >not
> > >contain reference to logotypes.  My understanding of COMPONENTS OF, which
> > >may be faulty, is that defining LogotypeData using COMPONENTS OF
> > >VerifiedReference as an element of a CHOICE would not produce a useful
> > >result because each of the elements of VerifiedReference would show up in
> > >the CHOICE rather than merely hashAlgorithm going into the CHOICE with the
> > >other fields added to LogotypeData's SEQUENCE.
> >
> >We are in the final steps of an updated I-D.  It addresses some of these
> >issues, but not all.
> >
> >Is there a reference for UTF8String URI?
> >
> >Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3G82Fa08555 for ietf-pkix-bks; Tue, 16 Apr 2002 01:02:15 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3G82Dm08535 for <[e-mail]>; Tue, 16 Apr 2002 01:02:13 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA26146; Tue, 16 Apr 2002 10:04:46 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041610013435:418 ; Tue, 16 Apr 2002 10:01:34 +0200 
Message-ID: <[e-mail]>
Date: Tue, 16 Apr 2002 10:01:33 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: Peter Sylvester <[e-mail]>, [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 10:01:34, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 16/04/2002 10:02:07, Serialize complete at 16/04/2002 10:02:07
Content-Transfer-Encoding: 7bit
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>

Peter,

> Denis:
> 
> In your phrase "authorised CRL issuers or authorised OCSP
> responders", who performs the act of authorization?

Many questions and simple answers.

Authorized means authorized by the CA that has issued the certificate.
Authorized CRL Issuers and authorized OCSP responders are designated by the
CA.

> Which mechanism(s) of OCSP communicate
> and handle "authorization", for the OCSP case?

A certificate is issued by the CA for the OCSP responder.

> Who is responsible for "enforcing" the authorization
> policy, of the authorization scheme, for the OCSP case?

The CA that has issued the certificate.

> Which procedures of the (to be specified) DPV Protocol
> will perform the requirements for authorization
> enforcement for DPV? And the interaction of DPV
> with CRL issuers and OCSP responders, and any
> other repository access provider.

Certificates issued by the CA for the CRL Issuers and OCSP responders will
do it.
 
> When a DPV relay server receives an OCSP response
> set from the upstream DPV relay, will it
> (a) forward the OCSP responses to the client?
> (b) reverify the OCSP responses, before sending material
> to the client?
> (c) take legal responsibility for the upstream
> validation policy enforcement?

A DPV server does not simply send back an OCSP response, but a DPV response
which *may* be accompanied with certificates, CRLs and OCSP responses, *all*
verified.
 
> How will the DPV relay server know if the
> OCSP responder upstream (several DPV relay
> servers away) is "authorized"?

See above.
 
> If a DPV server relays a DPV request, and
> authorization is issued by the relying party,

Authorisation comes from a CA, not from a relying party.

> how will an upstream DPV server enforce
> the policy - without knowledge of
> the relying party identity, and the
> validation policy.

The validation policy has to be known from a DPV server.

Denis

 
> >>>>-----Original Message-----
> >>>>From: Denis Pinkas [mailto:[e-mail]]
> >>>>Sent: Monday, April 15, 2002 12:49 AM
> >>>>To: Peter Sylvester
> >>>>Cc: [e-mail]
> >>>>Subject: Re: Open issue: DPV relay
> >>>>
> >>>>The DPV request MUST allow the client to request the response to
> >>>>include either the certification path and the revocation status
> >>>>information from authorised CRL issuers or authorised OCSP
> >>>>responders,
> >>>>or a DPV response from a DPV server that is trusted under the
> >>>>validation policy. This information may allow other clients, not
> >>>>trusting the requested DPV server to be confident that the
> >>>>certificate
> >>>>validation has correctly be performed. When the certificate
> >>>>is valid
> >>>>according to the validation policy, the server MUST, upon request,
> >>>>include that information in the response. However, the server MAY
> >>>>omit that information when the certificate is invalid or when it
> >>>>cannot determine the validity.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3G6CfH19842 for ietf-pkix-bks; Mon, 15 Apr 2002 23:12:41 -0700 (PDT)
Received: from maila.telia.com (maila.telia.com [194.22.194.231]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3G6Cdm19832 for <[e-mail]>; Mon, 15 Apr 2002 23:12:40 -0700 (PDT)
Received: from arport (t4o69p69.telia.com [62.20.145.189]) by maila.telia.com (8.11.6/8.11.6) with SMTP id g3G6CgS12086 for <[e-mail]>; Tue, 16 Apr 2002 08:12:43 +0200 (CEST)
Message-ID: <003d01c1e515$c1f07600$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>
Subject: Hi-Jacking the VeriSign WebServer CA
Date: Tue, 16 Apr 2002 09:10:13 +0200
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 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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>

Pardon the interesting title :-)  The following is a part of a coming B2B-
standard that I want you PKIXers to comment on.

The scenario
--------------
A multi-party portal supporting potentially millions of small businesses,
will, using the OBI Express B2B-standard, be forced to keep a unique
company-certificate and associated private key for each hosted business-
entity.  AKA a "Digital Company Paper".   The private keys are only
used on the portal-server, and never distributed as OBI Express is based
on organization-level, server-based PKI.

A portal of this kind typically only vouches for the hosted business-entity
as being a customer of the portal with a certain internal customer-ID and
common name.  Mostly because this is a safe thing for the portal to do.

To do this efficiently and securely, the portal usually has an integral
CA-function, with a corresponding CA-cert and key.  A business-
entity's "Digital Company Paper" is automatically created during
the registration of the business entity.  Renewals are performed
automatically in the background.  Revocation does not apply, as
you simply disable or delete the account if a customer is not wanted
anymore.  Private keys are preferably protected by HW-cryptography.

The problem
--------------
All this is great, but it also effectively means that each portal will
become an independent CA-root to be accepted, installed etc. by RPs.
This somewhat defeats the OBI Express goal of plug-and-play operation.
To make the portal-CA a part of an existing and trusted hierarchy is
certainly possible (who's?), but is also likely to cost a minor fortune.

The work-around
--------------------
The portal signs a message containing the local portal-CA certpath using
a web-server certificate issued by a generally known and trusted issuer
like VeriSign  (a web-server certificate is BTW needed anyway, as
OBI Express uses HTTPS for all external communication).  Then the
portal publishes this message for existing and potential RPs to use (OBI
Express' PKI-support functions are capable of performing the dual path-
validations needed).

====================================================
By doing this, the portal-CA gets a certified "home" and can (depending
on local policy) be "auto-accepted" as it was a part of the VeriSign tree.
====================================================

The only difference trustwise is that VeriSign has not sanctioned the portal's
CA-activities.  But for RPs that do not know the portal, that does not mean
much.  This is IMHO a problem with deeply nested PKIs in general.  For a
business operation, the concept of trust is also a bit more complicated than
just a trustworthy digital certificate.  It is more about reputation, and
execution.  To use a web server certificate as a CA-certificate had been
even better, but VeriSign's et al's key-usage constraints for avoiding trust-
anchor hi-jacking (!), make PKIX-conformant path-validation fail.

Is this hi-jacking illegal, unethical, technically broken, or just a "clever"
way to save maybe $25-$100K / installation?

Anders Rundgren
X-OBI

Trademarks: OBI and OBI Express are trademarks of CommerceNet




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3G334q11357 for ietf-pkix-bks; Mon, 15 Apr 2002 20:03:04 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3G333m11353 for <[e-mail]>; Mon, 15 Apr 2002 20:03:03 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 15 Apr 2002 10:38:48 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 15 Apr 2002 10:38:47 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <2X07K5C5>; Mon, 15 Apr 2002 10:40:58 -0700
Content-return: allowed
Date: Mon, 15 Apr 2002 10:40:52 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Open issue: DPV relay
To: "'Denis Pinkas'" <[e-mail]>, Peter Sylvester <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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:

In your phrase "authorised CRL issuers or authorised OCSP 
responders", who performs the act of authorization?

Which mechanism(s) of OCSP communicate
and handle "authorization", for the OCSP case?

Who is responsible for "enforcing" the authorization
policy, of the authorization scheme, for the OCSP case?

Which procedures of the (to be specified) DPV Protocol
will perform the requirements for authorization
enforcement for DPV? And the interaction of DPV
with CRL issuers and OCSP responders, and any
other repository access provider.

When a DPV relay server receives an OCSP response
set from the upstream DPV relay, will it
(a) forward the OCSP responses to the client?
(b) reverify the OCSP responses, before sending material
to the client?
(c) take legal responsibility for the upstream
validation policy enforcement?

How will the DPV relay server know if the
OCSP responder upstream (several DPV relay
servers away) is "authorized"?

If a DPV server relays a DPV request, and
authorization is issued by the relying party,
how will an upstream DPV server enforce
the policy - without knowledge of
the relying party identity, and the
validation policy.




>>>>-----Original Message-----
>>>>From: Denis Pinkas [mailto:[e-mail]]
>>>>Sent: Monday, April 15, 2002 12:49 AM
>>>>To: Peter Sylvester
>>>>Cc: [e-mail]
>>>>Subject: Re: Open issue: DPV relay
>>>>
>>>>The DPV request MUST allow the client to request the response to 
>>>>include either the certification path and the revocation status 
>>>>information from authorised CRL issuers or authorised OCSP 
>>>>responders, 
>>>>or a DPV response from a DPV server that is trusted under the 
>>>>validation policy. This information may allow other clients, not 
>>>>trusting the requested DPV server to be confident that the 
>>>>certificate 
>>>>validation has correctly be performed. When the certificate 
>>>>is valid 
>>>>according to the validation policy, the server MUST, upon request, 
>>>>include that information in the response. However, the server MAY 
>>>>omit that information when the certificate is invalid or when it 
>>>>cannot determine the validity.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3G2TSV10729 for ietf-pkix-bks; Mon, 15 Apr 2002 19:29:28 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3G2TQm10725 for <[e-mail]>; Mon, 15 Apr 2002 19:29:26 -0700 (PDT)
Received: from tsg1 ([12.81.64.131]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020416022924.ITVF28245.mtiwmhc23.worldnet.att.net@tsg1>; Tue, 16 Apr 2002 02:29:24 +0000
Message-ID: <004e01c1e4ee$5e51e7e0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Michael Myers" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Two  more nits re: DPV/DPD rqmts
Date: Mon, 15 Apr 2002 19:01:43 -0700
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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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: "Denis Pinkas" <[e-mail]>
To: "Michael Myers" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, April 15, 2002 10:05 AM
Subject: Re: Two more nits re: DPV/DPD rqmts


>
> Mike,
>
> > Russ, Denis:
> >
> > Section 4, Delegated Path Validation Protocol Requirements
> > begins with:
> > "The Delegated Path Validation (DPV) protocol allows . . ."
> >
> > Similarly, Section 5 Delegated Path Discovery Protocol
> > Requirements begins with:
> > "The Delegated Path Discovery (DPD) protocol allows . . ."
> >
> > Since we're defining requirements and not protocols in this I-D,
> > you may wish to consider amending both these phrases towards
> > something along the lines of "DPV protocols allow . . ." and
> > "DPD protocols allow . . ." respectively.
>
> Are we really defining multiple protocols ?
> I was assuming that we would like only one.
> I prefer to keep the current text.

Denis - are you saying that it is PKIX's operating rule to only allow one of
each protocol type its working on? Is this true Tim and Steve Kent?

Todd

>
> Denis
>
> >
> > Mike
> >
> > Michael Myers
> > t: +415.819.1362
> > e: mailto:[e-mail]
> > w: http://www.traceroutesecurity.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FNTsI07024 for ietf-pkix-bks; Mon, 15 Apr 2002 16:29:54 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FNTqm07018 for <[e-mail]>; Mon, 15 Apr 2002 16:29:52 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3FNTpPm020402; Mon, 15 Apr 2002 16:29:51 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Tim Polk" <[e-mail]>, <[e-mail]>
Subject: RE: Open issue: DPV relay
Date: Mon, 15 Apr 2002 16:27:03 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Tim,

A few specific comments embedded below regarding relay.  In
summary:

1. Relay may some day be relevant to clients;
2. Relay history lists may get long, another solution?; and
3. Common servers may not be the same vendors five years out.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Tim Polk
> Sent: Monday, April 15, 2002 1:08 PM
> To: [e-mail]
> Subject: RE: Open issue: DPV relay
>
>
>
> Folks,
>
> Here is my take on the relay/referral fracas, in two parts.
>
> The first part addresses DPV relay includes (1) my
> assumptions about DPV,  (2) a little rationale, and
> (3) a proposed "solution" for DPV replay.  The
> second part amounts to four complaints about the
> impact of adding  > referrals, and my belief that
> it should not be supported.
>
>
> Part 1: DPV Relay
> Proposal
>
> Assumption #1:
>
> DPV relay is irrelevant to DPV clients.  They request
> answers from a trusted DPV server X, and server X MUST
> stand behind the response.  (That is, X can't say "I don't
> know, but Server Y says this certificate is okay."  It
> is up to X whether it can trust that answer.)

We may be premature in assuming relay will never be relevant
to clients.  In future applications it may be important for
a client to have in hand a digitally signed assertion from the
entity ultimately at risk for the reliability of a certificate
even if the client trusts a given server as a service
aggregation point for the purposes of system design economy.

>
> Assumption #2:
>
> Many DPV servers will not relay requests.
>
> Tim's Theory and what it is, too:
>
> DPV servers that do not relay requests do not care if
> the request has been relayed before they received it.

I assume your further thinking is, "because in the event
they can't satisfy the request, they'll assert 'unknown' rather
than seek a suitable relay hop, thus breaking the relay chain."
Correct?

> That only matters for loop detection/relay limits, etc.
>
> DPV servers that do relay requests MUST be able to
> detect whether or not the request has been previously
> relayed, and the request MUST have the complete list of
> servers that have received the request.
>
> So, the conformance requirements:
>
> Support for DPV relay is OPTIONAL for DPV servers.
> DPV servers that do not relay requests do not need
> to process or recognize the relay history information.
>
> DPV servers that relay requests MUST satisfy all the
> following conditions:
>
> (1) recognize and process relay history if present
>    in a DPV request;

I'm a bit worried about relay history being an increasingly
long list of server names and IP addresses.  There should be
something simpler here that enables loop detection.  Problem
is I'm not sure we can predict what it would look like until
we get into the protocol selection issue.

> (2) able to generate a relay history including the
>    complete list of servers that have already
>    forwarded this request; and

See above.

> (3) before relaying a request, the DPV server MUST verify
>     that the chosen DPV server has not already seen the
>     message.  (That is loop detection occurs at the requester,
>     not the recipient).

Loop detection at the requester makes sense.

> This proposal does not impact clients, it simplifies
> the most common DPV servers,

Hmm.  In five years the most common DPV servers may not be
those currently in favor.  Maybe you meant to say this
differently, but I'm hearing that market share and installed
base is relevant to our technical considerations.  I'm confident
this is a minor point easily clarified due to my misreading
of the above.

> and it places *all* the burden on DPV servers that relay
> requests.  (As it should be, in my opinion.)

Looking forward, clients might want a piece of the action.
Hard to predict what the storage and processing limitations
will be (e.g. increasingly smarter smart cards).  My sense is
those capabilities are reliably expanding. Certainly though,
our intent from the very beginning with online status
mechanisms was to push complexity to the backend and so
make it easier to initiate, deploy and maintain a PKI.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FLc3904802 for ietf-pkix-bks; Mon, 15 Apr 2002 14:38:03 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FLc1m04798 for <[e-mail]>; Mon, 15 Apr 2002 14:38:01 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <JAAN6SNG>; Mon, 15 Apr 2002 17:22:35 -0400
Message-ID: <[e-mail]>
From: Tim Moses <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, Tim Polk <[e-mail]>, [e-mail]
Subject: RE: Open issue: DPV relay
Date: Mon, 15 Apr 2002 17:22:34 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E4C3.A8D48460"
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_01C1E4C3.A8D48460
Content-Type: text/plain;
	charset="iso-8859-1"

I'm hearing nothing but good sense.  All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: [phone]


-----Original Message-----
From: Trevor Freeman [mailto:[e-mail]]
Sent: Monday, April 15, 2002 4:47 PM
To: Tim Polk; [e-mail]
Subject: RE: Open issue: DPV relay



Hi Tim,
I am in 100% agreement on assumption 1 and consider this one of the
cornerstones of DPV. Given assumption 1, I really don't care how many
servers do\do not support relay. We need a loop detection payload in a
request, but that is all. A client should have full confidence that all
it will get back from the DPV server is a yes or no answer. My biggest
compliant is around C. This is a critical difference between DPV and
LDAP referrals. It cannot simply return a referral because the client
may not trust the server referred to. If you go down the rat hole of
also returning a signed token to say if you trust me, you can also trust
him we should give ourselves a red card for client complexity. The whole
point of this work is that the client wants to say "I want a strait
yes\no answer to this question and don't bother me with details".
So no flammable comments here, just agreement.
Trevor

-----Original Message-----
From: Tim Polk [mailto:[e-mail]] 
Sent: Monday, April 15, 2002 1:08 PM
To: [e-mail]
Subject: RE: Open issue: DPV relay


Folks,

Here is my take on the relay/referral fracas, in two parts.

The first part addresses DPV relay includes (1) my assumptions about
DPV, 
(2) a little rationale, and (3) a proposed "solution" for DPV replay.
The 
second part amounts to four complaints about the impact of adding 
referrals, and my belief that it should not be supported.

                                                         Part 1: DPV
Relay 
Proposal

Assumption #1:

DPV relay is irrelevant to DPV clients.  They request answers from a 
trusted DPV server X, and server X MUST stand behind the response.
(That 
is, X can't say "I don't know, but Server Y says this certificate is 
okay."  It is up to X whether it can trust that answer.)

Assumption #2:

Many DPV servers will not relay requests.

Tim's Theory and what it is, too:

DPV servers that do not relay requests do not care if the request has
been 
relayed before they received it.  That only matters for loop 
detection/relay limits, etc.

DPV servers that do relay requests MUST be able to detect whether or not

the request has been previously relayed, and the request MUST have the 
complete list of servers that have received the request.

So, the conformance requirements:

Support for DPV relay is OPTIONAL for DPV servers.  DPV servers that do
not 
relay requests do not need to process or recognize the relay history 
information.

DPV servers that relay requests MUST satisfy all the following
conditions:
           (1) recognize and process relay history if present in a DPV
request;
           (2) able to generate a relay history including the complete
list 
of servers that have
           already forwarded this request; and
           (3) before relaying a request, the DPV server MUST verify
that 
the chosen DPV server
           has not already seen the message.  (That is loop detection 
occurs at the requester,
           not the recipient).

This proposal does not impact clients, it simplifies the most common DPV

servers, and it places *all* the burden on DPV servers that relay 
requests.  (As it should be, in my opinion.)

                                                      Part 2: DPV
Referrals

Complaint A

Referrals impact *all* DPV clients, significantly increasing their 
complexity.  Currently, the requirements indicate whether or not the
server 
could build a satisfactory path.  It seems to me that referrals force
all 
DPV clients to interpret a new class of answers: "I don't know but ask 
Server B".  (By itself, this isn't that compelling, I admit.  They get 
stronger, IMHO.)

Complaint B

One of the nice features of DPV is a single "proof" for archival.  This 
feature is broken by the introduction of DPV referrals.  Assume Alice is

trusts Server A, but she receives a referral indicating that Server A 
trusts Server B to validate this certificate.  Alice will need to
maintain 
both the referral from Server A and the answer from Server B.

Complaint C

Referrals for DPV are a very different animal than LDAP referrals.  Once

again, assume Alice is trusts Server A but she receives a referral 
indicating that Server A trusts Server B to validate this 
certificate.  Alice will need to authenticate the identity of Server B 
using information from Server A.  I think that means that Server A needs
to 
identify Server B by including Server B's public key in the referral.
If 
that is true, we just created a parallel key management infrastructure
and 
increased the complexity of our universe.

Complaint D

If LDAP is any indicator, nobody does referrals anyway.  Since DPV 
referrals will be significantly more complex, wouldn't it be better to
put 
the load on the server?

Alright, I'm off my soapbox.  Flame suit is zipped.  What do you all
think 
of these proposals?

Thanks,

Tim Polk



------_=_NextPart_001_01C1E4C3.A8D48460
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Open issue: DPV relay</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I'm hearing nothing but good sense.&nbsp; All the =
best.&nbsp; Tim.</FONT>
</P>

<P><FONT SIZE=3D2>-----------------------------------------</FONT>
<BR><FONT SIZE=3D2>Tim Moses</FONT>
<BR><FONT SIZE=3D2>Tel: [phone]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Trevor Freeman [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
rosoft.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 15, 2002 4:47 PM</FONT>
<BR><FONT SIZE=3D2>To: Tim Polk; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Open issue: DPV relay</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi Tim,</FONT>
<BR><FONT SIZE=3D2>I am in 100% agreement on assumption 1 and consider =
this one of the</FONT>
<BR><FONT SIZE=3D2>cornerstones of DPV. Given assumption 1, I really =
don't care how many</FONT>
<BR><FONT SIZE=3D2>servers do\do not support relay. We need a loop =
detection payload in a</FONT>
<BR><FONT SIZE=3D2>request, but that is all. A client should have full =
confidence that all</FONT>
<BR><FONT SIZE=3D2>it will get back from the DPV server is a yes or no =
answer. My biggest</FONT>
<BR><FONT SIZE=3D2>compliant is around C. This is a critical difference =
between DPV and</FONT>
<BR><FONT SIZE=3D2>LDAP referrals. It cannot simply return a referral =
because the client</FONT>
<BR><FONT SIZE=3D2>may not trust the server referred to. If you go down =
the rat hole of</FONT>
<BR><FONT SIZE=3D2>also returning a signed token to say if you trust =
me, you can also trust</FONT>
<BR><FONT SIZE=3D2>him we should give ourselves a red card for client =
complexity. The whole</FONT>
<BR><FONT SIZE=3D2>point of this work is that the client wants to say =
&quot;I want a strait</FONT>
<BR><FONT SIZE=3D2>yes\no answer to this question and don't bother me =
with details&quot;.</FONT>
<BR><FONT SIZE=3D2>So no flammable comments here, just =
agreement.</FONT>
<BR><FONT SIZE=3D2>Trevor</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Tim Polk [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] </FONT>
<BR><FONT SIZE=3D2>Sent: Monday, April 15, 2002 1:08 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Open issue: DPV relay</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Folks,</FONT>
</P>

<P><FONT SIZE=3D2>Here is my take on the relay/referral fracas, in two =
parts.</FONT>
</P>

<P><FONT SIZE=3D2>The first part addresses DPV relay includes (1) my =
assumptions about</FONT>
<BR><FONT SIZE=3D2>DPV, </FONT>
<BR><FONT SIZE=3D2>(2) a little rationale, and (3) a proposed =
&quot;solution&quot; for DPV replay.</FONT>
<BR><FONT SIZE=3D2>The </FONT>
<BR><FONT SIZE=3D2>second part amounts to four complaints about the =
impact of adding </FONT>
<BR><FONT SIZE=3D2>referrals, and my belief that it should not be =
supported.</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Part 1: =
DPV</FONT>
<BR><FONT SIZE=3D2>Relay </FONT>
<BR><FONT SIZE=3D2>Proposal</FONT>
</P>

<P><FONT SIZE=3D2>Assumption #1:</FONT>
</P>

<P><FONT SIZE=3D2>DPV relay is irrelevant to DPV clients.&nbsp; They =
request answers from a </FONT>
<BR><FONT SIZE=3D2>trusted DPV server X, and server X MUST stand behind =
the response.</FONT>
<BR><FONT SIZE=3D2>(That </FONT>
<BR><FONT SIZE=3D2>is, X can't say &quot;I don't know, but Server Y =
says this certificate is </FONT>
<BR><FONT SIZE=3D2>okay.&quot;&nbsp; It is up to X whether it can trust =
that answer.)</FONT>
</P>

<P><FONT SIZE=3D2>Assumption #2:</FONT>
</P>

<P><FONT SIZE=3D2>Many DPV servers will not relay requests.</FONT>
</P>

<P><FONT SIZE=3D2>Tim's Theory and what it is, too:</FONT>
</P>

<P><FONT SIZE=3D2>DPV servers that do not relay requests do not care if =
the request has</FONT>
<BR><FONT SIZE=3D2>been </FONT>
<BR><FONT SIZE=3D2>relayed before they received it.&nbsp; That only =
matters for loop </FONT>
<BR><FONT SIZE=3D2>detection/relay limits, etc.</FONT>
</P>

<P><FONT SIZE=3D2>DPV servers that do relay requests MUST be able to =
detect whether or not</FONT>
</P>

<P><FONT SIZE=3D2>the request has been previously relayed, and the =
request MUST have the </FONT>
<BR><FONT SIZE=3D2>complete list of servers that have received the =
request.</FONT>
</P>

<P><FONT SIZE=3D2>So, the conformance requirements:</FONT>
</P>

<P><FONT SIZE=3D2>Support for DPV relay is OPTIONAL for DPV =
servers.&nbsp; DPV servers that do</FONT>
<BR><FONT SIZE=3D2>not </FONT>
<BR><FONT SIZE=3D2>relay requests do not need to process or recognize =
the relay history </FONT>
<BR><FONT SIZE=3D2>information.</FONT>
</P>

<P><FONT SIZE=3D2>DPV servers that relay requests MUST satisfy all the =
following</FONT>
<BR><FONT SIZE=3D2>conditions:</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(1) recognize and process relay history if present in a DPV</FONT>
<BR><FONT SIZE=3D2>request;</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(2) able to generate a relay history including the complete</FONT>
<BR><FONT SIZE=3D2>list </FONT>
<BR><FONT SIZE=3D2>of servers that have</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
already forwarded this request; and</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
(3) before relaying a request, the DPV server MUST verify</FONT>
<BR><FONT SIZE=3D2>that </FONT>
<BR><FONT SIZE=3D2>the chosen DPV server</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
has not already seen the message.&nbsp; (That is loop detection </FONT>
<BR><FONT SIZE=3D2>occurs at the requester,</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
not the recipient).</FONT>
</P>

<P><FONT SIZE=3D2>This proposal does not impact clients, it simplifies =
the most common DPV</FONT>
</P>

<P><FONT SIZE=3D2>servers, and it places *all* the burden on DPV =
servers that relay </FONT>
<BR><FONT SIZE=3D2>requests.&nbsp; (As it should be, in my =
opinion.)</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Part 2: DPV</FONT>
<BR><FONT SIZE=3D2>Referrals</FONT>
</P>

<P><FONT SIZE=3D2>Complaint A</FONT>
</P>

<P><FONT SIZE=3D2>Referrals impact *all* DPV clients, significantly =
increasing their </FONT>
<BR><FONT SIZE=3D2>complexity.&nbsp; Currently, the requirements =
indicate whether or not the</FONT>
<BR><FONT SIZE=3D2>server </FONT>
<BR><FONT SIZE=3D2>could build a satisfactory path.&nbsp; It seems to =
me that referrals force</FONT>
<BR><FONT SIZE=3D2>all </FONT>
<BR><FONT SIZE=3D2>DPV clients to interpret a new class of answers: =
&quot;I don't know but ask </FONT>
<BR><FONT SIZE=3D2>Server B&quot;.&nbsp; (By itself, this isn't that =
compelling, I admit.&nbsp; They get </FONT>
<BR><FONT SIZE=3D2>stronger, IMHO.)</FONT>
</P>

<P><FONT SIZE=3D2>Complaint B</FONT>
</P>

<P><FONT SIZE=3D2>One of the nice features of DPV is a single =
&quot;proof&quot; for archival.&nbsp; This </FONT>
<BR><FONT SIZE=3D2>feature is broken by the introduction of DPV =
referrals.&nbsp; Assume Alice is</FONT>
</P>

<P><FONT SIZE=3D2>trusts Server A, but she receives a referral =
indicating that Server A </FONT>
<BR><FONT SIZE=3D2>trusts Server B to validate this certificate.&nbsp; =
Alice will need to</FONT>
<BR><FONT SIZE=3D2>maintain </FONT>
<BR><FONT SIZE=3D2>both the referral from Server A and the answer from =
Server B.</FONT>
</P>

<P><FONT SIZE=3D2>Complaint C</FONT>
</P>

<P><FONT SIZE=3D2>Referrals for DPV are a very different animal than =
LDAP referrals.&nbsp; Once</FONT>
</P>

<P><FONT SIZE=3D2>again, assume Alice is trusts Server A but she =
receives a referral </FONT>
<BR><FONT SIZE=3D2>indicating that Server A trusts Server B to validate =
this </FONT>
<BR><FONT SIZE=3D2>certificate.&nbsp; Alice will need to authenticate =
the identity of Server B </FONT>
<BR><FONT SIZE=3D2>using information from Server A.&nbsp; I think that =
means that Server A needs</FONT>
<BR><FONT SIZE=3D2>to </FONT>
<BR><FONT SIZE=3D2>identify Server B by including Server B's public key =
in the referral.</FONT>
<BR><FONT SIZE=3D2>If </FONT>
<BR><FONT SIZE=3D2>that is true, we just created a parallel key =
management infrastructure</FONT>
<BR><FONT SIZE=3D2>and </FONT>
<BR><FONT SIZE=3D2>increased the complexity of our universe.</FONT>
</P>

<P><FONT SIZE=3D2>Complaint D</FONT>
</P>

<P><FONT SIZE=3D2>If LDAP is any indicator, nobody does referrals =
anyway.&nbsp; Since DPV </FONT>
<BR><FONT SIZE=3D2>referrals will be significantly more complex, =
wouldn't it be better to</FONT>
<BR><FONT SIZE=3D2>put </FONT>
<BR><FONT SIZE=3D2>the load on the server?</FONT>
</P>

<P><FONT SIZE=3D2>Alright, I'm off my soapbox.&nbsp; Flame suit is =
zipped.&nbsp; What do you all</FONT>
<BR><FONT SIZE=3D2>think </FONT>
<BR><FONT SIZE=3D2>of these proposals?</FONT>
</P>

<P><FONT SIZE=3D2>Thanks,</FONT>
</P>

<P><FONT SIZE=3D2>Tim Polk</FONT>
</P>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1E4C3.A8D48460--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FL2Jb04048 for ietf-pkix-bks; Mon, 15 Apr 2002 14:02:19 -0700 (PDT)
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FL2Hm04043 for <[e-mail]>; Mon, 15 Apr 2002 14:02:17 -0700 (PDT)
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Apr 2002 14:02:15 -0700
Received: from 157.54.6.150 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Apr 2002 14:02:15 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Apr 2002 14:02:14 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Apr 2002 14:02:14 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Mon, 15 Apr 2002 13:58:38 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: A few comments re: dpv-dpd requirements
Date: Mon, 15 Apr 2002 13:58:40 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: A few comments re: dpv-dpd requirements
Thread-Index: AcHkuq3R4Yc+CP93SqGPFErt89ADQwABLmnA
From: "Trevor Freeman" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 15 Apr 2002 20:58:38.0666 (UTC) FILETIME=[50FC72A0:01C1E4C0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3FL2Hm04044
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 Mike,
I still don't see it. The client is really searching for a digitally
signed success case. If the server sends back nothing, an unsigned
response of failure or signed response of failure - that's still a
failure as far as the client is concerned. I don't see we have exposed
the server in any way and we can accommodate any number of sub-statuses
to the failure responses.

Trevor

-----Original Message-----
From: Michael Myers [mailto:[e-mail]] 
Sent: Monday, April 15, 2002 1:19 PM
To: Trevor Freeman; [e-mail]
Subject: RE: A few comments re: dpv-dpd requirements

Trevor,

Looking at this from an abstract state machine perspective I see
a first, binary branching.  Upon receipt of a query, you have
either:

1. FAILURE:  Something's wrong here, can't proceed, raise an
exception, send back an unsigned response; or

2. PROCEED:  Understand the query, send to the backend for the
heavy lifting needed to produce a signed response.

My model is basically a frontend/backend architecture that
protects the backend (and, in the case of DPV, its signing key)
from DOS attacks, among other Internet-facing nastiness.

This model assume of course that when a query gets to the
trusted backend, a signature is required.  While we're not
lawyers here, it's arguable that a trusted entity's digitally
signed assertion that a certificate is "invalid" could be
significant in a dispute when in point of fact that trusted
backend couldn't arrive at conclusion due to lack of relevant
data.

Given that we're still into the early stages of defining and
using these things, I think it's better we enable a digitally
signed "unknown" to cover this instance.

Mike



Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com

> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Friday, April 12, 2002 12:32 PM
> To: Michael Myers; [e-mail]
> Subject: RE: A few comments re: dpv-dpd requirements
>
>
> Hi Mike,
> I don't see how supporting an unknown response helps.
> Unknown sounds
> like a sub-status on the failure case. If I did have
> multiple SA with
> multiple DPV servers, anything other than a cert is
> valid response will
> cause me to go select the next DPV server and try
> again. If I only have
> one DPV server, then again, if it is not valid - it's invalid.
> Insufficient information to be able to be able to
> complete the request
> could be a sub-status reason returned in the DPV
> response, which allows
> me to audit or account for why the cert was not used,
> but the DPV server
> should only return one of two states.
>
> Trevor
>
> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Thursday, April 04, 2002 4:51 PM
> To: [e-mail]
> Subject: A few comments re: dpv-dpd requirements
>
>
> Russ, Denis:
>
> The state "unknown" is missing in Section 4, "Delegated Path
> Validation Protocol Requirements".  The -03 draft currently
> reads:
>
> "The DPV response MUST indicate one of the following
> two status
> alternatives:
>
> 1) the certificate is valid according to the
> validation policy.
> 2) the certificate is not valid according to the validation
> policy."
>
> I think -04 should read:
>
> "The DPV response MUST indicate one of the following three
> status alternatives:
>
> 1) the certificate is valid according to the
> validation policy.
> 2) the certificate is not valid according to the validation
> policy.
> 3) the certificate is unknown to the validation server."
>
> Thus we remain at {valid, invalid, unknown} as primary initial
> states per list-based consensus.  Apologies for digging into
> this, but it has relevance to the design of state machines.
>
> Mike
>
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FKpBP03818 for ietf-pkix-bks; Mon, 15 Apr 2002 13:51:11 -0700 (PDT)
Received: from mail6.microsoft.com (mail6.microsoft.com [131.107.3.126]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FKpAm03814 for <[e-mail]>; Mon, 15 Apr 2002 13:51:10 -0700 (PDT)
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.201]) by mail6.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Apr 2002 13:51:08 -0700
Received: from 157.54.6.197 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Apr 2002 13:51:07 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Apr 2002 13:51:07 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Apr 2002 13:51:07 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Mon, 15 Apr 2002 13:47:23 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Open issue: DPV relay
Date: Mon, 15 Apr 2002 13:47:22 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Open issue: DPV relay
Thread-Index: AcHkunqPRvzcAPYoTmGV6FzPXVaoXQAAkl3A
From: "Trevor Freeman" <[e-mail]>
To: "Tim Polk" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 15 Apr 2002 20:47:23.0287 (UTC) FILETIME=[BE6DCA70:01C1E4BE]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3FKpAm03815
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 Tim,
I am in 100% agreement on assumption 1 and consider this one of the
cornerstones of DPV. Given assumption 1, I really don't care how many
servers do\do not support relay. We need a loop detection payload in a
request, but that is all. A client should have full confidence that all
it will get back from the DPV server is a yes or no answer. My biggest
compliant is around C. This is a critical difference between DPV and
LDAP referrals. It cannot simply return a referral because the client
may not trust the server referred to. If you go down the rat hole of
also returning a signed token to say if you trust me, you can also trust
him we should give ourselves a red card for client complexity. The whole
point of this work is that the client wants to say "I want a strait
yes\no answer to this question and don't bother me with details".
So no flammable comments here, just agreement.
Trevor

-----Original Message-----
From: Tim Polk [mailto:[e-mail]] 
Sent: Monday, April 15, 2002 1:08 PM
To: [e-mail]
Subject: RE: Open issue: DPV relay


Folks,

Here is my take on the relay/referral fracas, in two parts.

The first part addresses DPV relay includes (1) my assumptions about
DPV, 
(2) a little rationale, and (3) a proposed "solution" for DPV replay.
The 
second part amounts to four complaints about the impact of adding 
referrals, and my belief that it should not be supported.

                                                         Part 1: DPV
Relay 
Proposal

Assumption #1:

DPV relay is irrelevant to DPV clients.  They request answers from a 
trusted DPV server X, and server X MUST stand behind the response.
(That 
is, X can't say "I don't know, but Server Y says this certificate is 
okay."  It is up to X whether it can trust that answer.)

Assumption #2:

Many DPV servers will not relay requests.

Tim's Theory and what it is, too:

DPV servers that do not relay requests do not care if the request has
been 
relayed before they received it.  That only matters for loop 
detection/relay limits, etc.

DPV servers that do relay requests MUST be able to detect whether or not

the request has been previously relayed, and the request MUST have the 
complete list of servers that have received the request.

So, the conformance requirements:

Support for DPV relay is OPTIONAL for DPV servers.  DPV servers that do
not 
relay requests do not need to process or recognize the relay history 
information.

DPV servers that relay requests MUST satisfy all the following
conditions:
           (1) recognize and process relay history if present in a DPV
request;
           (2) able to generate a relay history including the complete
list 
of servers that have
           already forwarded this request; and
           (3) before relaying a request, the DPV server MUST verify
that 
the chosen DPV server
           has not already seen the message.  (That is loop detection 
occurs at the requester,
           not the recipient).

This proposal does not impact clients, it simplifies the most common DPV

servers, and it places *all* the burden on DPV servers that relay 
requests.  (As it should be, in my opinion.)

                                                      Part 2: DPV
Referrals

Complaint A

Referrals impact *all* DPV clients, significantly increasing their 
complexity.  Currently, the requirements indicate whether or not the
server 
could build a satisfactory path.  It seems to me that referrals force
all 
DPV clients to interpret a new class of answers: "I don't know but ask 
Server B".  (By itself, this isn't that compelling, I admit.  They get 
stronger, IMHO.)

Complaint B

One of the nice features of DPV is a single "proof" for archival.  This 
feature is broken by the introduction of DPV referrals.  Assume Alice is

trusts Server A, but she receives a referral indicating that Server A 
trusts Server B to validate this certificate.  Alice will need to
maintain 
both the referral from Server A and the answer from Server B.

Complaint C

Referrals for DPV are a very different animal than LDAP referrals.  Once

again, assume Alice is trusts Server A but she receives a referral 
indicating that Server A trusts Server B to validate this 
certificate.  Alice will need to authenticate the identity of Server B 
using information from Server A.  I think that means that Server A needs
to 
identify Server B by including Server B's public key in the referral.
If 
that is true, we just created a parallel key management infrastructure
and 
increased the complexity of our universe.

Complaint D

If LDAP is any indicator, nobody does referrals anyway.  Since DPV 
referrals will be significantly more complex, wouldn't it be better to
put 
the load on the server?

Alright, I'm off my soapbox.  Flame suit is zipped.  What do you all
think 
of these proposals?

Thanks,

Tim Polk





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FKLW603321 for ietf-pkix-bks; Mon, 15 Apr 2002 13:21:32 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FKLVm03317 for <[e-mail]>; Mon, 15 Apr 2002 13:21:31 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3FKLVPm028865; Mon, 15 Apr 2002 13:21:31 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>, <[e-mail]>
Subject: RE: A few comments re: dpv-dpd requirements
Date: Mon, 15 Apr 2002 13:18:42 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Trevor,

Looking at this from an abstract state machine perspective I see
a first, binary branching.  Upon receipt of a query, you have
either:

1. FAILURE:  Something's wrong here, can't proceed, raise an
exception, send back an unsigned response; or

2. PROCEED:  Understand the query, send to the backend for the
heavy lifting needed to produce a signed response.

My model is basically a frontend/backend architecture that
protects the backend (and, in the case of DPV, its signing key)
from DOS attacks, among other Internet-facing nastiness.

This model assume of course that when a query gets to the
trusted backend, a signature is required.  While we're not
lawyers here, it's arguable that a trusted entity's digitally
signed assertion that a certificate is "invalid" could be
significant in a dispute when in point of fact that trusted
backend couldn't arrive at conclusion due to lack of relevant
data.

Given that we're still into the early stages of defining and
using these things, I think it's better we enable a digitally
signed "unknown" to cover this instance.

Mike



Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com

> -----Original Message-----
> From: Trevor Freeman [mailto:[e-mail]]
> Sent: Friday, April 12, 2002 12:32 PM
> To: Michael Myers; [e-mail]
> Subject: RE: A few comments re: dpv-dpd requirements
>
>
> Hi Mike,
> I don't see how supporting an unknown response helps.
> Unknown sounds
> like a sub-status on the failure case. If I did have
> multiple SA with
> multiple DPV servers, anything other than a cert is
> valid response will
> cause me to go select the next DPV server and try
> again. If I only have
> one DPV server, then again, if it is not valid - it's invalid.
> Insufficient information to be able to be able to
> complete the request
> could be a sub-status reason returned in the DPV
> response, which allows
> me to audit or account for why the cert was not used,
> but the DPV server
> should only return one of two states.
>
> Trevor
>
> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Thursday, April 04, 2002 4:51 PM
> To: [e-mail]
> Subject: A few comments re: dpv-dpd requirements
>
>
> Russ, Denis:
>
> The state "unknown" is missing in Section 4, "Delegated Path
> Validation Protocol Requirements".  The -03 draft currently
> reads:
>
> "The DPV response MUST indicate one of the following
> two status
> alternatives:
>
> 1) the certificate is valid according to the
> validation policy.
> 2) the certificate is not valid according to the validation
> policy."
>
> I think -04 should read:
>
> "The DPV response MUST indicate one of the following three
> status alternatives:
>
> 1) the certificate is valid according to the
> validation policy.
> 2) the certificate is not valid according to the validation
> policy.
> 3) the certificate is unknown to the validation server."
>
> Thus we remain at {valid, invalid, unknown} as primary initial
> states per list-based consensus.  Apologies for digging into
> this, but it has relevance to the design of state machines.
>
> Mike
>
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FK9qH03075 for ietf-pkix-bks; Mon, 15 Apr 2002 13:09:52 -0700 (PDT)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FK9om03071 for <[e-mail]>; Mon, 15 Apr 2002 13:09:50 -0700 (PDT)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g3FK9pvV003137 for <[e-mail]>; Mon, 15 Apr 2002 16:09:51 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Mon, 15 Apr 2002 16:08:03 -0400
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: RE: Open issue: DPV relay
In-Reply-To: <[e-mail] .windeploy.ntdev.microsoft.com>
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>

Folks,

Here is my take on the relay/referral fracas, in two parts.

The first part addresses DPV relay includes (1) my assumptions about DPV, 
(2) a little rationale, and (3) a proposed "solution" for DPV replay.  The 
second part amounts to four complaints about the impact of adding 
referrals, and my belief that it should not be supported.

                                                         Part 1: DPV Relay 
Proposal

Assumption #1:

DPV relay is irrelevant to DPV clients.  They request answers from a 
trusted DPV server X, and server X MUST stand behind the response.  (That 
is, X can't say "I don't know, but Server Y says this certificate is 
okay."  It is up to X whether it can trust that answer.)

Assumption #2:

Many DPV servers will not relay requests.

Tim's Theory and what it is, too:

DPV servers that do not relay requests do not care if the request has been 
relayed before they received it.  That only matters for loop 
detection/relay limits, etc.

DPV servers that do relay requests MUST be able to detect whether or not 
the request has been previously relayed, and the request MUST have the 
complete list of servers that have received the request.

So, the conformance requirements:

Support for DPV relay is OPTIONAL for DPV servers.  DPV servers that do not 
relay requests do not need to process or recognize the relay history 
information.

DPV servers that relay requests MUST satisfy all the following conditions:
           (1) recognize and process relay history if present in a DPV request;
           (2) able to generate a relay history including the complete list 
of servers that have
           already forwarded this request; and
           (3) before relaying a request, the DPV server MUST verify that 
the chosen DPV server
           has not already seen the message.  (That is loop detection 
occurs at the requester,
           not the recipient).

This proposal does not impact clients, it simplifies the most common DPV 
servers, and it places *all* the burden on DPV servers that relay 
requests.  (As it should be, in my opinion.)

                                                      Part 2: DPV Referrals

Complaint A

Referrals impact *all* DPV clients, significantly increasing their 
complexity.  Currently, the requirements indicate whether or not the server 
could build a satisfactory path.  It seems to me that referrals force all 
DPV clients to interpret a new class of answers: "I don't know but ask 
Server B".  (By itself, this isn't that compelling, I admit.  They get 
stronger, IMHO.)

Complaint B

One of the nice features of DPV is a single "proof" for archival.  This 
feature is broken by the introduction of DPV referrals.  Assume Alice is 
trusts Server A, but she receives a referral indicating that Server A 
trusts Server B to validate this certificate.  Alice will need to maintain 
both the referral from Server A and the answer from Server B.

Complaint C

Referrals for DPV are a very different animal than LDAP referrals.  Once 
again, assume Alice is trusts Server A but she receives a referral 
indicating that Server A trusts Server B to validate this 
certificate.  Alice will need to authenticate the identity of Server B 
using information from Server A.  I think that means that Server A needs to 
identify Server B by including Server B's public key in the referral.  If 
that is true, we just created a parallel key management infrastructure and 
increased the complexity of our universe.

Complaint D

If LDAP is any indicator, nobody does referrals anyway.  Since DPV 
referrals will be significantly more complex, wouldn't it be better to put 
the load on the server?

Alright, I'm off my soapbox.  Flame suit is zipped.  What do you all think 
of these proposals?

Thanks,

Tim Polk





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FIcCa01012 for ietf-pkix-bks; Mon, 15 Apr 2002 11:38:12 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3FIcAm01007 for <[e-mail]>; Mon, 15 Apr 2002 11:38:10 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 Apr 2002 18:37:04 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA19287 for <[e-mail]>; Mon, 15 Apr 2002 14:36:54 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3FIcFi22210 for <[e-mail]>; Mon, 15 Apr 2002 14:38:15 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1SW09>; Mon, 15 Apr 2002 14:35:46 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.155]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1SW06; Mon, 15 Apr 2002 14:35:34 -0400
From: "Housley, Russ" <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Apr 2002 14:37:15 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
In-Reply-To: <[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>

Tom:

We are about to post an update to the draft.  Expect to see it in the next 
day or so.

I recognize the severe memory constraints of smartcards.

Russ


At 12:35 PM 4/10/2002 -0400, Tom Gindin wrote:

>       Russ:
>
>       Most of the following concerns the data structures of the current
>draft and of my last posting.  First, should the URI really be optional in
>cases where the binary component is a hash?  What good is the logotype
>field with a hash but no way to reference the image?  Second, I have
>reviewed draft-ietf-idn-uri-01.txt (by Martin Duerst) and it recommends
>that internationalized URI strings be converted to UTF-8 but then escaped
>using %HH, so UTF8String is unnecessary.  Therefore, we should simplify
>VerifiedReference as follows:
>       VerifiedReference ::= SEQUENCE {
>             hashAlgorithm     AlgorithmIdentifier,
>             dataHash    OCTET STRING,
>             uri          IA5String,
>       }
>
>       On a different topic, smart cards and other tokens have the least
>space of any place certificates are likely to be put, so if in-line
>logotypes are OK there they're OK anywhere.
>
>             Tom Gindin
>
>
>"Housley, Russ" <[e-mail]> on 04/08/2002 01:17:11 PM
>
>To:    Tom Gindin/Watson/IBM@IBMUS
>cc:    [e-mail]
>Subject:    Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
>
>
>Tom:
>
> >The following is just a personal opinion, but one based on fairly
> >well-understood trends.  I don't think that in-line logotypes are
>CURRENTLY
> >worth the space that they'd take up on a smart card, but I would guess
>that
> >they will be in two more smart-card generations and perhaps only one.
> >Given the amount of time between standard proposal and deployment, it's
>not
> >premature to standardize it.
>
>I tend to agree with your assessment of storage on smart cards.  Today, all
>
>of the certificates stored on one smart card are likely to be associated
>with one community.  Therefore, a logo will like appear on the smart card
>itself.
>
>Of course, there are other places that certificates and private keys are
>stored....
>
> >       However, I also have a question about the current data structure.
> >First, why is the URI optional (assuming that the only binary value is the
> >digest, as at present)?  Second, why would we not permit in-line logotypes
> >(in which case the URI is suppressed)?  This would require some edits to
> >LogotypeData, but nothing very difficult.  One possibility would be:
> >       LogotypeData ::= SEQUENCE {
> >           typeOfLogotype       TypeOfLogotype,
> >           hashAlgorithm        AlgorithmIdentifier,   -- might be
>OPTIONAL,
> >it's not meaningful for GIF's
> >           CHOICE  {
> >             logotypeDataHash     OCTET STRING,
> >       gif   [0]         IMPLICIT OCTET STRING
> >       },
> >           logotypeDataUri      IA5String OPTIONAL }
> >
> >       Another would be:
> >       LogotypeData ::= SEQUENCE {
> >           typeOfLogotype       TypeOfLogotype,
> >           CHOICE  {
> >             logotypeReference VerifiedReference,
> >       gif               OCTET STRING
> >       }
> >           }
> >       VerifiedReference ::= SEQUENCE {
> >             hashAlgorithm     AlgorithmIdentifier,
> >             dataHash    OCTET STRING,
> >             CHOICE      {
> >                   uri          IA5String,
> >                   intlUri           UTF8String  }
> >       }
> >
> >
> >       IMO VerifiedReference is a generally useful type, so its names do
>not
> >contain reference to logotypes.  My understanding of COMPONENTS OF, which
> >may be faulty, is that defining LogotypeData using COMPONENTS OF
> >VerifiedReference as an element of a CHOICE would not produce a useful
> >result because each of the elements of VerifiedReference would show up in
> >the CHOICE rather than merely hashAlgorithm going into the CHOICE with the
> >other fields added to LogotypeData's SEQUENCE.
>
>We are in the final steps of an updated I-D.  It addresses some of these
>issues, but not all.
>
>Is there a reference for UTF8String URI?
>
>Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FHsu529924 for ietf-pkix-bks; Mon, 15 Apr 2002 10:54:56 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FHstm29920 for <[e-mail]>; Mon, 15 Apr 2002 10:54:55 -0700 (PDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Apr 2002 10:54:48 -0700
Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Apr 2002 10:54:51 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 15 Apr 2002 10:54:51 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 15 Apr 2002 10:54:51 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Mon, 15 Apr 2002 10:51:20 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Open issue: DPV relay
Date: Mon, 15 Apr 2002 10:51:17 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Open issue: DPV relay
Thread-Index: AcHkhUXzzab0d+8lSVCefsr77LvyRwAHtY2w
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: "pkix" <[e-mail]>
X-OriginalArrivalTime: 15 Apr 2002 17:51:20.0004 (UTC) FILETIME=[2638B840:01C1E4A6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3FHstm29921
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>

Stephen,
There is obviously a relationship between implementation complexity and
protocol design. 
We are proposing a simple model where the client only has to consider
two responses from the DPV server, success or failure. Nothing in that
model excludes a DPV server for accessing or requesting any resource it
chooses. A DPV server can therefore act as a DPC client to other DPV
servers. What is not clear is why you seem to be so keen for the
original PDV client to do this work of contacting other DPV servers
instead of the client's original DPV server. If the DPV server truly
believes that an answer can be obtained from anther resource - why can't
it go get that answer for the client? What does the client know that the
server does not which would make that work? What piece of information is
missing from the DPV server that by returning a DPV referral to the
client, something will be accomplished that it could not do itself?

Trevor

-----Original Message-----
From: Stephen Farrell [mailto:[e-mail]] 
Sent: Monday, April 15, 2002 6:54 AM
To: Housley, Russ
Cc: pkix
Subject: Re: Open issue: DPV relay



Russ,

It seems that essentially you want to change "protocols MAY
re-direct/m-c" 
into "protocols MUST NOT re-direct/m-c", right?

- I fail to see how the MAY option adds complexity to clients since 
presumably the protocol you like that meets the requirements won't 
take up the "MAY" option and it won't be an issue for such clients.
Even if a conforming protocol does include re-direct, the text 
proposed ensures that there is mandatory impact on clients.

- Allowing re-direct/m-c does allow for some interesting server to
server interactions (in an IMO clean way) as previously discussed on 
the list. I see no reason to prohibit those or cause vendors to
re-invent or corrupt their use of a dpv protocol in order to 
support such cases.

- We can in any case judge relative compexity issues (only?) when 
concrete protocols are being compared against these requirements.

So, all in all, I see no reason to forbid protocols to support these
mechcnisms and some reasons to allow protocols to do so and no reason
at all to make a premature decision on this.

Regards,
Stephen.


"Housley, Russ" wrote:
> 
> I am strongly opposed to any requirements regarding re-direction
(a.k.a.
> referrals) or multicasting.  These services would add considerable
> complexity to the client side of the interface, making support for
> lightweight clients more difficult.
> 
> I have specific comments below...
> 
> >4.2. Relaying, re-direction and multicasting.
> >
> >Protocols designed to conform to these requirements MAY include
> >optional fields and extensions to support relaying, re-direction or
> >multicasting features. DPV clients are NOT REQUIRED to support relay,
> >re-direct or multicast, therefore clients or servers which do not
> >support such features still conform to the basic set of requirements.
> >DPV servers are NOT REQUIRED either to support relay, re-direct or
> >multicast.
> 
> I can support relaying (a.k.a. chaining) because it does not add
complexity
> to the client.
> 
> These are not protocol requirements.  They are implementation
requirements,
> and we are not defining a protocol in this document.
> 
> I prefer:
> 
> Protocols designed to satisfy these requirements MAY include
mechanisms for
> relaying.  However, such protocols MUST NOT include mechanisms for
> re-direction or multicasting.  Re-direction or multicasting mechanisms
> would add considerable complexity to the client side of the interface,
> making support for lightweight clients more difficult.
> 
> >1. Where relay or re-direct mechanisms are supported by a server
> >    a mechanism to detect loops or repetition SHOULD be supported.
> 
> I think that SHOULD ought to be changed to MUST.
> I think that re-direct ought to be deleted.
> 
> >2. Where a DPV server chooses to re-direct the request to another
> >    DPV server (i.e. chooses to provide a referral), a mechanism to
> >    provide information to be used for the re-direction SHOULD be
> >    supported. Note: In case where information to be used for the
> >    re-direction is sent back, clients are NOT REQUIRED to interpret
> >    that information (but MAY do so).
> 
> I think that this should be deleted.
> 
> >3. These features MAY be supported by using additional parameters
> >    in the request and/or response. Clients and servers that do not
> >    support such additional parameters MUST still be able to
use/offer
> >    DPV service. In this way, implementers need not understand the
> >    semantics of any such extensions.
> 
> I think that additional ought to be changed to optional.
> 
> Russ

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FHXgG29007 for ietf-pkix-bks; Mon, 15 Apr 2002 10:33:42 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3FHXem29003 for <[e-mail]>; Mon, 15 Apr 2002 10:33:40 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 Apr 2002 17:32:34 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA14108 for <[e-mail]>; Mon, 15 Apr 2002 13:32:23 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3FHXio15935 for <[e-mail]>; Mon, 15 Apr 2002 13:33:44 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1SWAB>; Mon, 15 Apr 2002 13:31:15 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.17]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1SV06; Mon, 15 Apr 2002 13:31:02 -0400
From: "Housley, Russ" <[e-mail]>
To: todd glassey <[e-mail]>
Cc: PKIX-IETF <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Apr 2002 13:31:44 -0400
Subject: Re: Open issue: DPV relay
In-Reply-To: <016201c1e49e$6d53aad0$020aff0a@tsg1>
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>

Todd:

You wrote:
>Doesn't chaining change the trust model since it will now not be clear at
>which link along the chain any trust-transaction went green or red. My take
>is that DPV still is far from being done since the use model is in conflict.

No.  The client gets a response from the server that it sent the request to 
in the first place.  The response is signed, and it can be validated with 
the expected trusted public key.  The fact that the DPV server used the 
resources of other DPV servers to fulfill the request is transparent to the 
client.  Of course, the first DPV server administrator must do some 
checking into the subsequent DPV servers in the chain before configuring it 
to forward requests.  That is, the subsequent DPV servers must meet the 
requirements of the validation policy.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FHQbs28854 for ietf-pkix-bks; Mon, 15 Apr 2002 10:26:37 -0700 (PDT)
Received: from gonzo.aus.rsa.com (mail.rsasecurity.com.au [203.46.112.10]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3FHQZm28847 for <[e-mail]>; Mon, 15 Apr 2002 10:26:35 -0700 (PDT)
Received: from checkpoint.local.aus.rsa.com by gonzo.aus.rsa.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 Apr 2002 17:26:57 UT
Received: from exaus01.local.aus.rsa.com (exaus01.local.aus.rsa.com [10.177.1.15]) by grover.local.aus.rsa.com (8.10.2/8.10.2) with ESMTP id g3FHVOq23666 for <[e-mail]>; Tue, 16 Apr 2002 03:31:24 +1000 (EST)
Received: by exaus01.local.aus.rsa.com with Internet Mail Service (5.5.2653.19) id <13VS1TY9>; Tue, 16 Apr 2002 03:27:01 +1000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.17]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1SV68; Mon, 15 Apr 2002 13:23:46 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Apr 2002 13:25:40 -0400
To: pkix <[e-mail]>
From: "Housley, Russ" <[e-mail]>
Subject: Re: Open issue: DPV relay
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>

All:

I remain strongly opposed to any requirements that impose re-direction 
(a.k.a. referrals) or multicasting on the client.  After a private e-mail 
exchange with Steve Farrell, I now realize that this is not the 
intention.  This intent was to permit the use of re-direction and 
multicasting between a collection of DPV servers.

I think that a bit of rationale will greatly help all readers.

I propose the following text.  Note that the rationale paragraph does not 
include any MUST, SHOULD, or MAY sentences.

Russ

= = = = = = = = = =

4.2. Relaying, re-direction and multicasting.

In some network environments, especially ones that include firewalls, a DPV 
server might not be able to obtain all of the information that it needs to 
process a request.  However, the DPV server might be configured to use the 
services of one or more other DPV servers to fulfill all requests.  In such 
cases, the client is unaware that the queried DPV server is using the 
services of other DPV servers.  In such environments, the client-queried 
DPV server acts as a DPV client to another DPV server.  Unlike the original 
client, the DPV server is expected to have moderate computing and memory 
resources, enabling the use of relay, re-direct or multicasting mechanisms. 
The requirements in this section support such mechanisms for DPV 
server-to-DPV server exchanges without imposing them on DPV client-to-DPV 
client exchanges.

Protocols designed to satisfy these requirements MAY include optional 
fields and/or extensions to support relaying, re-direction or multicasting. 
However, DPV clients are not expected to support relay, re-direct or 
multicast.  If the protocol supports such features, the protocol MUST 
include provisions for DPV clients and DPV servers that do not support such 
features, allowing them to conform to the basic set of requirements.

1. When a protocol provides a relay or re-direct mechanism, a companion 
mechanism to detect loops or repetition MUST also be provided.

2. When a protocol provides the capability for a DPV server to re-direct a 
request to another DPV server (i.e. the protocol chooses to provide a 
referral mechanism), a mechanism to provide information to be used for the 
re-direction SHOULD be supported.  If such re-direction information   is 
sent back to clients, then the protocol MUST allow conforming clients to 
ignore it.

3. Optional parameters in the protocol request and/or response MAY be 
provide support for relaying, re-direction or multicasting. DPV clients 
that ignore any such optional parameters MUST still be able to use the DPV 
service.  DPV servers that ignore any such optional parameters MUST MUST 
still be able to offer the DPV service, although they might not be able to 
overcome the limitations imposed by the network topology. In this way, 
protocol implementors need not understand the syntax or semantics of any 
such optional parameters.


Received: by above.proper.com (8.11.6/8.11.3) id g3FHJeG28691 for ietf-pkix-bks; Mon, 15 Apr 2002 10:19:40 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FHJdm28687 for <[e-mail]>; Mon, 15 Apr 2002 10:19:39 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3FHJVPm007810; Mon, 15 Apr 2002 10:19:32 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Two  more nits re: DPV/DPD rqmts
Date: Mon, 15 Apr 2002 10:16:44 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Denis,

I believe we are defining requirements that will be applied
against perhaps multiple technical proposals with a view towards
the WG selecting one.  It seems premature to assume the WG's
consensus on this point.

Mike


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Monday, April 15, 2002 10:05 AM
> To: Michael Myers
> Cc: [e-mail]
> Subject: Re: Two more nits re: DPV/DPD rqmts
>
>
> Mike,
>
> > Russ, Denis:
> >
> > Section 4, Delegated Path Validation Protocol Requirements
> > begins with:
> > "The Delegated Path Validation (DPV) protocol allows . . ."
> >
> > Similarly, Section 5 Delegated Path Discovery Protocol
> > Requirements begins with:
> > "The Delegated Path Discovery (DPD) protocol allows . . ."
> >
> > Since we're defining requirements and not protocols
> in this I-D,
> > you may wish to consider amending both these phrases towards
> > something along the lines of "DPV protocols allow . . ." and
> > "DPD protocols allow . . ." respectively.
>
> Are we really defining multiple protocols ?
> I was assuming that we would like only one.
> I prefer to keep the current text.
>
> Denis
>
> >
> > Mike
> >
> > Michael Myers
> > t: +415.819.1362
> > e: mailto:[e-mail]
> > w: http://www.traceroutesecurity.com
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FH5nu28241 for ietf-pkix-bks; Mon, 15 Apr 2002 10:05:49 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FH5mm28237 for <[e-mail]>; Mon, 15 Apr 2002 10:05:48 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA14090; Mon, 15 Apr 2002 19:08:25 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041519051345:395 ; Mon, 15 Apr 2002 19:05:13 +0200 
Message-ID: <[e-mail]>
Date: Mon, 15 Apr 2002 19:05:12 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: Two  more nits re: DPV/DPD rqmts
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 15/04/2002 19:05:13, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 15/04/2002 19:05:47, Serialize complete at 15/04/2002 19:05:47
Content-Transfer-Encoding: 7bit
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>

Mike,

> Russ, Denis:
> 
> Section 4, Delegated Path Validation Protocol Requirements
> begins with:
> "The Delegated Path Validation (DPV) protocol allows . . ."
> 
> Similarly, Section 5 Delegated Path Discovery Protocol
> Requirements begins with:
> "The Delegated Path Discovery (DPD) protocol allows . . ."
> 
> Since we're defining requirements and not protocols in this I-D,
> you may wish to consider amending both these phrases towards
> something along the lines of "DPV protocols allow . . ." and
> "DPD protocols allow . . ." respectively.

Are we really defining multiple protocols ? 
I was assuming that we would like only one. 
I prefer to keep the current text.

Denis

> 
> Mike
> 
> Michael Myers
> t: +415.819.1362
> e: mailto:[e-mail]
> w: http://www.traceroutesecurity.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FGvDG28079 for ietf-pkix-bks; Mon, 15 Apr 2002 09:57:13 -0700 (PDT)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FGvBm28075 for <[e-mail]>; Mon, 15 Apr 2002 09:57:11 -0700 (PDT)
Received: from tsg1 ([12.81.65.181]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020415165706.LYVK24238.mtiwmhc21.worldnet.att.net@tsg1>; Mon, 15 Apr 2002 16:57:06 +0000
Message-ID: <016201c1e49e$6d53aad0$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: "PKIX-IETF" <[e-mail]>
References: <[e-mail]>
Subject: Re: Open issue: DPV relay
Date: Mon, 15 Apr 2002 09:13:40 -0700
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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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 -
----- Original Message -----
From: "Housley, Russ" <[e-mail]>
To: "pkix" <[e-mail]>
Sent: Monday, April 15, 2002 6:26 AM
Subject: Re: Open issue: DPV relay


>
> I am strongly opposed to any requirements regarding re-direction (a.k.a.
> referrals) or multicasting.  These services would add considerable
> complexity to the client side of the interface, making support for
> lightweight clients more difficult.
>
> I have specific comments below...
>
>
> >4.2. Relaying, re-direction and multicasting.
> >
> >Protocols designed to conform to these requirements MAY include
> >optional fields and extensions to support relaying, re-direction or
> >multicasting features. DPV clients are NOT REQUIRED to support relay,
> >re-direct or multicast, therefore clients or servers which do not
> >support such features still conform to the basic set of requirements.
> >DPV servers are NOT REQUIRED either to support relay, re-direct or
> >multicast.
>
> I can support relaying (a.k.a. chaining) because it does not add
complexity
> to the client.

Doesn't chaining change the trust model since it will now not be clear at
which link along the chain any trust-transaction went green or red. My take
is that DPV still is far from being done since the use model is in conflict.



>
> These are not protocol requirements.  They are implementation
requirements,
> and we are not defining a protocol in this document.
>
> I prefer:
>
> Protocols designed to satisfy these requirements MAY include mechanisms
for
> relaying.  However, such protocols MUST NOT include mechanisms for
> re-direction or multicasting.  Re-direction or multicasting mechanisms
> would add considerable complexity to the client side of the interface,
> making support for lightweight clients more difficult.
>
> >1. Where relay or re-direct mechanisms are supported by a server
> >    a mechanism to detect loops or repetition SHOULD be supported.
>
> I think that SHOULD ought to be changed to MUST.
> I think that re-direct ought to be deleted.
>
> >2. Where a DPV server chooses to re-direct the request to another
> >    DPV server (i.e. chooses to provide a referral), a mechanism to
> >    provide information to be used for the re-direction SHOULD be
> >    supported. Note: In case where information to be used for the
> >    re-direction is sent back, clients are NOT REQUIRED to interpret
> >    that information (but MAY do so).
>
> I think that this should be deleted.
>
> >3. These features MAY be supported by using additional parameters
> >    in the request and/or response. Clients and servers that do not
> >    support such additional parameters MUST still be able to use/offer
> >    DPV service. In this way, implementers need not understand the
> >    semantics of any such extensions.
>
> I think that additional ought to be changed to optional.
>
> Russ
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FDsOY18046 for ietf-pkix-bks; Mon, 15 Apr 2002 06:54:24 -0700 (PDT)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FDsLm18038 for <[e-mail]>; Mon, 15 Apr 2002 06:54:21 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3FDsMb32236 for <[e-mail]>; Mon, 15 Apr 2002 14:54:22 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Mon, 15 Apr 2002 14:48:55 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA12988; Mon, 15 Apr 2002 14:54:19 +0100
Message-ID: <[e-mail]>
Date: Mon, 15 Apr 2002 14:54:29 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
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>

Russ,

It seems that essentially you want to change "protocols MAY re-direct/m-c" 
into "protocols MUST NOT re-direct/m-c", right?

- I fail to see how the MAY option adds complexity to clients since 
presumably the protocol you like that meets the requirements won't 
take up the "MAY" option and it won't be an issue for such clients.
Even if a conforming protocol does include re-direct, the text 
proposed ensures that there is mandatory impact on clients.

- Allowing re-direct/m-c does allow for some interesting server to
server interactions (in an IMO clean way) as previously discussed on 
the list. I see no reason to prohibit those or cause vendors to
re-invent or corrupt their use of a dpv protocol in order to 
support such cases.

- We can in any case judge relative compexity issues (only?) when 
concrete protocols are being compared against these requirements.

So, all in all, I see no reason to forbid protocols to support these
mechcnisms and some reasons to allow protocols to do so and no reason
at all to make a premature decision on this.

Regards,
Stephen.


"Housley, Russ" wrote:
> 
> I am strongly opposed to any requirements regarding re-direction (a.k.a.
> referrals) or multicasting.  These services would add considerable
> complexity to the client side of the interface, making support for
> lightweight clients more difficult.
> 
> I have specific comments below...
> 
> >4.2. Relaying, re-direction and multicasting.
> >
> >Protocols designed to conform to these requirements MAY include
> >optional fields and extensions to support relaying, re-direction or
> >multicasting features. DPV clients are NOT REQUIRED to support relay,
> >re-direct or multicast, therefore clients or servers which do not
> >support such features still conform to the basic set of requirements.
> >DPV servers are NOT REQUIRED either to support relay, re-direct or
> >multicast.
> 
> I can support relaying (a.k.a. chaining) because it does not add complexity
> to the client.
> 
> These are not protocol requirements.  They are implementation requirements,
> and we are not defining a protocol in this document.
> 
> I prefer:
> 
> Protocols designed to satisfy these requirements MAY include mechanisms for
> relaying.  However, such protocols MUST NOT include mechanisms for
> re-direction or multicasting.  Re-direction or multicasting mechanisms
> would add considerable complexity to the client side of the interface,
> making support for lightweight clients more difficult.
> 
> >1. Where relay or re-direct mechanisms are supported by a server
> >    a mechanism to detect loops or repetition SHOULD be supported.
> 
> I think that SHOULD ought to be changed to MUST.
> I think that re-direct ought to be deleted.
> 
> >2. Where a DPV server chooses to re-direct the request to another
> >    DPV server (i.e. chooses to provide a referral), a mechanism to
> >    provide information to be used for the re-direction SHOULD be
> >    supported. Note: In case where information to be used for the
> >    re-direction is sent back, clients are NOT REQUIRED to interpret
> >    that information (but MAY do so).
> 
> I think that this should be deleted.
> 
> >3. These features MAY be supported by using additional parameters
> >    in the request and/or response. Clients and servers that do not
> >    support such additional parameters MUST still be able to use/offer
> >    DPV service. In this way, implementers need not understand the
> >    semantics of any such extensions.
> 
> I think that additional ought to be changed to optional.
> 
> Russ

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FDQdJ17428 for ietf-pkix-bks; Mon, 15 Apr 2002 06:26:39 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3FDQbm17424 for <[e-mail]>; Mon, 15 Apr 2002 06:26:37 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 Apr 2002 13:25:30 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA19447 for <[e-mail]>; Mon, 15 Apr 2002 09:25:20 -0400 (EDT)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3FDQfe16094 for <[e-mail]>; Mon, 15 Apr 2002 09:26:41 -0400 (EDT)
Received: by exeu00.eu.rsa.net with Internet Mail Service (5.5.2653.19) id <2KMJW9Q4>; Mon, 15 Apr 2002 14:26:54 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.124]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1SPR6; Mon, 15 Apr 2002 09:24:00 -0400
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Apr 2002 09:26:22 -0400
To: pkix <[e-mail]>
From: "Housley, Russ" <[e-mail]>
Subject: Re: Open issue: DPV relay
In-Reply-To: <[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 am strongly opposed to any requirements regarding re-direction (a.k.a. 
referrals) or multicasting.  These services would add considerable 
complexity to the client side of the interface, making support for 
lightweight clients more difficult.

I have specific comments below...


>4.2. Relaying, re-direction and multicasting.
>
>Protocols designed to conform to these requirements MAY include
>optional fields and extensions to support relaying, re-direction or
>multicasting features. DPV clients are NOT REQUIRED to support relay,
>re-direct or multicast, therefore clients or servers which do not
>support such features still conform to the basic set of requirements.
>DPV servers are NOT REQUIRED either to support relay, re-direct or
>multicast.

I can support relaying (a.k.a. chaining) because it does not add complexity 
to the client.

These are not protocol requirements.  They are implementation requirements, 
and we are not defining a protocol in this document.

I prefer:

Protocols designed to satisfy these requirements MAY include mechanisms for 
relaying.  However, such protocols MUST NOT include mechanisms for 
re-direction or multicasting.  Re-direction or multicasting mechanisms 
would add considerable complexity to the client side of the interface, 
making support for lightweight clients more difficult.

>1. Where relay or re-direct mechanisms are supported by a server
>    a mechanism to detect loops or repetition SHOULD be supported.

I think that SHOULD ought to be changed to MUST.
I think that re-direct ought to be deleted.

>2. Where a DPV server chooses to re-direct the request to another
>    DPV server (i.e. chooses to provide a referral), a mechanism to
>    provide information to be used for the re-direction SHOULD be
>    supported. Note: In case where information to be used for the
>    re-direction is sent back, clients are NOT REQUIRED to interpret
>    that information (but MAY do so).

I think that this should be deleted.

>3. These features MAY be supported by using additional parameters
>    in the request and/or response. Clients and servers that do not
>    support such additional parameters MUST still be able to use/offer
>    DPV service. In this way, implementers need not understand the
>    semantics of any such extensions.

I think that additional ought to be changed to optional.

Russ



Received: by above.proper.com (8.11.6/8.11.3) id g3FDCcS17022 for ietf-pkix-bks; Mon, 15 Apr 2002 06:12:38 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3FDCYm17018 for <[e-mail]>; Mon, 15 Apr 2002 06:12:35 -0700 (PDT)
Received: from no.name.available by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 Apr 2002 13:11:27 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA18008 for <[e-mail]>; Mon, 15 Apr 2002 09:11:17 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3FDCbm14380 for <[e-mail]>; Mon, 15 Apr 2002 09:12:37 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1SPKS>; Mon, 15 Apr 2002 09:10:09 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.124]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1SPKP; Mon, 15 Apr 2002 09:10:04 -0400
From: "Housley, Russ" <[e-mail]>
To: osamafarook <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 15 Apr 2002 09:12:19 -0400
Subject: Re: Where does the certificate go
In-Reply-To: <[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>

This depends on the environment that you are working in and the protocol 
that you are using.  If there is an RA involved, the certificate will 
usually be sent to the RA and be posted in the repository.  If there is not 
an RA involved, then the certificate will usually be sent to the 
certificate holder and posted in the repository.

Russ

At 04:39 PM 4/14/2002 +0200, osamafarook wrote:

>Welcome
>I work in a graduation project " Building CA server"
>I want to know Where does the certificate go after it issued  by CA server?
>Is it being sent to user as a file?
>or what?
>Thank you.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3FCOfB15793 for ietf-pkix-bks; Mon, 15 Apr 2002 05:24:41 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3FCOdm15788 for <[e-mail]>; Mon, 15 Apr 2002 05:24:39 -0700 (PDT)
Received: from tsg1 ([12.81.65.181]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020415122421.IKNF28245.mtiwmhc23.worldnet.att.net@tsg1>; Mon, 15 Apr 2002 12:24:21 +0000
Message-ID: <005301c1e478$58985030$020aff0a@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Open issue: DPV relay
Date: Mon, 15 Apr 2002 05:13:32 -0700
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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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>

Gentlemen -See inline below...

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, April 15, 2002 12:49 AM
Subject: Re: Open issue: DPV relay


>
> Peter (Sylvester),
>
> I agree that there is a difference between an authorized responder
> and a server trusted under a given policy.
>
> So in order to solve this last issue, I propose to replace the current
text
> which is:
>
> The DPV request MUST allow the client to request that the response
> include the certification path and revocation status information used
> by the DPV server to process the request. When requested, the DPV
> server MUST include the certification path and revocation status
> information in the response when the certificate is valid according to
> the validation policy. However, the server MAY omit the certification
> path and revocation status information when the certificate is invalid.
>
> by the following text:
>
> The DPV request MUST allow the client to request the response to
> include either the certification path and the revocation status
> information from authorised CRL issuers or authorised OCSP responders,
> or a DPV response from a DPV server that is trusted under the
> validation policy. This information may allow other clients, not
> trusting the requested DPV server to be confident that the certificate
> validation has correctly be performed.

Denis - Peter -

I disagree with this next paragraph -

> When the certificate is valid
> according to the validation policy, the server MUST, upon request,
> include that information in the response. However, the server MAY
> omit that information when the certificate is invalid or when it
> cannot determine the validity.

I cant think of a commercial process when the RP would want the DPV to make
ANY decisions regarding what to include or not to as part of the data gram
and this is important to the bigger picture. The key-concept for audit-model
stability is to to keep the response types identical (from yes to no
answers) and have the content be reflective of that yes or a no answer
rather than the structure of the message envelope itself changing from
positive to negative states.

This is one of the ongoing problems with many PKI protocols. It is
technologically slick if the message types are different for a YES and NO
answer but from a commercial use standpoint the exact opposite is true... in
fact many PKI protocls have too much diversity and divergences in the
srtructure of YES messages relative to their NO messages. In fact from a
Legalese standpoint, it is very important that the record reflect why you
said "NO" too so the datapoints used to signify this are equally critical to
the yes or no content they reinforce.

>
> Regards,
>
> Denis
>
>




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3F7nqA07910 for ietf-pkix-bks; Mon, 15 Apr 2002 00:49:52 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3F7nom07905 for <[e-mail]>; Mon, 15 Apr 2002 00:49:50 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA09662; Mon, 15 Apr 2002 09:52:27 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041509491492:289 ; Mon, 15 Apr 2002 09:49:14 +0200 
Message-ID: <[e-mail]>
Date: Mon, 15 Apr 2002 09:49:21 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 15/04/2002 09:49:14, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 15/04/2002 09:49:47, Serialize complete at 15/04/2002 09:49:47
Content-Transfer-Encoding: 7bit
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>

Peter (Sylvester),

I agree that there is a difference between an authorized responder 
and a server trusted under a given policy. 

So in order to solve this last issue, I propose to replace the current text
which is:

The DPV request MUST allow the client to request that the response 
include the certification path and revocation status information used 
by the DPV server to process the request. When requested, the DPV 
server MUST include the certification path and revocation status 
information in the response when the certificate is valid according to 
the validation policy. However, the server MAY omit the certification 
path and revocation status information when the certificate is invalid.

by the following text:

The DPV request MUST allow the client to request the response to 
include either the certification path and the revocation status 
information from authorised CRL issuers or authorised OCSP responders, 
or a DPV response from a DPV server that is trusted under the 
validation policy. This information may allow other clients, not 
trusting the requested DPV server to be confident that the certificate 
validation has correctly be performed. When the certificate is valid 
according to the validation policy, the server MUST, upon request, 
include that information in the response. However, the server MAY 
omit that information when the certificate is invalid or when it 
cannot determine the validity.

Regards,

Denis

 
> Peter,
> 
> I am a little bit confused that you replied to a message sent
> by Denis as a repl to me.
> 
> >
> > Peter.
> >
> > OCSP has always envisioned and practised a relying party
> > authorizing an OCSP Responder: no CA/AA involvement
> > is required and no certificate need be issued, in this
> > case.
> 
> There seems to be a confusion about the difference of
> a 'Trusted Responder' and an 'Authorised Responder'
> 
>    All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
> 
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- 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
> 
> In 4.2.2.2 the text
> 
>    The key that signs a certificate's status information need not be the
>    same key that signed the certificate. It is necessary however to
>    ensure that the entity signing this information is authorized to do
>    so.  Therefore, a certificate's issuer MUST either sign the OCSP
>    responses itself or it MUST explicitly designate this authority to
>    another entity.  OCSP signing delegation SHALL be designated by the
>    inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
>    extension included in the OCSP response signer's certificate.  This
>    certificate MUST be issued directly by the CA that issued the
>    certificate in question.
> 
>    id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
> 
> seem to indicate that two of the three cases are AUTHORISED responders.
> The next sentences say:
> 
>    Systems or applications that rely on OCSP responses MUST be capable
>    of detecting and enforcing use of the id-ad-ocspSigning value as
>    described above. They MAY provide a means of locally configuring one
>    or more OCSP signing authorities, and specifying the set of CAs for
>    which each signing authority is trusted. They MUST reject the
>    response if the certificate required to validate the signature on the
>    response fails to meet at least one of the following criteria:
> 
>    1. Matches a local configuration of OCSP signing authority for the
>    certificate in question; or
> 
>    2. Is the certificate of the CA that issued the certificate in
>    question; or
> 
>    3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
>    extension and is issued by the CA that issued the certificate in
>    question."
> 
> which seems to explain an additional,thus three possible conditions for which
> a response can be excepted. But what exactly means 1) ?
> 
> what means 'locally configuring one or more OCSP signing authorities'?
> 
> Does it mean that this matched the second case in the introduction,
> which IMO is that a relying party that can operate its own OCSP
> service for its own benefit, just as a front end to a collection
> of some CRLs for example.
> 
> Or, the text says TWO things:
> 
> How a CA can delegate OCSP operations resulting in 2 modes
> to accept responses by a relying party, and a third mode indicating
> how a relying party can have an additional mode to trust someone
> who is NOT in one of the two other cases, and may have no
> relationship with the CA or else.
> 
> > Carry over this conformance requirement from OCSP to DPV:
> >
> > An OCSP client (which includes a client that is a DPV server)
> > must potentially accept an OCSP response according to ALL the
> > rules of 4.2.2.2. There are three cases: (1) (2) and (3).
> Do You mean ALL (conditions met at the same time) or *ANY*
> (of them may be true). ?
> 
> >
> > Lets remember, a relying party can operate its
> > own DPV service for its own benefit. The relying party
> > needs no authority from a CA to do so. The operator
> > of a DPV server is not necessarily a TTP, and
> > need have no relationship to the cert or CRL
> > issuer, other than that of performing
> > relying party obligations or (less stringent) user
> > obligations according to the CP.
> >
> In your paragraph, if you replace DPV by OCSP, I don't see
> why this would be different if my interpretation of the
> three cases are correct.
> 
> Or, for OCSP the condition
> 
>    1. Matches a local configuration of OCSP signing authority for the
>    certificate in question; or
> 
> doesn't it mean that some other relying party who will inspect the
> response will not necessarily have the same configuration?
> 
> Peter S


Received: by above.proper.com (8.11.6/8.11.3) id g3F2elm02149 for ietf-pkix-bks; Sun, 14 Apr 2002 19:40:47 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3F2ekm02145 for <[e-mail]>; Sun, 14 Apr 2002 19:40:46 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3F2efPm017678; Sun, 14 Apr 2002 19:40:42 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "pkix" <[e-mail]>
Subject: RE: Open issue: DPV relay
Date: Sun, 14 Apr 2002 19:37:55 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Denis, Stephen:

Good work.  I agree with the text as submitted.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
> Sent: Friday, April 12, 2002 7:46 AM
> To: pkix
> Subject: Re: Open issue: DPV relay
>
>
>
>
> Thanks to numerous private e-mail exchanges with
> Stephen Farrell
> (thanks Stephen !) we both came to an agreement on
> additional text
> to address relaying, re-direction and multicasting.
>
> So I submit this text to the list.
>
> Denis
>
> ======================================================
> ==============
>
> 4.2. Relaying, re-direction and multicasting.
>
> Protocols designed to conform to these requirements
> MAY include
> optional fields and extensions to support relaying,
> re-direction or
> multicasting features. DPV clients are NOT REQUIRED
> to support relay,
> re-direct or multicast, therefore clients or servers
> which do not
> support such features still conform to the basic set
> of requirements.
> DPV servers are NOT REQUIRED either to support relay,
> re-direct or
> multicast.
>
> 1. Where relay or re-direct mechanisms are supported
> by a server
>    a mechanism to detect loops or repetition SHOULD
> be supported.
>
> 2. Where a DPV server chooses to re-direct the
> request to another
>    DPV server (i.e. chooses to provide a referral), a
> mechanism to
>    provide information to be used for the
> re-direction SHOULD be
>    supported. Note: In case where information to be
> used for the
>    re-direction is sent back, clients are NOT
> REQUIRED to interpret
>    that information (but MAY do so).
>
> 3. These features MAY be supported by using
> additional parameters
>    in the request and/or response. Clients and
> servers that do not
>    support such additional parameters MUST still be
> able to use/offer
>    DPV service. In this way, implementers need not
> understand the
>    semantics of any such extensions.
>
> ======================================================
> ==============
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3EKpQk23907 for ietf-pkix-bks; Sun, 14 Apr 2002 13:51:26 -0700 (PDT)
Received: from nymelsmtp.internet.ny.fdms.firstdata.com ([204.124.248.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3EKpOm23903 for <[e-mail]>; Sun, 14 Apr 2002 13:51:24 -0700 (PDT)
Subject: Re: Where does the certificate go
To: "osamafarook" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.5  September 22, 2000
Message-ID: <[e-mail]>
From: [e-mail]
Date: Sun, 14 Apr 2002 14:50:05 -0600
X-MIMETrack: Serialize by Router on NYMELSMTP/NY/FDMS/FDC(Release 5.0.8 |June 18, 2001) at 04/14/2002 04:48:39 PM
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>

the RA/CA authority ... typically saves the original of the certificate it
has created in a local administration file. Frequently then a CA  either 1)
mails a copy of the certificate to the requester ... as an email attachment
or 2) mails the requester a notification ... giving a URL where the
requester can retrieve the a copy of the certificate.

certificates may also be compressed especially in the case where a RA/CA is
also the relying party (except for the SSL domain name certificates ... a
large percentage of the certificates issued are by relying parties).

For relying party certificates, a certificate can frequently be compressed
to zero bytes before sending to the requesting party.

random relying-party postings ....
http://www.garlic.com/~lynn/aadsm8.htm#softpki4 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki8 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki9 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki11 Software for PKI
http://www.garlic.com/~lynn/aadsm8.htm#softpki19 DNSSEC (RE: Software for
PKI)
http://www.garlic.com/~lynn/aadsm9.htm#softpki23 Software for PKI
http://www.garlic.com/~lynn/aadsm9.htm#carnivore Shades of FV's Nathaniel
Borenstein: Carnivore's "Magic Lantern"
http://www.garlic.com/~lynn/aadsm9.htm#pkcs12d A PKI Question: PKCS11->
PKCS12
http://www.garlic.com/~lynn/aadsm9.htm#cfppki CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki5 CFP: PKI research workshop
http://www.garlic.com/~lynn/aadsm9.htm#cfppki9 CFP: PKI research workshop
http://www.garlic.com/~lynn/2000.html#36 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#40 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000.html#41 "Trusted" CA - Oxymoron?
http://www.garlic.com/~lynn/2000b.html#40 general questions on SSL
certificates
http://www.garlic.com/~lynn/2000b.html#93 Question regarding authentication
implementation
http://www.garlic.com/~lynn/2000e.html#41 Why trust root CAs ?
http://www.garlic.com/~lynn/2000f.html#15 Why trust root CAs ?
http://www.garlic.com/~lynn/2001c.html#56 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#57 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#58 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#60 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#72 PKI and Non-repudiation
practicalities
http://www.garlic.com/~lynn/2001c.html#79 Q: ANSI X9.68 certificate format
standard
http://www.garlic.com/~lynn/2001d.html#7 Invalid certificate on 'security'
site.
http://www.garlic.com/~lynn/2001d.html#20 What is PKI?
http://www.garlic.com/~lynn/2001e.html#35 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001e.html#46 Can I create my own SSL key?
http://www.garlic.com/~lynn/2001f.html#77 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001f.html#79 FREE X.509 Certificates
http://www.garlic.com/~lynn/2001g.html#40 Self-Signed Certificate
http://www.garlic.com/~lynn/2001g.html#64 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#65 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001g.html#68 PKI/Digital signature doesn't
work
http://www.garlic.com/~lynn/2001h.html#0 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#3 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001h.html#7 PKI/Digital signature doesn't work
http://www.garlic.com/~lynn/2001i.html#16 Net banking, is it safe???
http://www.garlic.com/~lynn/2001k.html#0 Are client certificates really
secure?
http://www.garlic.com/~lynn/2001n.html#57 Certificate Authentication Issues
in IE and Verisign
http://www.garlic.com/~lynn/2001n.html#73 A PKI question and an  answer
http://www.garlic.com/~lynn/2002d.html#39 PKI Implementation
http://www.garlic.com/~lynn/2002e.html#49 PKI and Relying Parties
http://www.garlic.com/~lynn/2002e.html#56 PKI and Relying Parties
http://www.garlic.com/~lynn/2002e.html#72 Digital certificate varification




                                                                                      
                         "osamafarook"                                                
                    <osamafarook@hotma     To:      <[e-mail]>               
                               il.com>     cc:                                        
                              Sent by:     Subject:      Where does the certificate   
                    owner-ietf-pkix@ma        go                                      
                            il.imc.org                                                
                                                                                      
                                                                                      
                      04/14/2002 08:39                                                
                                    AM                                                
                                                                                      
                                                                                      





Welcome
I work in a graduation project " Building CA server"
I want to know Where does the certificate go after it issued  by CA server?
Is it being sent to user as a file?
or what?
Thank you.






Received: by above.proper.com (8.11.6/8.11.3) id g3EEpEc06368 for ietf-pkix-bks; Sun, 14 Apr 2002 07:51:14 -0700 (PDT)
Received: from hotmail.com (dav74.sea1.hotmail.com [207.68.162.209]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3EEpDm06364 for <[e-mail]>; Sun, 14 Apr 2002 07:51:13 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 14 Apr 2002 07:39:21 -0700
X-Originating-IP: [213.158.176.172]
From: "osamafarook" <[e-mail]>
To: <[e-mail]>
Subject: Where does the certificate go
Date: Sun, 14 Apr 2002 16:39:18 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1256"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 14 Apr 2002 14:39:21.0897 (UTC) FILETIME=[2A7B5190:01C1E3C2]
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>

Welcome 
I work in a graduation project " Building CA server"
I want to know Where does the certificate go after it issued  by CA server?
Is it being sent to user as a file?
or what?
Thank you.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3D3T1Q01970 for ietf-pkix-bks; Fri, 12 Apr 2002 20:29:01 -0700 (PDT)
Received: from zetnet.co.uk ([e-mail] [194.247.47.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3D3T0m01966 for <[e-mail]>; Fri, 12 Apr 2002 20:29:00 -0700 (PDT)
Received: from zetnet.co.uk (bts-0061.dialup.zetnet.co.uk [194.247.48.61]) by zetnet.co.uk (8.11.3/8.11.3/Debian 8.11.2-1) with ESMTP id g3D3T1I02507; Sat, 13 Apr 2002 04:29:01 +0100
Message-ID: <[e-mail]>
Date: Sat, 13 Apr 2002 04:16:42 +0000
From: David Hopwood <[e-mail]>
Reply-To: [e-mail], [e-mail], [e-mail]
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en-GB,en,fr-FR,fr,de-DE,de,ru
MIME-Version: 1.0
To: [e-mail], [e-mail]
Subject: Proposed MIME type application/pkix-pkipath
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-----

(Please keep replies posted to both <[e-mail]> and
<[e-mail]>.)

The Transport Layer Security WG has developed a draft for a set of
extensions to TLS. One of the extensions, "client_certificate_url",
is designed to allow TLS clients to specify client certificate chains
that should be retrieved from an URL, instead of the chain being sent
in the TLS protocol (so that memory-constrained clients do not have
to store the whole chain). Therefore a MIME type needs to be registered
for transferring the cert chain by HTTP, etc.

The ASN.1 type proposed to be used is PkiPath, as defined in X.509 (2000)
Technical Corrigendum 1, which is equivalent to "SEQUENCE OF Certificate".
(Other possible ASN.1 types such as CertificationPath and
ForwardCertificationPath were considered to be unnecessarily
complicated for this application, and CertificateSet from PKCS#7 is
not used because it defines a SET rather than a SEQUENCE, making
validation more difficult.)

A copy of X.509 (2000) TC 1 is at:
<ftp://ftp.bull.com/pub/OSIdirectory/DefectResolution/TechnicalCorrigenda/ApprovedTechnicalCorrigendaToX.509/8|X.509-TC1(4th).pdf>.

The current version of the TLS extensions draft is
<http://www.rfc-editor.org/internet-drafts/draft-ietf-tls-extensions-03.txt>.
It will be modified to include an IANA Considerations section with the
MIME template given below, and to specify use of "application/pkix-pkipath"
instead of "application/pkcs7-mime". <draft-ietf-tls-extensions-04.txt>
will then be taken to Last Call, since all issues other than this one have
already been resolved.

Here is the draft registration template, following RFC 2048. It is
intended to be consistent with application/pkix-{cert,crl} as defined
in RFC 2585.


To: [e-mail]
Subject: Registration of MIME media type application/pkix-pkipath

MIME media type name: application

MIME subtype name: pkix-pkipath

Required parameters: none

Optional parameters: version (default value is "1")

Encoding considerations:
   This is the DER-encoded ASN.1 type PkiPath, which is defined in
   [X509-TC1] as follows:

      PkiPath ::= SEQUENCE OF Certificate

      PkiPath is used to represent a certification path. Within the
      sequence, the order of certificates is such that the subject of
      the first certificate is the issuer of the second certificate,
      etc.

   All Certificates MUST conform to [PKIX] (an update to [PKIX] is
   in preparation, and should be followed when it is published).
   DER (as opposed to BER) encoding MUST be used. If this type is
   sent over a 7-bit transport, base64 encoding SHOULD be used.

Security considerations:
   The security considerations of [X509-2000] and [PKIX] (or any
   update to it) apply, as well as those of any protocol that uses
   this type (e.g. TLS).

   Note that this type only specifies a certificate chain that can
   be assessed for validity according to the relying party's existing
   configuration of trusted CAs; it is not intended to be used to
   specify any change to that configuration.

Interoperability considerations:
   No specific interoperability problems are known with this type, but
   for recommendations relating to X.509 certificates in general, see
   [PKIX].

Published specification: <draft-ietf-tls-extensions-04.txt>,
   [X509-TC1], and [PKIX].

Applications which use this media type: TLS. It may also be used by
   other protocols, or for general interchange of PKIX certificate
   chains.

Additional information:
   Magic number(s): DER-encoded ASN.1 can be easily recognised (further
      parsing is required to distinguish from other ASN.1 types)
   File extension(s): .pkipath
   Macintosh File Type Code(s): not specified

Person & email address to contact for further information:
   Magnus Nystrom <[e-mail]>

Intended usage: COMMON

Author/Change controller:
   Magnus Nystrom <[e-mail]>

References:
   [PKIX]      R. Housley, W. Ford, W. Polk, and D. Solo, "Internet
               Public Key Infrastructure: Part I: X.509 Certificate and CRL
               Profile", IETF RFC 2459, January 1999.

   [X509-2000] ITU-T RECOMMENDATION X.509 (2000) | ISO/IEC 9594-8:2001.

   [X509-TC1]  Technical Corrigendum 1 (DTC 2) to
               ITU-T RECOMMENDATION X.509 (2000) | ISO/IEC 9594-8:2001.

- -- 
David Hopwood <[e-mail]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBPLevKjkCAxeYt5gVAQECpAgAr5brsVe2Qqs/HGGxtfvAa/DWnW+OqeSb
qI27EMBS+Y+1lMsqObHULr67PoOB6jzBPHUfwqaA6iBzsKbh+95ZyRieuaXoaxV1
MNI70kgky43lhHR+rkP0r51mzUpzFFrXHNEIA94TEqFHLNOW7VF088MJEnGtbK0I
1mWqiJCB6jN7CkaOunEtsbmhZQ5hjkgw75JhypCWNnNLgFWSDyQyHFW3zn/XZnZf
4xGlrbN+rxwJyG+Orga23mpIo04VMnI0mTGsyOhAM5SdUbTc/3RQ4yqJMI4+oePf
3EPeDQTLO9BTHhSx4fcXeST6zjDWPWfMSHNW6brXGddQyNZ8nB7BJA==
=UXVS
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3CJZJR17348 for ietf-pkix-bks; Fri, 12 Apr 2002 12:35:19 -0700 (PDT)
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3CJZIm17343 for <[e-mail]>; Fri, 12 Apr 2002 12:35:18 -0700 (PDT)
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.154]) by mail4.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 12:35:15 -0700
Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Apr 2002 12:35:15 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 12:35:15 -0700
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Fri, 12 Apr 2002 12:35:14 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Fri, 12 Apr 2002 12:31:44 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: A few comments re: dpv-dpd requirements
Date: Fri, 12 Apr 2002 12:31:43 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: A few comments re: dpv-dpd requirements
Thread-Index: AcHcPPBMirus8SdtSqyL+Z/DFkJmbQGG0Vdg
From: "Trevor Freeman" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 12 Apr 2002 19:31:44.0062 (UTC) FILETIME=[AD99C5E0:01C1E258]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3CJZIm17345
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 Mike,
I don't see how supporting an unknown response helps. Unknown sounds
like a sub-status on the failure case. If I did have multiple SA with
multiple DPV servers, anything other than a cert is valid response will
cause me to go select the next DPV server and try again. If I only have
one DPV server, then again, if it is not valid - it's invalid.
Insufficient information to be able to be able to complete the request
could be a sub-status reason returned in the DPV response, which allows
me to audit or account for why the cert was not used, but the DPV server
should only return one of two states.

Trevor

-----Original Message-----
From: Michael Myers [mailto:[e-mail]] 
Sent: Thursday, April 04, 2002 4:51 PM
To: [e-mail]
Subject: A few comments re: dpv-dpd requirements


Russ, Denis:

The state "unknown" is missing in Section 4, "Delegated Path
Validation Protocol Requirements".  The -03 draft currently
reads:

"The DPV response MUST indicate one of the following two status
alternatives:

1) the certificate is valid according to the validation policy.
2) the certificate is not valid according to the validation
policy."

I think -04 should read:

"The DPV response MUST indicate one of the following three
status alternatives:

1) the certificate is valid according to the validation policy.
2) the certificate is not valid according to the validation
policy.
3) the certificate is unknown to the validation server."

Thus we remain at {valid, invalid, unknown} as primary initial
states per list-based consensus.  Apologies for digging into
this, but it has relevance to the design of state machines.

Mike




Received: by above.proper.com (8.11.6/8.11.3) id g3CHKnF11701 for ietf-pkix-bks; Fri, 12 Apr 2002 10:20:49 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3CHKmm11696 for <[e-mail]>; Fri, 12 Apr 2002 10:20:48 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 12 Apr 2002 10:18:11 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Fri, 12 Apr 2002 10:18:11 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <2X07KTDD>; Fri, 12 Apr 2002 10:20:23 -0700
Content-return: allowed
Date: Fri, 12 Apr 2002 10:20:22 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Open issue: DPV relay
To: pkix <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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 Denis,
    This sounds good to me.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Friday, April 12, 2002 7:46 AM
> To: pkix
> Subject: Re: Open issue: DPV relay
> 
> 
> 
> 
> Thanks to numerous private e-mail exchanges with Stephen Farrell 
> (thanks Stephen !) we both came to an agreement on additional text 
> to address relaying, re-direction and multicasting.
> 
> So I submit this text to the list.
> 
> Denis
> 
> ====================================================================
> 
> 4.2. Relaying, re-direction and multicasting.
> 
> Protocols designed to conform to these requirements MAY include 
> optional fields and extensions to support relaying, re-direction or 
> multicasting features. DPV clients are NOT REQUIRED to support relay, 
> re-direct or multicast, therefore clients or servers which do not 
> support such features still conform to the basic set of requirements. 
> DPV servers are NOT REQUIRED either to support relay, re-direct or 
> multicast.
> 
> 1. Where relay or re-direct mechanisms are supported by a server 
>    a mechanism to detect loops or repetition SHOULD be supported.
> 
> 2. Where a DPV server chooses to re-direct the request to another
>    DPV server (i.e. chooses to provide a referral), a mechanism to 
>    provide information to be used for the re-direction SHOULD be 
>    supported. Note: In case where information to be used for the 
>    re-direction is sent back, clients are NOT REQUIRED to interpret 
>    that information (but MAY do so).
> 
> 3. These features MAY be supported by using additional parameters
>    in the request and/or response. Clients and servers that do not
>    support such additional parameters MUST still be able to use/offer
>    DPV service. In this way, implementers need not understand the 
>    semantics of any such extensions.
> 
> ====================================================================
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3CGSaw10227 for ietf-pkix-bks; Fri, 12 Apr 2002 09:28:36 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3CGSXm10216 for <[e-mail]>; Fri, 12 Apr 2002 09:28:33 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA18120; Fri, 12 Apr 2002 18:28:30 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 12 Apr 2002 18:28:30 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA16517; Fri, 12 Apr 2002 18:28:29 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA07505; Fri, 12 Apr 2002 18:28:29 +0200 (MET DST)
Date: Fri, 12 Apr 2002 18:28:29 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Open issue: DPV relay
Cc: [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, 

I am a little bit confused that you replied to a message sent
by Denis as a repl to me. 

>  
> Peter.
> 
> OCSP has always envisioned and practised a relying party
> authorizing an OCSP Responder: no CA/AA involvement
> is required and no certificate need be issued, in this
> case.  

There seems to be a confusion about the difference of
a 'Trusted Responder' and an 'Authorised Responder' 

   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- 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

In 4.2.2.2 the text


   The key that signs a certificate's status information need not be the
   same key that signed the certificate. It is necessary however to
   ensure that the entity signing this information is authorized to do
   so.  Therefore, a certificate's issuer MUST either sign the OCSP
   responses itself or it MUST explicitly designate this authority to
   another entity.  OCSP signing delegation SHALL be designated by the
   inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
   extension included in the OCSP response signer's certificate.  This
   certificate MUST be issued directly by the CA that issued the
   certificate in question.

   id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}
  
seem to indicate that two of the three cases are AUTHORISED responders. 
The next sentences say: 

   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing use of the id-ad-ocspSigning value as
   described above. They MAY provide a means of locally configuring one
   or more OCSP signing authorities, and specifying the set of CAs for
   which each signing authority is trusted. They MUST reject the
   response if the certificate required to validate the signature on the
   response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."

which seems to explain an additional,thus three possible conditions for which
a response can be excepted. But what exactly means 1) ?

what means 'locally configuring one or more OCSP signing authorities'?

Does it mean that this matched the second case in the introduction,
which IMO is that a relying party that can operate its own OCSP
service for its own benefit, just as a front end to a collection
of some CRLs for example. 

Or, the text says TWO things:

How a CA can delegate OCSP operations resulting in 2 modes 
to accept responses by a relying party, and a third mode indicating
how a relying party can have an additional mode to trust someone
who is NOT in one of the two other cases, and may have no
relationship with the CA or else. 

> Carry over this conformance requirement from OCSP to DPV:
> 
> An OCSP client (which includes a client that is a DPV server)
> must potentially accept an OCSP response according to ALL the 
> rules of 4.2.2.2. There are three cases: (1) (2) and (3).
Do You mean ALL (conditions met at the same time) or *ANY*
(of them may be true). ?  

> 
> Lets remember, a relying party can operate its
> own DPV service for its own benefit. The relying party 
> needs no authority from a CA to do so. The operator
> of a DPV server is not necessarily a TTP, and
> need have no relationship to the cert or CRL 
> issuer, other than that of performing
> relying party obligations or (less stringent) user 
> obligations according to the CP.
> 
In your paragraph, if you replace DPV by OCSP, I don't see
why this would be different if my interpretation of the
three cases are correct. 

Or, for OCSP the condition

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

doesn't it mean that some other relying party who will inspect the
response will not necessarily have the same configuration? 



Peter S



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3CEnfA03383 for ietf-pkix-bks; Fri, 12 Apr 2002 07:49:41 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3CEnem03378 for <[e-mail]>; Fri, 12 Apr 2002 07:49:40 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA09936; Fri, 12 Apr 2002 16:52:17 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041216490928:216 ; Fri, 12 Apr 2002 16:49:09 +0200 
Message-ID: <[e-mail]>
Date: Fri, 12 Apr 2002 16:46:07 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: Open issue: DPV relay
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 12/04/2002 16:49:09, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 12/04/2002 16:49:42, Serialize complete at 12/04/2002 16:49:42
Content-Transfer-Encoding: 7bit
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>

Thanks to numerous private e-mail exchanges with Stephen Farrell 
(thanks Stephen !) we both came to an agreement on additional text 
to address relaying, re-direction and multicasting.

So I submit this text to the list.

Denis

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

4.2. Relaying, re-direction and multicasting.

Protocols designed to conform to these requirements MAY include 
optional fields and extensions to support relaying, re-direction or 
multicasting features. DPV clients are NOT REQUIRED to support relay, 
re-direct or multicast, therefore clients or servers which do not 
support such features still conform to the basic set of requirements. 
DPV servers are NOT REQUIRED either to support relay, re-direct or 
multicast.

1. Where relay or re-direct mechanisms are supported by a server 
   a mechanism to detect loops or repetition SHOULD be supported.

2. Where a DPV server chooses to re-direct the request to another
   DPV server (i.e. chooses to provide a referral), a mechanism to 
   provide information to be used for the re-direction SHOULD be 
   supported. Note: In case where information to be used for the 
   re-direction is sent back, clients are NOT REQUIRED to interpret 
   that information (but MAY do so).

3. These features MAY be supported by using additional parameters
   in the request and/or response. Clients and servers that do not
   support such additional parameters MUST still be able to use/offer
   DPV service. In this way, implementers need not understand the 
   semantics of any such extensions.

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3CEXK003057 for ietf-pkix-bks; Fri, 12 Apr 2002 07:33:20 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3CEXBm03049 for <[e-mail]>; Fri, 12 Apr 2002 07:33:11 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <2ZHH9YAH>; Fri, 12 Apr 2002 10:33:07 -0400
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: "'Al Arsenault'" <[e-mail]>
Cc: Alfred Arsenault <[e-mail]>, [e-mail]
Subject: RE: CMP Interoperability Question
Date: Fri, 12 Apr 2002 10:33:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1E22E.F623F850"
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_01C1E22E.F623F850
Content-Type: text/plain

Hi Al,

> ----------
> From: 	Al Arsenault[SMTP:[e-mail]]
> Sent: 	Wednesday, April 10, 2002 7:52 AM
> To: 	[e-mail]
> Cc: 	Alfred Arsenault
> Subject: 	CMP Interoperability Question
> 
>     The reason for asking this: we tend to believe that they private
> signing key used to sign certificates and revocation information (CRLs,
> OCSP responses) should ONLY be used for that purpose.  The CA has a
> separate key to use for secure communications, including signing CMP
> responses. (I can't find anything in the spec - either RFC2510 or
> son-of-2510 - that addresses this at all. My apologies if I just missed a
> section.)
 
The spec mentions the concept of a "protocol encryption key" and I was sure
it also mentioned the concept of a "protocol signing key" somewhere, but I
just took a look and I can't find it...

In any case, there was never any assumption in our minds that the key used
to sign CMP responses would be the same one as used to sign certificates,
CRLs, etc..  I always thought in terms of a protocol signing key (whose
public key was put into a certificate signed by the regular cert-signing key
so that the EE would be able to trust it).

As far as I am aware, this issue never came up during the CMP interop
testing.  In particular, we always used a separate key to sign CMP responses
and were able to successfully interoperate with the other participants.

Carlisle.


------_=_NextPart_001_01C1E22E.F623F850
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: CMP Interoperability Question</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi =
Al,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Al =
Arsenault[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Wednesday, April 10, 2002 7:52 =
AM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">[e-mail]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">Alfred =
Arsenault</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">CMP Interoperability Question</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">=A0=A0=A0 The reason for asking this: =
we tend to believe that they private signing key used to sign =
certificates and revocation information (CRLs, OCSP responses) should =
ONLY be used for that purpose.=A0 The CA has a separate key to use for =
secure communications, including signing CMP responses. (I can't find =
anything in the spec - either RFC2510 or son-of-2510 - that addresses =
this at all. My apologies if I just missed a section.)</FONT></P>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">The spec =
mentions the concept of a &quot;protocol encryption key&quot; and I was =
sure it also mentioned the concept of a &quot;protocol signing =
key&quot; somewhere, but I just took a look and I can't find =
it...</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">In any =
case, there was never any assumption in our minds that the key used to =
sign CMP responses would be the same one as used to sign certificates, =
CRLs, etc..&nbsp; I always thought in terms of a protocol signing key =
(whose public key was put into a certificate signed by the regular =
cert-signing key so that the EE would be able to trust it).</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">As far as =
I am aware, this issue never came up during the CMP interop =
testing.&nbsp; In particular, we always used a separate key to sign CMP =
responses and were able to successfully interoperate with the other =
participants.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1E22E.F623F850--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3C7ui929771 for ietf-pkix-bks; Fri, 12 Apr 2002 00:56:44 -0700 (PDT)
Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3C7ugm29762 for <[e-mail]>; Fri, 12 Apr 2002 00:56:42 -0700 (PDT)
Message-ID: <[e-mail]>
Date: Fri, 12 Apr 2002 09:56:28 +0200
From: Bernd Matthes <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: TSA Policy Identifiers
References: <000001c1dfed$e2a28730$[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms2DE93B2AFEC64AB26D4E3685"
X-Virus-Scanned: by AMaViS perl-11
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 cryptographically signed message in MIME format.

--------------ms2DE93B2AFEC64AB26D4E3685
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:
> 
> > Hi! Where can I find info on defined TSA Policy OIDs for TSP, rfc 3163?
>                                                                 ^^^^^^^^
>                                                                 rfc 3161
> The URL is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-00.txt
> 
> Regards,
> 
> Denis

Hi Denis!

In Section 7.3.1, g) NOTE2 I found:
"NOTE 2: A protocol for a time-stamp token is defined in RFC 3631 and 
profiled in TS 101 861 [TS 101861]." Is this a typo?  ---------^

with kind regards
-- 
Bernd Matthes                   Gemplus mids GmbH --
Senior Software Engineer    	   formerly Celo Communications GmbH
Dipl.-Ing.(FH)                  R&D Center Germany
--------------------------------------------------------------------
"Complexity breeds bugs. Bugs prevent adoption, lack of" \
"adoption results in death. Death not good." "Life sucks."
--------------ms2DE93B2AFEC64AB26D4E3685
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIH6gYJKoZIhvcNAQcCoIIH2zCCB9cCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Bb0wggKMMIIB9aADAgECAgMHA+kwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMjAzMTgxNzIxMzRaFw0wMzAzMTgxNzIxMzRa
MEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxKDAmBgkqhkiG9w0BCQEWGWJl
cm5kLm1hdHRoZXNAZ2VtcGx1cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANLH
Ug0UXihUAGRuILAJAZhyok9Oj2UG5HcQXVgAK8Q1MJOTs3XKzdimgxdKdl1C6GBj+XUDhyin
6EM0/nrgpIg+abWtjmz1U4XXOhmqDz7qLRP/wu/FZefkM/QRbgrBXZh/NTOr1m0sMThKGTgs
ZCiwc6HebSh43HNgwE74QTHhAgMBAAGjNjA0MCQGA1UdEQQdMBuBGWJlcm5kLm1hdHRoZXNA
Z2VtcGx1cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQDK4ZRCCCV5wytZ
NmCxQfoGRljKsUxU4L5gztN0ni6ibvlDeDfg6A2+Hsv5JqhNq1EoujkRAKAry4jcSDY/pI+7
D4zhyMxx4eH+vEIGq3z1Jvukx9Tm/wKGyW504SKWCBo5LI0jMnfydBY7gQd1wyGlRuYDm77f
mzOXD2VfcMy87jCCAykwggKSoAMCAQICAQwwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG
SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBa
Fw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBl
MRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlm
aWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjgu
MzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO
40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWo
J67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMB
AAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzASBgNV
HRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQBzG28mZYv/
FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpTkUvhzeY42e1Q9DpsNJKs5pKcbsEj
AcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3ooga7TlbOX00/LaWGCVNavSdxcOR
L6mWuAU8Uvzd6WIDSDGCAfUwggHxAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM
V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsG
A1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWls
IFJTQSAyMDAwLjguMzACAwcD6TAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDQxMjA3NTYzMlowIwYJKoZIhvcNAQkEMRYEFHOE
KL32M/trEKoQ35mt0RmYyXwcMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAqcKIppHIiDWH/yCGG0QivAUMbDCD3oNFjh1/sYbr8ICn7OalwS8wa16a
s5km8DQSxe+wiOVAPr/l14tSAgTVS0eP9IHvOue8KN8Lgat9F/MRBcDMB85gQTFV4uihCxwo
fVZrE1y54EnmRYoGNb2BZkpL22T9gY5+46Mz1VkqCFw=
--------------ms2DE93B2AFEC64AB26D4E3685--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BH1TW10414 for ietf-pkix-bks; Thu, 11 Apr 2002 10:01:29 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BH1Nm10408 for <[e-mail]>; Thu, 11 Apr 2002 10:01:23 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 11 Apr 2002 09:58:43 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 11 Apr 2002 09:58:43 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <2VWBV6BB>; Thu, 11 Apr 2002 10:00:54 -0700
Content-return: allowed
Date: Thu, 11 Apr 2002 10:00:53 -0700
From: Peter Williams <[e-mail]>
Subject: RE: Open issue: DPV relay
To: "'Peter Sylvester '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
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.

OCSP has always envisioned and practised a relying party
authorizing an OCSP Responder: no CA/AA involvement
is required and no certificate need be issued, in this
case.  

Carry over this conformance requirement from OCSP to DPV:

An OCSP client (which includes a client that is a DPV server)
must potentially accept an OCSP response according to ALL the 
rules of 4.2.2.2. There are three cases: (1) (2) and (3).

Lets remember, a relying party can operate its
own DPV service for its own benefit. The relying party 
needs no authority from a CA to do so. The operator
of a DPV server is not necessarily a TTP, and
need have no relationship to the cert or CRL 
issuer, other than that of performing
relying party obligations or (less stringent) user 
obligations according to the CP.

-----Original Message-----
From: Denis Pinkas
To: Peter Sylvester
Cc: [e-mail]
Sent: 4/11/02 3:18 AM
Subject: Re: Open issue: DPV relay


> See the second point and also read 4.2.2.2

Which says: 

   It is necessary however to ensure that the entity signing this 
   information is authorized to do so.  Therefore, a certificate's 
   issuer MUST either sign the OCSP responses itself or it MUST 
   explicitly designate this authority to another entity. 
 
> Or: You may want a requirement that the DPV responder must ensure
> that the OCSP responses are signed by a CA or an authorised responder
> and not by some locally trusted OCSP responder in order to
> be sure that an 'evidence verifier' finds trustworthy information.

This is correct. However, it is not necesssary to add this requirement
in
the DPV requirements document since this requirement is already in
section
4.2.2.2 from RFC 2560 (OCSP).

> > > To make the simple case, if a DPV response is signed directly by
the CA
> > > (or by an authorised responder), you have the same situation.
> >
> > No. A CA can only assert information about what it is directly
responsible.

> So, the DPV response made by the CA just talks about the certificates
> it has directly issued.

No. Talking about the certificates that a DPV server may have issued
does
not make sense. Certificates are only issued by CAs, AFAIK. Once again, 
a DPV server MUST answer for one (or more) certificates and must verify 
an entire chain of certificates, whoever has issued them. A DPV server
is 
*not* a CA. A DPV server can be *any* service provider. An organization
running a CA may also run a DPV server, in the same way as an
organization
running a CA may also provide a Time-Stamping service.
 
> > No CA is responsible for all the certifiactes from one path. An OCSP
query
> > is for ONE certificate, while a DPV query involves a CHAIN of
certificates.
> 
> The text says:
> 
>    The Delegated Path Validation (DPV) protocol allows a server to
>    validate one or more public key certificates according to a
validation
>    policy.
> 
>    In order to validate a certificate, a chain of multiple
certificates,
>    called a certification path, may be needed, comprising a
certificate
>    of the public key owner (the end entity) signed by one CA, and zero
or
>    more additional certificates of CAs signed by other CAs.
 
> In the simple case of only one CA, an OCSP response signed by the CA
> concerning the certificate in question does not say anything the
> validity of the CA cert since when it was signed with the same key.

> You thus just have on certificate.
 
> In a case of one intermediate CA, the DPV response may for example
> contain two OCSP responses, one signed by the intermediate CA
> concerning the revocation status of the end user and another
> concerning the statius of the intermediate CA signed by the
> top CA.
 
> If both CAs provide a DPV service instead of an OCSP service

You mean "If the organisation hosting a CA also provides a DPV service
... "

> in the same way, you have exactly the same situation except
> that this is a positive status information.
> 
> For example, the initial client asks for a combined status,
> it asks his own trusted service, this server asks the intermediate
> CA either to provide an OCSP status or a DPV status of the
> cert in question and then asks the top CA to provide a status of
> the intermediate CA's cert, and well, even three other OCSP
> responders to provide statement that the top level
> CA's cert is good.

I believe that you have mis-understood one idea behind DPV. DPV verifies
the
whole path processing. A DPV status about one intermediate certificate
of
the chain does not make sense. The validation policy is not about that
intermediate certificate but about a given certificate and a whole chain
above it. Applying the validation policy on an intermediate certificate
only
does not make sense.
 
> DPV would allow to combine the responses differently.
> It can well be that the intermediate CA/DPV responder
> itself asks for a DPV response from the top CA/DPV
> and include this in his DPV response to the initial server.
> 
> >
> > There are no similarities.
> "Ok, let's talk."
> 
> > > I think that there must be a language problem somewhere because I
> > > fail to see what *not* you are referring, i.e. to see where we are
> > > in disagreement.  I have not said that it is necessary for the
client
> > > to gather all information. I have said that the protocol must
provide
> > > a method to allow a client to ask and the server to respond with
that
> > > information.
> >
> > Maybe, since we possibly interpreted diffrently "what has
contributed to the
> > final decision".
> >
> > > > In case of a dispute, testing again the certificate validity,
means that
> > > > certificates, CRLs and OCSP responses must be available.
Anything else is
> > > > useless.
> >
> > > I think that this may be the core of our disagreement.
> >
> > > This is because you only accept that CA can create assertions
about the
> > > validity of their certificates using CRLs and OCSP.
> >
> > Correct.
> 
> Unfortunately we may be both wrong.
> 
> > > As soon as you would
> > > admit that some new protocol or service is provided that enhances
and in
> > > particular replaces them, the statements obtained via that service
are
> > > necessary.
> >
> > > I would like to know what you would have said 5 years ago when
only
> > > CRLs existed.
> >
> > Basicaly the chain must be verified and no element fom the chain
must be
> > revoked.
> >
> > Five years ago this information was provided off-line, i.e. via
CRLs. OCSP
> > allows to obtain the same information on-line. Between on-line and
off-line
> > I currently see no other mechanism.
 
> But you can have different protocols for these characteristics.
Offline
> you could use trees, online you can have DPV, 

No. On-line, to know the revocation status of a single certificate we
only
have OCSP. RFC 2560 states:

   It is necessary however to ensure that the entity signing this 
   information is authorized to do so.  Therefore, a certificate's 
   issuer MUST either sign the OCSP responses itself or it MUST 
   explicitly designate this authority to another entity.  

Note that this is true as well for CRLs. Either the CA signs the CRL
directly or designate another authority.

RFC 2459 RECOMMENDS for the support of the CRL distribution points
extension
which then contains a cRLIssuer field. "If the certificate issuer is not
the
CRL issuer, then the cRLIssuer field MUST be present and contain the
Name of
the CRL issuer. If the certificate issuer is also the CRL issuer, then
the
cRLIssuer field MUST be omitted ..." 

> or other techniques like
> timestamps over CRLs and OCSP responses to have a proof that the
server
> has provided the OCSPresp/CRL at a current date.

Time-stamping is not needed to prove that the server has provided the
OCSPresp/CRL at a current date. An OCSP response includes such a date.
CRL
checking uses thisUpdate and nextUpdate. Time-stamping may however be
useful
for other reasons. An informational RFC (i.e. RFC 3126 - Electronic
Signature Formats for long term electronic signatures) does however
indicate
such a format in the context of a signature policy. Another format could
be
derived from it in the context of a validation policy.
 
> > The basic question is whether first-hand information and second-hand
> > information should be used. In case of a dispute, only first-hand
> > information is useful (certificates and revocation status
information from
> > the CAs responsible for every certificate from the chain). DPV
responses
> > (i.e. the signed "yes" answers) are useless, unless the plaintiff
and the
> > defendant both trust the same DPV server.
 
> OCSP responses may also be useless, unless the plaintiff and the
> defendant both trust the same OCSP server.

Wrong. RFC 2560 sates:

   It is necessary however to ensure that the entity signing this 
   information is authorized to do so.  Therefore, a certificate's 
   issuer MUST either sign the OCSP responses itself or it MUST 
   explicitly designate this authority to another entity. 

In either of these cases, the plaintiff and the defendant cannot argue
that
the OCSP response is not valid (unless the OCSP responder has been
revoked
by the CA). They cannot argue that such responses are useless, or if
they
do, 
this argumentation will be rejected.

I have made my best efforts to explain all the rational behind DPV
responses,
which are very different from OCSP responses. I have also made my best
efforts to explain why in the general case a DPV response from a given
server is not necessarilly trusted by all clients, and thus would be
useless
in front of a court.

The security consideration section is very explicit on this issue:

"A DPV client must trust a DPV server to provide the correct answer. 
However, this does not mean that all DPV clients will trust the same 
DPV servers. While a positive answer might be sufficient for one DPV 
client, that same positive answer will not necessarily convince 
another DPV client."

Can we finally close this issue ?

Denis
 
> Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BBl5024128 for ietf-pkix-bks; Thu, 11 Apr 2002 04:47:05 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BBl4m24123 for <[e-mail]>; Thu, 11 Apr 2002 04:47:04 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3BBkQms034990; Thu, 11 Apr 2002 07:46:26 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g3BBkPp70986; Thu, 11 Apr 2002 07:46:25 -0400
Importance: Normal
Sensitivity: 
Subject: Re: WG Last Call: Roadmap
To: Al Arsenault <[e-mail]>
Cc: Denis Pinkas <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 11 Apr 2002 07:46:17 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/11/2002 07:46:25 AM
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>

      Al:

      Your argument against updating the terminology is pretty convincing.
We should probably provide a note that the term "trust anchor" is normally
used with roughly the same meaning as "root CA" in this document.  The term
is fairly commonly used, and unambiguous.

            Tom Gindin

Al Arsenault <[e-mail]> on 04/10/2002 01:28:43 PM

To:    Tom Gindin/Watson/IBM@IBMUS, Denis Pinkas <[e-mail]>
cc:    [e-mail]
Subject:    Re: WG Last Call: Roadmap


Tom,

    Going back to how that discussion got started lo those many years ago,
the problem was that different PKIX documents used the term "root CA" to
mean different things.  Most of them used it to mean "trust anchor" or some
similar thing; i.e., "this is the CA that you base all of your trust on as
an RP" (and yes, in a large complex PKI system there might be more than one
of these); a few used it as a synonym for "top CA"; i.e., the thing at the
top of a hierarchy.

    After much discussion on this list, the terms as they now appear in the
Roadmap document were agreed to (okay, it was pretty darned rough
consensus,
but it was as good as we were gonna get at that time).  This made the
Roadmap pretty consistent with other PKIX documents, and I think "best
efforts" were made to bring the usage in the other documents into line over
the years.

    So I'd be really hestitant to change the terminology in the Roadmap
now - it'd just bring up the same old issue again, and cause the roadmap to
be inconsistent with (almost) all of the other PKIX documents - which is
not
something I'd want.

    Thanks,

            Al Arsenault


----- Original Message -----
From: "Tom Gindin" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, April 10, 2002 10:41 AM
Subject: Re: WG Last Call: Roadmap


>
>
>       It is obviously important that this document get finalized fairly
> soon.  The only question we have outstanding is whether "root CA" as
> defined would be better replaced by "anchor CA" or "trust anchor".  This
> should not block the document for more than a day or two, but I think it
> worthwhile to find out what you think the difference is.  The term "root
> CA" as "root of trust" has caused some confusion in these discussions,
and
> if there's a better term which is in fairly common use (as "anchor" is)
we
> should use it.  If there's a real difference, we should keep "root CA".
In
> case it's not obvious, the term "anchor CA" means "a trust anchor which
is
> a CA" - which assumes that trust anchors could be defined in such a way
> that they might be EE's or even AA's.
>
>             Tom Gindin
>
>
> Denis Pinkas <[e-mail]> on 04/09/2002 12:00:26 PM
>
> To:    Tom Gindin/Watson/IBM@IBMUS
> cc:    [e-mail]
> Subject:    Re: WG Last Call: Roadmap
>
>
> Tom,
>
> >       Denis:
> >
> >       Should we really standardize on the term "root CA" rather than
> "trust
> > anchor" or "anchor CA"?
>
> I do not care, but I care for this document to be sent to the IESG soon.
So
> the sooner we may find a compromise, the better. Maybe the quickest way
> is to try to suppress the sentences that create problems. We should
> focuss on text replacement proposals.
>
> > "Trust anchor" has never been used to mean anything other than an
entity
> directly trusted by the RP, AFAIK.
>
> Not exactly. Read this sentence again.  However, I would like to resist
to
> start a new discusion now on trust anchors.
>
> > I have other comments below.
> >
> >             Tom Gindin
> >
> > Denis Pinkas <[e-mail]> on 04/08/2002 12:32:41 PM
> >
> > To:    Tom Gindin/Watson/IBM@IBMUS
> > cc:    [e-mail]
> > Subject:    Re: WG Last Call: Roadmap
> >
> > Tom,
> >
> > I have not forgotten this message, but I gave priority to the DPV
thread.
> >
> > >       Responses below.
> >
> > > The issue of who specifies the verifier's policy is
> > > rather serious.  If the policy to be used is expected to be the same
as
> > RFC
> > > 3126's SignaturePolicy, we need to specify a step in which the
verifier
> > has
> > > the right to reject such a policy or to consider it inapplicable to
the
> > > verifier's own current context.
> >
> > This is true. However, the text does not go at that level of detail:
> >
> > "Another model considers a set of rules that apply to an application
> > context. Every application context may have a different set of rules.
> > When choosing to use certificates in the context of that application,
> > the EE selects the set of rules for that context. In a set of rules,
> > one or more Top CAs may be trusted, each one may be associated with
> > different constraints, like the certificate policies that are trusted
> > or the naming constraints that apply. These constrains may be specified
> > either in self-signed certificates or in addition to self-signed
> > certificates when they do not incorporate these constraints. This set
> > of rules is called a validation policy (when validating a certificate)
> > or a signature policy (when validating a digital signature)."
> >
> > I do not think it is necesary to state it. If you think so, please
> provide
> > a text and a placement for that text.
> >
> > [TG] My biggest problem is the use of the term "signature policy",
which
> > you have elsewhere defined as something defined and signed by the
signer
> of
> > the document.
>
> There is a misunderstanding. A signer may provide the *reference* of the
> signature policy that he agrees to use when signing. In order to prevent
> someone else to change that reference, it is protected by the signer's
> signature. So in that case the verifier has first to see whether the
> signature policy used by the signer is appropriate for his application
> context. If it is the case, then it uses it, otherwise this is the end of
> the story.
>
> [TG] He mainly needs to check whether it's an approved signature policy
by
> his personal or organizational criteria.
>
> > In the paragraph above, I would replace the term "Top CAs"
> > by "root CA's",
>
> No problem.
>
> > and I would also call the sets of rules in the last
> > sentence a "certificate validation policy" and a "signature validation
> > policy".  I would then add the following statement: "Neither of these
> > policies is considered to be the same as either a CertificatePolicy as
> > defined in RFC 2459 or a SignaturePolicy as defined in RFC 3126."
>
> I would simply propose to delete the following sentence:
>
> "This set of rules is called a validation policy (when validating a
> certificate) or a signature policy (when validating a digital signature)"
> not because it is wrong, but because I would like this document to
proceed.
>
> This would lead to the following text:
>
> "Another model considers a set of rules that apply to an application
> context. Every application context may have a different set of rules.
> When choosing to use certificates in the context of that application,
> the EE selects the set of rules for that context. In a set of rules,
> one or more root CAs may be trusted, each one may be associated with
> different constraints, like the certificate policies that are trusted
> or the naming constraints that apply. These constrains may be specified
> either in self-signed certificates or in addition to self-signed
> certificates when they do not incorporate these constraints."
>
> Can you live with it ?
>
> [TG] Sure.
>
> > > To:    Tom Gindin/Watson/IBM@IBMUS
> > > cc:    [e-mail]
> > > Subject:    Re: WG Last Call: Roadmap
> > >
> > > Tom,
> > >
> > > >       I have a few issues with this, and some corrections as well.
> > >
> > > >       In comment 12, I have two issues.  The first one, which is
> minor,
> > > is
> > > > that  "one or more Top CA's may be trusted" should refer to root
CA's
> > > > instead - the two terms mean the same thing more often than not,
but
> > when
> > > > they differ the trust point is the root rather than the top.
> > >
> > > PKIX-1 states:
> > >
> > >    " - Top CA - A CA that is at the top of a PKI hierarchy.
> > >
> > >    Note: This is often also called a "Root CA," since in data
> structures
> > >    terms and in graph theory, the node at the top of a tree is the
> > >    "root." However, to minimize confusion in this document, we elect
to
> > >    call this node a "Top CA," and reserve "Root CA" for the CA
directly
> > >    trusted by the EE."
> > >
> > > The problem lies with the last sentence, i.e. "*the* CA directly
> trusted
> > by
> > > the EE.". The singular is being used which means that there is a
single
> > > one, multiple roots are not permitted, while multiple Top-CAs are
> > > permitted.
> > >
> > > [TG] Where in PKIX-1 is this?  I can't find the phrase "directly
> trusted"
> > > in either RFC 2459 or in draft 12 of new-pkix-1.
> >
> > Sorry for the confusion: it is in the roadmap document, not PKIX-1.
> >
> > The current text in the roadmap is:
> >
> >     " - Root CA - A CA that is directly trusted by an EE; that is,
> >        securely acquiring the value of a Root CA public key requires
> >        some out-of-band step(s). This term is not meant to imply that a
> >        Root CA is necessarily at the top of any hierarchy, simply that
> >        the CA in question is trusted directly.
> >
> > (...)
> >
> >    Note: This is often also called a "Root CA," since in data
structures
> >    terms and in graph theory, the node at the top of a tree is the
> >    "root." However, to minimize confusion in this document, we elect to
> >    call this node a "Top CA," and reserve "Root CA" for the CA directly
> >    trusted by the EE. Readers new to PKIX should be aware that these
> >    terms are not used consistently throughout the PKIX documents, as
the
> >    Internet PKI profile [2459bis] uses "Root CA" to refer to what this
> >    and other documents call a "Top CA," and "most-trusted CA" to refer
> >    to what this and other documents call a "Root CA."
> >
> > There is no problem with PKIX-1 but a problem with the roadmap
document.
> > PKIX-1 does not use the term "root CA", and thus it is wrong to say in
> > the roadmap that "these terms are not used consistently throughout the
> > PKIX documents".
> >
> > I would thus propose to change the note in the following way:
> >
> >    Note: Since in data structures terms and in graph theory, the node
> >    at the top of a tree is the "root", the term "root CA" is sometimes
> >    used. This term is not meant to imply that a Root CA is necessarily
> >    at the top of any hierarchy, simply that the CA in question is
trusted
> >    directly.
> >
> > [TG] As I stated at the beginning, I don't know why we should
standardize
> > on the term "root CA" rather than "trust anchor" or "anchor CA".  Those
> > terms cannot be mistaken for what is defined here as a "Top CA".  BTW,
I
> > approve of that coinage.
>
> We do use "root CA", so I see no harm to use that vocabulary. This is no
> attempt to standardize this term here. Originally my single concern what
> that the text was talking about *one* root CA whereas there can be
> multiple.
> This was my ONLY concern. This is now fixed. We should close this issue
> ASAP.
>
> Denis
>
> > Then, on page 14, change:
> >
> >    Additionally, once the Root CA ...
> >
> > with
> >
> >    Additionally, once a Root CA ...
> >
> > on pages 29 and 30, change:
> >
> >    (e.g., the DVCS's CA, or the Root CA in a
> >    hierarchy)
> >
> > with
> >
> >    (e.g., the DVCS's CA, or a Root CA)
> >
> > Regards,
> >
> > Denis
> >
> > (snip)
>
>
>
>







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BBLCX23022 for ietf-pkix-bks; Thu, 11 Apr 2002 04:21:12 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BBLAm23018 for <[e-mail]>; Thu, 11 Apr 2002 04:21:10 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3BBL5ms313408; Thu, 11 Apr 2002 07:21:05 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g3BBL3p31262; Thu, 11 Apr 2002 07:21:04 -0400
Importance: Normal
Sensitivity: 
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 10 Apr 2002 12:35:16 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/11/2002 07:21:04 AM
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>

      Russ:

      Most of the following concerns the data structures of the current
draft and of my last posting.  First, should the URI really be optional in
cases where the binary component is a hash?  What good is the logotype
field with a hash but no way to reference the image?  Second, I have
reviewed draft-ietf-idn-uri-01.txt (by Martin Duerst) and it recommends
that internationalized URI strings be converted to UTF-8 but then escaped
using %HH, so UTF8String is unnecessary.  Therefore, we should simplify
VerifiedReference as follows:
      VerifiedReference ::= SEQUENCE {
            hashAlgorithm     AlgorithmIdentifier,
            dataHash    OCTET STRING,
            uri          IA5String,
      }

      On a different topic, smart cards and other tokens have the least
space of any place certificates are likely to be put, so if in-line
logotypes are OK there they're OK anywhere.

            Tom Gindin


"Housley, Russ" <[e-mail]> on 04/08/2002 01:17:11 PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [e-mail]
Subject:    Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt


Tom:

>The following is just a personal opinion, but one based on fairly
>well-understood trends.  I don't think that in-line logotypes are
CURRENTLY
>worth the space that they'd take up on a smart card, but I would guess
that
>they will be in two more smart-card generations and perhaps only one.
>Given the amount of time between standard proposal and deployment, it's
not
>premature to standardize it.

I tend to agree with your assessment of storage on smart cards.  Today, all

of the certificates stored on one smart card are likely to be associated
with one community.  Therefore, a logo will like appear on the smart card
itself.

Of course, there are other places that certificates and private keys are
stored....

>       However, I also have a question about the current data structure.
>First, why is the URI optional (assuming that the only binary value is the
>digest, as at present)?  Second, why would we not permit in-line logotypes
>(in which case the URI is suppressed)?  This would require some edits to
>LogotypeData, but nothing very difficult.  One possibility would be:
>       LogotypeData ::= SEQUENCE {
>           typeOfLogotype       TypeOfLogotype,
>           hashAlgorithm        AlgorithmIdentifier,   -- might be
OPTIONAL,
>it's not meaningful for GIF's
>           CHOICE  {
>             logotypeDataHash     OCTET STRING,
>       gif   [0]         IMPLICIT OCTET STRING
>       },
>           logotypeDataUri      IA5String OPTIONAL }
>
>       Another would be:
>       LogotypeData ::= SEQUENCE {
>           typeOfLogotype       TypeOfLogotype,
>           CHOICE  {
>             logotypeReference VerifiedReference,
>       gif               OCTET STRING
>       }
>           }
>       VerifiedReference ::= SEQUENCE {
>             hashAlgorithm     AlgorithmIdentifier,
>             dataHash    OCTET STRING,
>             CHOICE      {
>                   uri          IA5String,
>                   intlUri           UTF8String  }
>       }
>
>
>       IMO VerifiedReference is a generally useful type, so its names do
not
>contain reference to logotypes.  My understanding of COMPONENTS OF, which
>may be faulty, is that defining LogotypeData using COMPONENTS OF
>VerifiedReference as an element of a CHOICE would not produce a useful
>result because each of the elements of VerifiedReference would show up in
>the CHOICE rather than merely hashAlgorithm going into the CHOICE with the
>other fields added to LogotypeData's SEQUENCE.

We are in the final steps of an updated I-D.  It addresses some of these
issues, but not all.

Is there a reference for UTF8String URI?

Russ




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3BAIxO18315 for ietf-pkix-bks; Thu, 11 Apr 2002 03:18:59 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3BAIvm18311 for <[e-mail]>; Thu, 11 Apr 2002 03:18:57 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA16466; Thu, 11 Apr 2002 12:21:30 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041112182382:53 ; Thu, 11 Apr 2002 12:18:23 +0200 
Message-ID: <[e-mail]>
Date: Thu, 11 Apr 2002 12:18:22 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 11/04/2002 12:18:24, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 11/04/2002 12:18:55, Serialize complete at 11/04/2002 12:18:55
Content-Transfer-Encoding: 7bit
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>

Peter,

> > > In OCSP, you have that either the response is signed by the same entity that
> > > signed the certificate or by an OCSP entity which has a certificate directly
> > > signed by the CA in question with some extended key usage.
> >
> > True.
> 
> Well, maybe not, I was just made aware that I have forgotten that OCSP says:
> 
>    All definitive response messages SHALL be digitally signed. The key
>    used to sign the response MUST belong to one of the following:
> 
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted by the requester
>    -- 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
> 
> See the second point and also read 4.2.2.2

Which says: 

   It is necessary however to ensure that the entity signing this 
   information is authorized to do so.  Therefore, a certificate's 
   issuer MUST either sign the OCSP responses itself or it MUST 
   explicitly designate this authority to another entity. 
 
> Or: You may want a requirement that the DPV responder must ensure
> that the OCSP responses are signed by a CA or an authorised responder
> and not by some locally trusted OCSP responder in order to
> be sure that an 'evidence verifier' finds trustworthy information.

This is correct. However, it is not necesssary to add this requirement in
the DPV requirements document since this requirement is already in section
4.2.2.2 from RFC 2560 (OCSP).

> > > To make the simple case, if a DPV response is signed directly by the CA
> > > (or by an authorised responder), you have the same situation.
> >
> > No. A CA can only assert information about what it is directly responsible.

> So, the DPV response made by the CA just talks about the certificates
> it has directly issued.

No. Talking about the certificates that a DPV server may have issued does
not make sense. Certificates are only issued by CAs, AFAIK. Once again, 
a DPV server MUST answer for one (or more) certificates and must verify 
an entire chain of certificates, whoever has issued them. A DPV server is 
*not* a CA. A DPV server can be *any* service provider. An organization
running a CA may also run a DPV server, in the same way as an organization
running a CA may also provide a Time-Stamping service.
 
> > No CA is responsible for all the certifiactes from one path. An OCSP query
> > is for ONE certificate, while a DPV query involves a CHAIN of certificates.
> 
> The text says:
> 
>    The Delegated Path Validation (DPV) protocol allows a server to
>    validate one or more public key certificates according to a validation
>    policy.
> 
>    In order to validate a certificate, a chain of multiple certificates,
>    called a certification path, may be needed, comprising a certificate
>    of the public key owner (the end entity) signed by one CA, and zero or
>    more additional certificates of CAs signed by other CAs.
 
> In the simple case of only one CA, an OCSP response signed by the CA
> concerning the certificate in question does not say anything the
> validity of the CA cert since when it was signed with the same key.

> You thus just have on certificate.
 
> In a case of one intermediate CA, the DPV response may for example
> contain two OCSP responses, one signed by the intermediate CA
> concerning the revocation status of the end user and another
> concerning the statius of the intermediate CA signed by the
> top CA.
 
> If both CAs provide a DPV service instead of an OCSP service

You mean "If the organisation hosting a CA also provides a DPV service ... "

> in the same way, you have exactly the same situation except
> that this is a positive status information.
> 
> For example, the initial client asks for a combined status,
> it asks his own trusted service, this server asks the intermediate
> CA either to provide an OCSP status or a DPV status of the
> cert in question and then asks the top CA to provide a status of
> the intermediate CA's cert, and well, even three other OCSP
> responders to provide statement that the top level
> CA's cert is good.

I believe that you have mis-understood one idea behind DPV. DPV verifies the
whole path processing. A DPV status about one intermediate certificate of
the chain does not make sense. The validation policy is not about that
intermediate certificate but about a given certificate and a whole chain
above it. Applying the validation policy on an intermediate certificate only
does not make sense.
 
> DPV would allow to combine the responses differently.
> It can well be that the intermediate CA/DPV responder
> itself asks for a DPV response from the top CA/DPV
> and include this in his DPV response to the initial server.
> 
> >
> > There are no similarities.
> "Ok, let's talk."
> 
> > > I think that there must be a language problem somewhere because I
> > > fail to see what *not* you are referring, i.e. to see where we are
> > > in disagreement.  I have not said that it is necessary for the client
> > > to gather all information. I have said that the protocol must provide
> > > a method to allow a client to ask and the server to respond with that
> > > information.
> >
> > Maybe, since we possibly interpreted diffrently "what has contributed to the
> > final decision".
> >
> > > > In case of a dispute, testing again the certificate validity, means that
> > > > certificates, CRLs and OCSP responses must be available. Anything else is
> > > > useless.
> >
> > > I think that this may be the core of our disagreement.
> >
> > > This is because you only accept that CA can create assertions about the
> > > validity of their certificates using CRLs and OCSP.
> >
> > Correct.
> 
> Unfortunately we may be both wrong.
> 
> > > As soon as you would
> > > admit that some new protocol or service is provided that enhances and in
> > > particular replaces them, the statements obtained via that service are
> > > necessary.
> >
> > > I would like to know what you would have said 5 years ago when only
> > > CRLs existed.
> >
> > Basicaly the chain must be verified and no element fom the chain must be
> > revoked.
> >
> > Five years ago this information was provided off-line, i.e. via CRLs. OCSP
> > allows to obtain the same information on-line. Between on-line and off-line
> > I currently see no other mechanism.
 
> But you can have different protocols for these characteristics. Offline
> you could use trees, online you can have DPV, 

No. On-line, to know the revocation status of a single certificate we only
have OCSP. RFC 2560 states:

   It is necessary however to ensure that the entity signing this 
   information is authorized to do so.  Therefore, a certificate's 
   issuer MUST either sign the OCSP responses itself or it MUST 
   explicitly designate this authority to another entity.  

Note that this is true as well for CRLs. Either the CA signs the CRL
directly or designate another authority.

RFC 2459 RECOMMENDS for the support of the CRL distribution points extension
which then contains a cRLIssuer field. "If the certificate issuer is not the
CRL issuer, then the cRLIssuer field MUST be present and contain the Name of
the CRL issuer. If the certificate issuer is also the CRL issuer, then the
cRLIssuer field MUST be omitted ..." 

> or other techniques like
> timestamps over CRLs and OCSP responses to have a proof that the server
> has provided the OCSPresp/CRL at a current date.

Time-stamping is not needed to prove that the server has provided the
OCSPresp/CRL at a current date. An OCSP response includes such a date. CRL
checking uses thisUpdate and nextUpdate. Time-stamping may however be useful
for other reasons. An informational RFC (i.e. RFC 3126 - Electronic
Signature Formats for long term electronic signatures) does however indicate
such a format in the context of a signature policy. Another format could be
derived from it in the context of a validation policy.
 
> > The basic question is whether first-hand information and second-hand
> > information should be used. In case of a dispute, only first-hand
> > information is useful (certificates and revocation status information from
> > the CAs responsible for every certificate from the chain). DPV responses
> > (i.e. the signed "yes" answers) are useless, unless the plaintiff and the
> > defendant both trust the same DPV server.
 
> OCSP responses may also be useless, unless the plaintiff and the
> defendant both trust the same OCSP server.

Wrong. RFC 2560 sates:

   It is necessary however to ensure that the entity signing this 
   information is authorized to do so.  Therefore, a certificate's 
   issuer MUST either sign the OCSP responses itself or it MUST 
   explicitly designate this authority to another entity. 

In either of these cases, the plaintiff and the defendant cannot argue that
the OCSP response is not valid (unless the OCSP responder has been revoked
by the CA). They cannot argue that such responses are useless, or if they
do, 
this argumentation will be rejected.

I have made my best efforts to explain all the rational behind DPV
responses,
which are very different from OCSP responses. I have also made my best
efforts to explain why in the general case a DPV response from a given
server is not necessarilly trusted by all clients, and thus would be useless
in front of a court.

The security consideration section is very explicit on this issue:

"A DPV client must trust a DPV server to provide the correct answer. 
However, this does not mean that all DPV clients will trust the same 
DPV servers. While a positive answer might be sufficient for one DPV 
client, that same positive answer will not necessarily convince 
another DPV client."

Can we finally close this issue ?

Denis
 
> Peter


Received: by above.proper.com (8.11.6/8.11.3) id g3AL8LA23249 for ietf-pkix-bks; Wed, 10 Apr 2002 14:08:21 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AL8Km23245 for <[e-mail]>; Wed, 10 Apr 2002 14:08:20 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3AL8KsB001059 for <[e-mail]>; Wed, 10 Apr 2002 14:08:20 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: Two  more nits re: DPV/DPD rqmts
Date: Wed, 10 Apr 2002 14:05:33 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <[e-mail]>
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>

Russ, Denis:

Section 4, Delegated Path Validation Protocol Requirements
begins with:
"The Delegated Path Validation (DPV) protocol allows . . ."

Similarly, Section 5 Delegated Path Discovery Protocol
Requirements begins with:
"The Delegated Path Discovery (DPD) protocol allows . . ."

Since we're defining requirements and not protocols in this I-D,
you may wish to consider amending both these phrases towards
something along the lines of "DPV protocols allow . . ." and
"DPD protocols allow . . ." respectively.

Mike


Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AKtIe22762 for ietf-pkix-bks; Wed, 10 Apr 2002 13:55:18 -0700 (PDT)
Received: from mail.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AKtGm22758 for <[e-mail]>; Wed, 10 Apr 2002 13:55:16 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3AKt8sB029515; Wed, 10 Apr 2002 13:55:09 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Open issue: DPV relay
Date: Wed, 10 Apr 2002 13:52:22 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <[e-mail]>
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>

Maybe this is well understood but FWIW take care in reading
4.2.2.2 of RFC 2560.  In part, we wrote "Therefore, a
certificate's issuer MUST either sign the OCSP responses itself
or . . ."  The intent with this particular wording its related
text "The key that signs a certificate's status information need
not be the same key that signed the certificate." was to enable
a differentiation between the identity of an abstract entity and
the key or keys that entity uses to assert its identity in
various circumstances.

Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> Peter Sylvester
> Sent: Wednesday, April 10, 2002 11:40 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: Open issue: DPV relay
>
>
>
> >
> > > In OCSP, you have that either the response is
> signed by the same entity that
> > > signed the certificate or by an OCSP entity which
> has a certificate directly
> > > signed by the CA in question with some extended key usage.
> >
> > True.
>
> Well, maybe not, I was just made aware that I have
> forgotten that OCSP says:
>
>    All definitive response messages SHALL be
> digitally signed. The key
>    used to sign the response MUST belong to one of
> the following:
>
>    -- the CA who issued the certificate in question
>    -- a Trusted Responder whose public key is trusted
> by the requester
>    -- 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
>
> See the second point and also read 4.2.2.2
>
> Or: You may want a requirement that the DPV responder
> must ensure
> that the OCSP responses are signed by a CA or an
> authorised responder
> and not by some locally trusted OCSP responder in order to
> be sure that an 'evidence verifier' finds trustworthy
> information.
>
> >
> > > To make the simple case, if a DPV response is
> signed directly by the CA
> > > (or by an authorised responder), you have the
> same situation.
> >
> > No. A CA can only assert information about what it
> is directly responsible.
> So, the DPV response made by the CA just talks about
> the certificates
> it has directly issued.
>
> > No CA is responsible for all the certifiactes from
> one path. An OCSP query
> > is for ONE certificate, while a DPV query involves
> a CHAIN of certificates.
>
> The text says:
>
>    The Delegated Path Validation (DPV) protocol
> allows a server to
>    validate one or more public key certificates
> according to a validation
>    policy.
>
>    In order to validate a certificate, a chain of
> multiple certificates,
>    called a certification path, may be needed,
> comprising a certificate
>    of the public key owner (the end entity) signed by
> one CA, and zero or
>    more additional certificates of CAs signed by other CAs.
>
> In the simple case of only one CA, an OCSP response
> signed by the CA
> concerning the certificate in question does not say
> anything the
> validity of the CA cert since when it was signed with
> the same key.
> You thus just have on certificate.
>
> In a case of one intermediate CA, the DPV response
> may for example
> contain two OCSP responses, one signed by the intermediate CA
> concerning the revocation status of the end user and another
> concerning the statius of the intermediate CA signed by the
> top CA.
>
> If both CAs provide a DPV service instead of an OCSP service
> in the same way, you have exactly the same situation except
> that this is a positive status information.
>
> For example, the initial client asks for a combined status,
> it asks his own trusted service, this server asks the
> intermediate
> CA either to provide an OCSP status or a DPV status of the
> cert in question and then asks the top CA to provide
> a status of
> the intermediate CA's cert, and well, even three other OCSP
> responders to provide statement that the top level
> CA's cert is good.
>
> DPV would allow to combine the responses differently.
> It can well be that the intermediate CA/DPV responder
> itself asks for a DPV response from the top CA/DPV
> and include this in his DPV response to the initial server.
>
> >
> > There are no similarities.
> "Ok, let's talk."
>
> > > I think that there must be a language problem
> somewhere because I
> > > fail to see what *not* you are referring, i.e. to
> see where we are
> > > in disagreement.  I have not said that it is
> necessary for the client
> > > to gather all information. I have said that the
> protocol must provide
> > > a method to allow a client to ask and the server
> to respond with that
> > > information.
> >
> > Maybe, since we possibly interpreted diffrently
> "what has contributed to the
> > final decision".
> >
> > > > In case of a dispute, testing again the
> certificate validity, means that
> > > > certificates, CRLs and OCSP responses must be
> available. Anything else is
> > > > useless.
> >
> > > I think that this may be the core of our disagreement.
> >
> > > This is because you only accept that CA can
> create assertions about the
> > > validity of their certificates using CRLs and OCSP.
> >
> > Correct.
>
> Unfortunately we may be both wrong.
>
> > > As soon as you would
> > > admit that some new protocol or service is
> provided that enhances and in
> > > particular replaces them, the statements obtained
> via that service are
> > > necessary.
> >
> > > I would like to know what you would have said 5
> years ago when only
> > > CRLs existed.
> >
> > Basicaly the chain must be verified and no element
> fom the chain must be
> > revoked.
> >
> > Five years ago this information was provided
> off-line, i.e. via CRLs. OCSP
> > allows to obtain the same information on-line.
> Between on-line and off-line
> > I currently see no other mechanism.
>
> But you can have different protocols for these
> characteristics. Offline
> you could use trees, online you can have DPV, or
> other techniques like
> timestamps over CRLs and OCSP responses to have a
> proof that the server
> has provided the OCSPresp/CRL at a current date.
>
> > The basic question is whether first-hand
> information and second-hand
> > information should be used. In case of a dispute,
> only first-hand
> > information is useful (certificates and revocation
> status information from
> > the CAs responsible for every certificate from the
> chain). DPV responses
> > (i.e. the signed "yes" answers) are useless, unless
> the plaintiff and the
> > defendant both trust the same DPV server.
>
> OCSP responses may also be useless, unless the
> plaintiff and the
> defendant both trust the same OCSP server.
>
> Peter
>
>
>
>
>



Received: by above.proper.com (8.11.6/8.11.3) id g3AIjHO14077 for ietf-pkix-bks; Wed, 10 Apr 2002 11:45:17 -0700 (PDT)
Received: from poseidon.coastside.net (poseidon.coastside.net [207.213.212.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AIjFm14073 for <[e-mail]>; Wed, 10 Apr 2002 11:45:15 -0700 (PDT)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g3AIj1q3012171; Wed, 10 Apr 2002 11:45:01 -0700 (PDT)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Peter Sylvester" <[e-mail]>
Subject: RE: Open issue: DPV relay
Date: Wed, 10 Apr 2002 11:42:16 -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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <[e-mail]>
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>

All,

Once the requirements settle down, we intend to update the
OCSPv2 I-D accordingly for the WG's consideration.  It made no
sense to produce incremental I-Ds until then.  Now that we're
about a year into the rqmts, I suspect we're near closure on
that issue.

Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Denis Pinkas
>
>
> There is no more a standing OCSP-v2 proposal today.
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AIdkm13797 for ietf-pkix-bks; Wed, 10 Apr 2002 11:39:46 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AIdim13790 for <[e-mail]>; Wed, 10 Apr 2002 11:39:44 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA07680; Wed, 10 Apr 2002 20:39:44 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 10 Apr 2002 20:39:44 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA08050; Wed, 10 Apr 2002 20:39:43 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA06783; Wed, 10 Apr 2002 20:39:43 +0200 (MET DST)
Date: Wed, 10 Apr 2002 20:39:43 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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>

>  
> > In OCSP, you have that either the response is signed by the same entity that
> > signed the certificate or by an OCSP entity which has a certificate directly
> > signed by the CA in question with some extended key usage.
> 
> True.

Well, maybe not, I was just made aware that I have forgotten that OCSP says: 

   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- 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

See the second point and also read 4.2.2.2

Or: You may want a requirement that the DPV responder must ensure
that the OCSP responses are signed by a CA or an authorised responder
and not by some locally trusted OCSP responder in order to
be sure that an 'evidence verifier' finds trustworthy information. 

>  
> > To make the simple case, if a DPV response is signed directly by the CA
> > (or by an authorised responder), you have the same situation.
> 
> No. A CA can only assert information about what it is directly responsible.
So, the DPV response made by the CA just talks about the certificates
it has directly issued.

> No CA is responsible for all the certifiactes from one path. An OCSP query
> is for ONE certificate, while a DPV query involves a CHAIN of certificates.

The text says:

   The Delegated Path Validation (DPV) protocol allows a server to 
   validate one or more public key certificates according to a validation 
   policy.

   In order to validate a certificate, a chain of multiple certificates, 
   called a certification path, may be needed, comprising a certificate 
   of the public key owner (the end entity) signed by one CA, and zero or 
   more additional certificates of CAs signed by other CAs.

In the simple case of only one CA, an OCSP response signed by the CA
concerning the certificate in question does not say anything the
validity of the CA cert since when it was signed with the same key.
You thus just have on certificate.

In a case of one intermediate CA, the DPV response may for example
contain two OCSP responses, one signed by the intermediate CA
concerning the revocation status of the end user and another
concerning the statius of the intermediate CA signed by the
top CA. 

If both CAs provide a DPV service instead of an OCSP service
in the same way, you have exactly the same situation except
that this is a positive status information. 

For example, the initial client asks for a combined status, 
it asks his own trusted service, this server asks the intermediate
CA either to provide an OCSP status or a DPV status of the
cert in question and then asks the top CA to provide a status of
the intermediate CA's cert, and well, even three other OCSP
responders to provide statement that the top level 
CA's cert is good. 

DPV would allow to combine the responses differently. 
It can well be that the intermediate CA/DPV responder
itself asks for a DPV response from the top CA/DPV
and include this in his DPV response to the initial server.  
  
> 
> There are no similarities.
"Ok, let's talk." 

> > I think that there must be a language problem somewhere because I
> > fail to see what *not* you are referring, i.e. to see where we are
> > in disagreement.  I have not said that it is necessary for the client
> > to gather all information. I have said that the protocol must provide
> > a method to allow a client to ask and the server to respond with that
> > information.
> 
> Maybe, since we possibly interpreted diffrently "what has contributed to the
> final decision".
> 
> > > In case of a dispute, testing again the certificate validity, means that
> > > certificates, CRLs and OCSP responses must be available. Anything else is
> > > useless.
>  
> > I think that this may be the core of our disagreement.
>  
> > This is because you only accept that CA can create assertions about the
> > validity of their certificates using CRLs and OCSP. 
> 
> Correct.

Unfortunately we may be both wrong.  
 
> > As soon as you would
> > admit that some new protocol or service is provided that enhances and in
> > particular replaces them, the statements obtained via that service are
> > necessary.
> 
> > I would like to know what you would have said 5 years ago when only
> > CRLs existed.
> 
> Basicaly the chain must be verified and no element fom the chain must be
> revoked. 
> 
> Five years ago this information was provided off-line, i.e. via CRLs. OCSP
> allows to obtain the same information on-line. Between on-line and off-line
> I currently see no other mechanism. 

But you can have different protocols for these characteristics. Offline
you could use trees, online you can have DPV, or other techniques like
timestamps over CRLs and OCSP responses to have a proof that the server 
has provided the OCSPresp/CRL at a current date. 

> The basic question is whether first-hand information and second-hand
> information should be used. In case of a dispute, only first-hand
> information is useful (certificates and revocation status information from
> the CAs responsible for every certificate from the chain). DPV responses
> (i.e. the signed "yes" answers) are useless, unless the plaintiff and the
> defendant both trust the same DPV server.

OCSP responses may also be useless, unless the plaintiff and the
defendant both trust the same OCSP server. 

Peter






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AHT0u08746 for ietf-pkix-bks; Wed, 10 Apr 2002 10:29:00 -0700 (PDT)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AHT0m08741 for <[e-mail]>; Wed, 10 Apr 2002 10:29:00 -0700 (PDT)
Received: from SJOSEPH (pcp237514pcs.elictc01.md.comcast.net [68.55.160.145]) by mtaout01.icomcast.net (iPlanet Messaging Server 5.1 (built Feb  6 2002)) with SMTP id <[e-mail]> for [e-mail]; Wed, 10 Apr 2002 13:28:57 -0400 (EDT)
Date: Wed, 10 Apr 2002 13:28:43 -0400
From: Al Arsenault <[e-mail]>
Subject: Re: WG Last Call: Roadmap
To: Tom Gindin <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-id: <002a01c1e0b5$2a48c8c0$6401a8c0@SJOSEPH>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <[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>

Tom,

    Going back to how that discussion got started lo those many years ago,
the problem was that different PKIX documents used the term "root CA" to
mean different things.  Most of them used it to mean "trust anchor" or some
similar thing; i.e., "this is the CA that you base all of your trust on as
an RP" (and yes, in a large complex PKI system there might be more than one
of these); a few used it as a synonym for "top CA"; i.e., the thing at the
top of a hierarchy.

    After much discussion on this list, the terms as they now appear in the
Roadmap document were agreed to (okay, it was pretty darned rough consensus,
but it was as good as we were gonna get at that time).  This made the
Roadmap pretty consistent with other PKIX documents, and I think "best
efforts" were made to bring the usage in the other documents into line over
the years.

    So I'd be really hestitant to change the terminology in the Roadmap
now - it'd just bring up the same old issue again, and cause the roadmap to
be inconsistent with (almost) all of the other PKIX documents - which is not
something I'd want.

    Thanks,

            Al Arsenault


----- Original Message -----
From: "Tom Gindin" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, April 10, 2002 10:41 AM
Subject: Re: WG Last Call: Roadmap


>
>
>       It is obviously important that this document get finalized fairly
> soon.  The only question we have outstanding is whether "root CA" as
> defined would be better replaced by "anchor CA" or "trust anchor".  This
> should not block the document for more than a day or two, but I think it
> worthwhile to find out what you think the difference is.  The term "root
> CA" as "root of trust" has caused some confusion in these discussions, and
> if there's a better term which is in fairly common use (as "anchor" is) we
> should use it.  If there's a real difference, we should keep "root CA".
In
> case it's not obvious, the term "anchor CA" means "a trust anchor which is
> a CA" - which assumes that trust anchors could be defined in such a way
> that they might be EE's or even AA's.
>
>             Tom Gindin
>
>
> Denis Pinkas <[e-mail]> on 04/09/2002 12:00:26 PM
>
> To:    Tom Gindin/Watson/IBM@IBMUS
> cc:    [e-mail]
> Subject:    Re: WG Last Call: Roadmap
>
>
> Tom,
>
> >       Denis:
> >
> >       Should we really standardize on the term "root CA" rather than
> "trust
> > anchor" or "anchor CA"?
>
> I do not care, but I care for this document to be sent to the IESG soon.
So
> the sooner we may find a compromise, the better. Maybe the quickest way
> is to try to suppress the sentences that create problems. We should
> focuss on text replacement proposals.
>
> > "Trust anchor" has never been used to mean anything other than an entity
> directly trusted by the RP, AFAIK.
>
> Not exactly. Read this sentence again.  However, I would like to resist to
> start a new discusion now on trust anchors.
>
> > I have other comments below.
> >
> >             Tom Gindin
> >
> > Denis Pinkas <[e-mail]> on 04/08/2002 12:32:41 PM
> >
> > To:    Tom Gindin/Watson/IBM@IBMUS
> > cc:    [e-mail]
> > Subject:    Re: WG Last Call: Roadmap
> >
> > Tom,
> >
> > I have not forgotten this message, but I gave priority to the DPV
thread.
> >
> > >       Responses below.
> >
> > > The issue of who specifies the verifier's policy is
> > > rather serious.  If the policy to be used is expected to be the same
as
> > RFC
> > > 3126's SignaturePolicy, we need to specify a step in which the
verifier
> > has
> > > the right to reject such a policy or to consider it inapplicable to
the
> > > verifier's own current context.
> >
> > This is true. However, the text does not go at that level of detail:
> >
> > "Another model considers a set of rules that apply to an application
> > context. Every application context may have a different set of rules.
> > When choosing to use certificates in the context of that application,
> > the EE selects the set of rules for that context. In a set of rules,
> > one or more Top CAs may be trusted, each one may be associated with
> > different constraints, like the certificate policies that are trusted
> > or the naming constraints that apply. These constrains may be specified
> > either in self-signed certificates or in addition to self-signed
> > certificates when they do not incorporate these constraints. This set
> > of rules is called a validation policy (when validating a certificate)
> > or a signature policy (when validating a digital signature)."
> >
> > I do not think it is necesary to state it. If you think so, please
> provide
> > a text and a placement for that text.
> >
> > [TG] My biggest problem is the use of the term "signature policy", which
> > you have elsewhere defined as something defined and signed by the signer
> of
> > the document.
>
> There is a misunderstanding. A signer may provide the *reference* of the
> signature policy that he agrees to use when signing. In order to prevent
> someone else to change that reference, it is protected by the signer's
> signature. So in that case the verifier has first to see whether the
> signature policy used by the signer is appropriate for his application
> context. If it is the case, then it uses it, otherwise this is the end of
> the story.
>
> [TG] He mainly needs to check whether it's an approved signature policy by
> his personal or organizational criteria.
>
> > In the paragraph above, I would replace the term "Top CAs"
> > by "root CA's",
>
> No problem.
>
> > and I would also call the sets of rules in the last
> > sentence a "certificate validation policy" and a "signature validation
> > policy".  I would then add the following statement: "Neither of these
> > policies is considered to be the same as either a CertificatePolicy as
> > defined in RFC 2459 or a SignaturePolicy as defined in RFC 3126."
>
> I would simply propose to delete the following sentence:
>
> "This set of rules is called a validation policy (when validating a
> certificate) or a signature policy (when validating a digital signature)"
> not because it is wrong, but because I would like this document to
proceed.
>
> This would lead to the following text:
>
> "Another model considers a set of rules that apply to an application
> context. Every application context may have a different set of rules.
> When choosing to use certificates in the context of that application,
> the EE selects the set of rules for that context. In a set of rules,
> one or more root CAs may be trusted, each one may be associated with
> different constraints, like the certificate policies that are trusted
> or the naming constraints that apply. These constrains may be specified
> either in self-signed certificates or in addition to self-signed
> certificates when they do not incorporate these constraints."
>
> Can you live with it ?
>
> [TG] Sure.
>
> > > To:    Tom Gindin/Watson/IBM@IBMUS
> > > cc:    [e-mail]
> > > Subject:    Re: WG Last Call: Roadmap
> > >
> > > Tom,
> > >
> > > >       I have a few issues with this, and some corrections as well.
> > >
> > > >       In comment 12, I have two issues.  The first one, which is
> minor,
> > > is
> > > > that  "one or more Top CA's may be trusted" should refer to root
CA's
> > > > instead - the two terms mean the same thing more often than not, but
> > when
> > > > they differ the trust point is the root rather than the top.
> > >
> > > PKIX-1 states:
> > >
> > >    " - Top CA - A CA that is at the top of a PKI hierarchy.
> > >
> > >    Note: This is often also called a "Root CA," since in data
> structures
> > >    terms and in graph theory, the node at the top of a tree is the
> > >    "root." However, to minimize confusion in this document, we elect
to
> > >    call this node a "Top CA," and reserve "Root CA" for the CA
directly
> > >    trusted by the EE."
> > >
> > > The problem lies with the last sentence, i.e. "*the* CA directly
> trusted
> > by
> > > the EE.". The singular is being used which means that there is a
single
> > > one, multiple roots are not permitted, while multiple Top-CAs are
> > > permitted.
> > >
> > > [TG] Where in PKIX-1 is this?  I can't find the phrase "directly
> trusted"
> > > in either RFC 2459 or in draft 12 of new-pkix-1.
> >
> > Sorry for the confusion: it is in the roadmap document, not PKIX-1.
> >
> > The current text in the roadmap is:
> >
> >     " - Root CA - A CA that is directly trusted by an EE; that is,
> >        securely acquiring the value of a Root CA public key requires
> >        some out-of-band step(s). This term is not meant to imply that a
> >        Root CA is necessarily at the top of any hierarchy, simply that
> >        the CA in question is trusted directly.
> >
> > (...)
> >
> >    Note: This is often also called a "Root CA," since in data structures
> >    terms and in graph theory, the node at the top of a tree is the
> >    "root." However, to minimize confusion in this document, we elect to
> >    call this node a "Top CA," and reserve "Root CA" for the CA directly
> >    trusted by the EE. Readers new to PKIX should be aware that these
> >    terms are not used consistently throughout the PKIX documents, as the
> >    Internet PKI profile [2459bis] uses "Root CA" to refer to what this
> >    and other documents call a "Top CA," and "most-trusted CA" to refer
> >    to what this and other documents call a "Root CA."
> >
> > There is no problem with PKIX-1 but a problem with the roadmap document.
> > PKIX-1 does not use the term "root CA", and thus it is wrong to say in
> > the roadmap that "these terms are not used consistently throughout the
> > PKIX documents".
> >
> > I would thus propose to change the note in the following way:
> >
> >    Note: Since in data structures terms and in graph theory, the node
> >    at the top of a tree is the "root", the term "root CA" is sometimes
> >    used. This term is not meant to imply that a Root CA is necessarily
> >    at the top of any hierarchy, simply that the CA in question is
trusted
> >    directly.
> >
> > [TG] As I stated at the beginning, I don't know why we should
standardize
> > on the term "root CA" rather than "trust anchor" or "anchor CA".  Those
> > terms cannot be mistaken for what is defined here as a "Top CA".  BTW, I
> > approve of that coinage.
>
> We do use "root CA", so I see no harm to use that vocabulary. This is no
> attempt to standardize this term here. Originally my single concern what
> that the text was talking about *one* root CA whereas there can be
> multiple.
> This was my ONLY concern. This is now fixed. We should close this issue
> ASAP.
>
> Denis
>
> > Then, on page 14, change:
> >
> >    Additionally, once the Root CA ...
> >
> > with
> >
> >    Additionally, once a Root CA ...
> >
> > on pages 29 and 30, change:
> >
> >    (e.g., the DVCS's CA, or the Root CA in a
> >    hierarchy)
> >
> > with
> >
> >    (e.g., the DVCS's CA, or a Root CA)
> >
> > Regards,
> >
> > Denis
> >
> > (snip)
>
>
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AHQvK08644 for ietf-pkix-bks; Wed, 10 Apr 2002 10:26:57 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AHQtm08639 for <[e-mail]>; Wed, 10 Apr 2002 10:26:56 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA24144; Wed, 10 Apr 2002 19:29:31 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041018470575:399 ; Wed, 10 Apr 2002 18:47:05 +0200 
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 18:47:04 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 18:47:05, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 19:26:57, Serialize complete at 10/04/2002 19:26:57
Content-Transfer-Encoding: 7bit
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>

Peter,

> > I now understand why we disagree.

> good.

> > This service does *not* need to be provided by a CA. It can be provided by
> > any service provider that the client is willing to trust. The case where it
> > would be provided by a CA, would be a very specific case. In order to
> > resolve disputes, the "proof" must directly come from the CAs. This means
> > that CRLs as well as OCSP responses must be provided by CAs (or authorities
> > empowered by the CAs). DPV responses would be of no value.
 
> 'directly come from' is not exactly defined.
 
> In OCSP, you have that either the response is signed by the same entity that
> signed the certificate or by an OCSP entity which has a certificate directly
> signed by the CA in question with some extended key usage.

True.
 
> To make the simple case, if a DPV response is signed directly by the CA
> (or by an authorised responder), you have the same situation.

No. A CA can only assert information about what it is directly responsible.
No CA is responsible for all the certifiactes from one path. An OCSP query
is for ONE certificate, while a DPV query involves a CHAIN of certificates.

There are no similarities.
 
> (text deleted)
> 
> > > > > Since you haven't commented the next paragraph may I assume that
> > > > > this is ok with you?
> > > >
> > > > > > > I think the general principle should be that there is one mode
> > > > > > > that all information essential to understand what has contributed
> > > > > > > to the final decision must be made available to the client.
> > > > > > > (Not necessarily understood by the client).
> > > >
> > > > No. It is always necessary to provide a yes/no/unknown answer (or an error).
> > > > It is optional to provide all the information essential to test again the
> > > > certificate validity, should another party not simply trust the signed "yes"
> > > > answer. It is certainly not necessary for the client to understand what has
> > > > contributed to the final decision.
> > >
> > > What is 'no':
> >
> > It is *not* necessary for the client to gather all the information that has
> > contributed to the final decision; i.e. relayed DPV responses, if any, are
> > not needed.
> >
> > > Where did I say that yes/no/unknown is NOT necessary? (is this the reason
> > > for the no?) In the remainder you just rephrase what I have said.
> >
> > With a *not*, which makes a big difference.

> I think that there must be a language problem somewhere because I
> fail to see what *not* you are referring, i.e. to see where we are
> in disagreement.  I have not said that it is necessary for the client
> to gather all information. I have said that the protocol must provide
> a method to allow a client to ask and the server to respond with that
> information.

Maybe, since we possibly interpreted diffrently "what has contributed to the
final decision".

> > In case of a dispute, testing again the certificate validity, means that
> > certificates, CRLs and OCSP responses must be available. Anything else is
> > useless.
 
> I think that this may be the core of our disagreement.
 
> This is because you only accept that CA can create assertions about the
> validity of their certificates using CRLs and OCSP. 

Correct.

> As soon as you would
> admit that some new protocol or service is provided that enhances and in
> particular replaces them, the statements obtained via that service are
> necessary.

> I would like to know what you would have said 5 years ago when only
> CRLs existed.

Basicaly the chain must be verified and no element fom the chain must be
revoked. 

Five years ago this information was provided off-line, i.e. via CRLs. OCSP
allows to obtain the same information on-line. Between on-line and off-line
I currently see no other mechanism. 

The basic question is whether first-hand information and second-hand
information should be used. In case of a dispute, only first-hand
information is useful (certificates and revocation status information from
the CAs responsible for every certificate from the chain). DPV responses
(i.e. the signed "yes" answers) are useless, unless the plaintiff and the
defendant both trust the same DPV server.

Denis
 
> Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AGpVY07219 for ietf-pkix-bks; Wed, 10 Apr 2002 09:51:31 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGpTm07214 for <[e-mail]>; Wed, 10 Apr 2002 09:51:30 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA07077; Wed, 10 Apr 2002 18:51:27 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 10 Apr 2002 18:51:27 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA07622; Wed, 10 Apr 2002 18:51:26 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA06757; Wed, 10 Apr 2002 18:51:25 +0200 (MET DST)
Date: Wed, 10 Apr 2002 18:51:25 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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>

> 
> But isn't it likely that the evaluation of the evidence happens
> at dispute-resolution time and is done not by the run-time 
> client but by some 3rd party? If not, then the client has to
> check everything at run-time; if so, then the fact that the
> client doesn't trust the relayed-to server is moot (what 
> matters is what the evidence evaluator thinks).

Yes, my interpretation is that the client trust HIS server to 
provide all evidences that MAY allow a potential/optional 
'evidence evaluator' to determine something *without* any 
need to access to some other hidden data. 

I did not say that the evidences MUST always be sufficient,
for example, as in real life they may degradable in time. 

> I would agree though that including just a dpv response as evidence
> might be misleading unless all relayed responses can be matched
> against the original request.

It seems that Denis think that only the OCSPresp, and CRLs that
are in a response need to be provided. One can also say that
time stamped versions of these data should be provided, then
well, a DPV response itself could contain a time stamp
of the data (e.g. CRL) etc. 

> Seems a bit confused to me (but then I'm often confused:-),
Wouldn't life otherwise life be much more boaring :-) 

Peter



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AGZJQ06540 for ietf-pkix-bks; Wed, 10 Apr 2002 09:35:19 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGZHm06532 for <[e-mail]>; Wed, 10 Apr 2002 09:35:17 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA06953; Wed, 10 Apr 2002 18:35:15 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 10 Apr 2002 18:35:15 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA07525; Wed, 10 Apr 2002 18:35:14 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA06752; Wed, 10 Apr 2002 18:35:13 +0200 (MET DST)
Date: Wed, 10 Apr 2002 18:35:13 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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>

> 
> My position would be that one can be just as meaningful 
> as the other, depending on the context, and that the DPV
> protocol MUST be able to be used in contexts where the
> DPV request/response are (according to me) as good as 
> the certificates/crls/ocsp stuff.
> 

I guess this message chracterises perfectly what I have been
trying to explain.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AGWC106350 for ietf-pkix-bks; Wed, 10 Apr 2002 09:32:12 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGWAm06346 for <[e-mail]>; Wed, 10 Apr 2002 09:32:10 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA06935; Wed, 10 Apr 2002 18:32:09 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 10 Apr 2002 18:32:09 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA07514; Wed, 10 Apr 2002 18:32:08 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA06749; Wed, 10 Apr 2002 18:32:08 +0200 (MET DST)
Date: Wed, 10 Apr 2002 18:32:08 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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 now understand why we disagree.
good. 

> 
> This service does *not* need to be provided by a CA. It can be provided by
> any service provider that the client is willing to trust. The case where it
> would be provided by a CA, would be a very specific case. In order to
> resolve disputes, the "proof" must directly come from the CAs. This means
> that CRLs as well as OCSP responses must be provided by CAs (or authorities
> empowered by the CAs). DPV responses would be of no value.


'directly come from' is not exactly defined.  

In OCSP, you have that either the response is signed by the same entity that 
signed the certificate or by an OCSP entity which has a certificate directly
signed by the CA in question with some extended key usage. 

To make the simple case, if a DPV response is signed directly by the CA
(or by an authorised responder), you have the same situation. 

(text deleted)

> > > > Since you haven't commented the next paragraph may I assume that
> > > > this is ok with you?
> > >
> > > > > > I think the general principle should be that there is one mode
> > > > > > that all information essential to understand what has contributed
> > > > > > to the final decision must be made available to the client.
> > > > > > (Not necessarily understood by the client).
> > >
> > > No. It is always necessary to provide a yes/no/unknown answer (or an error).
> > > It is optional to provide all the information essential to test again the
> > > certificate validity, should another party not simply trust the signed "yes"
> > > answer. It is certainly not necessary for the client to understand what has
> > > contributed to the final decision.
> > 
> > What is 'no':
> 
> It is *not* necessary for the client to gather all the information that has
> contributed to the final decision; i.e. relayed DPV responses, if any, are
> not needed.
> 
> > Where did I say that yes/no/unknown is NOT necessary? (is this the reason
> > for the no?) In the remainder you just rephrase what I have said.
> 
> With a *not*, which makes a big difference.
I think that there must be a language problem somewhere because I
fail to see what *not* you are referring, i.e. to see where we are
in disagreement.  I have not said that it is necessary for the client
to gather all information. I have said that the protocol must provide
a method to allow a client to ask and the server to respond with that
information. 

 
> In case of a dispute, testing again the certificate validity, means that
> certificates, CRLs and OCSP responses must be available. Anything else is
> useless.

I think that this may be the core of our disagreement. 

This is because you only accept that CA can create assertions about the
validity of their certificates using CRLs and OCSP. As soon as you would 
admit that some new protocol or service is provided that enhances and in 
particular replaces them, the statements obtained via that service are
necessary. 

I would like to know what you would have said 5 years ago when only
CRLs existed.

Peter


 
 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AGMbG06085 for ietf-pkix-bks; Wed, 10 Apr 2002 09:22:37 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGMZm06080 for <[e-mail]>; Wed, 10 Apr 2002 09:22:35 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA23444; Wed, 10 Apr 2002 18:25:10 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041018120537:392 ; Wed, 10 Apr 2002 18:12:05 +0200 
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 18:12:04 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 18:12:05, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 18:22:35, Serialize complete at 10/04/2002 18:22:35
Content-Transfer-Encoding: 7bit
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>

Stephen,

> Denis,
 
> Is the core of our difference that you consider that
> showing a DPV request/response pair (say to an expert
> witness who'll then turn up in court) is not as meaningful as
> showing a bunch of certificates, CRLs and OCSP request/response
> pairs (to that same expert witness who'll then turn up in
> court)? [And s/in court/in an arbitration meeting/ or
> whatever else you prefer which avoids us discussing how
> legal things happen.]

No. It is not the core of our difference.

A court may find some DPV responses from some specific DPV servers 
as appropriate, but this cannot be a general rule. So when it is not
appropriate, certificates and revocation stauts information will be used.

> My position would be that one can be just as meaningful
> as the other, depending on the context, 

Correct.

> and that the DPV
> protocol MUST be able to be used in contexts where the
> DPV request/response are (according to me) as good as
> the certificates/crls/ocsp stuff.

So we both agree. :-)
 
> Denis Pinkas wrote:
> >
> > Stephen,
> >
> > > Denis,
> > >
> > > > I would disagree. Let me explain why. The requester only trusts the DPV
> > > > server that it has queried. The DPV server may trust any server it likes,
> > > > but the client does not care: the client does not necessarilly trust them.
> > > > The original server is the only one responsible for the "valid" signed
> > > > response. So if a DPV response from another server were included as a proof
> > > > of the "valid" response, it would not be a proof for the client. The client
> > > > needs a proof from first hand, i.e. a proof that is not disputable. This can
> > > > only be the original certification path, the original CRLs and the original
> > > > OCSP responses, with all the proofs that the CRL Issuers and the OCSP
> > > > responders are indeed empowered to provide that information.
> >
> > > But isn't it likely that the evaluation of the evidence happens
> > > at dispute-resolution time and is done not by the run-time
> > > client but by some 3rd party?
> >
> > What do you call an evidence ? Is it the signed "yes" answer or the bunch of
> > certificates, CRLs and OCSP responses ? If it is the latter, then I agree.
 
> Practically speaking any data structure can provide some level of evidence,
> certificates, CRLs and OCSP responses included, but I'd also include DPV
> request/response pairs (assuming good protocol design) as being pretty
> much as good in some contexts.

No: the client nor a disputing party will not necessarilly trust it. The
only thing that the first DPV server knows is that it is trusted by that
client, but this first DPV server is unaware of any other DPV server trusted
by that client. The only information that is not disputable is: the
certificates, CRLs and OCSP responses.
 
> > > If not, then the client has to check everything at run-time; if so,
> > > then the fact that the client doesn't trust the relayed-to server is moot
> > > (what matters is what the evidence evaluator thinks).
> >
> > We are not in that case, so this argumenation does not apply.
> 
> We are in that case, so it does apply.
> 
> (See - didn't that bring the discussion along nicely:-)
> 
> > > I would agree though that including just a dpv response as evidence
> > > might be misleading unless all relayed responses can be matched
> > > against the original request.
> >
> > Relayed responses, if any, are invisible to the first requester.
> 
> We're discussing whether this should be the case or not.
> 
> > If, as mentionned earlier, an evidence is bunch of certificates, CRLs and
> > OCSP responses, then it is not the signed "yes" answer, i.e. the core of the
> > DPV response.
 
> I can't parse that, but I think its ok if I've identified where
> our difference lies.

The difference lies in the trust conditions. I believe that trust conditions
are *not* transitive and thus would a DPV response come from a another
server, it is unlikely that the client would trust it. Now, if the server
trusts it, it is its problem and becomes fully responsible of the final
response. If it wants to make sure that everything is correct, then it
should ask for and check itself the original data used to validate the full
path: all certificates, CRLs and OCSP responses.

I hope this helps.


Denis 
 
> Stephen.
> 
> > > Seems a bit confused to me (but then I'm often confused:-),
> >
> > Indeed since your are using a term (i.e. evidence) that is not used in the
> > document.
> >
> > Denis
> >
> > > Stephen.
> > >
> > > Denis Pinkas wrote:
> > > >
> > > > Peter,
> > > >
> > > > (text deleted)
> > > >
> > > > > I refer to my proposal to change the text saying that
> > > > > that among the optional returned infos like paths CRL,
> > > > > OCSP responses, there may alos occur DPV responses.
> > > >
> > > > I would disagree. Let me explain why. The requester only trusts the DPV
> > > > server that it has queried. The DPV server may trust any server it likes,
> > > > but the client does not care: the client does not necessarilly trust them.
> > > > The original server is the only one responsible for the "valid" signed
> > > > response. So if a DPV response from another server were included as a proof
> > > > of the "valid" response, it would not be a proof for the client. The client
> > > > needs a proof from first hand, i.e. a proof that is not disputable. This can
> > > > only be the original certification path, the original CRLs and the original
> > > > OCSP responses, with all the proofs that the CRL Issuers and the OCSP
> > > > responders are indeed empowered to provide that information.
> > > >
> > > > > Encapsulating a "DPV response" in a OCSP response still
> > > > > remains an option anyway.
> > > >
> > > > Encapsulating a "DPV response" in a OCSP response is out of the scope of
> > > > this discussion.
> > > >
> > > > > > Denis
> > > >
> > > > > Since you haven't commented the next paragraph may I assume that
> > > > > this is ok with you?
> > > >
> > > > > > > I think the general principle should be that there is one mode
> > > > > > > that all information essential to understand what has contributed
> > > > > > > to the final decision must be made available to the client.
> > > > > > > (Not necessarily understood by the client).
> > > >
> > > > No. It is always necessary to provide a yes/no/unknown answer (or an error).
> > > >
> > > > It is optional to provide all the information essential to test again the
> > > > certificate validity, should another party not simply trust the signed "yes"
> > > > answer. It is certainly not necessary for the client to understand what has
> > > > contributed to the final decision.
> > > >
> > > > Denis
> > > >
> > > > > > > I would also agree, that only necessary information should be made
> > > > > > > available. It may be not necessary to inform:
> > > > > > >
> > > > > > > - Yesterday I have made three unsuccesseful attempt at time1 2 3,
> > > > > > >   the last one finally succeed by using an internet connect to
> > > > > > >   address a.b.c.d using DPV protocol over OCSP, ...
> > > > > > >
> > > > > > > Peter
> > >
> > > --
> > > ____________________________________________________________
> > > Stephen Farrell
> > > Baltimore Technologies,   tel: (direct line) [phone]
> > > 39 Parkgate Street,                     fax: [phone]
> > > Dublin 8.                mailto:[e-mail]
> > > Ireland                             http://www.baltimore.com
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AGMYj06078 for ietf-pkix-bks; Wed, 10 Apr 2002 09:22:34 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AGMVm06072 for <[e-mail]>; Wed, 10 Apr 2002 09:22:32 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA23426; Wed, 10 Apr 2002 18:25:01 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041018025265:390 ; Wed, 10 Apr 2002 18:02:52 +0200 
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 18:02:51 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Linn, John" <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>, [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 18:02:52, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 18:22:26, Serialize complete at 10/04/2002 18:22:26
Content-Transfer-Encoding: 7bit
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>

John,

> I agree with Stephen's observation.  Within a DPV environment, much of the
> rationale for being (optionally) able to return information received from
> other servers, rather than simply distilling it, is to be able to support
> audit and dispute resolution.  

You address two different needs:

  1) audit,
  2) dispute resolution.

I have addressed the later in my mail exchanges with Peter. 
So let us address the former.

There is no requirement for an audit purposes in the current document. The
DPV server is responsible for providing a right answer. If it is not able to
do so, it shall answer "unknown". The server may keep anything it wants in
audit trail, but there is no requirement to provide "audit information "
associated with the response. Currently the only requirement, in addition
with a signed "yes" answer, is:

"The DPV request MUST allow the client to request that the response 
include the certification path and revocation status information used 
by the DPV server to process the request." 

Denis

> This would normally happen on an exception
> basis, and its verifier may well be different from the client that requested
> the DPV response.
> 
> --jl
> 
> > -----Original Message-----
> > From: Stephen Farrell [mailto:[e-mail]]
> > Sent: Wednesday, April 10, 2002 11:02 AM
> > To: Denis Pinkas
> > Cc: Peter Sylvester; [e-mail]
> > Subject: Re: Open issue: DPV relay
> >
> >
> >
> >
> > Denis,
> >
> > > I would disagree. Let me explain why. The requester only
> > trusts the DPV
> > > server that it has queried. The DPV server may trust any
> > server it likes,
> > > but the client does not care: the client does not
> > necessarilly trust them.
> > > The original server is the only one responsible for the
> > "valid" signed
> > > response. So if a DPV response from another server were
> > included as a proof
> > > of the "valid" response, it would not be a proof for the
> > client. The client
> > > needs a proof from first hand, i.e. a proof that is not
> > disputable. This can
> > > only be the original certification path, the original CRLs
> > and the original
> > > OCSP responses, with all the proofs that the CRL Issuers
> > and the OCSP
> > > responders are indeed empowered to provide that information.
> >
> > But isn't it likely that the evaluation of the evidence happens
> > at dispute-resolution time and is done not by the run-time
> > client but by some 3rd party? If not, then the client has to
> > check everything at run-time; if so, then the fact that the
> > client doesn't trust the relayed-to server is moot (what
> > matters is what the evidence evaluator thinks).
> >
> > I would agree though that including just a dpv response as evidence
> > might be misleading unless all relayed responses can be matched
> > against the original request.
> >
> > Seems a bit confused to me (but then I'm often confused:-),
> > Stephen.
> >
> > Denis Pinkas wrote:
> > >
> > > Peter,
> > >
> > > (text deleted)
> > >
> > > > I refer to my proposal to change the text saying that
> > > > that among the optional returned infos like paths CRL,
> > > > OCSP responses, there may alos occur DPV responses.
> > >
> > > I would disagree. Let me explain why. The requester only
> > trusts the DPV
> > > server that it has queried. The DPV server may trust any
> > server it likes,
> > > but the client does not care: the client does not
> > necessarilly trust them.
> > > The original server is the only one responsible for the
> > "valid" signed
> > > response. So if a DPV response from another server were
> > included as a proof
> > > of the "valid" response, it would not be a proof for the
> > client. The client
> > > needs a proof from first hand, i.e. a proof that is not
> > disputable. This can
> > > only be the original certification path, the original CRLs
> > and the original
> > > OCSP responses, with all the proofs that the CRL Issuers
> > and the OCSP
> > > responders are indeed empowered to provide that information.
> > >
> > > > Encapsulating a "DPV response" in a OCSP response still
> > > > remains an option anyway.
> > >
> > > Encapsulating a "DPV response" in a OCSP response is out of
> > the scope of
> > > this discussion.
> > >
> > > > > Denis
> > >
> > > > Since you haven't commented the next paragraph may I assume that
> > > > this is ok with you?
> > >
> > > > > > I think the general principle should be that there is one mode
> > > > > > that all information essential to understand what has
> > contributed
> > > > > > to the final decision must be made available to the client.
> > > > > > (Not necessarily understood by the client).
> > >
> > > No. It is always necessary to provide a yes/no/unknown
> > answer (or an error).
> > >
> > > It is optional to provide all the information essential to
> > test again the
> > > certificate validity, should another party not simply trust
> > the signed "yes"
> > > answer. It is certainly not necessary for the client to
> > understand what has
> > > contributed to the final decision.
> > >
> > > Denis
> > >
> > > > > > I would also agree, that only necessary information
> > should be made
> > > > > > available. It may be not necessary to inform:
> > > > > >
> > > > > > - Yesterday I have made three unsuccesseful attempt
> > at time1 2 3,
> > > > > >   the last one finally succeed by using an internet connect to
> > > > > >   address a.b.c.d using DPV protocol over OCSP, ...
> > > > > >
> > > > > > Peter
> >
> > --
> > ____________________________________________________________
> > Stephen Farrell
> > Baltimore Technologies,   tel: (direct line) [phone]
> > 39 Parkgate Street,                     fax: [phone]
> > Dublin 8.                mailto:[e-mail]
> > Ireland                             http://www.baltimore.com
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AFh7E01555 for ietf-pkix-bks; Wed, 10 Apr 2002 08:43:07 -0700 (PDT)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AFh4m01551 for <[e-mail]>; Wed, 10 Apr 2002 08:43:05 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3AFh5b32403 for <[e-mail]>; Wed, 10 Apr 2002 16:43:05 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Wed, 10 Apr 2002 16:37:41 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA07530; Wed, 10 Apr 2002 16:43:03 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 16:43:08 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

Denis,

Is the core of our difference that you consider that
showing a DPV request/response pair (say to an expert 
witness who'll then turn up in court) is not as meaningful as 
showing a bunch of certificates, CRLs and OCSP request/response
pairs (to that same expert witness who'll then turn up in 
court)? [And s/in court/in an arbitration meeting/ or 
whatever else you prefer which avoids us discussing how 
legal things happen.] 

My position would be that one can be just as meaningful 
as the other, depending on the context, and that the DPV
protocol MUST be able to be used in contexts where the
DPV request/response are (according to me) as good as 
the certificates/crls/ocsp stuff.

Denis Pinkas wrote:
> 
> Stephen,
> 
> > Denis,
> >
> > > I would disagree. Let me explain why. The requester only trusts the DPV
> > > server that it has queried. The DPV server may trust any server it likes,
> > > but the client does not care: the client does not necessarilly trust them.
> > > The original server is the only one responsible for the "valid" signed
> > > response. So if a DPV response from another server were included as a proof
> > > of the "valid" response, it would not be a proof for the client. The client
> > > needs a proof from first hand, i.e. a proof that is not disputable. This can
> > > only be the original certification path, the original CRLs and the original
> > > OCSP responses, with all the proofs that the CRL Issuers and the OCSP
> > > responders are indeed empowered to provide that information.
> 
> > But isn't it likely that the evaluation of the evidence happens
> > at dispute-resolution time and is done not by the run-time
> > client but by some 3rd party?
> 
> What do you call an evidence ? Is it the signed "yes" answer or the bunch of
> certificates, CRLs and OCSP responses ? If it is the latter, then I agree.

Practically speaking any data structure can provide some level of evidence,
certificates, CRLs and OCSP responses included, but I'd also include DPV
request/response pairs (assuming good protocol design) as being pretty
much as good in some contexts.

> > If not, then the client has to check everything at run-time; if so,
> > then the fact that the client doesn't trust the relayed-to server is moot
> > (what matters is what the evidence evaluator thinks).
> 
> We are not in that case, so this argumenation does not apply.

We are in that case, so it does apply. 

(See - didn't that bring the discussion along nicely:-)

> > I would agree though that including just a dpv response as evidence
> > might be misleading unless all relayed responses can be matched
> > against the original request.
> 
> Relayed responses, if any, are invisible to the first requester.

We're discussing whether this should be the case or not.

> If, as mentionned earlier, an evidence is bunch of certificates, CRLs and
> OCSP responses, then it is not the signed "yes" answer, i.e. the core of the
> DPV response.

I can't parse that, but I think its ok if I've identified where
our difference lies.

Stephen.

> > Seems a bit confused to me (but then I'm often confused:-),
> 
> Indeed since your are using a term (i.e. evidence) that is not used in the
> document.
> 
> Denis
> 
> > Stephen.
> >
> > Denis Pinkas wrote:
> > >
> > > Peter,
> > >
> > > (text deleted)
> > >
> > > > I refer to my proposal to change the text saying that
> > > > that among the optional returned infos like paths CRL,
> > > > OCSP responses, there may alos occur DPV responses.
> > >
> > > I would disagree. Let me explain why. The requester only trusts the DPV
> > > server that it has queried. The DPV server may trust any server it likes,
> > > but the client does not care: the client does not necessarilly trust them.
> > > The original server is the only one responsible for the "valid" signed
> > > response. So if a DPV response from another server were included as a proof
> > > of the "valid" response, it would not be a proof for the client. The client
> > > needs a proof from first hand, i.e. a proof that is not disputable. This can
> > > only be the original certification path, the original CRLs and the original
> > > OCSP responses, with all the proofs that the CRL Issuers and the OCSP
> > > responders are indeed empowered to provide that information.
> > >
> > > > Encapsulating a "DPV response" in a OCSP response still
> > > > remains an option anyway.
> > >
> > > Encapsulating a "DPV response" in a OCSP response is out of the scope of
> > > this discussion.
> > >
> > > > > Denis
> > >
> > > > Since you haven't commented the next paragraph may I assume that
> > > > this is ok with you?
> > >
> > > > > > I think the general principle should be that there is one mode
> > > > > > that all information essential to understand what has contributed
> > > > > > to the final decision must be made available to the client.
> > > > > > (Not necessarily understood by the client).
> > >
> > > No. It is always necessary to provide a yes/no/unknown answer (or an error).
> > >
> > > It is optional to provide all the information essential to test again the
> > > certificate validity, should another party not simply trust the signed "yes"
> > > answer. It is certainly not necessary for the client to understand what has
> > > contributed to the final decision.
> > >
> > > Denis
> > >
> > > > > > I would also agree, that only necessary information should be made
> > > > > > available. It may be not necessary to inform:
> > > > > >
> > > > > > - Yesterday I have made three unsuccesseful attempt at time1 2 3,
> > > > > >   the last one finally succeed by using an internet connect to
> > > > > >   address a.b.c.d using DPV protocol over OCSP, ...
> > > > > >
> > > > > > Peter
> >
> > --
> > ____________________________________________________________
> > Stephen Farrell
> > Baltimore Technologies,   tel: (direct line) [phone]
> > 39 Parkgate Street,                     fax: [phone]
> > Dublin 8.                mailto:[e-mail]
> > Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AFfgC01485 for ietf-pkix-bks; Wed, 10 Apr 2002 08:41:42 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AFfem01481 for <[e-mail]>; Wed, 10 Apr 2002 08:41:40 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA17050; Wed, 10 Apr 2002 17:44:15 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041017412420:387 ; Wed, 10 Apr 2002 17:41:24 +0200 
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 17:41:22 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 17:41:24, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 17:41:41, Serialize complete at 10/04/2002 17:41:41
Content-Transfer-Encoding: 7bit
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>

Peter,

> > Peter,
> >
> > (text deleted)
> >
> > > I refer to my proposal to change the text saying that
> > > that among the optional returned infos like paths CRL,
> > > OCSP responses, there may alos occur DPV responses.
> >
> > I would disagree. Let me explain why. The requester only trusts the DPV
> > server that it has queried. The DPV server may trust any server it likes,
> > but the client does not care: the client does not necessarilly trust them.
> > The original server is the only one responsible for the "valid" signed
> > response. So if a DPV response from another server were included as a proof
> > of the "valid" response, it would not be a proof for the client. The client
> > needs a proof from first hand, i.e. a proof that is not disputable. This can
> > only be the original certification path, the original CRLs and the original
> > OCSP responses, with all the proofs that the CRL Issuers and the OCSP
> > responders are indeed empowered to provide that information.
 
> I disagree when you say 'this can *only* be'. You assume implicitly that
> the only service providable by CAs are CRLs and/or OCSP. So far,
> DPV has been designed in a way that instead of providing an OCSP service
> through whatever structure, a CA can provide a quite similar service
> using DPV.

I now understand why we disagree.

This service does *not* need to be provided by a CA. It can be provided by
any service provider that the client is willing to trust. The case where it
would be provided by a CA, would be a very specific case. In order to
resolve disputes, the "proof" must directly come from the CAs. This means
that CRLs as well as OCSP responses must be provided by CAs (or authorities
empowered by the CAs). DPV responses would be of no value.
 
> > > Encapsulating a "DPV response" in a OCSP response still
> > > remains an option anyway.
> >
> > Encapsulating a "DPV response" in a OCSP response is out of the scope of
> > this discussion.

> I am not discussing this, I just reminded that in order to formally
> respond to the actual text, it is always possible to create
> an OCSP response together with an indication about the existance
> of the cert, and one may or not call this *DPV* response.

Certainly not. The full path is being checked, not a single certificate.

> Or: If one would take the DPV proposal of OCSP-V2 as a potential
> implementation there would be conformance of 'only OCSP responses'
> and at the same time there would be DPV reponses.

There is no more a standing OCSP-v2 proposal today.

> > > Since you haven't commented the next paragraph may I assume that
> > > this is ok with you?
> >
> > > > > I think the general principle should be that there is one mode
> > > > > that all information essential to understand what has contributed
> > > > > to the final decision must be made available to the client.
> > > > > (Not necessarily understood by the client).
> >
> > No. It is always necessary to provide a yes/no/unknown answer (or an error).
> > It is optional to provide all the information essential to test again the
> > certificate validity, should another party not simply trust the signed "yes"
> > answer. It is certainly not necessary for the client to understand what has
> > contributed to the final decision.
> 
> What is 'no':

It is *not* necessary for the client to gather all the information that has
contributed to the final decision; i.e. relayed DPV responses, if any, are
not needed.

> Where did I say that yes/no/unknown is NOT necessary? (is this the reason
> for the no?) In the remainder you just rephrase what I have said.

With a *not*, which makes a big difference.

In case of a dispute, testing again the certificate validity, means that
certificates, CRLs and OCSP responses must be available. Anything else is
useless.

Denis.
 
> 'it is optional'  == "there is one mode"
> 'all the information essential'  idem
> 'Not necessarily understood by the client'  == last sentence.
> 
> >
> > Denis
> >
> > > > > I would also agree, that only necessary information should be made
> > > > > available. It may be not necessary to inform:
> > > > >
> > > > > - Yesterday I have made three unsuccesseful attempt at time1 2 3,
> > > > >   the last one finally succeed by using an internet connect to
> > > > >   address a.b.c.d using DPV protocol over OCSP, ...
> > > > >
> > > > > Peter
> >


Received: by above.proper.com (8.11.6/8.11.3) id g3AFWWF01247 for ietf-pkix-bks; Wed, 10 Apr 2002 08:32:32 -0700 (PDT)
Received: from phaos.com (phaos.com [161.58.151.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AFWVm01243 for <[e-mail]>; Wed, 10 Apr 2002 08:32:31 -0700 (PDT)
Received: from phaos_arik.phaos.com ([198.78.132.60]) by phaos.com (8.11.6) id g3AFWWO34627; Wed, 10 Apr 2002 09:32:32 -0600 (MDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 10 Apr 2002 11:33:18 -0400
To: Al Arsenault <[e-mail]>, [e-mail]
From: Ari Kermaier <[e-mail]>
Subject: Re: CMP Interoperability Question
Cc: Alfred Arsenault <[e-mail]>
In-Reply-To: <029301c1e086$348d00a0$6401a8c0@SJOSEPH>
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>

Yes, our CMP toolkit lets you build any sort of CA, RA or EE component you 
like -- policies enforcing who is permitted to sign what are mostly left up 
to the application developer.

Ari Kermaier
Senior Software Engineer
Phaos Technology Corp.
http://www.phaos.com/

>Folks,
>
>     I'm looking for some information, so I figured that this might be the 
> fastest way to do an "informal survey".
>
>     For those who have implemented CMP, the question is: Does your 
> implementation support CAs who sign CMP messages (e.g., cp, ip, ...) 
> using a different key than they use to sign certificates?
>
>     The reason for asking this: we tend to believe that they private 
> signing key used to sign certificates and revocation information (CRLs, 
> OCSP responses) should ONLY be used for that purpose.  The CA has a 
> separate key to use for secure communications, including signing CMP 
> responses. (I can't find anything in the spec - either RFC2510 or 
> son-of-2510 - that addresses this at all. My apologies if I just missed a 
> section.)
>
>     The problem was that a little informal testing showed a problem.  We 
> had a "brand X" RA send our CA a cr message.  The CA responded with a 
> cp.  The RA rejected the cp, apparently because it wasn't signed with the 
> same key used to sign certs/CRLs.  (We're investigating to find out what 
> the exact conditions for success are; e.g., does the CMP cp message have 
> to be signed with the same key the cert contained in the message is 
> signed with; or do basic constraints and/or specific key usage values 
> have to be set in the signing cert.)
>
>     So, for you CMP implementors - would your code reject a cp or other 
> message from a CA, if it was:
>
>     - signed with a key other than that used by the CA to sign certs?
>     - signed with a key that  matched a certificate without 
> basicConstraints set to CA?
>     - signed with a key without keyUsage set to some magic value?
>
>     Thanks for any information you can provide,
>
>                 Al Arsenault
>                 Chief Security Architect
>                 Diversinet Corp.
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AFJCq00836 for ietf-pkix-bks; Wed, 10 Apr 2002 08:19:12 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AFJAm00832 for <[e-mail]>; Wed, 10 Apr 2002 08:19:10 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA13974; Wed, 10 Apr 2002 17:21:44 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041017181324:384 ; Wed, 10 Apr 2002 17:18:13 +0200 
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 17:18:11 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 17:18:13, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 17:19:09, Serialize complete at 10/04/2002 17:19:09
Content-Transfer-Encoding: 7bit
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>

Stephen,

> Denis,
> 
> > I would disagree. Let me explain why. The requester only trusts the DPV
> > server that it has queried. The DPV server may trust any server it likes,
> > but the client does not care: the client does not necessarilly trust them.
> > The original server is the only one responsible for the "valid" signed
> > response. So if a DPV response from another server were included as a proof
> > of the "valid" response, it would not be a proof for the client. The client
> > needs a proof from first hand, i.e. a proof that is not disputable. This can
> > only be the original certification path, the original CRLs and the original
> > OCSP responses, with all the proofs that the CRL Issuers and the OCSP
> > responders are indeed empowered to provide that information.
 
> But isn't it likely that the evaluation of the evidence happens
> at dispute-resolution time and is done not by the run-time
> client but by some 3rd party? 

What do you call an evidence ? Is it the signed "yes" answer or the bunch of
certificates, CRLs and OCSP responses ? If it is the latter, then I agree.

> If not, then the client has to check everything at run-time; if so, 
> then the fact that the client doesn't trust the relayed-to server is moot 
> (what matters is what the evidence evaluator thinks).

We are not in that case, so this argumenation does not apply.

> I would agree though that including just a dpv response as evidence
> might be misleading unless all relayed responses can be matched
> against the original request.

Relayed responses, if any, are invisible to the first requester.

If, as mentionned earlier, an evidence is bunch of certificates, CRLs and
OCSP responses, then it is not the signed "yes" answer, i.e. the core of the
DPV response.

> Seems a bit confused to me (but then I'm often confused:-),

Indeed since your are using a term (i.e. evidence) that is not used in the
document.

Denis

> Stephen.
> 
> Denis Pinkas wrote:
> >
> > Peter,
> >
> > (text deleted)
> >
> > > I refer to my proposal to change the text saying that
> > > that among the optional returned infos like paths CRL,
> > > OCSP responses, there may alos occur DPV responses.
> >
> > I would disagree. Let me explain why. The requester only trusts the DPV
> > server that it has queried. The DPV server may trust any server it likes,
> > but the client does not care: the client does not necessarilly trust them.
> > The original server is the only one responsible for the "valid" signed
> > response. So if a DPV response from another server were included as a proof
> > of the "valid" response, it would not be a proof for the client. The client
> > needs a proof from first hand, i.e. a proof that is not disputable. This can
> > only be the original certification path, the original CRLs and the original
> > OCSP responses, with all the proofs that the CRL Issuers and the OCSP
> > responders are indeed empowered to provide that information.
> >
> > > Encapsulating a "DPV response" in a OCSP response still
> > > remains an option anyway.
> >
> > Encapsulating a "DPV response" in a OCSP response is out of the scope of
> > this discussion.
> >
> > > > Denis
> >
> > > Since you haven't commented the next paragraph may I assume that
> > > this is ok with you?
> >
> > > > > I think the general principle should be that there is one mode
> > > > > that all information essential to understand what has contributed
> > > > > to the final decision must be made available to the client.
> > > > > (Not necessarily understood by the client).
> >
> > No. It is always necessary to provide a yes/no/unknown answer (or an error).
> >
> > It is optional to provide all the information essential to test again the
> > certificate validity, should another party not simply trust the signed "yes"
> > answer. It is certainly not necessary for the client to understand what has
> > contributed to the final decision.
> >
> > Denis
> >
> > > > > I would also agree, that only necessary information should be made
> > > > > available. It may be not necessary to inform:
> > > > >
> > > > > - Yesterday I have made three unsuccesseful attempt at time1 2 3,
> > > > >   the last one finally succeed by using an internet connect to
> > > > >   address a.b.c.d using DPV protocol over OCSP, ...
> > > > >
> > > > > Peter
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AFHN800793 for ietf-pkix-bks; Wed, 10 Apr 2002 08:17:23 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g3AFHLm00789 for <[e-mail]>; Wed, 10 Apr 2002 08:17:21 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 10 Apr 2002 15:16:20 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA11270; Wed, 10 Apr 2002 11:16:08 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g3AFHIu26873; Wed, 10 Apr 2002 11:17:19 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1Q8HF>; Wed, 10 Apr 2002 11:14:51 -0400
Message-ID: <[e-mail]>
From: "Linn, John" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Cc: [e-mail]
Subject: RE: Open issue: DPV relay
Date: Wed, 10 Apr 2002 11:16:55 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
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 Stephen's observation.  Within a DPV environment, much of the
rationale for being (optionally) able to return information received from
other servers, rather than simply distilling it, is to be able to support
audit and dispute resolution.  This would normally happen on an exception
basis, and its verifier may well be different from the client that requested
the DPV response.  

--jl

> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Wednesday, April 10, 2002 11:02 AM
> To: Denis Pinkas
> Cc: Peter Sylvester; [e-mail]
> Subject: Re: Open issue: DPV relay
> 
> 
> 
> 
> Denis,
> 
> > I would disagree. Let me explain why. The requester only 
> trusts the DPV
> > server that it has queried. The DPV server may trust any 
> server it likes,
> > but the client does not care: the client does not 
> necessarilly trust them.
> > The original server is the only one responsible for the 
> "valid" signed
> > response. So if a DPV response from another server were 
> included as a proof
> > of the "valid" response, it would not be a proof for the 
> client. The client
> > needs a proof from first hand, i.e. a proof that is not 
> disputable. This can
> > only be the original certification path, the original CRLs 
> and the original
> > OCSP responses, with all the proofs that the CRL Issuers 
> and the OCSP
> > responders are indeed empowered to provide that information.
> 
> But isn't it likely that the evaluation of the evidence happens
> at dispute-resolution time and is done not by the run-time 
> client but by some 3rd party? If not, then the client has to
> check everything at run-time; if so, then the fact that the
> client doesn't trust the relayed-to server is moot (what 
> matters is what the evidence evaluator thinks).
> 
> I would agree though that including just a dpv response as evidence
> might be misleading unless all relayed responses can be matched
> against the original request.
> 
> Seems a bit confused to me (but then I'm often confused:-),
> Stephen.
> 
> Denis Pinkas wrote:
> > 
> > Peter,
> > 
> > (text deleted)
> > 
> > > I refer to my proposal to change the text saying that
> > > that among the optional returned infos like paths CRL,
> > > OCSP responses, there may alos occur DPV responses.
> > 
> > I would disagree. Let me explain why. The requester only 
> trusts the DPV
> > server that it has queried. The DPV server may trust any 
> server it likes,
> > but the client does not care: the client does not 
> necessarilly trust them.
> > The original server is the only one responsible for the 
> "valid" signed
> > response. So if a DPV response from another server were 
> included as a proof
> > of the "valid" response, it would not be a proof for the 
> client. The client
> > needs a proof from first hand, i.e. a proof that is not 
> disputable. This can
> > only be the original certification path, the original CRLs 
> and the original
> > OCSP responses, with all the proofs that the CRL Issuers 
> and the OCSP
> > responders are indeed empowered to provide that information.
> > 
> > > Encapsulating a "DPV response" in a OCSP response still
> > > remains an option anyway.
> > 
> > Encapsulating a "DPV response" in a OCSP response is out of 
> the scope of
> > this discussion.
> > 
> > > > Denis
> > 
> > > Since you haven't commented the next paragraph may I assume that
> > > this is ok with you?
> > 
> > > > > I think the general principle should be that there is one mode
> > > > > that all information essential to understand what has 
> contributed
> > > > > to the final decision must be made available to the client.
> > > > > (Not necessarily understood by the client).
> > 
> > No. It is always necessary to provide a yes/no/unknown 
> answer (or an error).
> > 
> > It is optional to provide all the information essential to 
> test again the
> > certificate validity, should another party not simply trust 
> the signed "yes"
> > answer. It is certainly not necessary for the client to 
> understand what has
> > contributed to the final decision.
> > 
> > Denis
> > 
> > > > > I would also agree, that only necessary information 
> should be made
> > > > > available. It may be not necessary to inform:
> > > > >
> > > > > - Yesterday I have made three unsuccesseful attempt 
> at time1 2 3,
> > > > >   the last one finally succeed by using an internet connect to
> > > > >   address a.b.c.d using DPV protocol over OCSP, ...
> > > > >
> > > > > Peter
> 
> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AFAAt00304 for ietf-pkix-bks; Wed, 10 Apr 2002 08:10:10 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AFA7m00293 for <[e-mail]>; Wed, 10 Apr 2002 08:10:07 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA06406; Wed, 10 Apr 2002 17:10:06 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 10 Apr 2002 17:10:06 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA07132; Wed, 10 Apr 2002 17:10:05 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA06729; Wed, 10 Apr 2002 17:10:04 +0200 (MET DST)
Date: Wed, 10 Apr 2002 17:10:04 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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,
> 
> (text deleted)
> 
> > I refer to my proposal to change the text saying that
> > that among the optional returned infos like paths CRL,
> > OCSP responses, there may alos occur DPV responses.
> 
> I would disagree. Let me explain why. The requester only trusts the DPV
> server that it has queried. The DPV server may trust any server it likes,
> but the client does not care: the client does not necessarilly trust them. 
> The original server is the only one responsible for the "valid" signed 
> response. So if a DPV response from another server were included as a proof 
> of the "valid" response, it would not be a proof for the client. The client
> needs a proof from first hand, i.e. a proof that is not disputable. This can
> only be the original certification path, the original CRLs and the original
> OCSP responses, with all the proofs that the CRL Issuers and the OCSP
> responders are indeed empowered to provide that information.

I disagree when you say 'this can *only* be'. You assume implicitly that
the only service providable by CAs are CRLs and/or OCSP. So far,
DPV has been designed in a way that instead of providing an OCSP service
through whatever structure, a CA can provide a quite similar service
using DPV. 
  
> > Encapsulating a "DPV response" in a OCSP response still
> > remains an option anyway.
> 
> Encapsulating a "DPV response" in a OCSP response is out of the scope of
> this discussion.
I am not discussing this, I just reminded that in order to formally
respond to the actual text, it is always possible to create
an OCSP response together with an indication about the existance
of the cert, and one may or not call this *DPV* response. 
Or: If one would take the DPV proposal of OCSP-V2 as a potential
implementation there would be conformance of 'only OCSP responses'
and at the same time there would be DPV reponses. 

> > Since you haven't commented the next paragraph may I assume that
> > this is ok with you?
> 
> > > > I think the general principle should be that there is one mode
> > > > that all information essential to understand what has contributed
> > > > to the final decision must be made available to the client.
> > > > (Not necessarily understood by the client).
> 
> No. It is always necessary to provide a yes/no/unknown answer (or an error).
> It is optional to provide all the information essential to test again the
> certificate validity, should another party not simply trust the signed "yes"
> answer. It is certainly not necessary for the client to understand what has
> contributed to the final decision. 

What is 'no': 

Where did I say that yes/no/unknown is NOT necessary? (is this the reason
for the no?) In the remainder you just rephrase what I have said. 

'it is optional'  == "there is one mode"
'all the information essential'  idem
'Not necessarily understood by the client'  == last sentence. 


> 
> Denis
> 
> > > > I would also agree, that only necessary information should be made
> > > > available. It may be not necessary to inform:
> > > >
> > > > - Yesterday I have made three unsuccesseful attempt at time1 2 3,
> > > >   the last one finally succeed by using an internet connect to
> > > >   address a.b.c.d using DPV protocol over OCSP, ...
> > > >
> > > > Peter
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AF94029985 for ietf-pkix-bks; Wed, 10 Apr 2002 08:09:04 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AF93m29976 for <[e-mail]>; Wed, 10 Apr 2002 08:09:03 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA17834; Wed, 10 Apr 2002 17:11:38 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041017085936:383 ; Wed, 10 Apr 2002 17:08:59 +0200 
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 17:08:58 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: Roadmap
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 17:08:59, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 17:09:04, Serialize complete at 10/04/2002 17:09:04
Content-Transfer-Encoding: 7bit
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>

Tom,

> It is obviously important that this document get finalized fairly soon.  

Indeed.

> The only question we have outstanding is whether "root CA" as
> defined would be better replaced by "anchor CA" or "trust anchor".  This
> should not block the document for more than a day or two, but I think it
> worthwhile to find out what you think the difference is.  The term "root
> CA" as "root of trust" has caused some confusion in these discussions, 

Maybe.

> and
> if there's a better term which is in fairly common use (as "anchor" is) 

I wonder. "Anchor" or "trust anchor" is a term that few people understand
(and there is no unanimity on its meaning). Root CA has been used (or
mis-used ?) for years. We cannot ignore thee fact that "root CA" is being
used.

> we should use it.  If there's a real difference, we should keep "root CA".

There is a real difference, since you mention that a trust anchor could be
defined in such a way that they might be EE's or even AA.

By opposition a root CA is always a CA, not necessarilly a Top CA. This is
what the current text says. So these terms are not equivalent

So if I take your previous statement, i.e. "If there's a real difference, we
should keep "root CA", I let you draw the conclusion.

Denis

> In case it's not obvious, the term "anchor CA" means "a trust anchor which 
> is a CA" - which assumes that trust anchors could be defined in such a way
> that they might be EE's or even AA's.
> 
>             Tom Gindin
> 
> Denis Pinkas <[e-mail]> on 04/09/2002 12:00:26 PM
> 
> To:    Tom Gindin/Watson/IBM@IBMUS
> cc:    [e-mail]
> Subject:    Re: WG Last Call: Roadmap
> 
> Tom,
> 
> >       Denis:
> >
> >       Should we really standardize on the term "root CA" rather than
> "trust
> > anchor" or "anchor CA"?
> 
> I do not care, but I care for this document to be sent to the IESG soon. So
> the sooner we may find a compromise, the better. Maybe the quickest way
> is to try to suppress the sentences that create problems. We should
> focuss on text replacement proposals.
> 
> > "Trust anchor" has never been used to mean anything other than an entity
> directly trusted by the RP, AFAIK.
> 
> Not exactly. Read this sentence again.  However, I would like to resist to
> start a new discusion now on trust anchors.
> 
> > I have other comments below.
> >
> >             Tom Gindin
> >
> > Denis Pinkas <[e-mail]> on 04/08/2002 12:32:41 PM
> >
> > To:    Tom Gindin/Watson/IBM@IBMUS
> > cc:    [e-mail]
> > Subject:    Re: WG Last Call: Roadmap
> >
> > Tom,
> >
> > I have not forgotten this message, but I gave priority to the DPV thread.
> >
> > >       Responses below.
> >
> > > The issue of who specifies the verifier's policy is
> > > rather serious.  If the policy to be used is expected to be the same as
> > RFC
> > > 3126's SignaturePolicy, we need to specify a step in which the verifier
> > has
> > > the right to reject such a policy or to consider it inapplicable to the
> > > verifier's own current context.
> >
> > This is true. However, the text does not go at that level of detail:
> >
> > "Another model considers a set of rules that apply to an application
> > context. Every application context may have a different set of rules.
> > When choosing to use certificates in the context of that application,
> > the EE selects the set of rules for that context. In a set of rules,
> > one or more Top CAs may be trusted, each one may be associated with
> > different constraints, like the certificate policies that are trusted
> > or the naming constraints that apply. These constrains may be specified
> > either in self-signed certificates or in addition to self-signed
> > certificates when they do not incorporate these constraints. This set
> > of rules is called a validation policy (when validating a certificate)
> > or a signature policy (when validating a digital signature)."
> >
> > I do not think it is necesary to state it. If you think so, please
> provide
> > a text and a placement for that text.
> >
> > [TG] My biggest problem is the use of the term "signature policy", which
> > you have elsewhere defined as something defined and signed by the signer
> of
> > the document.
> 
> There is a misunderstanding. A signer may provide the *reference* of the
> signature policy that he agrees to use when signing. In order to prevent
> someone else to change that reference, it is protected by the signer's
> signature. So in that case the verifier has first to see whether the
> signature policy used by the signer is appropriate for his application
> context. If it is the case, then it uses it, otherwise this is the end of
> the story.
> 
> [TG] He mainly needs to check whether it's an approved signature policy by
> his personal or organizational criteria.
> 
> > In the paragraph above, I would replace the term "Top CAs"
> > by "root CA's",
> 
> No problem.
> 
> > and I would also call the sets of rules in the last
> > sentence a "certificate validation policy" and a "signature validation
> > policy".  I would then add the following statement: "Neither of these
> > policies is considered to be the same as either a CertificatePolicy as
> > defined in RFC 2459 or a SignaturePolicy as defined in RFC 3126."
> 
> I would simply propose to delete the following sentence:
> 
> "This set of rules is called a validation policy (when validating a
> certificate) or a signature policy (when validating a digital signature)"
> not because it is wrong, but because I would like this document to proceed.
> 
> This would lead to the following text:
> 
> "Another model considers a set of rules that apply to an application
> context. Every application context may have a different set of rules.
> When choosing to use certificates in the context of that application,
> the EE selects the set of rules for that context. In a set of rules,
> one or more root CAs may be trusted, each one may be associated with
> different constraints, like the certificate policies that are trusted
> or the naming constraints that apply. These constrains may be specified
> either in self-signed certificates or in addition to self-signed
> certificates when they do not incorporate these constraints."
> 
> Can you live with it ?
> 
> [TG] Sure.
> 
> > > To:    Tom Gindin/Watson/IBM@IBMUS
> > > cc:    [e-mail]
> > > Subject:    Re: WG Last Call: Roadmap
> > >
> > > Tom,
> > >
> > > >       I have a few issues with this, and some corrections as well.
> > >
> > > >       In comment 12, I have two issues.  The first one, which is
> minor,
> > > is
> > > > that  "one or more Top CA's may be trusted" should refer to root CA's
> > > > instead - the two terms mean the same thing more often than not, but
> > when
> > > > they differ the trust point is the root rather than the top.
> > >
> > > PKIX-1 states:
> > >
> > >    " - Top CA - A CA that is at the top of a PKI hierarchy.
> > >
> > >    Note: This is often also called a "Root CA," since in data
> structures
> > >    terms and in graph theory, the node at the top of a tree is the
> > >    "root." However, to minimize confusion in this document, we elect to
> > >    call this node a "Top CA," and reserve "Root CA" for the CA directly
> > >    trusted by the EE."
> > >
> > > The problem lies with the last sentence, i.e. "*the* CA directly
> trusted
> > by
> > > the EE.". The singular is being used which means that there is a single
> > > one, multiple roots are not permitted, while multiple Top-CAs are
> > > permitted.
> > >
> > > [TG] Where in PKIX-1 is this?  I can't find the phrase "directly
> trusted"
> > > in either RFC 2459 or in draft 12 of new-pkix-1.
> >
> > Sorry for the confusion: it is in the roadmap document, not PKIX-1.
> >
> > The current text in the roadmap is:
> >
> >     " - Root CA - A CA that is directly trusted by an EE; that is,
> >        securely acquiring the value of a Root CA public key requires
> >        some out-of-band step(s). This term is not meant to imply that a
> >        Root CA is necessarily at the top of any hierarchy, simply that
> >        the CA in question is trusted directly.
> >
> > (...)
> >
> >    Note: This is often also called a "Root CA," since in data structures
> >    terms and in graph theory, the node at the top of a tree is the
> >    "root." However, to minimize confusion in this document, we elect to
> >    call this node a "Top CA," and reserve "Root CA" for the CA directly
> >    trusted by the EE. Readers new to PKIX should be aware that these
> >    terms are not used consistently throughout the PKIX documents, as the
> >    Internet PKI profile [2459bis] uses "Root CA" to refer to what this
> >    and other documents call a "Top CA," and "most-trusted CA" to refer
> >    to what this and other documents call a "Root CA."
> >
> > There is no problem with PKIX-1 but a problem with the roadmap document.
> > PKIX-1 does not use the term "root CA", and thus it is wrong to say in
> > the roadmap that "these terms are not used consistently throughout the
> > PKIX documents".
> >
> > I would thus propose to change the note in the following way:
> >
> >    Note: Since in data structures terms and in graph theory, the node
> >    at the top of a tree is the "root", the term "root CA" is sometimes
> >    used. This term is not meant to imply that a Root CA is necessarily
> >    at the top of any hierarchy, simply that the CA in question is trusted
> >    directly.
> >
> > [TG] As I stated at the beginning, I don't know why we should standardize
> > on the term "root CA" rather than "trust anchor" or "anchor CA".  Those
> > terms cannot be mistaken for what is defined here as a "Top CA".  BTW, I
> > approve of that coinage.
> 
> We do use "root CA", so I see no harm to use that vocabulary. This is no
> attempt to standardize this term here. Originally my single concern what
> that the text was talking about *one* root CA whereas there can be
> multiple.
> This was my ONLY concern. This is now fixed. We should close this issue
> ASAP.
> 
> Denis
> 
> > Then, on page 14, change:
> >
> >    Additionally, once the Root CA ...
> >
> > with
> >
> >    Additionally, once a Root CA ...
> >
> > on pages 29 and 30, change:
> >
> >    (e.g., the DVCS's CA, or the Root CA in a
> >    hierarchy)
> >
> > with
> >
> >    (e.g., the DVCS's CA, or a Root CA)
> >
> > Regards,
> >
> > Denis
> >
> > (snip)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AF2L028504 for ietf-pkix-bks; Wed, 10 Apr 2002 08:02:21 -0700 (PDT)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AF2Jm28497 for <[e-mail]>; Wed, 10 Apr 2002 08:02:19 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g3AF2Jb31175 for <[e-mail]>; Wed, 10 Apr 2002 16:02:19 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Wed, 10 Apr 2002 15:56:56 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id QAA06710; Wed, 10 Apr 2002 16:02:16 +0100
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 16:02:21 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Peter Sylvester <[e-mail]>, [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]>
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>

Denis,

> I would disagree. Let me explain why. The requester only trusts the DPV
> server that it has queried. The DPV server may trust any server it likes,
> but the client does not care: the client does not necessarilly trust them.
> The original server is the only one responsible for the "valid" signed
> response. So if a DPV response from another server were included as a proof
> of the "valid" response, it would not be a proof for the client. The client
> needs a proof from first hand, i.e. a proof that is not disputable. This can
> only be the original certification path, the original CRLs and the original
> OCSP responses, with all the proofs that the CRL Issuers and the OCSP
> responders are indeed empowered to provide that information.

But isn't it likely that the evaluation of the evidence happens
at dispute-resolution time and is done not by the run-time 
client but by some 3rd party? If not, then the client has to
check everything at run-time; if so, then the fact that the
client doesn't trust the relayed-to server is moot (what 
matters is what the evidence evaluator thinks).

I would agree though that including just a dpv response as evidence
might be misleading unless all relayed responses can be matched
against the original request.

Seems a bit confused to me (but then I'm often confused:-),
Stephen.

Denis Pinkas wrote:
> 
> Peter,
> 
> (text deleted)
> 
> > I refer to my proposal to change the text saying that
> > that among the optional returned infos like paths CRL,
> > OCSP responses, there may alos occur DPV responses.
> 
> I would disagree. Let me explain why. The requester only trusts the DPV
> server that it has queried. The DPV server may trust any server it likes,
> but the client does not care: the client does not necessarilly trust them.
> The original server is the only one responsible for the "valid" signed
> response. So if a DPV response from another server were included as a proof
> of the "valid" response, it would not be a proof for the client. The client
> needs a proof from first hand, i.e. a proof that is not disputable. This can
> only be the original certification path, the original CRLs and the original
> OCSP responses, with all the proofs that the CRL Issuers and the OCSP
> responders are indeed empowered to provide that information.
> 
> > Encapsulating a "DPV response" in a OCSP response still
> > remains an option anyway.
> 
> Encapsulating a "DPV response" in a OCSP response is out of the scope of
> this discussion.
> 
> > > Denis
> 
> > Since you haven't commented the next paragraph may I assume that
> > this is ok with you?
> 
> > > > I think the general principle should be that there is one mode
> > > > that all information essential to understand what has contributed
> > > > to the final decision must be made available to the client.
> > > > (Not necessarily understood by the client).
> 
> No. It is always necessary to provide a yes/no/unknown answer (or an error).
> 
> It is optional to provide all the information essential to test again the
> certificate validity, should another party not simply trust the signed "yes"
> answer. It is certainly not necessary for the client to understand what has
> contributed to the final decision.
> 
> Denis
> 
> > > > I would also agree, that only necessary information should be made
> > > > available. It may be not necessary to inform:
> > > >
> > > > - Yesterday I have made three unsuccesseful attempt at time1 2 3,
> > > >   the last one finally succeed by using an internet connect to
> > > >   address a.b.c.d using DPV protocol over OCSP, ...
> > > >
> > > > Peter

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AEsiZ28172 for ietf-pkix-bks; Wed, 10 Apr 2002 07:54:44 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AEsgm28166 for <[e-mail]>; Wed, 10 Apr 2002 07:54:42 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g3AEs6lh050854; Wed, 10 Apr 2002 10:54:06 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g3AEs3023888; Wed, 10 Apr 2002 10:54:03 -0400
Importance: Normal
Sensitivity: 
Subject: Re: WG Last Call: Roadmap
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 10 Apr 2002 10:41:39 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/10/2002 10:54:04 AM
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>

      It is obviously important that this document get finalized fairly
soon.  The only question we have outstanding is whether "root CA" as
defined would be better replaced by "anchor CA" or "trust anchor".  This
should not block the document for more than a day or two, but I think it
worthwhile to find out what you think the difference is.  The term "root
CA" as "root of trust" has caused some confusion in these discussions, and
if there's a better term which is in fairly common use (as "anchor" is) we
should use it.  If there's a real difference, we should keep "root CA".  In
case it's not obvious, the term "anchor CA" means "a trust anchor which is
a CA" - which assumes that trust anchors could be defined in such a way
that they might be EE's or even AA's.

            Tom Gindin


Denis Pinkas <[e-mail]> on 04/09/2002 12:00:26 PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [e-mail]
Subject:    Re: WG Last Call: Roadmap


Tom,

>       Denis:
>
>       Should we really standardize on the term "root CA" rather than
"trust
> anchor" or "anchor CA"?

I do not care, but I care for this document to be sent to the IESG soon. So
the sooner we may find a compromise, the better. Maybe the quickest way
is to try to suppress the sentences that create problems. We should
focuss on text replacement proposals.

> "Trust anchor" has never been used to mean anything other than an entity
directly trusted by the RP, AFAIK.

Not exactly. Read this sentence again.  However, I would like to resist to
start a new discusion now on trust anchors.

> I have other comments below.
>
>             Tom Gindin
>
> Denis Pinkas <[e-mail]> on 04/08/2002 12:32:41 PM
>
> To:    Tom Gindin/Watson/IBM@IBMUS
> cc:    [e-mail]
> Subject:    Re: WG Last Call: Roadmap
>
> Tom,
>
> I have not forgotten this message, but I gave priority to the DPV thread.
>
> >       Responses below.
>
> > The issue of who specifies the verifier's policy is
> > rather serious.  If the policy to be used is expected to be the same as
> RFC
> > 3126's SignaturePolicy, we need to specify a step in which the verifier
> has
> > the right to reject such a policy or to consider it inapplicable to the
> > verifier's own current context.
>
> This is true. However, the text does not go at that level of detail:
>
> "Another model considers a set of rules that apply to an application
> context. Every application context may have a different set of rules.
> When choosing to use certificates in the context of that application,
> the EE selects the set of rules for that context. In a set of rules,
> one or more Top CAs may be trusted, each one may be associated with
> different constraints, like the certificate policies that are trusted
> or the naming constraints that apply. These constrains may be specified
> either in self-signed certificates or in addition to self-signed
> certificates when they do not incorporate these constraints. This set
> of rules is called a validation policy (when validating a certificate)
> or a signature policy (when validating a digital signature)."
>
> I do not think it is necesary to state it. If you think so, please
provide
> a text and a placement for that text.
>
> [TG] My biggest problem is the use of the term "signature policy", which
> you have elsewhere defined as something defined and signed by the signer
of
> the document.

There is a misunderstanding. A signer may provide the *reference* of the
signature policy that he agrees to use when signing. In order to prevent
someone else to change that reference, it is protected by the signer's
signature. So in that case the verifier has first to see whether the
signature policy used by the signer is appropriate for his application
context. If it is the case, then it uses it, otherwise this is the end of
the story.

[TG] He mainly needs to check whether it's an approved signature policy by
his personal or organizational criteria.

> In the paragraph above, I would replace the term "Top CAs"
> by "root CA's",

No problem.

> and I would also call the sets of rules in the last
> sentence a "certificate validation policy" and a "signature validation
> policy".  I would then add the following statement: "Neither of these
> policies is considered to be the same as either a CertificatePolicy as
> defined in RFC 2459 or a SignaturePolicy as defined in RFC 3126."

I would simply propose to delete the following sentence:

"This set of rules is called a validation policy (when validating a
certificate) or a signature policy (when validating a digital signature)"
not because it is wrong, but because I would like this document to proceed.

This would lead to the following text:

"Another model considers a set of rules that apply to an application
context. Every application context may have a different set of rules.
When choosing to use certificates in the context of that application,
the EE selects the set of rules for that context. In a set of rules,
one or more root CAs may be trusted, each one may be associated with
different constraints, like the certificate policies that are trusted
or the naming constraints that apply. These constrains may be specified
either in self-signed certificates or in addition to self-signed
certificates when they do not incorporate these constraints."

Can you live with it ?

[TG] Sure.

> > To:    Tom Gindin/Watson/IBM@IBMUS
> > cc:    [e-mail]
> > Subject:    Re: WG Last Call: Roadmap
> >
> > Tom,
> >
> > >       I have a few issues with this, and some corrections as well.
> >
> > >       In comment 12, I have two issues.  The first one, which is
minor,
> > is
> > > that  "one or more Top CA's may be trusted" should refer to root CA's
> > > instead - the two terms mean the same thing more often than not, but
> when
> > > they differ the trust point is the root rather than the top.
> >
> > PKIX-1 states:
> >
> >    " - Top CA - A CA that is at the top of a PKI hierarchy.
> >
> >    Note: This is often also called a "Root CA," since in data
structures
> >    terms and in graph theory, the node at the top of a tree is the
> >    "root." However, to minimize confusion in this document, we elect to
> >    call this node a "Top CA," and reserve "Root CA" for the CA directly
> >    trusted by the EE."
> >
> > The problem lies with the last sentence, i.e. "*the* CA directly
trusted
> by
> > the EE.". The singular is being used which means that there is a single
> > one, multiple roots are not permitted, while multiple Top-CAs are
> > permitted.
> >
> > [TG] Where in PKIX-1 is this?  I can't find the phrase "directly
trusted"
> > in either RFC 2459 or in draft 12 of new-pkix-1.
>
> Sorry for the confusion: it is in the roadmap document, not PKIX-1.
>
> The current text in the roadmap is:
>
>     " - Root CA - A CA that is directly trusted by an EE; that is,
>        securely acquiring the value of a Root CA public key requires
>        some out-of-band step(s). This term is not meant to imply that a
>        Root CA is necessarily at the top of any hierarchy, simply that
>        the CA in question is trusted directly.
>
> (...)
>
>    Note: This is often also called a "Root CA," since in data structures
>    terms and in graph theory, the node at the top of a tree is the
>    "root." However, to minimize confusion in this document, we elect to
>    call this node a "Top CA," and reserve "Root CA" for the CA directly
>    trusted by the EE. Readers new to PKIX should be aware that these
>    terms are not used consistently throughout the PKIX documents, as the
>    Internet PKI profile [2459bis] uses "Root CA" to refer to what this
>    and other documents call a "Top CA," and "most-trusted CA" to refer
>    to what this and other documents call a "Root CA."
>
> There is no problem with PKIX-1 but a problem with the roadmap document.
> PKIX-1 does not use the term "root CA", and thus it is wrong to say in
> the roadmap that "these terms are not used consistently throughout the
> PKIX documents".
>
> I would thus propose to change the note in the following way:
>
>    Note: Since in data structures terms and in graph theory, the node
>    at the top of a tree is the "root", the term "root CA" is sometimes
>    used. This term is not meant to imply that a Root CA is necessarily
>    at the top of any hierarchy, simply that the CA in question is trusted
>    directly.
>
> [TG] As I stated at the beginning, I don't know why we should standardize
> on the term "root CA" rather than "trust anchor" or "anchor CA".  Those
> terms cannot be mistaken for what is defined here as a "Top CA".  BTW, I
> approve of that coinage.

We do use "root CA", so I see no harm to use that vocabulary. This is no
attempt to standardize this term here. Originally my single concern what
that the text was talking about *one* root CA whereas there can be
multiple.
This was my ONLY concern. This is now fixed. We should close this issue
ASAP.

Denis

> Then, on page 14, change:
>
>    Additionally, once the Root CA ...
>
> with
>
>    Additionally, once a Root CA ...
>
> on pages 29 and 30, change:
>
>    (e.g., the DVCS's CA, or the Root CA in a
>    hierarchy)
>
> with
>
>    (e.g., the DVCS's CA, or a Root CA)
>
> Regards,
>
> Denis
>
> (snip)






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AEatf27213 for ietf-pkix-bks; Wed, 10 Apr 2002 07:36:55 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AEarm27208 for <[e-mail]>; Wed, 10 Apr 2002 07:36:53 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id QAA22428; Wed, 10 Apr 2002 16:39:27 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041016362058:375 ; Wed, 10 Apr 2002 16:36:20 +0200 
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 16:36:19 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 16:36:20, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 16:36:52, Serialize complete at 10/04/2002 16:36:52
Content-Transfer-Encoding: 7bit
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>

Peter,

(text deleted)

> I refer to my proposal to change the text saying that
> that among the optional returned infos like paths CRL,
> OCSP responses, there may alos occur DPV responses.

I would disagree. Let me explain why. The requester only trusts the DPV
server that it has queried. The DPV server may trust any server it likes,
but the client does not care: the client does not necessarilly trust them. 
The original server is the only one responsible for the "valid" signed 
response. So if a DPV response from another server were included as a proof 
of the "valid" response, it would not be a proof for the client. The client
needs a proof from first hand, i.e. a proof that is not disputable. This can
only be the original certification path, the original CRLs and the original
OCSP responses, with all the proofs that the CRL Issuers and the OCSP
responders are indeed empowered to provide that information.
 
> Encapsulating a "DPV response" in a OCSP response still
> remains an option anyway.

Encapsulating a "DPV response" in a OCSP response is out of the scope of
this discussion.

> > Denis
 
> Since you haven't commented the next paragraph may I assume that
> this is ok with you?

> > > I think the general principle should be that there is one mode
> > > that all information essential to understand what has contributed
> > > to the final decision must be made available to the client.
> > > (Not necessarily understood by the client).

No. It is always necessary to provide a yes/no/unknown answer (or an error).

It is optional to provide all the information essential to test again the
certificate validity, should another party not simply trust the signed "yes"
answer. It is certainly not necessary for the client to understand what has
contributed to the final decision. 

Denis

> > > I would also agree, that only necessary information should be made
> > > available. It may be not necessary to inform:
> > >
> > > - Yesterday I have made three unsuccesseful attempt at time1 2 3,
> > >   the last one finally succeed by using an internet connect to
> > >   address a.b.c.d using DPV protocol over OCSP, ...
> > >
> > > Peter


Received: by above.proper.com (8.11.6/8.11.3) id g3ADRu124488 for ietf-pkix-bks; Wed, 10 Apr 2002 06:27:56 -0700 (PDT)
Received: from dymwsm13.mailwatch.com (dymwsm13.mailwatch.com [204.253.83.37]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ADRtm24483 for <[e-mail]>; Wed, 10 Apr 2002 06:27:55 -0700 (PDT)
Received: from mwsc0202.mw4.mailwatch.com (mwsc0202.mw4.mailwatch.com [204.253.83.132]) by dymwsm13.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3ADRZb28478 for <[e-mail]>; Wed, 10 Apr 2002 09:27:35 -0400
Received: from mail pickup service by mwsc0202.mw4.mailwatch.com with Microsoft SMTPSVC; Wed, 10 Apr 2002 09:27:35 -0400
Received: from 204.253.83.72 ([204.253.83.72]) by MWSC0202 with SMTP id 00020002894052e0-9318-4b66-ad3e-0dfcb196d7f9;	 Wed, 10 Apr 2002 09:27:35 -0500
Received: from bigbird.entegrity.com (bigbird.gradient.com [192.92.110.50])	by dymwsm10.mailwatch.com (8.11.0/8.11.0) with ESMTP id g3ADRZV11840;	Wed, 10 Apr 2002 09:27:35 -0400
Received: by bigbird.gradient.com with Internet Mail Service (5.5.2650.10)	id <2SMDF0TW>; Wed, 10 Apr 2002 09:24:34 -0400
Message-ID: <[e-mail]>
From: Hal Lockhart <[e-mail]>
To: "'todd glassey'" <[e-mail]>
Cc: [e-mail]
Subject: RE: NEW THREAD: Too Complex - WAS - Re: Open issue: DPV relay
Date: Wed, 10 Apr 2002 09:24:33 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.10)
Content-Type: multipart/alternative;	boundary="----_=_NextPart_001_01C1E093.0DDA59B4"
HOP-COUNT: 1
X-MAILWATCH-INSTANCEID: 01020002894052e0-9318-4b66-ad3e-0dfcb196d7f9
X-OriginalArrivalTime: 10 Apr 2002 13:27:35.0740 (UTC) FILETIME=[7A28E7C0:01C1E093]
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_01C1E093.0DDA59B4
Content-Type: text/plain;
	charset="ISO-8859-1"

Todd,

> > BTW, what percentage of Internet traffic do you assert is
> > "transaction processing"
> 
> 100% - All of it.

That did it. You just made my kill file. You are obviously designing
standards for some "other" Internet.

Hal

------_=_NextPart_001_01C1E093.0DDA59B4
Content-Type: text/html;
	charset="ISO-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2448.0">
<TITLE>RE: NEW THREAD: Too Complex - WAS - Re: Open issue: DPV relay</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Todd,</FONT>
</P>

<P><FONT SIZE=2>&gt; &gt; BTW, what percentage of Internet traffic do you assert is</FONT>
<BR><FONT SIZE=2>&gt; &gt; &quot;transaction processing&quot;</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; 100% - All of it.</FONT>
</P>

<P><FONT SIZE=2>That did it. You just made my kill file. You are obviously designing standards for some &quot;other&quot; Internet.</FONT>
</P>

<P><FONT SIZE=2>Hal</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1E093.0DDA59B4--


Received: by above.proper.com (8.11.6/8.11.3) id g3ADR7u24416 for ietf-pkix-bks; Wed, 10 Apr 2002 06:27:07 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ADR5m24410 for <[e-mail]>; Wed, 10 Apr 2002 06:27:06 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.2/8.12.2) with ESMTP id g3ADQnXv025732; Thu, 11 Apr 2002 01:26:49 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id BAA77179; Thu, 11 Apr 2002 01:26:43 +1200 (NZST) (sender [e-mail])
Date: Thu, 11 Apr 2002 01:26:43 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  CMP Interoperability Question
Cc: [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>

Al Arsenault <[e-mail]> writes:

>For those who have implemented CMP, the question is: Does your implementation
>support CAs who sign CMP messages (e.g., cp, ip, ...) using a different key
>than they use to sign certificates?

Sure.  If it didn't, it wouldn't be possible to use an RA which proxies for a
CA.  I'd be surprised if there were implementations which didn't allow this...
no hang on, after having taken part in CMP interop testing I wouldn't be
surprised if there were implementations which reformatted the hard drive or
played an MPEG of a cat :-).

>- signed with a key without keyUsage set to some magic value?

keyUsage = signature or nonrepudiation would be useful (there's a Norwegian CA
which believes that a keyUsage extension is unnecessary in its root cert, and
obviously I'm not going to be able to check anything signed with that).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3ACvss22152 for ietf-pkix-bks; Wed, 10 Apr 2002 05:57:54 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ACvrm22145 for <[e-mail]>; Wed, 10 Apr 2002 05:57:53 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 10 Apr 2002 05:55:22 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 10 Apr 2002 05:55:22 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <2L0B8MJ9>; Wed, 10 Apr 2002 05:57:34 -0700
Content-return: allowed
Date: Wed, 10 Apr 2002 05:57:33 -0700
From: Frank Balluffi <[e-mail]>
Subject: RE: CMP Interoperability Question
To: "'[e-mail]'" <[e-mail]>, "'[e-mail]'" <[e-mail]>
Cc: "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="iso-8859-1"
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>

Al Arsenault asked:

>     For those who have implemented CMP, the question is: Does 
> your implementation support CAs who sign CMP messages (e.g., 
> cp, ip, ...) using a different key than they use to sign certificates?

Yes. It is possible to configure our validation authority product to accept
a CMP revocation request signed with a key other than the CA's certificate
signing key. For example, it is possible to configure the system to accept
requests signed by a local administrator.

Frank


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3ABqu618824 for ietf-pkix-bks; Wed, 10 Apr 2002 04:52:56 -0700 (PDT)
Received: from smtp.comcast.net (smtp.comcast.net [24.153.64.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3ABqpm18817 for <[e-mail]>; Wed, 10 Apr 2002 04:52:51 -0700 (PDT)
Received: from SJOSEPH (pcp237514pcs.elictc01.md.comcast.net [68.55.160.145]) by mtaout04.icomcast.net (iPlanet Messaging Server 5.1 (built Feb  6 2002)) with SMTP id <[e-mail]> for [e-mail]; Wed, 10 Apr 2002 07:52:47 -0400 (EDT)
Date: Wed, 10 Apr 2002 07:52:35 -0400
From: Al Arsenault <[e-mail]>
Subject: CMP Interoperability Question
To: [e-mail]
Cc: Alfred Arsenault <[e-mail]>
Message-id: <029301c1e086$348d00a0$6401a8c0@SJOSEPH>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-type: multipart/alternative; boundary="Boundary_(ID_S+hEdpM9yy3FVZgvW/Duaw)"
X-Priority: 3
X-MSMail-priority: 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.

--Boundary_(ID_S+hEdpM9yy3FVZgvW/Duaw)
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 7BIT

Folks,

    I'm looking for some information, so I figured that this might be the fastest way to do an "informal survey".

    For those who have implemented CMP, the question is: Does your implementation support CAs who sign CMP messages (e.g., cp, ip, ...) using a different key than they use to sign certificates?

    The reason for asking this: we tend to believe that they private signing key used to sign certificates and revocation information (CRLs, OCSP responses) should ONLY be used for that purpose.  The CA has a separate key to use for secure communications, including signing CMP responses. (I can't find anything in the spec - either RFC2510 or son-of-2510 - that addresses this at all. My apologies if I just missed a section.)

    The problem was that a little informal testing showed a problem.  We had a "brand X" RA send our CA a cr message.  The CA responded with a cp.  The RA rejected the cp, apparently because it wasn't signed with the same key used to sign certs/CRLs.  (We're investigating to find out what the exact conditions for success are; e.g., does the CMP cp message have to be signed with the same key the cert contained in the message is signed with; or do basic constraints and/or specific key usage values have to be set in the signing cert.)

    So, for you CMP implementors - would your code reject a cp or other message from a CA, if it was:

    - signed with a key other than that used by the CA to sign certs?
    - signed with a key that  matched a certificate without basicConstraints set to CA?
    - signed with a key without keyUsage set to some magic value?

    Thanks for any information you can provide,

                Al Arsenault
                Chief Security Architect
                Diversinet Corp.



--Boundary_(ID_S+hEdpM9yy3FVZgvW/Duaw)
Content-type: text/html; charset=iso-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 5.50.4134.600" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face=Arial size=2>Folks,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; I'm looking for some 
information, so I figured that this might be the fastest way to do an "informal 
survey".</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; For those who have implemented 
CMP, the question is: Does your implementation support CAs who sign CMP messages 
(e.g., cp, ip, ...) using a different key than they use to sign 
certificates?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; The reason for asking this: we 
tend to believe that they private signing key used to sign certificates and 
revocation information (CRLs, OCSP responses) should ONLY be used for that 
purpose.&nbsp; The CA has a separate key to use for secure communications, 
including signing CMP responses. (I can't find anything in the spec - either 
RFC2510 or son-of-2510 - that addresses this at all. My apologies if I just 
missed a section.)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; The problem was that a little 
informal testing showed a problem.&nbsp; We had a "brand X" RA send our CA a cr 
message.&nbsp; The CA responded with a cp.&nbsp; The RA rejected the cp, 
apparently because it wasn't signed with the same key used to sign 
certs/CRLs.&nbsp; (We're investigating to find out what the exact conditions for 
success are; e.g., does the CMP cp message have to be signed with the same key 
the cert contained in the message is signed with; or do basic constraints and/or 
specific key usage values have to be set in the signing cert.)</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; So, for you CMP implementors - 
would your code reject a cp or other message from a CA, if it was:</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; - signed with a key other than 
that used by the CA to sign certs?</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; - signed with a key that&nbsp; 
matched a certificate without basicConstraints set to CA?</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; - signed with a key without 
keyUsage set to some magic value?</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; Thanks for any information you 
can provide,</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Al Arsenault</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Chief Security Architect</FONT></DIV>
<DIV><FONT face=Arial size=2>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; 
&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; Diversinet Corp.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial size=2></FONT>&nbsp;</DIV></BODY></HTML>

--Boundary_(ID_S+hEdpM9yy3FVZgvW/Duaw)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3AAhoD15145 for ietf-pkix-bks; Wed, 10 Apr 2002 03:43:50 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3AAhnm15137 for <[e-mail]>; Wed, 10 Apr 2002 03:43:49 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA25508; Wed, 10 Apr 2002 12:46:22 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002041012431476:327 ; Wed, 10 Apr 2002 12:43:14 +0200 
Message-ID: <[e-mail]>
Date: Wed, 10 Apr 2002 12:43:13 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Miguel Angel Rodriguez <[e-mail]>
CC: [e-mail]
Subject: Re: TSA Policy Identifiers
References: <000001c1dfed$e2a28730$[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 12:43:15, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 10/04/2002 12:43:47, Serialize complete at 10/04/2002 12:43:47
Content-Transfer-Encoding: 7bit
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>

> Hi! Where can I find info on defined TSA Policy OIDs for TSP, rfc 3163?
                                                                ^^^^^^^^
                                                                rfc 3161   
> Regards,

> Miguel A Rodriguez
> SeguriDATA
> Mexico

You may find one on page 9, section 5.2. from the "Policy Requirements for
Time-Stamping Authorities" draft, i.e. draft-ietf-pkix-pr-tsa-00.txt.

The object-identifier of the baseline time-stamp policy is:
itu-t(0) identified-organization(4) etsi(0) time-stamp-policy(2023) 
policy-identifiers(1) baseline-ts-policy (1)

The draft has been announced on Monday, 25 March 2002.

The URL is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pr-tsa-00.txt

Regards,

Denis


Received: by above.proper.com (8.11.6/8.11.3) id g3A7SXI20675 for ietf-pkix-bks; Wed, 10 Apr 2002 00:28:33 -0700 (PDT)
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3A7SVm20664 for <[e-mail]>; Wed, 10 Apr 2002 00:28:31 -0700 (PDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id JAA12686; Wed, 10 Apr 2002 09:28:25 +0200 (MET DST)
Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id JAA05051; Wed, 10 Apr 2002 09:28:19 +0200 (MET DST)
Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id <H22NQQD0>; Wed, 10 Apr 2002 09:28:18 +0200
Message-ID: <1D82815C322BD41196EA00508B951F7B01B40EB4@MCHH265E>
From: Fantou Patrick <[e-mail]>
To: "'Kurt D. Zeilenga'" <[e-mail]>, Fantou Patrick <[e-mail]>
Cc: Christopher Oliva <[e-mail]>, David Chadwick <[e-mail]>, Mark Wahl <[e-mail]>, [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: AW: AW: LDAP Certificate transfer syntax
Date: Wed, 10 Apr 2002 09:27:52 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g3A7SWm20669
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>

Kurt, Peter and Ron, thanks for your comments.

Let me make more precise what i mean whith
*no choice* for *some attributes*

As Peter said, there are additional dependancies directly connected
with the attribute type and the fact that some attributes do not have any string encoding possibilities.

For some attributes like certificates, the only possibility as transfer encoding is the binary encoding.
It is what i mean with "there is no choice".
And in this case, as Ron says, ;binary is redundant.

Other comments in Kurt´s text.
Patrick


> -----Ursprüngliche Nachricht-----
> Von: Kurt D. Zeilenga [mailto:[e-mail]]
> Gesendet: Dienstag, 9. April 2002 18:17
> An: Fantou Patrick
> Cc: Christopher Oliva; David Chadwick; Mark Wahl;
> [e-mail]; 'LDAP BIS'; 'PKIX'
> Betreff: Re: AW: LDAP Certificate transfer syntax
> 
> 
> At 10:44 AM 2002-04-09, Fantou Patrick wrote:
> >I am not sure this discussion really brings us further.
> 
> I think this discussion is bringing us further along.  It has,
> at least, boiled down this particular debate to one issue:
>    whether or not ;binary is required when the binary
>    encoding of a value is transferred in the protocol.
> 

For certificates in any case the binary encoding has to be transferred in the protocol.
So the presence or absence of ;binary cannot change anything here.

> >There is no choice with some attributes like certificates.
> 
> I would have to agree that this is no choice.  But I think
> we disagree on what that choice is.
> 
The choice is string encoding, when it exists, or binary encoding.

> One must transfer certificates in their binary encoding as
> indicates by ;binary.   Note only is this the intent of RFC
> 2251, but we have demonstrated interoperability between
> multiple independently developed implementations of this.
> 

One must always transfer certificates in their binary encoding.
And  i am not sure that interoperability was demonstrated because 
;binary was implemented correctly, or because the presence or the
absence of ;binary was ignored by the servers for the attribute types which do not have
any string encoding.

P.F.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39KOHg10556 for ietf-pkix-bks; Tue, 9 Apr 2002 13:24:17 -0700 (PDT)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39KOAm10552 for <[e-mail]>; Tue, 9 Apr 2002 13:24:10 -0700 (PDT)
Received: from tsg1 ([12.81.78.249]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020409202406.ZFDC38.mtiwmhc22.worldnet.att.net@tsg1>; Tue, 9 Apr 2002 20:24:06 +0000
Message-ID: <000201c1e004$5425f7f0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References:  <[e-mail]> <001901c1dd74$8d26a730$020aff0c@tsg1> <p05100300b8d76b579027@[128.33.238.74]>
Subject: Re: NEW THREAD: Too Complex - WAS - Re: Open issue: DPV relay
Date: Tue, 9 Apr 2002 13:18:34 -0700
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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, April 08, 2002 9:05 PM
Subject: Re: NEW THREAD: Too Complex - WAS - Re: Open issue: DPV relay


>
> Todd,
>
> >Peter - All - I agree with you to some extent but let me also that there
is
> >another side and its about a bigger picture.  And in this bigger picture
> >PKIX is way out of control. What it really needs is to have a thread of
> >commonality drawn through all that PKIX produces. What I mean by that is
> >that the entire process of  complex-decision-support and evidentiary
> >processing of x.509 certs is out of control.
>
> As noted in my immediate, previous message, not all the PKI standards
> we address are in support of NR. This it is not reasonable to insist
> that all of these standards have an "evidentiary" flavor to them.

Why not Stephen?  NR is something that only a set of practices can
establish.

>
> >What we as a culture really need is something like CDSA only for PKIX.
What
> >I would conceptually propose as the PKIX streamlined PKI architecture. A
> >common PKIX transaction architecture and process model. A simpler one,
and
> >one that does not allow recursion or ambiguity that is unchecked. What
PKIX
> >needs to do is to simplify everything it does.
> >
> >The intent would be to identify:
> >
> >     1)    Is there any value in making all this PKI ware at the Network
> >Transport Level. I.e will the evidentiary needs of the world need and use
> >what we are proposing. Will it fit into Human Law and Process currently
> >accepted or, like the TSA, will it need artificial stimulus in the form
of
> >something like Italy's mandating some EU approved timestamp process
without
> >understanding exactly what the TSA provides relative to simple receipts
> >(i.e. not much at this point but we should spin that off as a separate
> >thread!).
>
> Your terminology is seriously flawed.

No Stephen its not. What is flawed is the response I get from you.


1)    What I said was simple - Is PKI technology being implemented at the
TCP/UDP based network level a good idea. So far the only parts of the market
that agree with you as the chair of the Global; PKI Standards group is the
manufacturers. What this means is that you have failed to date to get the
end users to buy in.

What was that line from that Van Morrison song, "and the Girls go by,
dressed up for each other"... or something like that.

The real issue I think is that you have failed to bring the evolution of PKI
to a place where it is marketable and isnt that what you set out to do? if
not then please correct me as to what and why we are all here?

> We make us of transport layer
> protocols such as UDP and TCP.

Steve - pardon my being picking about this next point but you are not the
WG, so its "The WG makes use of"...

>Using the Internet protocol
> architecture terminology, we are developing application protocols.
> after that sentence, I begin to lose track of your point, other than
> apparently insulting Italians.

The problem here is not with the Italian Government it is with the people
that convinced them that a Timestamp was something new that they needed for
official document processing. This has nothing to do with Italians per se
except that they came to understand something that most of the world missed
in B2B style models. The fact that you took it as an insult as opposed to an
obersvation is almost amusing to me...

>
> >     2)    How can the same services be used for both Evidentiary Service
> >Models and for Decision Support (Hey Stephen - I going Cap Crazy!)...
>
> yes, you are
>
> >
> >     3)    And who we are going to work with.
> >
> >What has happened so far is that with its key architects, this WG has
come
> >up with so many pieces that it is freakin impossible to come to any gross
> >agreements about anything. Take this argument - "Should DPV servers refer
> >their requests to another node in a chain if local policy is failed or
> >exceeded?" - it is totally constrained by how this system is being used
and
> >what types of legal frameworks are manding functionality under it.
> >
> >This is more than a problem with PKIX and people submitting technologies
> >that while the use seems mechanically cool, do not satisfy the existing
> >legal or process framework. And to that end PKIX and the IETF force the
> >world to tau-tau to its goals rather that the IETF doing what its
supposed
> >to and that is to build protocols for the real world. Well the real world
is
> >commercial transaction processing and without it there would be no
Internet.

Come on Steve - no comment on #3? except to the spelling of Tau tau.

>
>
> "tau-tau?" I assume you mean "kowtow," meaning to bow as a sign of
> respect (from the ancient Mandarin).

OK the spelling issue - yes pardon me - I was using one of the Cantonese
forms of the phrase, and in the colloquiel manner. Something like 200 ways
to spell and say POT STICKER. You understand, eh?

>
> Anyway, the folks who participate in the WG do believe that they are
> building protocols that are of value to the real world.

I just advocate that the world is ready for something more that Microsoft's
Fully Fledged, Development Enabled OS. That appliance computing is coming
and that it will soon take the place of many complex services. And that
becuase of what it is many of the OS Flaws that we spend so much time
working around will not be there.

>As noted
> elsewhere, many of us have a model of the real world that is a bit
> more encompassing that what you seem to advocate, and thus our ideas
> of an appropriate level of protocol generality differ from yours.

yes, so it seems.

>
> BTW, what percentage of Internet traffic do you assert is
> "transaction processing"

100% - All of it.

> of the sort that requires the
> non-repudiation facilities

that is currently unknown, but email and corporate email in particular may
soon need NR and testimonial capability. As far as other issues go, when the
privacy legislation comes on line and the DoJ gets up to speed with managing
slamming and spamming properly who knows maybe the answer is that this
number is going to get HUGE!!!

> that seem to be the focus of all your
> comments?

Depends on what the legal framework is for the country that this traffic is
passing through.

> If we eliminate all the informal e-mail, essentially all
> file transfers, web surfing for a great variety of information that
> may not result in purchases, the credit card transactions that, due
> to extant laws, are acceptably well protected, ...

But Steve all of these are transactions. Just not ones of the Buy or Sell
type. Everytime that a request and a fulfillment is made a transaction
happens.

> Yes, the Internet
> is about to grind to a halt because PKIX has not addressed your
> notion of what is required.

Ahahaha - You make the joke, No?

>
> Steve
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39HgKk01182 for ietf-pkix-bks; Tue, 9 Apr 2002 10:42:20 -0700 (PDT)
Received: from web.seguridata.com (seguridata02.terra.net.mx [200.4.103.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39HgIm01174 for <[e-mail]>; Tue, 9 Apr 2002 10:42:18 -0700 (PDT)
Received: from MarsXP ([192.168.0.166]) by web.seguridata.com (Post.Office MTA v3.5.3 release 223 ID# 517-61027U100L2S100V35) with ESMTP id com for <[e-mail]>; Tue, 9 Apr 2002 11:51:08 -0600
From: [e-mail] (Miguel Angel Rodriguez)
To: <[e-mail]>
Subject: TSA Policy Identifiers
Date: Tue, 9 Apr 2002 12:42:14 -0500
Message-ID: <000001c1dfed$e2a28730$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C1DFC3.F9CC7F30"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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_0001_01C1DFC3.F9CC7F30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi! Where can I find info on defined TSA Policy OIDs for TSP, rfc 3163?
 
Regards,
 
Miguel A Rodriguez
SeguriDATA
Mexico

------=_NextPart_000_0001_01C1DFC3.F9CC7F30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1DFC3.F99CE3B0">
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:GrammarState>Clean</w:GrammarState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:35.4pt;
	mso-footer-margin:35.4pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Hi! Where can I find info on defined TSA Policy <span
class=3DSpellE>OIDs</span> for TSP, <span class=3DSpellE>rfc</span> =
3163?<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Miguel A Rodriguez<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>SeguriDATA<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>Mexico<o:p></o:p></span></font></p>

</div>

</body>

</html>

------=_NextPart_000_0001_01C1DFC3.F9CC7F30--



Received: by above.proper.com (8.11.6/8.11.3) id g39HAwX28878 for ietf-pkix-bks; Tue, 9 Apr 2002 10:10:58 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39HAsm28872 for <[e-mail]>; Tue, 9 Apr 2002 10:10:55 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA01453; Tue, 9 Apr 2002 19:10:55 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 9 Apr 2002 19:10:55 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA03401; Tue, 9 Apr 2002 19:10:54 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA06370; Tue, 9 Apr 2002 19:10:53 +0200 (MET DST)
Date: Tue, 9 Apr 2002 19:10:53 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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 was told in private mail that in one of my previous messages
a statement that ended with a :-) could be misinterpreted
as a personal offense against Denis Pinkas.

I agree with that and hereby declare that there has been
no such intention.

The different styles of argumentation reminded me to
some discussions that happened almost 20 years ago
among former and actual colleagues; and I wanted
to share with all the anecdotical conclusions that had 
been drawn at that time.
   

Peter Sylvester



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39Gxft28423 for ietf-pkix-bks; Tue, 9 Apr 2002 09:59:41 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39Gxdm28419 for <[e-mail]>; Tue, 9 Apr 2002 09:59:39 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA01371; Tue, 9 Apr 2002 18:59:38 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 9 Apr 2002 18:59:38 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA03322; Tue, 9 Apr 2002 18:59:37 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA06361; Tue, 9 Apr 2002 18:59:37 +0200 (MET DST)
Date: Tue, 9 Apr 2002 18:59:37 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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>

> 
> We both agree that authentication is only from the initial server, 
> so the client does not need to understand where the data comes from. 

Ok.  More, the client may not even need to know what the data *ARE*. 

> > My definition
> > of visibility is just that it is possible to determine all data
> > that have contributed to a decision, and this information may
> > include the fact that they had original been build by someone
> > else and confirmed by the DPV server.
> > 
> > Somewhat related to this : On last Friday Ambarish wrote:
> > 
> >   Hi Peter,
> >       I agree with your desire to have a DPV response included where
> >    one would allow CRLs or OCSP responses to be included to prove
> >    how a server obtained the status of a certificate.
> > 
> >   Regards,
> >   Ambarish
> 
> This is different. CRLs, OCSP responses and certificates may be needed in
> case someone else, not trusting the YES anwser from one DPV server, would
> like to verify the certificate against the same policy using another DPV
> server. All the information collected at the time of first validation is not
> necessarilly available, e.g. two years later, hence why this data may be
> useful. 

A DPV server can operate in a simular way as an OCSP. with a similar "trust
environment", creating a "positive response" instead of a negative negative 
response. 

A CA may just want to operate an 'authorized DPV responder' instead
of providing CRLs or OCSP. Note, that the various extensions for OCSP proposing
to turn the -*- answer into a + answer by including the cert or
something like that could be regarded as an implementation of DPV.  

    
> > If this requirement is accepted by the group one can regards this
> > as a kind of visibility of relaying. 
> 
> There is no requirement for any visibility of relying.

That's not what I said. There is also no requirement for complete
obscurity or information hiding. 
 
> > The DPV responses may concern
> > the same certificate or some certicate in the chain or else.
> > 
> > As far as I remember, I have not read an argument why such
> > a thing would create harm or would be undesirable for whatever
> > reason.
> 
> There is no need for any extra information. Complexity and over-engineering
> should be avoided whenever possible.

What do you call 'any extra information'? 'extra' related to some
information considered 'normal'? 

What has this to do with over-engineering and complexity? 


These information are not 'extra'. DPV responses may the only 
ones available to return a 'timely status' of the certificate like
a 'timely revocation information'. 
    
> > Signatures of CAs, CRL providers, OCSP providers may are also visible.
> 
> Not exactly: CA certificates, CRLs and OCSP responses may optionally be
> returned.
Sorry for having made a error in my previous phrase the 'are' should be 'be'.

So we agree, still where is the essential difference between a DPV
response and an OCSP response concerning their signature?

There is already a requirement: 

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

which IMO means that the DPV response does not has a pure ephemeral status
but at least a similar characteristics as those of an OCSP response. 

> > Remember I said that "I agree that it is probably not necssary .."
> > 
> > Where do you see too much complexity: It is already complex to return a path,
> > CRLs and others. Is *this* complexity necessary, if one only needs
> > a yes/no/unknown answer?
> 
> See the rational explained above.

I still don't see where you see the complexity. DPV responses
may be given to other relying parties. Such a party must be 
able to validate it. It don't think that there is much code
complexity by allowing that the response itself may contain
a response as part of the justifications. 

I would think that there may be even simplicity If I only have 
to treat DPV responses for example.
 
> > Or, I fail to understand why some information that contributed to the
> > decision almost MUST be thrown away, in particular when it is possible
> > that it is important.
> 
> This information is optional and MAY be requested by the client.

Isn't this exactly what I am asking for. A DPV response may be
the only information available indicating that some intermediate CA
cert is valid. It MAY be optional returned when requested (or
defined as to be returned in the policy).    
 
> I hope these explanations will allow to close this issue.

I refer to my proposal to change the text saying that
that among the optional returned infos like paths CRL, 
OCSP responses, there may alos occur DPV responses.

Encapsulating a "DPV response" in a OCSP response still 
remains an option anyway.  
  
> Denis

Since you haven't commented the next paragraph may I assume that
this is ok with you?  

>  
> > I think the general principle should be that there is one mode
> > that all information essential to understand what has contributed
> > to the final decision must be made available to the client.
> > (Not necessarily understood by the client).
> > 
> > I would also agree, that only necessary information should be made
> > available. It may be not necessary to inform:
> > 
> > - Yesterday I have made three unsuccesseful attempt at time1 2 3,
> >   the last one finally succeed by using an internet connect to
> >   address a.b.c.d using DPV protocol over OCSP, ...
> > 
> > Peter
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39GKfl27450 for ietf-pkix-bks; Tue, 9 Apr 2002 09:20:41 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39GKdm27446 for <[e-mail]>; Tue, 9 Apr 2002 09:20:39 -0700 (PDT)
Received: from tsg1 ([12.81.78.88]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020409162034.RVOM8815.mtiwmhc23.worldnet.att.net@tsg1>; Tue, 9 Apr 2002 16:20:34 +0000
Message-ID: <032f01c1dfe2$4f7e3a40$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Tom Gindin" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: WG Last Call: Roadmap
Date: Tue, 9 Apr 2002 09:03:18 -0700
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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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>

For what it is worth- the term Trust Anchor is something that I coined at
Coastek some number of years ago  (1997) and is specific to an evaulated set
of trust processes. What I mean by that is that a trust anchor is the
uppermost anchoring trust element to which all others are referenced to or
through but that this is also specific to a particular transaction or set of
transactions.

The intent was/is to define on a per transaction basis a uniform point of
anchoring these referencable datasets. As to the mechanics of the process,
the term ROOT CA is the mechanical analog of the trust anchor only for the
mechanics of the transaction and not the content of the transaction per se.

The term "trust anchor" was/is to remove any ambiguity on a transaction
specific basis, and the term ROOT CA is more likely to be accepted as the
mechanical top of the pyramid (i.e. as part of the plumbing and not its use
per se.)

Todd

----- Original Message -----
From: "Tom Gindin" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, April 09, 2002 7:46 AM
Subject: Re: WG Last Call: Roadmap


>
>
>       Denis:
>
>       Should we really standardize on the term "root CA" rather than
"trust
> anchor" or "anchor CA"?  "Trust anchor" has never been used to mean
> anything other than an entity directly trusted by the RP, AFAIK.  I have
> other comments below.
>
>             Tom Gindin
>
> Denis Pinkas <[e-mail]> on 04/08/2002 12:32:41 PM
>
> To:    Tom Gindin/Watson/IBM@IBMUS
> cc:    [e-mail]
> Subject:    Re: WG Last Call: Roadmap
>
>
> Tom,
>
> I have not forgotten this message, but I gave priority to the DPV thread.
>
> >       Responses below.
>
> > The issue of who specifies the verifier's policy is
> > rather serious.  If the policy to be used is expected to be the same as
> RFC
> > 3126's SignaturePolicy, we need to specify a step in which the verifier
> has
> > the right to reject such a policy or to consider it inapplicable to the
> > verifier's own current context.
>
> This is true. However, the text does not go at that level of detail:
>
> "Another model considers a set of rules that apply to an application
> context. Every application context may have a different set of rules.
> When choosing to use certificates in the context of that application,
> the EE selects the set of rules for that context. In a set of rules,
> one or more Top CAs may be trusted, each one may be associated with
> different constraints, like the certificate policies that are trusted
> or the naming constraints that apply. These constrains may be specified
> either in self-signed certificates or in addition to self-signed
> certificates when they do not incorporate these constraints. This set
> of rules is called a validation policy (when validating a certificate)
> or a signature policy (when validating a digital signature)."
>
> I do not think it is necesary to state it. If you think so, please provide
> a text and a placement for that text.
>
> [TG] My biggest problem is the use of the term "signature policy", which
> you have elsewhere defined as something defined and signed by the signer
of
> the document.  In the paragraph above, I would replace the term "Top CAs"
> by "root CA's", and I would also call the sets of rules in the last
> sentence a "certificate validation policy" and a "signature validation
> policy".  I would then add the following statement: "Neither of these
> policies is considered to be the same as either a CertificatePolicy as
> defined in RFC 2459 or a SignaturePolicy as defined in RFC 3126."
>
> >
> > To:    Tom Gindin/Watson/IBM@IBMUS
> > cc:    [e-mail]
> > Subject:    Re: WG Last Call: Roadmap
> >
> > Tom,
> >
> > >       I have a few issues with this, and some corrections as well.
> >
> > >       In comment 12, I have two issues.  The first one, which is
minor,
> > is
> > > that  "one or more Top CA's may be trusted" should refer to root CA's
> > > instead - the two terms mean the same thing more often than not, but
> when
> > > they differ the trust point is the root rather than the top.
> >
> > PKIX-1 states:
> >
> >    " - Top CA - A CA that is at the top of a PKI hierarchy.
> >
> >    Note: This is often also called a "Root CA," since in data structures
> >    terms and in graph theory, the node at the top of a tree is the
> >    "root." However, to minimize confusion in this document, we elect to
> >    call this node a "Top CA," and reserve "Root CA" for the CA directly
> >    trusted by the EE."
> >
> > The problem lies with the last sentence, i.e. "*the* CA directly trusted
> by
> > the EE.". The singular is being used which means that there is a single
> > one, multiple roots are not permitted, while multiple Top-CAs are
> > permitted.
> >
> > [TG] Where in PKIX-1 is this?  I can't find the phrase "directly
trusted"
> > in either RFC 2459 or in draft 12 of new-pkix-1.
>
> Sorry for the confusion: it is in the roadmap document, not PKIX-1.
>
> The current text in the roadmap is:
>
>     " - Root CA - A CA that is directly trusted by an EE; that is,
>        securely acquiring the value of a Root CA public key requires
>        some out-of-band step(s). This term is not meant to imply that a
>        Root CA is necessarily at the top of any hierarchy, simply that
>        the CA in question is trusted directly.
>
> (...)
>
>    Note: This is often also called a "Root CA," since in data structures
>    terms and in graph theory, the node at the top of a tree is the
>    "root." However, to minimize confusion in this document, we elect to
>    call this node a "Top CA," and reserve "Root CA" for the CA directly
>    trusted by the EE. Readers new to PKIX should be aware that these
>    terms are not used consistently throughout the PKIX documents, as the
>    Internet PKI profile [2459bis] uses "Root CA" to refer to what this
>    and other documents call a "Top CA," and "most-trusted CA" to refer
>    to what this and other documents call a "Root CA."
>
> There is no problem with PKIX-1 but a problem with the roadmap document.
> PKIX-1 does not use the term "root CA", and thus it is wrong to say in
> the roadmap that "these terms are not used consistently throughout the
> PKIX documents".
>
> I would thus propose to change the note in the following way:
>
>    Note: Since in data structures terms and in graph theory, the node
>    at the top of a tree is the "root", the term "root CA" is sometimes
>    used. This term is not meant to imply that a Root CA is necessarily
>    at the top of any hierarchy, simply that the CA in question is trusted
>    directly.
>
> [TG] As I stated at the beginning, I don't know why we should standardize
> on the term "root CA" rather than "trust anchor" or "anchor CA".  Those
> terms cannot be mistaken for what is defined here as a "Top CA".  BTW, I
> approve of that coinage.
>
> Then, on page 14, change:
>
>    Additionally, once the Root CA ...
>
> with
>
>    Additionally, once a Root CA ...
>
>
> on pages 29 and 30, change:
>
>    (e.g., the DVCS's CA, or the Root CA in a
>    hierarchy)
>
> with
>
>    (e.g., the DVCS's CA, or a Root CA)
>
> Regards,
>
> Denis
>
>
> (snip)
>
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39GHCC27353 for ietf-pkix-bks; Tue, 9 Apr 2002 09:17:12 -0700 (PDT)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39GHAm27349 for <[e-mail]>; Tue, 9 Apr 2002 09:17:10 -0700 (PDT)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g39GGvC48003; Tue, 9 Apr 2002 16:16:58 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020409105853.02615830@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 09 Apr 2002 11:17:10 -0500
To: Fantou Patrick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: AW: LDAP Certificate transfer syntax
Cc: Christopher Oliva <[e-mail]>, David Chadwick <[e-mail]>, Mark Wahl <[e-mail]>, [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
In-Reply-To: <1D82815C322BD41196EA00508B951F7B01B40EB3@MCHH265E>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g39GHBm27350
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 10:44 AM 2002-04-09, Fantou Patrick wrote:
>I am not sure this discussion really brings us further.

I think this discussion is bringing us further along.  It has,
at least, boiled down this particular debate to one issue:
   whether or not ;binary is required when the binary
   encoding of a value is transferred in the protocol.

>There is no choice with some attributes like certificates.

I would have to agree that this is no choice.  But I think
we disagree on what that choice is.

One must transfer certificates in their binary encoding as
indicates by ;binary.   Note only is this the intent of RFC
2251, but we have demonstrated interoperability between
multiple independently developed implementations of this.

Others have argued that RFC 2251 could be read otherwise.
That's a good reason for clarifying the specification.  It's
a lousy reason for making changes which would cause implementations
which interoperate today to fail to interoperate with
implementations of the future specification.

>I fully support David´s proposal:
>"The use of the ;binary encoding option, i.e. by
>requesting or returning the attributes with descriptions
>"userCertificate;binary" or "caCertificate;binary" has no effect on the
>transfer syntax."

Noted.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39G0eI26543 for ietf-pkix-bks; Tue, 9 Apr 2002 09:00:40 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39G0dm26539 for <[e-mail]>; Tue, 9 Apr 2002 09:00:39 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA20544; Tue, 9 Apr 2002 18:03:14 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040918002784:251 ; Tue, 9 Apr 2002 18:00:27 +0200 
Message-ID: <[e-mail]>
Date: Tue, 09 Apr 2002 18:00:26 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: Roadmap
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 09/04/2002 18:00:28, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 09/04/2002 18:00:39, Serialize complete at 09/04/2002 18:00:39
Content-Transfer-Encoding: 7bit
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>

Tom,

>       Denis:
> 
>       Should we really standardize on the term "root CA" rather than "trust
> anchor" or "anchor CA"?  

I do not care, but I care for this document to be sent to the IESG soon. So
the sooner we may find a compromise, the better. Maybe the quickest way
is to try to suppress the sentences that create problems. We should
focuss on text replacement proposals.

> "Trust anchor" has never been used to mean anything other than an entity directly trusted by the RP, AFAIK.  

Not exactly. Read this sentence again.  However, I would like to resist to
start a new discusion now on trust anchors.

> I have other comments below.
> 
>             Tom Gindin
> 
> Denis Pinkas <[e-mail]> on 04/08/2002 12:32:41 PM
> 
> To:    Tom Gindin/Watson/IBM@IBMUS
> cc:    [e-mail]
> Subject:    Re: WG Last Call: Roadmap
> 
> Tom,
> 
> I have not forgotten this message, but I gave priority to the DPV thread.
> 
> >       Responses below.
> 
> > The issue of who specifies the verifier's policy is
> > rather serious.  If the policy to be used is expected to be the same as
> RFC
> > 3126's SignaturePolicy, we need to specify a step in which the verifier
> has
> > the right to reject such a policy or to consider it inapplicable to the
> > verifier's own current context.
> 
> This is true. However, the text does not go at that level of detail:
> 
> "Another model considers a set of rules that apply to an application
> context. Every application context may have a different set of rules.
> When choosing to use certificates in the context of that application,
> the EE selects the set of rules for that context. In a set of rules,
> one or more Top CAs may be trusted, each one may be associated with
> different constraints, like the certificate policies that are trusted
> or the naming constraints that apply. These constrains may be specified
> either in self-signed certificates or in addition to self-signed
> certificates when they do not incorporate these constraints. This set
> of rules is called a validation policy (when validating a certificate)
> or a signature policy (when validating a digital signature)."
> 
> I do not think it is necesary to state it. If you think so, please provide
> a text and a placement for that text.
> 
> [TG] My biggest problem is the use of the term "signature policy", which
> you have elsewhere defined as something defined and signed by the signer of
> the document.  

There is a misunderstanding. A signer may provide the *reference* of the
signature policy that he agrees to use when signing. In order to prevent
someone else to change that reference, it is protected by the signer's
signature. So in that case the verifier has first to see whether the
signature policy used by the signer is appropriate for his application
context. If it is the case, then it uses it, otherwise this is the end of
the story.

> In the paragraph above, I would replace the term "Top CAs"
> by "root CA's", 

No problem.

> and I would also call the sets of rules in the last
> sentence a "certificate validation policy" and a "signature validation
> policy".  I would then add the following statement: "Neither of these
> policies is considered to be the same as either a CertificatePolicy as
> defined in RFC 2459 or a SignaturePolicy as defined in RFC 3126."

I would simply propose to delete the following sentence:

"This set of rules is called a validation policy (when validating a
certificate) or a signature policy (when validating a digital signature)"
not because it is wrong, but because I would like this document to proceed.

This would lead to the following text:

"Another model considers a set of rules that apply to an application
context. Every application context may have a different set of rules.
When choosing to use certificates in the context of that application,
the EE selects the set of rules for that context. In a set of rules,
one or more root CAs may be trusted, each one may be associated with
different constraints, like the certificate policies that are trusted
or the naming constraints that apply. These constrains may be specified
either in self-signed certificates or in addition to self-signed
certificates when they do not incorporate these constraints." 

Can you live with it ?

> > To:    Tom Gindin/Watson/IBM@IBMUS
> > cc:    [e-mail]
> > Subject:    Re: WG Last Call: Roadmap
> >
> > Tom,
> >
> > >       I have a few issues with this, and some corrections as well.
> >
> > >       In comment 12, I have two issues.  The first one, which is minor,
> > is
> > > that  "one or more Top CA's may be trusted" should refer to root CA's
> > > instead - the two terms mean the same thing more often than not, but
> when
> > > they differ the trust point is the root rather than the top.
> >
> > PKIX-1 states:
> >
> >    " - Top CA - A CA that is at the top of a PKI hierarchy.
> >
> >    Note: This is often also called a "Root CA," since in data structures
> >    terms and in graph theory, the node at the top of a tree is the
> >    "root." However, to minimize confusion in this document, we elect to
> >    call this node a "Top CA," and reserve "Root CA" for the CA directly
> >    trusted by the EE."
> >
> > The problem lies with the last sentence, i.e. "*the* CA directly trusted
> by
> > the EE.". The singular is being used which means that there is a single
> > one, multiple roots are not permitted, while multiple Top-CAs are
> > permitted.
> >
> > [TG] Where in PKIX-1 is this?  I can't find the phrase "directly trusted"
> > in either RFC 2459 or in draft 12 of new-pkix-1.
> 
> Sorry for the confusion: it is in the roadmap document, not PKIX-1.
> 
> The current text in the roadmap is:
> 
>     " - Root CA - A CA that is directly trusted by an EE; that is,
>        securely acquiring the value of a Root CA public key requires
>        some out-of-band step(s). This term is not meant to imply that a
>        Root CA is necessarily at the top of any hierarchy, simply that
>        the CA in question is trusted directly.
> 
> (...)
> 
>    Note: This is often also called a "Root CA," since in data structures
>    terms and in graph theory, the node at the top of a tree is the
>    "root." However, to minimize confusion in this document, we elect to
>    call this node a "Top CA," and reserve "Root CA" for the CA directly
>    trusted by the EE. Readers new to PKIX should be aware that these
>    terms are not used consistently throughout the PKIX documents, as the
>    Internet PKI profile [2459bis] uses "Root CA" to refer to what this
>    and other documents call a "Top CA," and "most-trusted CA" to refer
>    to what this and other documents call a "Root CA."
> 
> There is no problem with PKIX-1 but a problem with the roadmap document.
> PKIX-1 does not use the term "root CA", and thus it is wrong to say in
> the roadmap that "these terms are not used consistently throughout the
> PKIX documents".
> 
> I would thus propose to change the note in the following way:
> 
>    Note: Since in data structures terms and in graph theory, the node
>    at the top of a tree is the "root", the term "root CA" is sometimes
>    used. This term is not meant to imply that a Root CA is necessarily
>    at the top of any hierarchy, simply that the CA in question is trusted
>    directly.
> 
> [TG] As I stated at the beginning, I don't know why we should standardize
> on the term "root CA" rather than "trust anchor" or "anchor CA".  Those
> terms cannot be mistaken for what is defined here as a "Top CA".  BTW, I
> approve of that coinage.

We do use "root CA", so I see no harm to use that vocabulary. This is no
attempt to standardize this term here. Originally my single concern what
that the text was talking about *one* root CA whereas there can be multiple.
This was my ONLY concern. This is now fixed. We should close this issue
ASAP.

Denis

> Then, on page 14, change:
> 
>    Additionally, once the Root CA ...
> 
> with
> 
>    Additionally, once a Root CA ...
> 
> on pages 29 and 30, change:
> 
>    (e.g., the DVCS's CA, or the Root CA in a
>    hierarchy)
> 
> with
> 
>    (e.g., the DVCS's CA, or a Root CA)
> 
> Regards,
> 
> Denis
> 
> (snip)


Received: by above.proper.com (8.11.6/8.11.3) id g39Fj0k24077 for ietf-pkix-bks; Tue, 9 Apr 2002 08:45:00 -0700 (PDT)
Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39Fiwm24067 for <[e-mail]>; Tue, 9 Apr 2002 08:44:58 -0700 (PDT)
Received: from moody.mchh.siemens.de (mail2.mchh.siemens.de [194.138.158.226]) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id RAA00957; Tue, 9 Apr 2002 17:44:44 +0200 (MET DST)
Received: from mchh246e.demchh201e.icn.siemens.de ([139.21.200.56]) by moody.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id RAA20992; Tue, 9 Apr 2002 17:44:45 +0200 (MET DST)
Received: by MCHH246E with Internet Mail Service (5.5.2653.19) id <H22NPZ9Q>; Tue, 9 Apr 2002 17:44:44 +0200
Message-ID: <1D82815C322BD41196EA00508B951F7B01B40EB3@MCHH265E>
From: Fantou Patrick <[e-mail]>
To: "'Kurt D. Zeilenga'" <[e-mail]>, Christopher Oliva <[e-mail]>
Cc: David Chadwick <[e-mail]>, Mark Wahl <[e-mail]>, [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: AW: LDAP Certificate transfer syntax
Date: Tue, 9 Apr 2002 17:44:17 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g39Fixm24072
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 Kurt and Chris,
 
I am not sure this discussion really brings us further.

There is no choice with some attributes like certificates.

I fully support David´s proposal:
"The use of the ;binary encoding option, i.e. by
requesting or returning the attributes with descriptions
"userCertificate;binary" or "caCertificate;binary" has no effect on the
transfer syntax."

Patrick

> -----Ursprüngliche Nachricht-----
> Von: Kurt D. Zeilenga [mailto:[e-mail]]
> Gesendet: Dienstag, 9. April 2002 17:19
> An: Christopher Oliva
> Cc: David Chadwick; Mark Wahl; [e-mail]; 'LDAP BIS';
> 'PKIX'
> Betreff: RE: LDAP Certificate transfer syntax
> 
> 
> At 10:05 AM 2002-04-09, Christopher Oliva wrote:
> >> ;binary must be present when the binary encoding is transferred. 
> >> ;binary must not be present when the native encoding is 
> transferred. 
> >
> >Where is that stated in the RFC ? There are no such statements. 
> 
> It is implied by the language of RFC 2251.  When a protocol
> provides multiple possible transfer encodings for a particular
> value, the protocol needs to provide a clear indication of
> which transfer encoding is being used.  In LDAPv3, absence
> and presence of transfer options is used to indicate which
> transfer encoding is used. 
> 
> Kurt
> 


Received: by above.proper.com (8.11.6/8.11.3) id g39FIhO21926 for ietf-pkix-bks; Tue, 9 Apr 2002 08:18:43 -0700 (PDT)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39FIfm21922 for <[e-mail]>; Tue, 9 Apr 2002 08:18:41 -0700 (PDT)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g39FITC47798; Tue, 9 Apr 2002 15:18:29 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020409101448.0260aa30@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 09 Apr 2002 10:18:42 -0500
To: Christopher Oliva <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Cc: David Chadwick <[e-mail]>, Mark Wahl <[e-mail]>, [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
In-Reply-To: <[e-mail] .com>
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>

At 10:05 AM 2002-04-09, Christopher Oliva wrote:
>> ;binary must be present when the binary encoding is transferred. 
>> ;binary must not be present when the native encoding is transferred. 
>
>Where is that stated in the RFC ? There are no such statements. 

It is implied by the language of RFC 2251.  When a protocol
provides multiple possible transfer encodings for a particular
value, the protocol needs to provide a clear indication of
which transfer encoding is being used.  In LDAPv3, absence
and presence of transfer options is used to indicate which
transfer encoding is used. 

Kurt



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39F6F321326 for ietf-pkix-bks; Tue, 9 Apr 2002 08:06:15 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39F6Em21321 for <[e-mail]>; Tue, 9 Apr 2002 08:06:14 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <2TBP0R8R>; Tue, 9 Apr 2002 11:06:00 -0400
Message-ID: <[e-mail]>
From: Christopher Oliva <[e-mail]>
To: "'Kurt D. Zeilenga'" <[e-mail]>
Cc: David Chadwick <[e-mail]>, Mark Wahl <[e-mail]>, [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Date: Tue, 9 Apr 2002 11:05:58 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DFD8.0DF67470"
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_01C1DFD8.0DF67470
Content-Type: text/plain;
	charset="iso-8859-1"


> >> >a) and b) 
> >> >RFC 2252 clause 6.5 only mandates a binary encoding. 
> >> >As previously pointed out by others, there is no absolute 
> >> imperative that requires the use of the ";binary" option. 
> >> 
> >> How else would you indicate that the "binary" encoding was 
> >> requested/used instead of the "string" encoding? 
> >
> >RFC 2252, 6.5 says that ".. values in this syntax MUST only 
> be transferred using the binary encoding ..".
> 
> Yes.  And RFC 2251 makes it quite clear that ;binary is used
> to indicate that the binary encoding was used instead of the
> native string encoding.  If ;binary is not present, binary
> transfer of the binary encoding is not used.

There is no statement that says that if the ";binary" option is absent, that
the syntax encoding cannot be the binary encoding. All the RFC says is that
";binary" overrides a string encoding. But certificates do not have a string
encoding. Since there is no string encoding to override, the ";binary"
option is not necessary.

> >Although 4.3.1 lists two reasons to use the binary encoding, 
> it does not say that other valid reasons or syntaxes cannot 
> require the use of the binary encoding.
> 
> But RFC 2251 states when binary encoding is to be used and when
> native encodings are to be used.

All it says is that ";binary" can override a string encoding. It doesn't say
anything about "native" encodings or what happens when no string encoding is
defined. It also does not say what happens when a syntax definition requires
a specific encoding (such as the Certificate syntax mandating the binary
encoding).

The only guide is that the Certificate syntax requires the binary encoding.
Therefore even if ";binary" is not used, the binary encoding must be
generated.

> 
> >Since the use of ";binary" is not mandatory for the 
> Certificate syntax,
> 
> I disagree.

Others have stated their belief that ";binary" is not mandatory for
certificates. There is no text that supports an absolute imperative that
";binary" MUST be used.

> 
> >and there is no other possible encoding, then the default 
> encoding that is used (that must be used) is the binary encoding.
> 
> There is no such thing as the "default" encoding.  That term is
> no where used in the specification.  There is the native string
> encoding and there is the binary encoding.  Which one is used
> is indicated by the absence or presence of transfer options.
> If this wasn't the case, then clients would have no clue as to
> what encoding was actually used.

The term "string encoding" is not defined either. So it is not clear if the
RFC refers to a "native string" encoding or an encoding based on text
(printable) strings.

I note that for Directory String, the RFC does not explicitly identify the
"string encoding" either. But we understand that the encoding mandated for
Directory String is UTF8. The same logic can be applied to certificates.

> 
> >If the ";binary" option is used to explicitly specify the 
> binary encoding, this results in the same encodings and this 
> would also satisfy the RFC.
> 
> ;binary must be present when the binary encoding is transferred.
> ;binary must not be present when the native encoding is transferred.

Where is that stated in the RFC ? There are no such statements.

> 
> >> >c) 
> >> >Nowhere in the ldapv3 RFCs is there a description of the 
> >> behavior for this case. There is no justification to label 
> >> this as non conformant. 
> >> 
> >> You are right in that the RFC does not explicit state this. 
> >> 
> >> But it should be obvious that "CN;binary" should not be 
> >> returned unless "CN;binary" was requested.  Same goes 
> >> for userCertificate. 
> >> 
> >
> >Attributes must be returned according to their syntax 
> encoding requirements. 
> 
> Values of a syntax can encoded multiple ways for transfer.  The
> encoding used is always indicated by the presence or absence of
> transfer options such as ;binary.
> 

The ";binary" only specifies that a "string encoding" was overridden. But if
there is not string encoding to override, then the ";binary" is not required
(there is no text that says ;binary is required when there is no string
encoding to override).

Chris.

------_=_NextPart_001_01C1DFD8.0DF67470
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: LDAP Certificate transfer syntax</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>&gt; &gt;&gt; &gt;a) and b) </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;RFC 2252 clause 6.5 only mandates =
a binary encoding. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;As previously pointed out by =
others, there is no absolute </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; imperative that requires the use of =
the &quot;;binary&quot; option. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; How else would you indicate that the =
&quot;binary&quot; encoding was </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; requested/used instead of the =
&quot;string&quot; encoding? </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;RFC 2252, 6.5 says that &quot;.. values in =
this syntax MUST only </FONT>
<BR><FONT SIZE=3D2>&gt; be transferred using the binary encoding =
..&quot;.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Yes.&nbsp; And RFC 2251 makes it quite clear =
that ;binary is used</FONT>
<BR><FONT SIZE=3D2>&gt; to indicate that the binary encoding was used =
instead of the</FONT>
<BR><FONT SIZE=3D2>&gt; native string encoding.&nbsp; If ;binary is not =
present, binary</FONT>
<BR><FONT SIZE=3D2>&gt; transfer of the binary encoding is not =
used.</FONT>
</P>

<P><FONT SIZE=3D2>There is no statement that says that if the =
&quot;;binary&quot; option is absent, that the syntax encoding cannot =
be the binary encoding. All the RFC says is that &quot;;binary&quot; =
overrides a string encoding. But certificates do not have a string =
encoding. Since there is no string encoding to override, the =
&quot;;binary&quot; option is not necessary.</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt;Although 4.3.1 lists two reasons to use the =
binary encoding, </FONT>
<BR><FONT SIZE=3D2>&gt; it does not say that other valid reasons or =
syntaxes cannot </FONT>
<BR><FONT SIZE=3D2>&gt; require the use of the binary encoding.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; But RFC 2251 states when binary encoding is to =
be used and when</FONT>
<BR><FONT SIZE=3D2>&gt; native encodings are to be used.</FONT>
</P>

<P><FONT SIZE=3D2>All it says is that &quot;;binary&quot; can override =
a string encoding. It doesn't say anything about &quot;native&quot; =
encodings or what happens when no string encoding is defined. It also =
does not say what happens when a syntax definition requires a specific =
encoding (such as the Certificate syntax mandating the binary =
encoding).</FONT></P>

<P><FONT SIZE=3D2>The only guide is that the Certificate syntax =
requires the binary encoding. Therefore even if &quot;;binary&quot; is =
not used, the binary encoding must be generated.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Since the use of &quot;;binary&quot; is not =
mandatory for the </FONT>
<BR><FONT SIZE=3D2>&gt; Certificate syntax,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I disagree.</FONT>
</P>

<P><FONT SIZE=3D2>Others have stated their belief that =
&quot;;binary&quot; is not mandatory for certificates. There is no text =
that supports an absolute imperative that &quot;;binary&quot; MUST be =
used.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;and there is no other possible encoding, =
then the default </FONT>
<BR><FONT SIZE=3D2>&gt; encoding that is used (that must be used) is =
the binary encoding.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; There is no such thing as the =
&quot;default&quot; encoding.&nbsp; That term is</FONT>
<BR><FONT SIZE=3D2>&gt; no where used in the specification.&nbsp; There =
is the native string</FONT>
<BR><FONT SIZE=3D2>&gt; encoding and there is the binary =
encoding.&nbsp; Which one is used</FONT>
<BR><FONT SIZE=3D2>&gt; is indicated by the absence or presence of =
transfer options.</FONT>
<BR><FONT SIZE=3D2>&gt; If this wasn't the case, then clients would =
have no clue as to</FONT>
<BR><FONT SIZE=3D2>&gt; what encoding was actually used.</FONT>
</P>

<P><FONT SIZE=3D2>The term &quot;string encoding&quot; is not defined =
either. So it is not clear if the RFC refers to a &quot;native =
string&quot; encoding or an encoding based on text (printable) =
strings.</FONT></P>

<P><FONT SIZE=3D2>I note that for Directory String, the RFC does not =
explicitly identify the &quot;string encoding&quot; either. But we =
understand that the encoding mandated for Directory String is UTF8. The =
same logic can be applied to certificates.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;If the &quot;;binary&quot; option is used =
to explicitly specify the </FONT>
<BR><FONT SIZE=3D2>&gt; binary encoding, this results in the same =
encodings and this </FONT>
<BR><FONT SIZE=3D2>&gt; would also satisfy the RFC.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ;binary must be present when the binary =
encoding is transferred.</FONT>
<BR><FONT SIZE=3D2>&gt; ;binary must not be present when the native =
encoding is transferred.</FONT>
</P>

<P><FONT SIZE=3D2>Where is that stated in the RFC ? There are no such =
statements.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;c) </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; &gt;Nowhere in the ldapv3 RFCs is =
there a description of the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; behavior for this case. There is no =
justification to label </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; this as non conformant. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; You are right in that the RFC does not =
explicit state this. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; But it should be obvious that =
&quot;CN;binary&quot; should not be </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; returned unless &quot;CN;binary&quot; =
was requested.&nbsp; Same goes </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; for userCertificate. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Attributes must be returned according to =
their syntax </FONT>
<BR><FONT SIZE=3D2>&gt; encoding requirements. </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Values of a syntax can encoded multiple ways =
for transfer.&nbsp; The</FONT>
<BR><FONT SIZE=3D2>&gt; encoding used is always indicated by the =
presence or absence of</FONT>
<BR><FONT SIZE=3D2>&gt; transfer options such as ;binary.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>The &quot;;binary&quot; only specifies that a =
&quot;string encoding&quot; was overridden. But if there is not string =
encoding to override, then the &quot;;binary&quot; is not required =
(there is no text that says ;binary is required when there is no string =
encoding to override).</FONT></P>

<P><FONT SIZE=3D2>Chris.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1DFD8.0DF67470--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39EuAu19922 for ietf-pkix-bks; Tue, 9 Apr 2002 07:56:10 -0700 (PDT)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39Eu8m19914 for <[e-mail]>; Tue, 9 Apr 2002 07:56:08 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g39EtWlh444222; Tue, 9 Apr 2002 10:55:32 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g39EtTj70172; Tue, 9 Apr 2002 10:55:29 -0400
Importance: Normal
Sensitivity: 
Subject: Re: WG Last Call: Roadmap
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Tue, 9 Apr 2002 10:46:34 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/09/2002 10:55:30 AM
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>

      Denis:

      Should we really standardize on the term "root CA" rather than "trust
anchor" or "anchor CA"?  "Trust anchor" has never been used to mean
anything other than an entity directly trusted by the RP, AFAIK.  I have
other comments below.

            Tom Gindin

Denis Pinkas <[e-mail]> on 04/08/2002 12:32:41 PM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [e-mail]
Subject:    Re: WG Last Call: Roadmap


Tom,

I have not forgotten this message, but I gave priority to the DPV thread.

>       Responses below.

> The issue of who specifies the verifier's policy is
> rather serious.  If the policy to be used is expected to be the same as
RFC
> 3126's SignaturePolicy, we need to specify a step in which the verifier
has
> the right to reject such a policy or to consider it inapplicable to the
> verifier's own current context.

This is true. However, the text does not go at that level of detail:

"Another model considers a set of rules that apply to an application
context. Every application context may have a different set of rules.
When choosing to use certificates in the context of that application,
the EE selects the set of rules for that context. In a set of rules,
one or more Top CAs may be trusted, each one may be associated with
different constraints, like the certificate policies that are trusted
or the naming constraints that apply. These constrains may be specified
either in self-signed certificates or in addition to self-signed
certificates when they do not incorporate these constraints. This set
of rules is called a validation policy (when validating a certificate)
or a signature policy (when validating a digital signature)."

I do not think it is necesary to state it. If you think so, please provide
a text and a placement for that text.

[TG] My biggest problem is the use of the term "signature policy", which
you have elsewhere defined as something defined and signed by the signer of
the document.  In the paragraph above, I would replace the term "Top CAs"
by "root CA's", and I would also call the sets of rules in the last
sentence a "certificate validation policy" and a "signature validation
policy".  I would then add the following statement: "Neither of these
policies is considered to be the same as either a CertificatePolicy as
defined in RFC 2459 or a SignaturePolicy as defined in RFC 3126."

>
> To:    Tom Gindin/Watson/IBM@IBMUS
> cc:    [e-mail]
> Subject:    Re: WG Last Call: Roadmap
>
> Tom,
>
> >       I have a few issues with this, and some corrections as well.
>
> >       In comment 12, I have two issues.  The first one, which is minor,
> is
> > that  "one or more Top CA's may be trusted" should refer to root CA's
> > instead - the two terms mean the same thing more often than not, but
when
> > they differ the trust point is the root rather than the top.
>
> PKIX-1 states:
>
>    " - Top CA - A CA that is at the top of a PKI hierarchy.
>
>    Note: This is often also called a "Root CA," since in data structures
>    terms and in graph theory, the node at the top of a tree is the
>    "root." However, to minimize confusion in this document, we elect to
>    call this node a "Top CA," and reserve "Root CA" for the CA directly
>    trusted by the EE."
>
> The problem lies with the last sentence, i.e. "*the* CA directly trusted
by
> the EE.". The singular is being used which means that there is a single
> one, multiple roots are not permitted, while multiple Top-CAs are
> permitted.
>
> [TG] Where in PKIX-1 is this?  I can't find the phrase "directly trusted"
> in either RFC 2459 or in draft 12 of new-pkix-1.

Sorry for the confusion: it is in the roadmap document, not PKIX-1.

The current text in the roadmap is:

    " - Root CA - A CA that is directly trusted by an EE; that is,
       securely acquiring the value of a Root CA public key requires
       some out-of-band step(s). This term is not meant to imply that a
       Root CA is necessarily at the top of any hierarchy, simply that
       the CA in question is trusted directly.

(...)

   Note: This is often also called a "Root CA," since in data structures
   terms and in graph theory, the node at the top of a tree is the
   "root." However, to minimize confusion in this document, we elect to
   call this node a "Top CA," and reserve "Root CA" for the CA directly
   trusted by the EE. Readers new to PKIX should be aware that these
   terms are not used consistently throughout the PKIX documents, as the
   Internet PKI profile [2459bis] uses "Root CA" to refer to what this
   and other documents call a "Top CA," and "most-trusted CA" to refer
   to what this and other documents call a "Root CA."

There is no problem with PKIX-1 but a problem with the roadmap document.
PKIX-1 does not use the term "root CA", and thus it is wrong to say in
the roadmap that "these terms are not used consistently throughout the
PKIX documents".

I would thus propose to change the note in the following way:

   Note: Since in data structures terms and in graph theory, the node
   at the top of a tree is the "root", the term "root CA" is sometimes
   used. This term is not meant to imply that a Root CA is necessarily
   at the top of any hierarchy, simply that the CA in question is trusted
   directly.

[TG] As I stated at the beginning, I don't know why we should standardize
on the term "root CA" rather than "trust anchor" or "anchor CA".  Those
terms cannot be mistaken for what is defined here as a "Top CA".  BTW, I
approve of that coinage.

Then, on page 14, change:

   Additionally, once the Root CA ...

with

   Additionally, once a Root CA ...


on pages 29 and 30, change:

   (e.g., the DVCS's CA, or the Root CA in a
   hierarchy)

with

   (e.g., the DVCS's CA, or a Root CA)

Regards,

Denis


(snip)




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39EY3H18707 for ietf-pkix-bks; Tue, 9 Apr 2002 07:34:03 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g39EY1m18703 for <[e-mail]>; Tue, 9 Apr 2002 07:34:01 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 9 Apr 2002 14:33:01 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA11278 for <[e-mail]>; Tue, 9 Apr 2002 10:32:53 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g39EXVf21723 for <[e-mail]>; Tue, 9 Apr 2002 10:33:32 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1QG44>; Tue, 9 Apr 2002 10:30:10 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.95]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1QG4T; Tue, 9 Apr 2002 10:30:06 -0400
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 09 Apr 2002 10:32:26 -0400
Subject: Re: Open issue: DPV relay
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05100303b8d77d9f2730@[128.33.238.74]>
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>

Steve:

>So, in requirements language I guess I'd be arguing for something
>like:
>
>- A protocol SHOULD NOT require DPV clients to support relay or
>   re-direct (aka chaining or referral)
>- A protocol MAY require DPV servers to include support for
>   relay and/or re-direct (aka chaining and/or referral)
>
>Is that reasonable?

I could live with:

1.  The DPV protocol MUST NOT require DPV clients to support relay, 
re-direct or multicast.

2.  The DPV protocol MUST NOT prohibit DPV servers from employing relay 
(a.k.a. chaining).

I do not want to include any capability for re-direct (a.k.a. referral) for 
any party.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39ESc418512 for ietf-pkix-bks; Tue, 9 Apr 2002 07:28:38 -0700 (PDT)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39ESbm18508 for <[e-mail]>; Tue, 9 Apr 2002 07:28:37 -0700 (PDT)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g39ESAC47484; Tue, 9 Apr 2002 14:28:10 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020409091556.02621180@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 09 Apr 2002 09:28:23 -0500
To: Christopher Oliva <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Cc: David Chadwick <[e-mail]>, Mark Wahl <[e-mail]>, [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
In-Reply-To: <[e-mail] .com>
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>

At 08:09 PM 2002-04-08, Christopher Oliva wrote:
>> >Here are some observations on the three cases: 
>> > 
>> >a) and b) 
>> >RFC 2252 clause 6.5 only mandates a binary encoding. 
>> >As previously pointed out by others, there is no absolute 
>> imperative that requires the use of the ";binary" option. 
>> 
>> How else would you indicate that the "binary" encoding was 
>> requested/used instead of the "string" encoding? 
>
>RFC 2252, 6.5 says that ".. values in this syntax MUST only be transferred using the binary encoding ..".

Yes.  And RFC 2251 makes it quite clear that ;binary is used
to indicate that the binary encoding was used instead of the
native string encoding.  If ;binary is not present, binary
transfer of the binary encoding is not used.

>Also, no other encoding is provided therefore only the binary encoding can be used.

Yes, so ;binary must be used.

>Although 4.3.1 lists two reasons to use the binary encoding, it does not say that other valid reasons or syntaxes cannot require the use of the binary encoding.

But RFC 2251 states when binary encoding is to be used and when
native encodings are to be used.

>Since the use of ";binary" is not mandatory for the Certificate syntax,

I disagree.

>and there is no other possible encoding, then the default encoding that is used (that must be used) is the binary encoding.

There is no such thing as the "default" encoding.  That term is
no where used in the specification.  There is the native string
encoding and there is the binary encoding.  Which one is used
is indicated by the absence or presence of transfer options.
If this wasn't the case, then clients would have no clue as to
what encoding was actually used.

>If the ";binary" option is used to explicitly specify the binary encoding, this results in the same encodings and this would also satisfy the RFC.

;binary must be present when the binary encoding is transferred.
;binary must not be present when the native encoding is transferred.

>> >c) 
>> >Nowhere in the ldapv3 RFCs is there a description of the 
>> behavior for this case. There is no justification to label 
>> this as non conformant. 
>> 
>> You are right in that the RFC does not explicit state this. 
>> 
>> But it should be obvious that "CN;binary" should not be 
>> returned unless "CN;binary" was requested.  Same goes 
>> for userCertificate. 
>> 
>
>Attributes must be returned according to their syntax encoding requirements. 

Values of a syntax can encoded multiple ways for transfer.  The
encoding used is always indicated by the presence or absence of
transfer options such as ;binary.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39DE4C15230 for ietf-pkix-bks; Tue, 9 Apr 2002 06:14:04 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39DE2m15221 for <[e-mail]>; Tue, 9 Apr 2002 06:14:03 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA26562; Tue, 9 Apr 2002 15:16:36 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040915133360:197 ; Tue, 9 Apr 2002 15:13:33 +0200 
Message-ID: <[e-mail]>
Date: Tue, 09 Apr 2002 15:13:32 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 09/04/2002 15:13:33, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 09/04/2002 15:14:01, Serialize complete at 09/04/2002 15:14:01
Content-Transfer-Encoding: 7bit
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>

Peter,

> > > If the final answer
> > > MAY contain answer from other service, a client might get some idea,
> > > but I don't think that this creates a problem.
> >
> > The answer from a DPV server to an end-user client DOES NOT contain a signed
> > answer from another server, but may contain some data from another server.
> > The fact that that data comes from another server is NOT visible to the
> > end-user client.

> It may be that we have a different idea of visibility. I don't mean
> that the client has to understand where data come from and the
> only authentication is from the initial service. 

We both agree that authentication is only from the initial server, 
so the client does not need to understand where the data comes from. 

> My definition
> of visibility is just that it is possible to determine all data
> that have contributed to a decision, and this information may
> include the fact that they had original been build by someone
> else and confirmed by the DPV server.
> 
> Somewhat related to this : On last Friday Ambarish wrote:
> 
>   Hi Peter,
>       I agree with your desire to have a DPV response included where
>    one would allow CRLs or OCSP responses to be included to prove
>    how a server obtained the status of a certificate.
> 
>   Regards,
>   Ambarish

This is different. CRLs, OCSP responses and certificates may be needed in
case someone else, not trusting the YES anwser from one DPV server, would
like to verify the certificate against the same policy using another DPV
server. All the information collected at the time of first validation is not
necessarilly available, e.g. two years later, hence why this data may be
useful.   
 
> If this requirement is accepted by the group one can regards this
> as a kind of visibility of relaying. 

There is no requirement for any visibility of relying.

> The DPV responses may concern
> the same certificate or some certicate in the chain or else.
> 
> As far as I remember, I have not read an argument why such
> a thing would create harm or would be undesirable for whatever
> reason.

There is no need for any extra information. Complexity and over-engineering
should be avoided whenever possible.
 
> > > I agree that it is probably not necssary to make explicitely available
> > > some information of the kind: "I have used a multicasting scheme among
> > > servers X to Z or chaining to Y'.
> > >
> > > The client or another relying party want to know whether it is
> > > valid and (maybe) why the server believes so.
> > >
> > > There may be: I have asked the following n servers and they all told me *no*.
> >
> > All that complexity is not needed, there is a single signature visible and
> > the names of the intermediate servers, if any, are not visible. These names
> > are not necessary (a stop-loop mechanism can be implemented without them).
 
> Signatures of CAs, CRL providers, OCSP providers may are also visible.

Not exactly: CA certificates, CRLs and OCSP responses may optionally be
returned.

> Remember I said that "I agree that it is probably not necssary .."
> 
> Where do you see too much complexity: It is already complex to return a path,
> CRLs and others. Is *this* complexity necessary, if one only needs
> a yes/no/unknown answer?

See the rational explained above.

> Or, I fail to understand why some information that contributed to the
> decision almost MUST be thrown away, in particular when it is possible
> that it is important.

This information is optional and MAY be requested by the client.

I hope these explanations will allow to close this issue.

Denis
 
> I think the general principle should be that there is one mode
> that all information essential to understand what has contributed
> to the final decision must be made available to the client.
> (Not necessarily understood by the client).
> 
> I would also agree, that only necessary information should be made
> available. It may be not necessary to inform:
> 
> - Yesterday I have made three unsuccesseful attempt at time1 2 3,
>   the last one finally succeed by using an internet connect to
>   address a.b.c.d using DPV protocol over OCSP, ...
> 
> Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39CqOK13042 for ietf-pkix-bks; Tue, 9 Apr 2002 05:52:24 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39CqLm13038 for <[e-mail]>; Tue, 9 Apr 2002 05:52:22 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA00256; Tue, 9 Apr 2002 14:52:12 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 9 Apr 2002 14:52:12 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA02379; Tue, 9 Apr 2002 14:52:11 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA06312; Tue, 9 Apr 2002 14:52:11 +0200 (MET DST)
Date: Tue, 9 Apr 2002 14:52:11 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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>

> 
> > If the final answer
> > MAY contain answer from other service, a client might get some idea,
> > but I don't think that this creates a problem.
> 
> The answer from a DPV server to an end-user client DOES NOT contain a signed
> answer from another server, but may contain some data from another server.
> The fact that that data comes from another server is NOT visible to the
> end-user client. 
It may be that we have a different idea of visibility. I don't mean
that the client has to understand where data come from and the
only authentication is from the initial service. My definition
of visibility is just that it is possible to determine all data
that have contributed to a decision, and this information may
include the fact that they had original been build by someone
else and confirmed by the DPV server.

Somewhat related to this : On last Friday Ambarish wrote:

  Hi Peter,
      I agree with your desire to have a DPV response included where
   one would allow CRLs or OCSP responses to be included to prove
   how a server obtained the status of a certificate.

  Regards,
  Ambarish

If this requirement is accepted by the group one can regards this
as a kind of visibility of relaying. The DPV responses may concern
the same certificate or some certicate in the chain or else. 

As far as I remember, I have not read an argument why such
a thing would create harm or would be undesirable for whatever
reason.  
  
> > I agree that it is probably not necssary to make explicitely available
> > some information of the kind: "I have used a multicasting scheme among
> > servers X to Z or chaining to Y'.
> > 
> > The client or another relying party want to know whether it is
> > valid and (maybe) why the server believes so.
> > 
> > There may be: I have asked the following n servers and they all told me *no*.
> 
> All that complexity is not needed, there is a single signature visible and
> the names of the intermediate servers, if any, are not visible. These names
> are not necessary (a stop-loop mechanism can be implemented without them).

Signatures of CAs, CRL providers, OCSP providers may are also visible. 

Remember I said that "I agree that it is probably not necssary .."

Where do you see too much complexity: It is already complex to return a path,
CRLs and others. Is *this* complexity necessary, if one only needs
a yes/no/unknown answer? 

Or, I fail to understand why some information that contributed to the 
decision almost MUST be thrown away, in particular when it is possible 
that it is important. 

I think the general principle should be that there is one mode
that all information essential to understand what has contributed
to the final decision must be made available to the client. 
(Not necessarily understood by the client).

I would also agree, that only necessary information should be made
available. It may be not necessary to inform:

- Yesterday I have made three unsuccesseful attempt at time1 2 3,
  the last one finally succeed by using an internet connect to
  address a.b.c.d using DPV protocol over OCSP, ... 

Peter








Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39CEbF10742 for ietf-pkix-bks; Tue, 9 Apr 2002 05:14:37 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39CEZm10738 for <[e-mail]>; Tue, 9 Apr 2002 05:14:35 -0700 (PDT)
Received: from Chokhani ([12.91.128.183]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020409121430.KLFL8815.mtiwmhc23.worldnet.att.net@Chokhani>; Tue, 9 Apr 2002 12:14:30 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Trevor Freeman'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>, "'Peter Williams'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: Open issue: DPV relay
Date: Tue, 9 Apr 2002 08:16:09 -0400
Message-ID: <000001c1dfc0$55ed8970$a300a8c0@Chokhani>
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, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
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 agree with what Trevor says.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Trevor Freeman
Sent: Monday, April 08, 2002 9:49 PM
To: Housley, Russ; Peter Williams
Cc: [e-mail]
Subject: RE: Open issue: DPV relay



Asking for a DPV relay is serious miss-interpreting the intent of DPV. 

In DPV you have a security association between the client and DPV
server. The client is outsourcing its certificate trust decisions to DPV
server. It is reasonable for the DPV server to employ any resource it
deems necessary to complete the request from the client that the DPV
server underwrites. The DPV server has to decide what resources it uses.
None of this is of any consequence to the client as long as the decision
is gives back to the client in accordance with the previously agreed
policy. All the client wants is a decision according to the policy. A
client could set up multiple SA to different DPV servers if it wanted
higher assurance that the answer from the DPV server was the "right"
answer - but that begs the question of why the client is not using DPD

Trevor

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]] 
Sent: Monday, April 08, 2002 9:22 AM
To: Peter Williams
Cc: [e-mail]
Subject: RE: Open issue: DPV relay


Peter:

I think you are changing the context of my statement.  I said: "... the 
client asks one DPV server to perform an action.  The response should
come 
back, signed by that DPV server, or it is an error from the client's 
perspective."

I did not say that the client could not have a trust relationship with
more 
than one DPV server.

Russ



At 05:28 PM 4/5/2002 -0800, Peter Williams wrote:

>Todd,
>
>I do not believe we should formulate any
>particular use-model at this time, for DPV REQUIREMENTS; leaving aside 
>the philosophical issue of whether use-modeling would or would not help

>IETF standards adoption. The requirements should prepare for
>protocol-specification, not establish operational
>usage constraints.
>
>The only valuable use-issues topics I can forsee that might serve us 
>(in contradiction to the above) are precisely those that Ambarish 
>mentioned: do what OCSP did, so succesfully in the Internet 
>environment... for the same issue; and dont lets sucumb to the 
>temptation to over-architect!
>
>--------------
>
>In my view, on Russ side comment, constraining DPV to
>require users to interact
>with a service provider at a single access-point is
>like setting the clock back on X.509, and requiring
>the world to adopt the Entrust use-model
>of PKC key management. Entrust's use-model makes
>for a fine and highly-manageable system, but it
>competes (successfully) with other domain-management
>models that are equally succesful in the wider Internet environment we 
>server.
>
>The only trust issue for DPV requirments I can see
>is this:
>
>Just, as Sharon recently indicated, PMI's SOAs
>are trusted as authoritative for their policy
>scope, so DPV servers are trusted. PMI deals
>with privileges; DPV deals with remote processing
>of chains against validation policies. The two
>authority models are really identical, otherwise.
>
>Lets note that PMI didnt constrain an AC verifier to use
>only a single SOA-headed source of AC paths. So
>should the DPV requirements not constrain the
>DPV client from accepting results from
>any  set of (possibly (out of IETF scope) constained) DPV servers - 
>whose service is provided at the access point to which the client is 
>bound (including that operated, perhaps, by a simple-proxing or a
>chaining&resigning DPV server).
>
>
>-----Original Message-----
>From: todd glassey [mailto:[e-mail]]
>Sent: Friday, April 05, 2002 3:52 PM
>To: Housley, Russ; jim
>Cc: [e-mail]; Tim Polk; [e-mail]
>Subject: Re: Open issue: DPV relay
>
>
>
>Russ is 100% dead on  but this is about the mechanics of the use model
more
>than anything - let me demonstrate...
>
>----- Original Message -----
>From: "Housley, Russ" <[e-mail]>
>To: "jim" <[e-mail]>
>Cc: <[e-mail]>; "Tim Polk" <[e-mail]>; 
><[e-mail]>
>Sent: Friday, April 05, 2002 12:42 PM
>Subject: Re: Open issue: DPV relay
>
>
> >
> > Jim:
> >
> > I am not talking about trust in the X.500 system.  I am talking
about
>trust
> > in a DPV server.  In my mind, the client asks one DPV server to
perform an
> > action.  The response should come back, signed by that DPV server,
or it
>is
> > an error from the client's perspective.
> >
> > I see no reason for the client to be made aware of an chaining or
>multicasting.
> >
> > I do not think that we should include referrals in the DPV system at
all.
>
>The only way this would not want to be true is if the trust model
between
>the requesting agents and the supplying agents had a pre-existing
agreement
>that the trust supplying agent could look beyond its own services as
sources
>of the trust model its looking for from this DPV server. It would then
stand
>as a referred trust provider when it cannot satisfy the trust request 
>itself.
>
>In fact from a use model perspective, it would seem that only the
client
>could authotize this  for privacy reasons, and it seems that it would
need
>to be on a per transaction basis (I.e. the Trust provider says " my
trust
>processes cannon fulfill this request so I have passed it onward to
someone
>that can" ... the only problem is that you run the potential that the
next
>link in the trust envelope would also not be able to satisfy this
request
>either or coupdl get locked in a loop... so where does it stop???)
>
>The "what" of what you have now is a situation where the referring
agent is
>going around and shopping for an external DPV agent who can and is
willing
>to satisfy this trust validation request.  And this seems at best kinda

>clunky and potentially a real problem  over privacy and context
information
>from the actual agent requesting this validation service.
>
>I suggest that becuase of this, that unless specifically authorized or 
>requested from the client, that the DPV services should be restruicted
to
>stay on a single platform... and it be the Client's responsibility to 
>hierarchicly check out the trust element in question.
>
> >
> > Russ
>
>SNIP



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39BkdV09782 for ietf-pkix-bks; Tue, 9 Apr 2002 04:46:39 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39Bkbm09775 for <[e-mail]>; Tue, 9 Apr 2002 04:46:37 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA29976; Tue, 9 Apr 2002 13:46:30 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 9 Apr 2002 13:46:30 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA02258; Tue, 9 Apr 2002 13:46:29 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA06299; Tue, 9 Apr 2002 13:46:29 +0200 (MET DST)
Date: Tue, 9 Apr 2002 13:46:29 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Open issue: DPV relay
Cc: [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>

> 
> Asking for a DPV relay is serious miss-interpreting the intent of DPV. 

I am confused: 

I am not sure but when I follow your following argument to the end,
a DPV client would need anything more than
just a authentic yes/no/unknown,  not even a path; what is the
purpose of giving a path to a client if the only thing it needs
is a assertion about the status of the certificate.

> In DPV you have a security association between the client and DPV
> server. The client is outsourcing its certificate trust decisions to DPV
> server. It is reasonable for the DPV server to employ any resource it
> deems necessary to complete the request from the client that the DPV
> server underwrites. The DPV server has to decide what resources it uses.

The term 'relaying' is related to the observation that
one of the possible resources is another DPV server. 
There is a possibility that the server turns itself into a 
client to another service and uses the same protocol.

One of the questions related to 'blind relaying' (if I 
correctly understand Tim's definition) is how to avoid loops
simply because the same or a similar request is used.

Another question is to what degree the details of who
has created the essence of the response is visible to a user. 
The initial server SHOULD be required to create a response 
that can be authenticated by the initial client. 

> None of this is of any consequence to the client as long as the decision
> is gives back to the client in accordance with the previously agreed
> policy. All the client wants is a decision according to the policy. A
> client could set up multiple SA to different DPV servers if it wanted
> higher assurance that the answer from the DPV server was the "right"
> answer - but that begs the question of why the client is not using DPD

I think that had been a lot discussion about use cases where
some clients want more than just a simple decision.   

A client may require to see some or all the elements (path, CRLs, OCSPs, 
DVCs, DPV responses) that have contributed to the decision. Furthermore, 
it is not necessarily the client who asked for them will exploit these 
information, they may be just kept in order to have a verifiable trace of 
what had contributed to the decision. 

This is independant from 'relaying' which can occur simply because the
protocol may be a convenient way to obtain information from what Denis calls
'a server that operates in the background'. 

Did I miss something?  
>
> Trevor
>
Peter S.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39BXEH08987 for ietf-pkix-bks; Tue, 9 Apr 2002 04:33:14 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39BXCm08980 for <[e-mail]>; Tue, 9 Apr 2002 04:33:13 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA29926; Tue, 9 Apr 2002 13:33:05 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 9 Apr 2002 13:33:05 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA02216; Tue, 9 Apr 2002 13:33:03 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA06294; Tue, 9 Apr 2002 13:33:03 +0200 (MET DST)
Date: Tue, 9 Apr 2002 13:33:03 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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>

> 
> So, in requirements language I guess I'd be arguing for something 
> like:
> 
> - A protocol SHOULD NOT require DPV clients to support relay or
>   re-direct (aka chaining or referral)
> - A protocol MAY require DPV servers to include support for 
>   relay and/or re-direct (aka chaining and/or referral)
> 
> Is that reasonable?

I agree with the second statement. 

Splitting the first into 

1a - A protocol SHOULD NOT require DPV clients to support relay
   (aka chaining)
1b - A protocol SHOULD NOT require DPV clients to support re-direct 
   (aka referral)

I agree with 1b. But with 1a I would like some explanation
What means 'a client support relay'. If you mean for example 
one of the following, I'd agree that this should not be required
for a client. 

- a client MUST indicate to a server the next hop
  in a chain. 

- a client MUST be able to authenticate the response from
  a second level server.
 
Are there other possibilities where a client has to
understand the fact that relaying or referral may occur or
had occured in order to prepare a request or to 
authenticate the response? 

Peter






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39BKWo08246 for ietf-pkix-bks; Tue, 9 Apr 2002 04:20:32 -0700 (PDT)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39BKUm08241 for <[e-mail]>; Tue, 9 Apr 2002 04:20:30 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g39BKTb26044 for <[e-mail]>; Tue, 9 Apr 2002 12:20:29 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Tue, 9 Apr 2002 12:15:07 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id MAA17484; Tue, 9 Apr 2002 12:20:26 +0100
Message-ID: <[e-mail]>
Date: Tue, 09 Apr 2002 12:20:32 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05100303b8d77d9f2730@[128.33.238.74]> <[e-mail]>
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>

Denis,

> However, for the question of supporting referrals, if we go back to the
> trust model problem, an intermediate server has to make its own decision
> to trust or not to trust a referral: trust is NOT a transitive property.

True in general, but in this case? Take the example I gave, where Charlie
re-directs/refers to Denis. In that case Charlie is already completely
trusted by Bob to answer the question since Charlie can give whatever
answer he likes. The only controls on Charlie are accountability schemes
(like logging signed responses), which apply equally to a response
containing a re-direct/referral.

In other words, I don't see how transitivity applies here. (Or more
crudely: Charlie can already shaft Bob, what does it matter if he
chooses to do it in a complicated, rather than a simple, manner?)

One way to convince me you're right woiuld be to show a difference
between two scenarios, both with a bad-guy DPV server, but where
one scenario supports re-direct/referral and the other doesn't. Right
now, I can't see any difference. (I could see a differnce if the bad-guy
DPV server were allowed to annouce to other servers which names/certs/keys
he's authorative for, and where they were forced to belive the bad-guy,
but I don't think anyone's proposed that.)

> Yesterday I suggested to use a simple model where the client redirects
> the request to another trusted server. If a referral is given back, then
> the client has still to make its own decision of whether or not it shall
> trust that other server. It must do that using some local information.
> There are two bacic ways to make that decision:
> 
> 1) it is one of the names from a list of servers, certified by a CA under
>    some root CAs,

Hmm... are we trying to get a DPV server to distinguish a re-direct/referral 
*instruction* response from re-direct/referral *advice* response? Sort of a
half-way house isn't it, but possibly useful I guess.

> 2) that server has some properties, e.g. its certificate is related to some
>    trusted root CA and is issued under some certificate policy.
> 
> In the first case, no referral is needed. In the second case, walking down a
> certificate tree looking for certificates with that property would do the
> job in a less easy way, but would do the job as well.

I do agree that some requirements language could be derived to the effect
that a protocol supporting re-direct/referral MUST address this issue. I
think we probably disagree as to whether it (i.e. transitivity) applies
in the case of re-directed/referred DPV. (Well, I'm still not sure, rather
than claiming transitivity doesn't apply.)

> Unless we would add some flag (to be used by intermediate servers acting as
> clients) asking for referrals to be sent back (whenever possible) in the
> form of a certificate, a name and/or a URI, referrals cannot be supported
> in a fashion invisible to end-user clients.

That sounds too close to protocol design, but something like that would 
probably be required when it did come to design-time.

Stephen.

> 
> Denis
> 
> > Of course, if we choose to make the fact of
> > relaying or referral visible to the client, this argument no loner
> > applies. (Which is not the same as having evidence of the relay or
> > referral contained in an opaque blob of bits returned by the server.)
> > The last does impinge on the simplicity of the client, and for that
> > reason alone I would argue against any explicit provision for it in
> > the client/server protocol, consistent with our broader goals for
> > this protocol.
> >
> > Steve

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39AOqI03742 for ietf-pkix-bks; Tue, 9 Apr 2002 03:24:52 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39AOom03734 for <[e-mail]>; Tue, 9 Apr 2002 03:24:50 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA14214; Tue, 9 Apr 2002 12:27:23 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040912241786:171 ; Tue, 9 Apr 2002 12:24:17 +0200 
Message-ID: <[e-mail]>
Date: Tue, 09 Apr 2002 12:24:16 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 09/04/2002 12:24:17, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 09/04/2002 12:24:48, Serialize complete at 09/04/2002 12:24:48
Content-Transfer-Encoding: 7bit
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>

Peter,

(text deleted)

> > 1) "I see no reason for the client to be made aware of an chaining or
> >     multicasting".
 
> I am not sure whether you can hide this completely. 

We can certainly hide this completely from the end-user client point of
view.

> If the final answer
> MAY contain answer from other service, a client might get some idea,
> but I don't think that this creates a problem.

The answer from a DPV server to an end-user client DOES NOT contain a signed
answer from another server, but may contain some data from another server.
The fact that that data comes from another server is NOT visible to the
end-user client. 
 
> I agree that it is probably not necssary to make explicitely available
> some information of the kind: "I have used a multicasting scheme among
> servers X to Z or chaining to Y'.
> 
> The client or another relying party want to know whether it is
> valid and (maybe) why the server believes so.
> 
> There may be: I have asked the following n servers and they all told me *no*.

All that complexity is not needed, there is a single signature visible and
the names of the intermediate servers, if any, are not visible. These names
are not necessary (a stop-loop mechanism can be implemented without them).

> > 2) "I do not think that we should include referrals in the DPV system
> >     at all".

> I am just a little bit careful asking about the meaning of this
> sentence.

See my response to Steve on that topic.

Denis
 
> Do You want a specification: A conformming protocol MUST not specify
> any method that implies whatever kind of referral, or do you 'just
> don't care', i.e. a protocol MAY implement an extension to be
> used among consenting client/servers? see below.
> 
> >
> > Now, taking the scenario depicted by Peter, with some important changes:
> >
> >  End user A asks server S1 "validate cert".
> >  client S1 asks server S2.
> >  server S2 responds : don't know.
> S2 answers : Don't know, please go to service S3, here is a trustworthy cert of S3.
> 
> >  client S1 asks to another DPV server that it trusts, e.g. server S3.
> >  server S3 responds to client S1 : the certificate is valid.
> >  server S1 responds to end user A: the certificate is valid.
> >
> > This is not referral, but it works fine with a list of servers trusted
> > by server S1.
> 
> Indeed, it works fine. But the *important change* removes the problem
> of the situation that may be interesting.
> 
> One of the questions here is whether the protocol MAY/SHOULD/MUST provide for a
> means to transfer some 'trust', i.e. to inform a client (maybe not to real
> end users if they can be distinguished) about the trustworthiness of another server
> (for a particular request).
> 
> I wouldn't mind about MAY if simplicity of a real end user client is
> guaranteed, i.e., in general, an end client SHOULD not be required to make
> more than one request to obtain a result.
> 
> In general: Do we have to put into this specification protocol
> features that 'MAY' exist?
 
> Peter

(text deleted)


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39A2MN02038 for ietf-pkix-bks; Tue, 9 Apr 2002 03:02:22 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39A2Im02024 for <[e-mail]>; Tue, 9 Apr 2002 03:02:18 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA23276; Tue, 9 Apr 2002 12:04:50 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040912015540:167 ; Tue, 9 Apr 2002 12:01:55 +0200 
Message-ID: <[e-mail]>
Date: Tue, 09 Apr 2002 12:01:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05100303b8d77d9f2730@[128.33.238.74]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 09/04/2002 12:01:55, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 09/04/2002 12:02:15, Serialize complete at 09/04/2002 12:02:15
Content-Transfer-Encoding: 7bit
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>

Steve,

(...)
 
> There are a few issues here:

>         - should DPV servers support relaying requests?
>         - should DPV servers support referral among servers?
>         - should DPV servers refer clients to other servers?

> The first two facilities, if done in a fashion invisible to the
> client, add no complexity to the client and might even be supported
> by a different protocol. 

Relaying may indeed be supported in a fashion that is invisible to end-user
clients. So I agree with the first statement. It is possible for relaying
servers to implement a stop-loop mechanism. In order to close this issue, 
I have already proposed the following addition:

" In case a DPV server chooses to relay the request to another server 
using the same protocol, a method to detect loops MUST be supported 
by that relaying server."

However, for the question of supporting referrals, if we go back to the
trust model problem, an intermediate server has to make its own decision 
to trust or not to trust a referral: trust is NOT a transitive property. 
Yesterday I suggested to use a simple model where the client redirects 
the request to another trusted server. If a referral is given back, then 
the client has still to make its own decision of whether or not it shall 
trust that other server. It must do that using some local information. 
There are two bacic ways to make that decision:

1) it is one of the names from a list of servers, certified by a CA under
   some root CAs,

2) that server has some properties, e.g. its certificate is related to some
   trusted root CA and is issued under some certificate policy. 

In the first case, no referral is needed. In the second case, walking down a
certificate tree looking for certificates with that property would do the
job in a less easy way, but would do the job as well. 

Unless we would add some flag (to be used by intermediate servers acting as
clients) asking for referrals to be sent back (whenever possible) in the
form of a certificate, a name and/or a URI, referrals cannot be supported 
in a fashion invisible to end-user clients.

Denis 

> Of course, if we choose to make the fact of
> relaying or referral visible to the client, this argument no loner
> applies. (Which is not the same as having evidence of the relay or
> referral contained in an opaque blob of bits returned by the server.)
> The last does impinge on the simplicity of the client, and for that
> reason alone I would argue against any explicit provision for it in
> the client/server protocol, consistent with our broader goals for
> this protocol.
> 
> Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g399p5P01313 for ietf-pkix-bks; Tue, 9 Apr 2002 02:51:05 -0700 (PDT)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g399p2m01303 for <[e-mail]>; Tue, 9 Apr 2002 02:51:03 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g399p2b23849 for <[e-mail]>; Tue, 9 Apr 2002 10:51:02 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Tue, 9 Apr 2002 10:45:39 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id KAA15882; Tue, 9 Apr 2002 10:50:59 +0100
Message-ID: <[e-mail]>
Date: Tue, 09 Apr 2002 10:51:05 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]> <[e-mail]> <p05100303b8d77d9f2730@[128.33.238.74]>
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>

Steve,

> There are a few issues here:
>         - should DPV servers support relaying requests?
>         - should DPV servers support referral among servers?
>         - should DPV servers refer clients to other servers?

A good list. (But I interpret the 2nd one above as being 
sufficient to support the use case I described - let me know
if I'm misinterpreting you.)

> The first two facilities, if done in a fashion invisible to the
> client, add no complexity to the client and might even be supported
> by a different protocol. Of course, if we choose to make the fact of
> relaying or referral visible to the client, this argument no loner
> applies. (Which is not the same as having evidence of the relay or
> referral contained in an opaque blob of bits returned by the server.)

I agree with the above too. For clarity, I'm interpreting the term
"client" in the above to cover the Alice in my example but not the 
Bob, even though Bob also has a DPV client built into his backend 
(which suggests rude things that could be said about DPV:-). So Bob's 
built-in DPV client is a "special" one that might support 
re-direct/referral, even though Alice's DPV client doesn't.

> The last does impinge on the simplicity of the client, and for that
> reason alone I would argue against any explicit provision for it in
> the client/server protocol, consistent with our broader goals for
> this protocol.

So, in requirements language I guess I'd be arguing for something 
like:

- A protocol SHOULD NOT require DPV clients to support relay or
  re-direct (aka chaining or referral)
- A protocol MAY require DPV servers to include support for 
  relay and/or re-direct (aka chaining and/or referral)

Is that reasonable?

Stephen.

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g39455f19170 for ietf-pkix-bks; Mon, 8 Apr 2002 21:05:05 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g39454m19165 for <[e-mail]>; Mon, 8 Apr 2002 21:05:04 -0700 (PDT)
Received: from [10.81.115.157] (SSH.BBN.COM [192.1.50.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id AAA22909; Tue, 9 Apr 2002 00:04:57 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05100300b8d76b579027@[128.33.238.74]>
In-Reply-To: <001901c1dd74$8d26a730$020aff0c@tsg1>
References:  <[e-mail]> <001901c1dd74$8d26a730$020aff0c@tsg1>
Date: Tue, 9 Apr 2002 00:05:04 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: NEW THREAD: Too Complex - WAS - Re: Open issue: DPV relay
Cc: <[e-mail]>
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>

Todd,

>Peter - All - I agree with you to some extent but let me also that there is
>another side and its about a bigger picture.  And in this bigger picture
>PKIX is way out of control. What it really needs is to have a thread of
>commonality drawn through all that PKIX produces. What I mean by that is
>that the entire process of  complex-decision-support and evidentiary
>processing of x.509 certs is out of control.

As noted in my immediate, previous message, not all the PKI standards 
we address are in support of NR. This it is not reasonable to insist 
that all of these standards have an "evidentiary" flavor to them.

>What we as a culture really need is something like CDSA only for PKIX. What
>I would conceptually propose as the PKIX streamlined PKI architecture. A
>common PKIX transaction architecture and process model. A simpler one, and
>one that does not allow recursion or ambiguity that is unchecked. What PKIX
>needs to do is to simplify everything it does.
>
>The intent would be to identify:
>
>     1)    Is there any value in making all this PKI ware at the Network
>Transport Level. I.e will the evidentiary needs of the world need and use
>what we are proposing. Will it fit into Human Law and Process currently
>accepted or, like the TSA, will it need artificial stimulus in the form of
>something like Italy's mandating some EU approved timestamp process without
>understanding exactly what the TSA provides relative to simple receipts
>(i.e. not much at this point but we should spin that off as a separate
>thread!).

Your terminology is seriously flawed. We make us of transport layer 
protocols such as UDP and TCP. Using the Internet protocol 
architecture terminology, we are developing application protocols. 
after that sentence, I begin to lose track of your point, other than 
apparently insulting Italians.

>     2)    How can the same services be used for both Evidentiary Service
>Models and for Decision Support (Hey Stephen - I going Cap Crazy!)...

yes, you are.

>
>     3)    And who we are going to work with.
>
>What has happened so far is that with its key architects, this WG has come
>up with so many pieces that it is freakin impossible to come to any gross
>agreements about anything. Take this argument - "Should DPV servers refer
>their requests to another node in a chain if local policy is failed or
>exceeded?" - it is totally constrained by how this system is being used and
>what types of legal frameworks are manding functionality under it.
>
>This is more than a problem with PKIX and people submitting technologies
>that while the use seems mechanically cool, do not satisfy the existing
>legal or process framework. And to that end PKIX and the IETF force the
>world to tau-tau to its goals rather that the IETF doing what its supposed
>to and that is to build protocols for the real world. Well the real world is
>commercial transaction processing and without it there would be no Internet.


"tau-tau?" I assume you mean "kowtow," meaning to bow as a sign of 
respect (from the ancient Mandarin).

Anyway, the folks who participate in the WG do believe that they are 
building protocols that are of value to the real world. As noted 
elsewhere, many of us have a model of the real world that is a bit 
more encompassing that what you seem to advocate, and thus our ideas 
of an appropriate level of protocol generality differ from yours.

BTW, what percentage of Internet traffic do you assert is 
"transaction processing" of the sort that requires the 
non-repudiation facilities that seem to be the focus of all your 
comments?  If we eliminate all the informal e-mail, essentially all 
file transfers, web surfing for a great variety of information that 
may not result in purchases, the credit card transactions that, due 
to extant laws, are acceptably well protected, ... Yes, the Internet 
is about to grind to a halt because PKIX has not addressed your 
notion of what is required.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3944xD19163 for ietf-pkix-bks; Mon, 8 Apr 2002 21:04:59 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3944wm19159 for <[e-mail]>; Mon, 8 Apr 2002 21:04:58 -0700 (PDT)
Received: from [10.81.115.157] (SSH.BBN.COM [192.1.50.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id AAA22905; Tue, 9 Apr 2002 00:04:53 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05100308b8d7411d48cf@[128.89.88.34]>
In-Reply-To: <001801c1dd74$8703c2c0$020aff0c@tsg1>
References:  <[e-mail]> <001801c1dd74$8703c2c0$020aff0c@tsg1>
Date: Tue, 9 Apr 2002 00:05:04 -0400
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Open issue: DPV relay
Cc: <[e-mail]>
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>

Todd,

>  >
>>  I do not believe we should formulate any
>>  particular use-model at this time, for DPV REQUIREMENTS;
>
>Then how can we make a determination on what its supposed to do in the real
>world and how the policy is supposed to work? This one especially, I think,
>needs a use model.
>
>o-    Jane calls DPV server with the embedded clients in her document or
>event authenticator applet.
>
>o-    The applet transfers the query to the DPV server and then awaits
>response. (and how is gross DPV discovery done anyhow?)
>
>o-    Server responds - "No data, sorry Jane. But I do want to ask "should I
>forward this request to the next link in the chain or what?"
>
>o-    Jane responds through her applet - "Yeah go ahead and forward it."
>(except that I see Safe Harbor violations in this so large that no one in
>their right mind uses it without constraints.)

Your effort above shows why it's not trivial to develop use models, 
i.e., one needs to identify the essential aspects of the model that 
should guide development of the standards. Your example does not seem 
to do that; it is not clear what the essential features are, based on 
the example, and how they should affect the requirements document.

For example, I would remove all references to applets, etc.  We don't 
care what sort of software invokes the protocol. With regard to your 
second bullet, we have already discussed the fact that since a client 
is relying on a DPV to verify certs, a means of identifying an 
acceptable DPV server must be configured into the client.  We already 
have analogous provisions for local path validation in 2459 and 
2459bis, where we discuss the role of trust anchors, and in OCSP, 
where one can configure the ID of the OCSP server to be employed. 
Here we don't have the luxury of relying on PKI-based facilities, 
since the client is assumed to be pretty dumb re PKI in the first 
place, so our options will be more limited.  The precise means by 
which acceptable DPV servers are identified (securely) may be outside 
the scope of the protocol, though the need to provide for such 
binding should be part of the protocol, and of the requirements 
document. Presumably the heart of your example resides in the last 
two bullets, where you bring up a possible user interaction re 
approval of invocation of a relay function. But, I don't think your 
example helps clarify the issue. We're assuming dumb client software, 
and we have assumed reference to validation policies via OIDs. This 
suggests that the users probably ought not be assumed to be in the 
loop for a decision such as this. in fact, one could easily imagine 
that authorization to make use of a relay could be a part of a 
validation policy to which we are already referring. (By the way, the 
"next link in the chain" is an odd reference since there is no 
presumed correspondence between cert path elements and DPV servers.) 
So, at the end of the example, I don't think I have any additional 
insights into what should or should not be part of the requirements 
doc.

>  > The requirements should prepare for
>>  protocol-specification, not establish operational
>>  usage constraints.
>
>Except that this context is supposed to carry data that is directly impacted
>by any number of already in place legal regimens. The concept that Safe
>Harmor is not relative to what PKIX does is more than stupid its negligent
>as no protocol that would violate what these laws were setup to do will fly.

DPV is not for use ONLY in contexts involving NR, which I assume is 
the unstated assumption behind your reference to "legal regimens." 
Yes, NR may represent part of the use model, but it is not the 
overriding focus.  Remember we're not restricted to digital signature 
uses of the keys extracted from certs, and even when signatures are 
involved, they may be used for authentication without invoking the 
complexity of NR.

	<SNIP>

>  > The only trust issue for DPV requirments I can see
>  > is this:
>>
>>  Just, as Sharon recently indicated, PMI's SOAs
>  > are trusted as authoritative for their policy
>>  scope, so DPV servers are trusted.
>
>OK then should the source of the trust have the ability to refer you to
>another trust node as the source of the trust its proferring to you. Remeber
>that the request and servicing of a trust process may in many legal senses
>be a contract and as such it has peculiar nuances that we as technogeeks are
>usually unconcerned with. But its time to wake up and get concerned.

I have a lot of trouble parsing this paragraph. Is not a replying 
party ultimately responsible to ensuring that the mechanisms it 
employs to verify a cert are adequate to protect its interests, 
should a legal challenge arise? If so, the responsibility here is on 
the folks configuring the policies in the DPV server, and on the 
clients invoking those policies, to make choices consistent with 
their requirements, whatever they may be.

>So lets look what actually happens to a contract model wherein the end-node
>trust service refers that trust process to a second or follow-on server...
>The contract is still between the first two players, eh? - not likely  - so
>then what is the difference in DPV being driven by the Client Side as
>opposed to authmatically being referred onward to the next node in a web of
>trust? Simple - If the client is responsible for all escalation of the/up
>the  DPV Proofing Chain (thats my term for the identified chain of trust
>verifiers for any given "D"), then the legal issues become more one for the
>client application to address and this is a much safer method of dealing
>with the process I think.

The client is invoking a DPV server to perform a service constrained 
by the validation policy referred to in the request. That abstraction 
is capable of addressing the concern you cite, if the folks managing 
the policies choose to do so. Not all clients may have the concerns 
you cite, so it makes sense to address this in the policy.


	<SNIP>

The bottom line is that DPV is about more than path validation in 
support of NR applications. Note that Denis previously proposed a 
signature validation capability that the WG decided was best 
separated from this path validation activity.

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g393sT818941 for ietf-pkix-bks; Mon, 8 Apr 2002 20:54:29 -0700 (PDT)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g393sCm18935 for <[e-mail]>; Mon, 8 Apr 2002 20:54:27 -0700 (PDT)
Received: from [10.81.115.157] (SSH.BBN.COM [192.1.50.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id XAA22278; Mon, 8 Apr 2002 23:53:58 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1 (Unverified)
Message-Id: <p05100303b8d77d9f2730@[128.33.238.74]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Mon, 8 Apr 2002 23:52:41 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: Re: Open issue: DPV relay
Cc: [e-mail]
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>

At 11:13 AM +0100 4/8/02, Stephen Farrell wrote:
>Hi Russ,
>
>I do tend to agree that re-direct/referral carries some complexity
>and therefore adding it might not be warranted at this stage. However,
>if we are adding relay (though I'm not sure what requirement on a
>protocol is being added - is it: "MAY have the ability to be used in
>relaying fashion"?) then thinking about re-direct/referral seems
>appropriate.
>
>I would think that the closest-to-real use case for this is actually
>a combination of relaying and referral as in:
>
>Alice -> Bob - is this a good key?
>     Robert -> Charlie - is this a good key? (relaying)
>     Chaz -> Robert - I dunno, ask Denis (re-direct/referral)
>     Robbie -> Denis - is this a good key?
>     Denis -> Rob - I strongly disagree (with apologies:-)
>Robert -> Alice - Nope
>
>That has some nice properties for hiding internal structure, using
>fewer trust points, avoiding firewall problems, not making the client
>more complicated than necessary etc that I think you don't get with
>relaying alone.
>
>I also agree that the following is an intresting question that
>would have to be answered by any protocol that claimed to support
>re-direct/referral: "if I trust you for DPV, does it follow that
>I trust you to tell me who else I trust for DPV?". On the one
>hand the client is no more exposed since the first DPV server can
>always cheat, on the other hand, this smacks of some meta-protocol,
>so I don't know the answer.
>
>Cheers,
>Stephen.

There are a few issues here:
	- should DPV servers support relaying requests?
	- should DPV servers support referral among servers?
	- should DPV servers refer clients to other servers?

The first two facilities, if done in a fashion invisible to the 
client, add no complexity to the client and might even be supported 
by a different protocol. Of course, if we choose to make the fact of 
relaying or referral visible to the client, this argument no loner 
applies. (Which is not the same as having evidence of the relay or 
referral contained in an opaque blob of bits returned by the server.) 
The last does impinge on the simplicity of the client, and for that 
reason alone I would argue against any explicit provision for it in 
the client/server protocol, consistent with our broader goals for 
this protocol.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g391qIA16892 for ietf-pkix-bks; Mon, 8 Apr 2002 18:52:18 -0700 (PDT)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g391qHm16888 for <[e-mail]>; Mon, 8 Apr 2002 18:52:17 -0700 (PDT)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Apr 2002 18:52:15 -0700
Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 08 Apr 2002 18:52:15 -0700
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Mon, 8 Apr 2002 18:52:09 -0700
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 8 Apr 2002 18:52:14 -0700
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Mon, 8 Apr 2002 18:48:33 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.6177.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Open issue: DPV relay
Date: Mon, 8 Apr 2002 18:48:33 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Open issue: DPV relay
Thread-Index: AcHfGYxAMMlmmwvLT4SL4mH/TkqACQATcriQ
From: "Trevor Freeman" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Peter Williams" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 09 Apr 2002 01:48:33.0764 (UTC) FILETIME=[A8618240:01C1DF68]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g391qHm16889
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>

Asking for a DPV relay is serious miss-interpreting the intent of DPV. 

In DPV you have a security association between the client and DPV
server. The client is outsourcing its certificate trust decisions to DPV
server. It is reasonable for the DPV server to employ any resource it
deems necessary to complete the request from the client that the DPV
server underwrites. The DPV server has to decide what resources it uses.
None of this is of any consequence to the client as long as the decision
is gives back to the client in accordance with the previously agreed
policy. All the client wants is a decision according to the policy. A
client could set up multiple SA to different DPV servers if it wanted
higher assurance that the answer from the DPV server was the "right"
answer - but that begs the question of why the client is not using DPD

Trevor

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]] 
Sent: Monday, April 08, 2002 9:22 AM
To: Peter Williams
Cc: [e-mail]
Subject: RE: Open issue: DPV relay


Peter:

I think you are changing the context of my statement.  I said: "... the 
client asks one DPV server to perform an action.  The response should
come 
back, signed by that DPV server, or it is an error from the client's 
perspective."

I did not say that the client could not have a trust relationship with
more 
than one DPV server.

Russ



At 05:28 PM 4/5/2002 -0800, Peter Williams wrote:

>Todd,
>
>I do not believe we should formulate any
>particular use-model at this time, for DPV REQUIREMENTS;
>leaving aside the philosophical issue of
>whether use-modeling would or would not help IETF standards
>adoption. The requirements should prepare for
>protocol-specification, not establish operational
>usage constraints.
>
>The only valuable use-issues topics I can forsee that might
>serve us (in contradiction to the above) are precisely
>those that Ambarish mentioned: do what OCSP did,
>so succesfully in the Internet environment... for the
>same issue; and dont lets sucumb to the temptation to
>over-architect!
>
>--------------
>
>In my view, on Russ side comment, constraining DPV to
>require users to interact
>with a service provider at a single access-point is
>like setting the clock back on X.509, and requiring
>the world to adopt the Entrust use-model
>of PKC key management. Entrust's use-model makes
>for a fine and highly-manageable system, but it
>competes (successfully) with other domain-management
>models that are equally succesful in the wider Internet
>environment we server.
>
>The only trust issue for DPV requirments I can see
>is this:
>
>Just, as Sharon recently indicated, PMI's SOAs
>are trusted as authoritative for their policy
>scope, so DPV servers are trusted. PMI deals
>with privileges; DPV deals with remote processing
>of chains against validation policies. The two
>authority models are really identical, otherwise.
>
>Lets note that PMI didnt constrain an AC verifier to use
>only a single SOA-headed source of AC paths. So
>should the DPV requirements not constrain the
>DPV client from accepting results from
>any  set of (possibly (out of IETF scope) constained) DPV
>servers - whose service is provided at the
>access point to which the client is bound (including
>that operated, perhaps, by a simple-proxing or a
>chaining&resigning DPV server).
>
>
>-----Original Message-----
>From: todd glassey [mailto:[e-mail]]
>Sent: Friday, April 05, 2002 3:52 PM
>To: Housley, Russ; jim
>Cc: [e-mail]; Tim Polk; [e-mail]
>Subject: Re: Open issue: DPV relay
>
>
>
>Russ is 100% dead on  but this is about the mechanics of the use model
more
>than anything - let me demonstrate...
>
>----- Original Message -----
>From: "Housley, Russ" <[e-mail]>
>To: "jim" <[e-mail]>
>Cc: <[e-mail]>; "Tim Polk" <[e-mail]>;
><[e-mail]>
>Sent: Friday, April 05, 2002 12:42 PM
>Subject: Re: Open issue: DPV relay
>
>
> >
> > Jim:
> >
> > I am not talking about trust in the X.500 system.  I am talking
about
>trust
> > in a DPV server.  In my mind, the client asks one DPV server to
perform an
> > action.  The response should come back, signed by that DPV server,
or it
>is
> > an error from the client's perspective.
> >
> > I see no reason for the client to be made aware of an chaining or
>multicasting.
> >
> > I do not think that we should include referrals in the DPV system at
all.
>
>The only way this would not want to be true is if the trust model
between
>the requesting agents and the supplying agents had a pre-existing
agreement
>that the trust supplying agent could look beyond its own services as
sources
>of the trust model its looking for from this DPV server. It would then
stand
>as a referred trust provider when it cannot satisfy the trust request
>itself.
>
>In fact from a use model perspective, it would seem that only the
client
>could authotize this  for privacy reasons, and it seems that it would
need
>to be on a per transaction basis (I.e. the Trust provider says " my
trust
>processes cannon fulfill this request so I have passed it onward to
someone
>that can" ... the only problem is that you run the potential that the
next
>link in the trust envelope would also not be able to satisfy this
request
>either or coupdl get locked in a loop... so where does it stop???)
>
>The "what" of what you have now is a situation where the referring
agent is
>going around and shopping for an external DPV agent who can and is
willing
>to satisfy this trust validation request.  And this seems at best kinda
>clunky and potentially a real problem  over privacy and context
information
>from the actual agent requesting this validation service.
>
>I suggest that becuase of this, that unless specifically authorized or
>requested from the client, that the DPV services should be restruicted
to
>stay on a single platform... and it be the Client's responsibility to
>hierarchicly check out the trust element in question.
>
> >
> > Russ
>
>SNIP


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3919hE16060 for ietf-pkix-bks; Mon, 8 Apr 2002 18:09:43 -0700 (PDT)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3919Zm16054 for <[e-mail]>; Mon, 8 Apr 2002 18:09:35 -0700 (PDT)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <2RPWH92Q>; Mon, 8 Apr 2002 21:09:23 -0400
Message-ID: <[e-mail]>
From: Christopher Oliva <[e-mail]>
To: "'Kurt D. Zeilenga'" <[e-mail]>
Cc: David Chadwick <[e-mail]>, Mark Wahl <[e-mail]>, [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Date: Mon, 8 Apr 2002 21:09:22 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DF63.2F153580"
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_01C1DF63.2F153580
Content-Type: text/plain;
	charset="iso-8859-1"

 
> >Here are some observations on the three cases: 
> >
> >a) and b) 
> >RFC 2252 clause 6.5 only mandates a binary encoding.
> >As previously pointed out by others, there is no absolute 
> imperative that requires the use of the ";binary" option.
> 
> How else would you indicate that the "binary" encoding was
> requested/used instead of the "string" encoding?

RFC 2252, 6.5 says that ".. values in this syntax MUST only be transferred
using the binary encoding ..". Also, no other encoding is provided therefore
only the binary encoding can be used. Although 4.3.1 lists two reasons to
use the binary encoding, it does not say that other valid reasons or
syntaxes cannot require the use of the binary encoding.

Since the use of ";binary" is not mandatory for the Certificate syntax, and
there is no other possible encoding, then the default encoding that is used
(that must be used) is the binary encoding. If the ";binary" option is used
to explicitly specify the binary encoding, this results in the same
encodings and this would also satisfy the RFC.

> >c) 
> >Nowhere in the ldapv3 RFCs is there a description of the 
> behavior for this case. There is no justification to label 
> this as non conformant.
> 
> You are right in that the RFC does not explicit state this.
> 
> But it should be obvious that "CN;binary" should not be
> returned unless "CN;binary" was requested.  Same goes
> for userCertificate.
> 

Attributes must be returned according to their syntax encoding requirements.
The Certificate syntax requires the encoding to be the binary encoding; in
this case, the use of ";binary" is a red herring.

Chris.

------_=_NextPart_001_01C1DF63.2F153580
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: LDAP Certificate transfer syntax</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Here are some observations on the three =
cases: </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;a) and b) </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;RFC 2252 clause 6.5 only mandates a binary =
encoding.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;As previously pointed out by others, there =
is no absolute </FONT>
<BR><FONT SIZE=3D2>&gt; imperative that requires the use of the =
&quot;;binary&quot; option.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; How else would you indicate that the =
&quot;binary&quot; encoding was</FONT>
<BR><FONT SIZE=3D2>&gt; requested/used instead of the =
&quot;string&quot; encoding?</FONT>
</P>

<P><FONT SIZE=3D2>RFC 2252, 6.5 says that &quot;.. values in this =
syntax MUST only be transferred using the binary encoding ..&quot;. =
Also, no other encoding is provided therefore only the binary encoding =
can be used. Although 4.3.1 lists two reasons to use the binary =
encoding, it does not say that other valid reasons or syntaxes cannot =
require the use of the binary encoding.</FONT></P>

<P><FONT SIZE=3D2>Since the use of &quot;;binary&quot; is not mandatory =
for the Certificate syntax, and there is no other possible encoding, =
then the default encoding that is used (that must be used) is the =
binary encoding. If the &quot;;binary&quot; option is used to =
explicitly specify the binary encoding, this results in the same =
encodings and this would also satisfy the RFC.</FONT></P>

<P><FONT SIZE=3D2>&gt; &gt;c) </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;Nowhere in the ldapv3 RFCs is there a =
description of the </FONT>
<BR><FONT SIZE=3D2>&gt; behavior for this case. There is no =
justification to label </FONT>
<BR><FONT SIZE=3D2>&gt; this as non conformant.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; You are right in that the RFC does not explicit =
state this.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; But it should be obvious that =
&quot;CN;binary&quot; should not be</FONT>
<BR><FONT SIZE=3D2>&gt; returned unless &quot;CN;binary&quot; was =
requested.&nbsp; Same goes</FONT>
<BR><FONT SIZE=3D2>&gt; for userCertificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

<P><FONT SIZE=3D2>Attributes must be returned according to their syntax =
encoding requirements. The Certificate syntax requires the encoding to =
be the binary encoding; in this case, the use of &quot;;binary&quot; is =
a red herring.</FONT></P>

<P><FONT SIZE=3D2>Chris.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1DF63.2F153580--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38ILL600623 for ietf-pkix-bks; Mon, 8 Apr 2002 11:21:21 -0700 (PDT)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38ILLm00619 for <[e-mail]>; Mon, 8 Apr 2002 11:21:21 -0700 (PDT)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 8 Apr 2002 11:18:51 -0700 (PDT)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 08 Apr 2002 11:18:51 -0700 (PDT)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <2L0B8DG0>; Mon, 08 Apr 2002 11:21:03 -0700
Content-return: allowed
Date: Mon, 08 Apr 2002 11:20:53 -0700
From: Ambarish Malpani <[e-mail]>
Subject: RE: Summary:open issues for draft-ietf-pkix-dpv-dpd-req-03.txt
To: "'Tim Polk'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative; boundary="Boundary_(ID_fqEx02Ti/Xa5gcPpcKftKQ)"
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.

--Boundary_(ID_fqEx02Ti/Xa5gcPpcKftKQ)
Content-type: text/plain

 
Hi Tim,
    Any idea when and how we can come to closure on these issues? As far as
I am
concerned, an executive decision on the open issued would be fine - can we
just
move ahead?
 
Regards,
Ambarish
 

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043


-----Original Message-----
From: Tim Polk [mailto:[e-mail]]
Sent: Thursday, April 04, 2002 3:01 PM
To: [e-mail]
Subject: Summary:open issues for draft-ietf-pkix-dpv-dpd-req-03.txt


Folks,

I think the discussion is converging here, and thought a summary was in
order.

There are a number of issues that were raised on the list and have
demonstrated consensus on the list.  (I will not enumerate them.)  Proposed
text has been submitted to the list and I sense general satisfaction with
that text.

However, there are two open issues that must be resolved before we forward
the document to the Area Directors.

Open Issue #1

The first issue involves "DPV relay".  Peter Sylvester has stated a
requirement for DPV servers to relay requests to one another:

>
>There is a requirement, similar as for OCSP caches, 
>that server just relays a request to another. This had been 
>discussed several times, the differences had only been to 
>what degree the relaying should become visible; whether one 
>server can rewrite/resigns the answers of another etc. 
>Relaying via cache is an obvious feature in many OCSP implementation, 
>how do they protect itself against loops between two servers? 
>

I understand this issue remains open.

Open Issue #2

The second issue is conformance requirements for multiple paths in the DPD
service.  As I read it, the current draft requires support for multiple
paths at the server, but not the client.  The client may request a maximum
number of paths N; if the request does not specify N, it defaults to one.
The DPD server includes zero, one, or up to N paths in a response.  If the
number of paths is less than N, this indicates that the server could not
find as many paths as the client requested.

Since the DPD process is performed with respect to a policy, just as in DPV,
it has been suggested that a DPD server could be designed to always return a
single path.  If the specified policy matches the path validation process
performed at the client (e.g., same certificate policies and same trust
anchor) the client should be able to use that path.

However, this could result in an ambiguity.  How does the DPD client that
requested three paths tell the difference between the following answers:
        "I gave you one path because it is the only one that exists"
     and
        "I gave you one path 'cause that's the way I was designed"

In the case where the single path failed, a client may need to know the
difference!

Careful selection of conformance requirements and error condition statements
will be required to permit building single answer DPD servers.

Moving Forward

Here is my plan for moving forward...

I will start two threads for the remaining open issues.  I consider all
other issues regarding the DPD/DPV requirements to be resolved.

Once the last two issues are resolved, I will ask the editors to post an -04
draft incorporating the currently agreed changes and the resolution to the
two open issues.  The -04 draft will be forwarded to the ADs.

Hope this works for everyone.

Thanks,

Tim Polk 


--Boundary_(ID_fqEx02Ti/Xa5gcPpcKftKQ)
Content-type: text/html
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">


<META content=3D"MSHTML 6.00.2713.1100" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D173132018-08042002><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
Tim,</FONT></SPAN></DIV>
<DIV><SPAN class=3D173132018-08042002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>&nbsp;&nbsp;&nbsp; Any idea when and how we can come to =
closure on these=20
issues? As far as I am</FONT></SPAN></DIV>
<DIV><SPAN class=3D173132018-08042002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>concerned, an executive decision on the open issued would be =
fine - can=20
we just</FONT></SPAN></DIV>
<DIV><SPAN class=3D173132018-08042002><FONT face=3DArial =
color=3D#0000ff size=3D2>move=20
ahead?</FONT></SPAN></DIV>
<DIV><SPAN class=3D173132018-08042002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D173132018-08042002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D173132018-08042002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Ambarish</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV>
<P><FONT=20
size=3D2>---------------------------------------------------------------=
------<BR>Ambarish=20
Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
650.567.5457<BR>ValiCert,=20
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[e-mail]<BR>339 N. Bernardo=20
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
<A href=3D"http://www.valicert.com/"=20
target=3D_blank>http://www.valicert.com</A><BR>Mountain View, CA=20
94043<BR></FONT></P>
<BLOCKQUOTE=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Tim Polk=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, April 04, 2002 =
3:01=20
  PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> Summary:open =
issues for=20
  =
draft-ietf-pkix-dpv-dpd-req-03.txt<BR><BR></FONT></DIV>Folks,<BR><BR>I =
think=20
  the discussion is converging here, and thought a summary was in=20
  order.<BR><BR>There are a number of issues that were raised on the =
list and=20
  have demonstrated consensus on the list.&nbsp; (I will not enumerate=20
  them.)&nbsp; Proposed text has been submitted to the list and I sense =
general=20
  satisfaction with that text.<BR><BR>However, there are two open =
issues that=20
  must be resolved before we forward the document to the Area=20
  Directors.<BR><BR><U>Open Issue #1<BR><BR></U>The first issue =
involves "DPV=20
  relay".&nbsp; Peter Sylvester has stated a requirement for DPV =
servers to=20
  relay requests to one another:<BR><BR>&gt;<BR>&gt;There is a =
requirement,=20
  similar as for OCSP caches, <BR>&gt;that server just relays a request =
to=20
  another. This had been <BR>&gt;discussed several times, the =
differences had=20
  only been to <BR>&gt;what degree the relaying should become visible; =
whether=20
  one <BR>&gt;server can rewrite/resigns the answers of another etc.=20
  <BR>&gt;Relaying via cache is an obvious feature in many OCSP =
implementation,=20
  <BR>&gt;how do they protect itself against loops between two servers? =

  <BR>&gt;<BR><BR>I understand this issue remains open.<BR><BR><U>Open =
Issue=20
  #2<BR><BR></U>The second issue is conformance requirements for =
multiple paths=20
  in the DPD service.&nbsp; As I read it, the current draft requires =
support for=20
  multiple paths at the server, but not the client.&nbsp; The client =
may request=20
  a maximum number of paths N; if the request does not specify N, it =
defaults to=20
  one.&nbsp; The DPD server includes zero, one, or up to N paths in a=20
  response.&nbsp; If the number of paths is less than N, this indicates =
that the=20
  server could not find as many paths as the client =
requested.<BR><BR>Since the=20
  DPD process is performed with respect to a policy, just as in DPV, it =
has been=20
  suggested that a DPD server could be designed to always return a =
single=20
  path.&nbsp; If the specified policy matches the path validation =
process=20
  performed at the client (e.g., same certificate policies and same =
trust=20
  anchor) the client should be able to use that path.<BR><BR>However, =
this could=20
  result in an ambiguity.&nbsp; How does the DPD client that requested =
three=20
  paths tell the difference between the following=20
  =
answers:<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-T=
AB>"I=20
  gave you one path because it is the only one that=20
  exists"<BR>&nbsp;&nbsp;&nbsp;&nbsp;=20
  =
and<BR><X-TAB>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</X-TAB>"I=
 gave=20
  you one path 'cause that's the way I was designed"<BR><BR>In the case =
where=20
  the single path failed, a client may need to know the=20
  difference!<BR><BR>Careful selection of conformance requirements and =
error=20
  condition statements will be required to permit building single =
answer DPD=20
  servers.<BR><BR><U>Moving Forward<BR><BR></U>Here is my plan for =
moving=20
  forward...<BR><BR>I will start two threads for the remaining open=20
  issues.&nbsp; I consider all other issues regarding the DPD/DPV =
requirements=20
  to be resolved.<BR><BR>Once the last two issues are resolved, I will =
ask the=20
  editors to post an -04 draft incorporating the currently agreed =
changes and=20
  the resolution to the two open issues.&nbsp; The -04 draft will be =
forwarded=20
  to the ADs.<BR><BR>Hope this works for =
everyone.<BR><BR>Thanks,<BR><BR>Tim=20
  Polk </BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_fqEx02Ti/Xa5gcPpcKftKQ)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38HHIV26685 for ietf-pkix-bks; Mon, 8 Apr 2002 10:17:18 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g38HHGm26681 for <[e-mail]>; Mon, 8 Apr 2002 10:17:16 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Apr 2002 17:16:17 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA10307 for <[e-mail]>; Mon, 8 Apr 2002 13:16:10 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g38HHKi26585 for <[e-mail]>; Mon, 8 Apr 2002 13:17:20 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1PY7B>; Mon, 8 Apr 2002 13:14:54 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.65]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1PY7A; Mon, 8 Apr 2002 13:14:53 -0400
From: "Housley, Russ" <[e-mail]>
To: Tom Gindin <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 08 Apr 2002 13:17:11 -0400
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
In-Reply-To: <[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>

Tom:

>The following is just a personal opinion, but one based on fairly
>well-understood trends.  I don't think that in-line logotypes are CURRENTLY
>worth the space that they'd take up on a smart card, but I would guess that
>they will be in two more smart-card generations and perhaps only one.
>Given the amount of time between standard proposal and deployment, it's not
>premature to standardize it.

I tend to agree with your assessment of storage on smart cards.  Today, all 
of the certificates stored on one smart card are likely to be associated 
with one community.  Therefore, a logo will like appear on the smart card 
itself.

Of course, there are other places that certificates and private keys are 
stored....

>       However, I also have a question about the current data structure.
>First, why is the URI optional (assuming that the only binary value is the
>digest, as at present)?  Second, why would we not permit in-line logotypes
>(in which case the URI is suppressed)?  This would require some edits to
>LogotypeData, but nothing very difficult.  One possibility would be:
>       LogotypeData ::= SEQUENCE {
>           typeOfLogotype       TypeOfLogotype,
>           hashAlgorithm        AlgorithmIdentifier,   -- might be OPTIONAL,
>it's not meaningful for GIF's
>           CHOICE  {
>             logotypeDataHash     OCTET STRING,
>       gif   [0]         IMPLICIT OCTET STRING
>       },
>           logotypeDataUri      IA5String OPTIONAL }
>
>       Another would be:
>       LogotypeData ::= SEQUENCE {
>           typeOfLogotype       TypeOfLogotype,
>           CHOICE  {
>             logotypeReference VerifiedReference,
>       gif               OCTET STRING
>       }
>           }
>       VerifiedReference ::= SEQUENCE {
>             hashAlgorithm     AlgorithmIdentifier,
>             dataHash    OCTET STRING,
>             CHOICE      {
>                   uri          IA5String,
>                   intlUri           UTF8String  }
>       }
>
>
>       IMO VerifiedReference is a generally useful type, so its names do not
>contain reference to logotypes.  My understanding of COMPONENTS OF, which
>may be faulty, is that defining LogotypeData using COMPONENTS OF
>VerifiedReference as an element of a CHOICE would not produce a useful
>result because each of the elements of VerifiedReference would show up in
>the CHOICE rather than merely hashAlgorithm going into the CHOICE with the
>other fields added to LogotypeData's SEQUENCE.

We are in the final steps of an updated I-D.  It addresses some of these 
issues, but not all.

Is there a reference for UTF8String URI?

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38GWou25804 for ietf-pkix-bks; Mon, 8 Apr 2002 09:32:50 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38GWmm25800 for <[e-mail]>; Mon, 8 Apr 2002 09:32:49 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA08598; Mon, 8 Apr 2002 18:35:22 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040818324508:109 ; Mon, 8 Apr 2002 18:32:45 +0200 
Message-ID: <[e-mail]>
Date: Mon, 08 Apr 2002 18:32:41 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: Roadmap
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 08/04/2002 18:32:45, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 08/04/2002 18:32:49, Serialize complete at 08/04/2002 18:32:49
Content-Transfer-Encoding: 7bit
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>

Tom,

I have not forgotten this message, but I gave priority to the DPV thread.

>       Responses below.  

> The issue of who specifies the verifier's policy is
> rather serious.  If the policy to be used is expected to be the same as RFC
> 3126's SignaturePolicy, we need to specify a step in which the verifier has
> the right to reject such a policy or to consider it inapplicable to the
> verifier's own current context.

This is true. However, the text does not go at that level of detail:

"Another model considers a set of rules that apply to an application
context. Every application context may have a different set of rules. 
When choosing to use certificates in the context of that application, 
the EE selects the set of rules for that context. In a set of rules, 
one or more Top CAs may be trusted, each one may be associated with 
different constraints, like the certificate policies that are trusted 
or the naming constraints that apply. These constrains may be specified 
either in self-signed certificates or in addition to self-signed 
certificates when they do not incorporate these constraints. This set 
of rules is called a validation policy (when validating a certificate) 
or a signature policy (when validating a digital signature)."

I do not think it is necesary to state it. If you think so, please provide 
a text and a placement for that text.

> 
>             Tom Gindin
> 
> To:    Tom Gindin/Watson/IBM@IBMUS
> cc:    [e-mail]
> Subject:    Re: WG Last Call: Roadmap
> 
> Tom,
> 
> >       I have a few issues with this, and some corrections as well.
> 
> >       In comment 12, I have two issues.  The first one, which is minor,
> is
> > that  "one or more Top CA's may be trusted" should refer to root CA's
> > instead - the two terms mean the same thing more often than not, but when
> > they differ the trust point is the root rather than the top.
> 
> PKIX-1 states:
> 
>    " - Top CA - A CA that is at the top of a PKI hierarchy.
> 
>    Note: This is often also called a "Root CA," since in data structures
>    terms and in graph theory, the node at the top of a tree is the
>    "root." However, to minimize confusion in this document, we elect to
>    call this node a "Top CA," and reserve "Root CA" for the CA directly
>    trusted by the EE."
> 
> The problem lies with the last sentence, i.e. "*the* CA directly trusted by
> the EE.". The singular is being used which means that there is a single
> one, multiple roots are not permitted, while multiple Top-CAs are
> permitted.
> 
> [TG] Where in PKIX-1 is this?  I can't find the phrase "directly trusted"
> in either RFC 2459 or in draft 12 of new-pkix-1.  

Sorry for the confusion: it is in the roadmap document, not PKIX-1.

The current text in the roadmap is:

    " - Root CA - A CA that is directly trusted by an EE; that is, 
       securely acquiring the value of a Root CA public key requires 
       some out-of-band step(s). This term is not meant to imply that a 
       Root CA is necessarily at the top of any hierarchy, simply that 
       the CA in question is trusted directly. 

(...)

   Note: This is often also called a "Root CA," since in data structures 
   terms and in graph theory, the node at the top of a tree is the 
   "root." However, to minimize confusion in this document, we elect to 
   call this node a "Top CA," and reserve "Root CA" for the CA directly 
   trusted by the EE. Readers new to PKIX should be aware that these 
   terms are not used consistently throughout the PKIX documents, as the 
   Internet PKI profile [2459bis] uses "Root CA" to refer to what this 
   and other documents call a "Top CA," and "most-trusted CA" to refer 
   to what this and other documents call a "Root CA." 

There is no problem with PKIX-1 but a problem with the roadmap document. 
PKIX-1 does not use the term "root CA", and thus it is wrong to say in 
the roadmap that "these terms are not used consistently throughout the 
PKIX documents". 

I would thus propose to change the note in the following way:

   Note: Since in data structures terms and in graph theory, the node 
   at the top of a tree is the "root", the term "root CA" is sometimes 
   used. This term is not meant to imply that a Root CA is necessarily 
   at the top of any hierarchy, simply that the CA in question is trusted 
   directly.

Then, on page 14, change:

   Additionally, once the Root CA ... 

with

   Additionally, once a Root CA ... 


on pages 29 and 30, change:

   (e.g., the DVCS's CA, or the Root CA in a 
   hierarchy)

with 

   (e.g., the DVCS's CA, or a Root CA)

Regards,
  
Denis


> Furthermore, if it does
> appear in such a draft I hope that it will be with reference to a
> particular validation path.  Since one normally performs validation against
> a specific context, only one trusted root is evaluated at a time.
 
> >       The second is less minor.  Is it truly intended that a signing EE
> > be permitted to specify the set of trusted CA's for an RP to use in
> > verifying a signature?  At a minimum, an RP in this model is responsible
> > for validating the the set of rules is identical to one it has already
> > decided to trust, but there is no reference in the model description to
> > any active role for the RP.
> 
> A verifier (not a signing EE as you mentioned) does not know what an anchor
> is, but may know what a policy is. So by selecting the policy that applies
> to the application, indirectly trust anchors (and much more) are selected.
> Remember that the same verifier may verify digital signatures in various
> contexts, e.g. for a Bank transaction or for a green reservation in a Golf
> Club. The trust conditions are not necessarilly identical. Note also that a
> verifier does not need to be a signer and may not have any certificate of
> its own.
> 
> [TG] My point is that the policy used to verify a signature is something
> which the VERIFIER must decide on, rather than the signer, and signature
> policies are things which you have defined as being specified by a signer
> (see your own RFC 3126).  A verifier is as likely to know what an anchor is
> as what a signature policy is.  If a signature policy includes a
> specification of the trust anchors as well as of the verification mechanism
> a user who does not know what a trust anchor is operating blindly in
> accepting or choosing a signature policy.
> 
> The case of a single (root) CA trusted for any kind of application is a
> very
> specific case and cannot be considered as the general case.
> 
> >       In your comment 5 (on page 15), replace "date of issue" by "date
> and
> > time of issue".
> 
> This is fine.
> 
> >       At a slightly more substantive level, shouldn't the clarification
> of
> > the definition of Top CA on page 4 end "and reserve 'root CA' for a CA
> > directly trusted by the EE."?  This wording permits multiple trusted
> roots.
> 
> I do not think that PKIX-1 allows for this. See the quote above.
> 
> >       In your comment 4, shouldn't "CA certificate" be "hierarchical CA
> > certificate"?  Surely a Top CA's self-signed certificate is also a "CA
> > certificate", and your definition excludes it.  Then the sentence "Some
> > people in the WG believe that a cross certificate is a special kind of CA
> > certificate." is reversed to "... believe that a hierarchical CA
> > certificate is a special kind of cross certificate".
> 
> You say that the definition excludes the fact that a Top CA's self-signed
> certificate is also a CA-certificate. This is correct, ... but was not
> intended.
> 
> So what about this full correction ?
> 
> [2459bis] defines a cross-certificate as "a certificate issued by one CA to
> another CA". [2459bis] does not provide a formal definition of a CA
> certificate but implictly means a certificate where the subject of the
> certificate is a CA. This means that self-signed certificates are CA
> certificats but are not cross-certificates. Some people in the WG believe
> that a cross certificate is a special kind of CA certificate issued by a CA
> under one Top CA for another CA under a different Top CA. CAs in the same
> hierarchy usually have part of their names imposed by the Top CA or by the
> CAs under that Top CAs. When a cross certificate is issued, there is no
> relationship between the names of the CAs.
> 
> >       In comment 11, the i.e. should remain "what are the root CA's"
> rather
> > than "what are the Top CA's", for the same reason as in comment 12.
> 
> I do not think so. See my first comment.
> 
> Regards,
> 
> Denis
> 
> >             Tom Gindin
> >
> > Denis Pinkas <[e-mail]>@mail.imc.org on 03/26/2002 12:11:50
> PM
> >
> > Sent by:    [e-mail]
> >
> > To:    [e-mail]
> > cc:    Carlisle Adams <[e-mail]>
> > Subject:    Re: WG Last Call: Roadmap
> >
> > Comments on the roadmap document draft-ietf-pkix-roadmap-07.txt
> >
> > (snip)
> > COMMENT 3. A sentence states: "However, to minimize confusion in this
> > document, we elect to call this node a "Top CA," and reserve "Root CA"
> for
> > the CA directly trusted by the EE". Since an EE may trust more than one
> Top
> > CA, shouldn't we say:
> >
> > "However, to minimize confusion in this document, we elect to call this
> > node
> > a "Top CA," and reserve "Root CA" when there is a single CA directly
> > trusted
> > by the EE."
> >
> > COMMENT 4. On page 14. A clarification needs to be done between
> > cross-certificates and CA certificates. The text currently states:
> >
> >    A cross-certificate is a PKC issued by one CA to another CA which
> >    contains a public CA key associated with the private CA signature key
> >    used for issuing PKCs. Typically, a cross-certificate is used to
> >    allow client systems or end entities in one administrative domain to
> >    communicate securely with client systems or end users in another
> >    administrative domain. Use of a cross-certificate issued from CA_1 to
> >    CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob,
> >    which was issued by CA_2. Cross-certificates can also be issued from
> >    one CA to another CA in the same administrative domain, if required.
> >
> > I would propose instead the following:
> >
> > " A CA certificate is a certificate in a hierarchy that is neither a
> > self-signed certificate, nor an end-entity certificate. [2459bis] does
> not
> > make a difference between a CA certificate and a cross certificate since
> it
> > defines a cross-certificate as "a certificate issued by one CA to another
> > CA". Some people in the WG believe that a cross certificate is a special
> > kind of CA certificate. A cross certificate is issued by a CA under one
> > Top CA for another CA under a different Top CA. CAs in the same hierarchy
> > have part of their names imposed by the Top CA or by the CAs under that
> > Top CAS. When a cross certificate is issued, there is no relationship
> > between the names of the CAS.
> >
> > Typically, a cross-certificate is used to allow client systems or end
> > entities in one administrative domain to communicate securely with client
> > systems or end users in another administrative domain. Use of a
> > cross-certificate issued from CA_1 to CA_2 allows user Alice, who trusts
> > CA_1, to accept a PKC used by Bob, which was issued by CA_2.
> > Cross-certificates can also be issued from one CA to another CA in the
> same
> > administrative domain, if required."
> >
> > COMMENT 5. On page 15, the text states: "A CRL is a time stamped list
> > identifying revoked PKCs that is signed by a CA and made freely available
> > in a public repository."
> >
> > I would prefer to avoid to use "time-stamped" in that context and thus I
> > would propose the following wording:
> >
> > "A CRL is a list that identifies the references of revoked PKCs. This
> list
> > contains a date of issue and is signed by a CA and made freely available
> in
> > a public repository."
> >
> > (snip)
> >
> > COMMENT 11. On page 47. Section 5.5 talks about trust model, but only
> > consider a single trust point:
> >
> > "  An important design decision is where a particular EE's trust point
> >    is located (i.e., where is the EE's Root CA). There are a number of
> >    models that have been developed and depending on the environment some
> >    models may be more suited than others. The following provides some
> >    background on the models."
> >
> > I would rather propose to change it into:
> >
> > " An important design decision is, for a given application, where the
> > particular EE's trust points are located (i.e. what are the Top CAs).
> > There are a number of models that have been developed and depending on
> > the environment some models may be more suited than others. The following
> > provides some background on the models."
> >
> > COMMENT 12. On page 49. Section 5.5 I would propose to add another model.
> >
> > 5.5.5 Validation policies
> >
> > Another model considers a set of rules that apply to an application
> > context.
> > Every application context may have a different set of rules. When
> choosing
> > to use certificates in the context of that application, the EE selects
> the
> > set of rules for that context. In a set of rules, one or more Top CAs may
> > be
> > trusted, each one may be associated with different constraints, like the
> > certificate policies that are trusted or the naming constraints that
> apply.
> > These constrains may be specified either in self-signed certificates or
> in
> > addition to self-signed certificates when they do not incorporate these
> > constraints. This set of rules is called a validation policy (when
> > validating a certificate) or a signature policy (when validating a
> digital
> > signature).
> >
> > Regards,
> >
> > Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38GMEP25537 for ietf-pkix-bks; Mon, 8 Apr 2002 09:22:14 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g38GM8m25533 for <[e-mail]>; Mon, 8 Apr 2002 09:22:08 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Apr 2002 16:21:09 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA05067 for <[e-mail]>; Mon, 8 Apr 2002 12:21:01 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g38GMBR20248 for <[e-mail]>; Mon, 8 Apr 2002 12:22:11 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1PX8A>; Mon, 8 Apr 2002 12:19:45 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.65]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1PX78; Mon, 8 Apr 2002 12:19:40 -0400
From: "Housley, Russ" <[e-mail]>
To: Peter Williams <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 08 Apr 2002 12:21:49 -0400
Subject: RE: Open issue: DPV relay
In-Reply-To: <[e-mail]. com>
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>

Peter:

I think you are changing the context of my statement.  I said: "... the 
client asks one DPV server to perform an action.  The response should come 
back, signed by that DPV server, or it is an error from the client's 
perspective."

I did not say that the client could not have a trust relationship with more 
than one DPV server.

Russ



At 05:28 PM 4/5/2002 -0800, Peter Williams wrote:

>Todd,
>
>I do not believe we should formulate any
>particular use-model at this time, for DPV REQUIREMENTS;
>leaving aside the philosophical issue of
>whether use-modeling would or would not help IETF standards
>adoption. The requirements should prepare for
>protocol-specification, not establish operational
>usage constraints.
>
>The only valuable use-issues topics I can forsee that might
>serve us (in contradiction to the above) are precisely
>those that Ambarish mentioned: do what OCSP did,
>so succesfully in the Internet environment... for the
>same issue; and dont lets sucumb to the temptation to
>over-architect!
>
>--------------
>
>In my view, on Russ side comment, constraining DPV to
>require users to interact
>with a service provider at a single access-point is
>like setting the clock back on X.509, and requiring
>the world to adopt the Entrust use-model
>of PKC key management. Entrust's use-model makes
>for a fine and highly-manageable system, but it
>competes (successfully) with other domain-management
>models that are equally succesful in the wider Internet
>environment we server.
>
>The only trust issue for DPV requirments I can see
>is this:
>
>Just, as Sharon recently indicated, PMI's SOAs
>are trusted as authoritative for their policy
>scope, so DPV servers are trusted. PMI deals
>with privileges; DPV deals with remote processing
>of chains against validation policies. The two
>authority models are really identical, otherwise.
>
>Lets note that PMI didnt constrain an AC verifier to use
>only a single SOA-headed source of AC paths. So
>should the DPV requirements not constrain the
>DPV client from accepting results from
>any  set of (possibly (out of IETF scope) constained) DPV
>servers - whose service is provided at the
>access point to which the client is bound (including
>that operated, perhaps, by a simple-proxing or a
>chaining&resigning DPV server).
>
>
>-----Original Message-----
>From: todd glassey [mailto:[e-mail]]
>Sent: Friday, April 05, 2002 3:52 PM
>To: Housley, Russ; jim
>Cc: [e-mail]; Tim Polk; [e-mail]
>Subject: Re: Open issue: DPV relay
>
>
>
>Russ is 100% dead on  but this is about the mechanics of the use model more
>than anything - let me demonstrate...
>
>----- Original Message -----
>From: "Housley, Russ" <[e-mail]>
>To: "jim" <[e-mail]>
>Cc: <[e-mail]>; "Tim Polk" <[e-mail]>;
><[e-mail]>
>Sent: Friday, April 05, 2002 12:42 PM
>Subject: Re: Open issue: DPV relay
>
>
> >
> > Jim:
> >
> > I am not talking about trust in the X.500 system.  I am talking about
>trust
> > in a DPV server.  In my mind, the client asks one DPV server to perform an
> > action.  The response should come back, signed by that DPV server, or it
>is
> > an error from the client's perspective.
> >
> > I see no reason for the client to be made aware of an chaining or
>multicasting.
> >
> > I do not think that we should include referrals in the DPV system at all.
>
>The only way this would not want to be true is if the trust model between
>the requesting agents and the supplying agents had a pre-existing agreement
>that the trust supplying agent could look beyond its own services as sources
>of the trust model its looking for from this DPV server. It would then stand
>as a referred trust provider when it cannot satisfy the trust request
>itself.
>
>In fact from a use model perspective, it would seem that only the client
>could authotize this  for privacy reasons, and it seems that it would need
>to be on a per transaction basis (I.e. the Trust provider says " my trust
>processes cannon fulfill this request so I have passed it onward to someone
>that can" ... the only problem is that you run the potential that the  next
>link in the trust envelope would also not be able to satisfy this request
>either or coupdl get locked in a loop... so where does it stop???)
>
>The "what" of what you have now is a situation where the referring agent is
>going around and shopping for an external DPV agent who can and is willing
>to satisfy this trust validation request.  And this seems at best kinda
>clunky and potentially a real problem  over privacy and context information
>from the actual agent requesting this validation service.
>
>I suggest that becuase of this, that unless specifically authorized or
>requested from the client, that the DPV services should be restruicted to
>stay on a single platform... and it be the Client's responsibility to
>hierarchicly check out the trust element in question.
>
> >
> > Russ
>
>SNIP


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38GASU25276 for ietf-pkix-bks; Mon, 8 Apr 2002 09:10:28 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38GAPm25271 for <[e-mail]>; Mon, 8 Apr 2002 09:10:26 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA25785; Mon, 8 Apr 2002 18:10:24 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 8 Apr 2002 18:10:24 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA28647; Mon, 8 Apr 2002 18:10:23 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA05966; Mon, 8 Apr 2002 18:10:23 +0200 (MET DST)
Date: Mon, 8 Apr 2002 18:10:23 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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,

fortunately I know how to interprete 'French comments', I hope that
you can interprete 'German comments', for the others, see PS. :-)


> 1) "I see no reason for the client to be made aware of an chaining or
>     multicasting".

I am not sure whether you can hide this completely. If the final answer
MAY contain answer from other service, a client might get some idea,
but I don't think that this creates a problem. 

I agree that it is probably not necssary to make explicitely available 
some information of the kind: "I have used a multicasting scheme among 
servers X to Z or chaining to Y'.  

The client or another relying party want to know whether it is
valid and (maybe) why the server believes so.

There may be: I have asked the following n servers and they all told me *no*.
 
> 2) "I do not think that we should include referrals in the DPV system 
>     at all".
I am just a little bit careful asking about the meaning of this
sentence. 

Do You want a specification: A conformming protocol MUST not specify
any method that implies whatever kind of referral, or do you 'just
don't care', i.e. a protocol MAY implement an extension to be
used among consenting client/servers? see below.  


> 
> Now, taking the scenario depicted by Peter, with some important changes:
> 
>  End user A asks server S1 "validate cert".
>  client S1 asks server S2. 
>  server S2 responds : don't know. 
S2 answers : Don't know, please go to service S3, here is a trustworthy cert of S3.

>  client S1 asks to another DPV server that it trusts, e.g. server S3.
>  server S3 responds to client S1 : the certificate is valid.
>  server S1 responds to end user A: the certificate is valid.
> 
> This is not referral, but it works fine with a list of servers trusted 
> by server S1.

Indeed, it works fine. But the *important change* removes the problem
of the situation that may be interesting. 

One of the questions here is whether the protocol MAY/SHOULD/MUST provide for a
means to transfer some 'trust', i.e. to inform a client (maybe not to real 
end users if they can be distinguished) about the trustworthiness of another server
(for a particular request). 

I wouldn't mind about MAY if simplicity of a real end user client is
guaranteed, i.e., in general, an end client SHOULD not be required to make
more than one request to obtain a result. 

In general: Do we have to put into this specification protocol
features that 'MAY' exist? 



Peter

PS:

French comment : 'no, absolutely unaceptable'  
                    ==> let's talk, more work is needed
                 'yes, that's already something'  
                    ==> go implement that, no need for discussion
                

German comment : 'No, absolutely unacceptable'
                    ==> no need for discussion, throw it away.
                 'Yes, that's already something'
                    ==> let's talk, more work is needed


If I remember it correctly, at least the ar of 1870 was created
by a voluntary provocation of such a misunderstanding. 

"We ask you to consider to dismantle the Strasbourg garnison".
"No way".
"ok, then we might consider take the whole North East of France"
"That is an absolutely unacceptable declaration of war."
'Here you have it". 


 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38F5Xe19392 for ietf-pkix-bks; Mon, 8 Apr 2002 08:05:33 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38F5Um19383 for <[e-mail]>; Mon, 8 Apr 2002 08:05:30 -0700 (PDT)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA06756 for <[e-mail]>; Mon, 8 Apr 2002 17:08:04 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040817051971:93 ; Mon, 8 Apr 2002 17:05:19 +0200 
Message-ID: <[e-mail]>
Date: Mon, 08 Apr 2002 17:05:16 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: Open issue: DPV relay
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 08/04/2002 17:05:19, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 08/04/2002 17:05:31, Serialize complete at 08/04/2002 17:05:31
Content-Transfer-Encoding: 7bit
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>

Russ,

I fully agree with you: 

1) "I see no reason for the client to be made aware of an chaining or
    multicasting".

2) "I do not think that we should include referrals in the DPV system 
    at all".

Now, taking the scenario depicted by Peter, with some important changes:

 End user A asks server S1 "validate cert".
 client S1 asks server S2. 
 server S2 responds : don't know. 
 client S1 asks to another DPV server that it trusts, e.g. server S3.
 server S3 responds to client S1 : the certificate is valid.
 server S1 responds to end user A: the certificate is valid.

This is not referral, but it works fine with a list of servers trusted 
by server S1.

Denis

> Jim:
> 
> I am not talking about trust in the X.500 system.  I am talking about trust
> in a DPV server.  In my mind, the client asks one DPV server to perform an
> action.  The response should come back, signed by that DPV server, or it is
> an error from the client's perspective.
> 
> I see no reason for the client to be made aware of an chaining or multicasting.
> 
> I do not think that we should include referrals in the DPV system at all.
> 
> Russ
> 
> At 02:50 PM 4/5/2002 -0500, jim wrote:
> >A small addition, but X.500 directories also have the ability for
> >multicasting in
> >which case a number of other directories are queried for a certificate at
> >the same
> >time.  Multicasting requires the greatest amount of directory and system
> >overhead,
> >but gets the quickest returns; where chaining requires the least and
> >referral is
> >the slowest, so there should be support for all three in the DPV
> >capability.  There
> >are no associated trust issues with use of either of the three methods as
> >far as I
> >know.
> >Jim
> >
> >"Housley, Russ" wrote:
> >
> > > Steve:
> > >
> > > In the X.500 directory, they two communication models are called chaining
> > > referrals.  Peter has asked for chaining support.  You are asking whether
> > > referrals should also be supported.
> > >
> > > I can see cases where chaining might be helpful.  It does not change the
> > > client's trust model.  It asks a particular DPV server for a response, and
> > > it gets one (signed by the same server that it asked).
> > >
> > > I think that referrals complicate the trust model.  The client asks one DPV
> > > server, then that server suggests that a different server might be better
> > > able to help.  If the client chooses to ask that server, it will get back a
> > > response signed by the second server.  Does the client trust it only
> > > because the first server made a referral?  What information need to be
> > > stored by the client to prove that it was referred to this server? All of
> > > this is more complication than I want.
> > >
> > > Russ
> > >
> > > At 02:21 PM 4/5/2002 +0100, Stephen Farrell wrote:
> > >
> > > >*If* relaying support/capability is to be considered as a
> > > >MUST/SHOULD/MAY requirement for a DPV protocol, then should
> > > >re-direction be handled similarly? (Note: I'm not proposing
> > > >that it should be, just asking!)
> > > >
> > > >By re-direction I mean:
> > > >
> > > >Alice: Hey Bob - is this key good?
> > > >Robert: Dunno Alice - but Charlie might know.
> > > >Alice: Hey Charles - is this key good?
> > > >Chaz: Yep.
> > > >
> > > >Stephen.
> > > >
> > > >Tim Polk wrote:
> > > > >
> > > > > Peter Sylvester has stated a requirement for DPV servers to relay
> > requests
> > > > > to one another:
> > > > >
> > > > >  >
> > > > >  >There is a requirement, similar as for OCSP caches,
> > > > >  >that server just relays a request to another. This had been
> > > > >  >discussed several times, the differences had only been to
> > > > >  >what degree the relaying should become visible; whether one
> > > > >  >server can rewrite/resigns the answers of another etc.
> > > > >  >Relaying via cache is an obvious feature in many OCSP implementation,
> > > > >  >how do they protect itself against loops between two servers?
> > > > >  >
> > > > >
> > > > > I believe this is an open issue, and would like to start a new
> > discussion
> > > > > thread limited to this topic.
> > > > >
> > > > > As I understand Peter's scenario, there are three mutually trusting DPV
> > > > > servers.  If a server cannot satisfy a request directly, it may
> > relay the
> > > > > request to a different server.  We'll assume the server is smart
> > enough not
> > > > > to relay a request back to the requester.  (That is, if server A
> > relays a
> > > > > request to Server B, B may relay it to Server C but not A.)
> > > > >
> > > > > (1) Assume Alice requests a valid path for Bob's certificate from
> > Server A,
> > > > > when none exists.
> > > > > (2) Server A relays the request to Server B, since it cannot satisfy it
> > > > > directly. (A could have chosen Server C; it is irrelevant.)
> > > > > (3) Server B relays the request to Server C, since it cannot satisfy it
> > > > > directly.  (C could not choose A, since it was the requester.)
> > > > > (4) Server C relays the request to Server A, since it cannot satisfy it
> > > > > directly.  (A could not choose B, since it was the requester.)
> > > > >
> > > > > At this point, either A must maintain state and recognize that the
> > request
> > > > > has cycled around or the protocol has to handle this by maintaining a
> > > > > history list.
> > > > >
> > > > > Peter, please confirm that I have characterized the problem
> > correctly (or
> > > > > post the right scenario)!  I am not personally convinced that blind
> > > > > relaying amongst DPV servers is a requirement.
> > > > >
> > > > > IMHO, DPV relaying would be limited to the scenario where each
> > Server was
> > > > > authoritative for a particular community (perhaps based on
> > privately held
> > > > > status information).  Alice directs all requests to Server A to
> > simplify
> > > > > her life.  Server A would be able to determine which server (B or
> > C) could
> > > > > possibly satisfy the request based on Bob's certificate.
> > > > >
> > > > > Even though relaying occurred, Server A acted as a simple DPV client,
> > > > > imposing no additional requirements...
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Tim Polk
> > > >
> > > >--
> > > >____________________________________________________________
> > > >Stephen Farrell
> > > >Baltimore Technologies,   tel: (direct line) [phone]
> > > >39 Parkgate Street,                     fax: [phone]
> > > >Dublin 8.                mailto:[e-mail]
> > > >Ireland                             http://www.baltimore.com


Received: by above.proper.com (8.11.6/8.11.3) id g38Eao315730 for ietf-pkix-bks; Mon, 8 Apr 2002 07:36:50 -0700 (PDT)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38Eamm15726 for <[e-mail]>; Mon, 8 Apr 2002 07:36:48 -0700 (PDT)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g38EZecw108050; Mon, 8 Apr 2002 10:35:40 -0400
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g38EZc543474; Mon, 8 Apr 2002 10:35:38 -0400
Importance: Normal
Sensitivity: 
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
To: Denis Pinkas <[e-mail]>
Cc: Stefan Santesson <[e-mail]>, "Housley, Russ" <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 8 Apr 2002 10:35:41 -0400
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/08/2002 10:35:39 AM
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>

The following is just a personal opinion, but one based on fairly
well-understood trends.  I don't think that in-line logotypes are CURRENTLY
worth the space that they'd take up on a smart card, but I would guess that
they will be in two more smart-card generations and perhaps only one.
Given the amount of time between standard proposal and deployment, it's not
premature to standardize it.
      However, I also have a question about the current data structure.
First, why is the URI optional (assuming that the only binary value is the
digest, as at present)?  Second, why would we not permit in-line logotypes
(in which case the URI is suppressed)?  This would require some edits to
LogotypeData, but nothing very difficult.  One possibility would be:
      LogotypeData ::= SEQUENCE {
          typeOfLogotype       TypeOfLogotype,
          hashAlgorithm        AlgorithmIdentifier,   -- might be OPTIONAL,
it's not meaningful for GIF's
          CHOICE  {
            logotypeDataHash     OCTET STRING,
      gif   [0]         IMPLICIT OCTET STRING
      },
          logotypeDataUri      IA5String OPTIONAL }

      Another would be:
      LogotypeData ::= SEQUENCE {
          typeOfLogotype       TypeOfLogotype,
          CHOICE  {
            logotypeReference VerifiedReference,
      gif               OCTET STRING
      }
          }
      VerifiedReference ::= SEQUENCE {
            hashAlgorithm     AlgorithmIdentifier,
            dataHash    OCTET STRING,
            CHOICE      {
                  uri          IA5String,
                  intlUri           UTF8String  }
      }


      IMO VerifiedReference is a generally useful type, so its names do not
contain reference to logotypes.  My understanding of COMPONENTS OF, which
may be faulty, is that defining LogotypeData using COMPONENTS OF
VerifiedReference as an element of a CHOICE would not produce a useful
result because each of the elements of VerifiedReference would show up in
the CHOICE rather than merely hashAlgorithm going into the CHOICE with the
other fields added to LogotypeData's SEQUENCE.

            Tom Gindin




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38E5r114837 for ietf-pkix-bks; Mon, 8 Apr 2002 07:05:53 -0700 (PDT)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38E5pm14831 for <[e-mail]>; Mon, 8 Apr 2002 07:05:51 -0700 (PDT)
Received: from tsg1 ([12.81.71.62]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020408140546.BYKO8815.mtiwmhc23.worldnet.att.net@tsg1>; Mon, 8 Apr 2002 14:05:46 +0000
Message-ID: <005c01c1df06$5574f290$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: Open issue: DPV relay
Date: Mon, 8 Apr 2002 07:02:12 -0700
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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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>

Isnt the question we are looking to address here  whether the DPV server can
prosecute the processing of a DPV request to a response or a next node in
that DPV server's or that Certificate's CHAIN OF TRUST.

So there are two issues really on the table here:

    1)    Does the Client have the ability to
            a)    Force the server to accept a particular chain of DPV
services to resolve its trusatability to the next DPV NODE as per the Client
            b)    Force the server to accept a particular chain of DPV
services to resolve its trusatability to the next DPV NODE as per the Server

    2)    Does the Server have the ability
            a)    To refer this request without the clients approval
            b)   Just Say No... That is "Sorry I cannot service this
request"...


T.
----- Original Message -----
From: "Peter Sylvester" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Monday, April 08, 2002 4:10 AM
Subject: Re: Open issue: DPV relay


>
> >
> > Jim:
> >
> > I am not talking about trust in the X.500 system.  I am talking about
trust
> > in a DPV server.  In my mind, the client asks one DPV server to perform
an
> > action.  The response should come back, signed by that DPV server, or it
is
> > an error from the client's perspective.
>
> I'd say this in a slightly slightly different way.
>
> A client MUST be able to authenticate the response at the moment when
> he receives it. The authentication method should be as simple as possible.
> Possible authentication methods include a signature (e.g. CMS
> signedData), TLS/SSL authentication or evel lower layers.
>
> Whenever there is a need that another entity needs to reverify
> a response "later" (which may not be necessary in all
> circumstances), an appropriate method to authenticate
> the response MUST be available, i.e., a combination
> of protocol data and services MUST be available to ensure
> this feature.
>
> > I see no reason for the client to be made aware of an chaining or
multicasting.
> I'd say that the response MUST include all essential
> element that have contributed to the decision, this MAY mean to
> include some responses or the identities of entities that
> have contributed to the response.
>
> > I do not think that we should include referrals in the DPV system at
all.
> I'm rather reluctant to have a referral type of mode, but Stephen Farrell
> gave an interesting example that may be slightly modified as
> follows:
>
>  End user A  ask  server S1 "validate cert".
>  S1 asks service S2.
>  S2 answers : Don't know, please go to service S3, here is a trustworthy
cert of S3.
>  S1 answers S3
>  S3 gives a signed response.
>  S1 validates the response agains the cert received by S3 and creates a
final reponse
>     to end user.
>
> I can imagine that there may be servers like S2 that would like to operate
> that way.
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38Cubj12279 for ietf-pkix-bks; Mon, 8 Apr 2002 05:56:37 -0700 (PDT)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g38CuRm12273 for <[e-mail]>; Mon, 8 Apr 2002 05:56:35 -0700 (PDT)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 8 Apr 2002 12:55:27 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA10561 for <[e-mail]>; Mon, 8 Apr 2002 08:55:20 -0400 (EDT)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g38CuTC20919 for <[e-mail]>; Mon, 8 Apr 2002 08:56:29 -0400 (EDT)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1PTS4>; Mon, 8 Apr 2002 08:54:03 -0400
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.104]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1PTSR; Mon, 8 Apr 2002 08:53:56 -0400
From: "Housley, Russ" <[e-mail]>
To: jim <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 08 Apr 2002 08:56:14 -0400
Subject: Re: Open issue: DPV relay
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[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>

Jim:

You missed my point altogether.

This discussion has nothing to do with directories.  We are discussion DPV 
servers.  The DPV server will do to a directory to obtain certificates and 
CRLs, go to OCSP responders, and (if needed) go to other DPV servers.

In DPV, we only want to support a chaining model in the DPV client to DPV 
server communication.

Russ

  At 05:27 PM 4/5/2002 -0500, jim wrote:
>Russ,
>     But the exact point is that if you decide that creating trust with 
> directories
>is the key instead of trust with the certificate holders and issuers, then 
>the only
>type of directory interaction that can occur is referral, which increases 
>system
>overhead, delays based on directory response times, and a general 
>inability to grow
>large systems in which any individual cross-certifying PKI has a single 
>directory
>to address.  Every individual PKI implementation would have to have not only a
>central directory, but also border directories and each border directory 
>would have
>to hold the same level of trust as the central directory.  This implies 
>constant
>near-real-time updating of border directories or the threat of failed 
>validation.
>Help me to understand how you envision the directory system that 
>successfully can
>respond to a multitude of simultaneous or near-simultaneous requests for
>validation.  Thanks.  Feel free to reply just to me if you wish as not 
>everyone may
>be interested from this point forward.
>Jim
>
>"Housley, Russ" wrote:
>
> > Jim:
> >
> > I am not talking about trust in the X.500 system.  I am talking about trust
> > in a DPV server.  In my mind, the client asks one DPV server to perform an
> > action.  The response should come back, signed by that DPV server, or it is
> > an error from the client's perspective.
> >
> > I see no reason for the client to be made aware of an chaining or 
> multicasting.
> >
> > I do not think that we should include referrals in the DPV system at all.
> >
> > Russ
> >
> > At 02:50 PM 4/5/2002 -0500, jim wrote:
> > >A small addition, but X.500 directories also have the ability for
> > >multicasting in
> > >which case a number of other directories are queried for a certificate at
> > >the same
> > >time.  Multicasting requires the greatest amount of directory and system
> > >overhead,
> > >but gets the quickest returns; where chaining requires the least and
> > >referral is
> > >the slowest, so there should be support for all three in the DPV
> > >capability.  There
> > >are no associated trust issues with use of either of the three methods as
> > >far as I
> > >know.
> > >Jim
> > >
> > >"Housley, Russ" wrote:
> > >
> > > > Steve:
> > > >
> > > > In the X.500 directory, they two communication models are called 
> chaining
> > > > referrals.  Peter has asked for chaining support.  You are asking 
> whether
> > > > referrals should also be supported.
> > > >
> > > > I can see cases where chaining might be helpful.  It does not 
> change the
> > > > client's trust model.  It asks a particular DPV server for a 
> response, and
> > > > it gets one (signed by the same server that it asked).
> > > >
> > > > I think that referrals complicate the trust model.  The client asks 
> one DPV
> > > > server, then that server suggests that a different server might be 
> better
> > > > able to help.  If the client chooses to ask that server, it will 
> get back a
> > > > response signed by the second server.  Does the client trust it only
> > > > because the first server made a referral?  What information need to be
> > > > stored by the client to prove that it was referred to this server? 
> All of
> > > > this is more complication than I want.
> > > >
> > > > Russ
> > > >
> > > > At 02:21 PM 4/5/2002 +0100, Stephen Farrell wrote:
> > > >
> > > > >*If* relaying support/capability is to be considered as a
> > > > >MUST/SHOULD/MAY requirement for a DPV protocol, then should
> > > > >re-direction be handled similarly? (Note: I'm not proposing
> > > > >that it should be, just asking!)
> > > > >
> > > > >By re-direction I mean:
> > > > >
> > > > >Alice: Hey Bob - is this key good?
> > > > >Robert: Dunno Alice - but Charlie might know.
> > > > >Alice: Hey Charles - is this key good?
> > > > >Chaz: Yep.
> > > > >
> > > > >Stephen.
> > > > >
> > > > >Tim Polk wrote:
> > > > > >
> > > > > > Peter Sylvester has stated a requirement for DPV servers to relay
> > > requests
> > > > > > to one another:
> > > > > >
> > > > > >  >
> > > > > >  >There is a requirement, similar as for OCSP caches,
> > > > > >  >that server just relays a request to another. This had been
> > > > > >  >discussed several times, the differences had only been to
> > > > > >  >what degree the relaying should become visible; whether one
> > > > > >  >server can rewrite/resigns the answers of another etc.
> > > > > >  >Relaying via cache is an obvious feature in many OCSP 
> implementation,
> > > > > >  >how do they protect itself against loops between two servers?
> > > > > >  >
> > > > > >
> > > > > > I believe this is an open issue, and would like to start a new
> > > discussion
> > > > > > thread limited to this topic.
> > > > > >
> > > > > > As I understand Peter's scenario, there are three mutually 
> trusting DPV
> > > > > > servers.  If a server cannot satisfy a request directly, it may
> > > relay the
> > > > > > request to a different server.  We'll assume the server is smart
> > > enough not
> > > > > > to relay a request back to the requester.  (That is, if server A
> > > relays a
> > > > > > request to Server B, B may relay it to Server C but not A.)
> > > > > >
> > > > > > (1) Assume Alice requests a valid path for Bob's certificate from
> > > Server A,
> > > > > > when none exists.
> > > > > > (2) Server A relays the request to Server B, since it cannot 
> satisfy it
> > > > > > directly. (A could have chosen Server C; it is irrelevant.)
> > > > > > (3) Server B relays the request to Server C, since it cannot 
> satisfy it
> > > > > > directly.  (C could not choose A, since it was the requester.)
> > > > > > (4) Server C relays the request to Server A, since it cannot 
> satisfy it
> > > > > > directly.  (A could not choose B, since it was the requester.)
> > > > > >
> > > > > > At this point, either A must maintain state and recognize that the
> > > request
> > > > > > has cycled around or the protocol has to handle this by 
> maintaining a
> > > > > > history list.
> > > > > >
> > > > > > Peter, please confirm that I have characterized the problem
> > > correctly (or
> > > > > > post the right scenario)!  I am not personally convinced that blind
> > > > > > relaying amongst DPV servers is a requirement.
> > > > > >
> > > > > > IMHO, DPV relaying would be limited to the scenario where each
> > > Server was
> > > > > > authoritative for a particular community (perhaps based on
> > > privately held
> > > > > > status information).  Alice directs all requests to Server A to
> > > simplify
> > > > > > her life.  Server A would be able to determine which server (B or
> > > C) could
> > > > > > possibly satisfy the request based on Bob's certificate.
> > > > > >
> > > > > > Even though relaying occurred, Server A acted as a simple DPV 
> client,
> > > > > > imposing no additional requirements...
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Tim Polk
> > > > >
> > > > >--
> > > > >____________________________________________________________
> > > > >Stephen Farrell
> > > > >Baltimore Technologies,   tel: (direct line) [phone]
> > > > >39 Parkgate Street,                     fax: [phone]
> > > > >Dublin 8.                mailto:[e-mail]
> > > > >Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38BsGG07331 for ietf-pkix-bks; Mon, 8 Apr 2002 04:54:16 -0700 (PDT)
Received: from mailrelay.tugraz.at (mailrelay.tu-graz.ac.at [129.27.3.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38Bs3m07324 for <[e-mail]>; Mon, 8 Apr 2002 04:54:03 -0700 (PDT)
Received: from iaik.at (iaik.tu-graz.ac.at [129.27.152.30]) by mailrelay.tugraz.at (8.12.2/8.12.2) with ESMTP id g38Br270013994; Mon, 8 Apr 2002 13:53:03 +0200 (MEST)
Received: from plato [129.27.152.123] by iaik.at (SMTPD32-7.05) id A1E22139011E; Mon, 08 Apr 2002 13:41:22 +0200
Received: from plato.iaik.at [127.0.0.1] by plato (IAIK S/MIME Mapper 2.01 18/May/2001); Mon, 08 Apr 2002 13:42:11 +0100
From: "Stefan Kraxberger" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Peter Sylvester" <[e-mail]>, <[e-mail]>, "Andrea Caccia" <[e-mail]>, "Stefan Kraxberger" <[e-mail]>, <[e-mail]>, <[e-mail]>, "Peter Gutmann" <[e-mail]>, "Raffaello Galli" <[e-mail]>, "Romano Pedroli" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: Updated TSA Service
Date: Mon, 8 Apr 2002 13:42:03 +0200
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.67B06B63--"; protocol="application/x-pkcs7-signature"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Importance: Normal
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
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 multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.67B06B63--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi

According to the test results from Thomas i have updated the our TSA
service.
Now the problems, documented in the test report, should be solved. The
service
is now running under an new address:

Host: neurath.iaik.at
Port: 318

Thomas, please can you try your test vectors against the this new version?

If anyone has problems with the new implementation please let me know.

/Stefan

----------------------------------------------------------------
Insitute for Applied Information Processing and Communication
Graz University of Technology
Inffeldgasse 16a, A-8010 Graz, Austria
mailto:[e-mail]
phone:[phone]
----------------------------------------------------------------



----IAIK.SMIME.MAPPER.67B06B63--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIIgqTCCBNYwggO+oAMCAQICFQC3HWS4/i03mbnh7A3pagLKv3pQqTANBgkqhkiG
9w0BAQUFADCBxDELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lU
WSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJ
bmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEhMB8GA1UE
CxMYSUFJSyBFdXJvUEtJIElOVFJBTkVUIENBMSEwHwYDVQQDExhJQUlLIEV1cm9Q
S0kgVFUtR1JBWiBTSUcwHhcNMDExMTI5MTMyNzE2WhcNMDIxMjMwMjIwMDAwWjCB
mjELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNI
Tk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlv
biBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEaMBgGA1UEAxMRU3RlZmFu
IEtyYXhiZXJnZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAIfTFg1Y/7xJ
Z3LWZc9hycGVAHTAWpyTIBUeEZKhx4x213MRRx9SFTzGbFuro5vGLIgLYy/GROKS
N5T4ADhjB5+OTFJ3VgMSLROOhQ4TBDWB+5PXNqLHJ5NxL/40Vz/mG9qk5qT+vPWe
4U6RfmD+zF9nR6BUxYJ3y2b0FcrJvEqtAgMBAAGjggFpMIIBZTAMBgNVHRMBAf8E
AjAAMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBR4tVWhM72DJX/q8+eMt6Of
lXOqezBUBgNVHSAETTBLMEkGDCsGAQQBlRIBAgIBAjA5MDcGCCsGAQUFBwIBFito
dHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2ludHJhbmV0L2Nwcy8xLjIvMEwGA1Ud
HwRFMEMwQaA/oD2GO2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaW50cmFuZXQv
Y3JsL2lhaWtfZXVyb3BraV9zaWcuY3JsMBEGCWCGSAGG+EIBAQQEAwIAIDAoBglg
hkgBhvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAkBgNVHREEHTAb
gRlzdGVmYW4ua3JheGJlcmdlckBpYWlrLmF0MB0GA1UdDgQWBBS3HWS4/i03mbnh
7A3pagHgRzEPEDANBgkqhkiG9w0BAQUFAAOCAQEAQxdjAsPNy6A3S6sj3DxWkfCS
6D2YRrUZwsM1fwe4Y08Du5jfIwWZ0+HJCAfysGWUm4wmApCxD9IhMzaufkfqgJMM
cXkdoXX75V839/FbrzXwMY+Ve6ba7WrNZvEUcl+/Xyg7UaAl/D7+QODLHgacuFVH
7FiFnQuiC5JHAMxMDKcrKSw7fJ75zTspRsRM2RXTu3HAoLe0MNxeNmFsvynTtb8Y
zSz5afUcvWFFDOe2Uf7B34sc+MszUz26p8xat8DGqdp11kI7IdZDMD83BRZlYJ47
sJMVQiglalwAZLZLkOp1dJOa7/Ob086p3elkDD6TVwTqeIEqEMX/ZJZtAsPZVzCC
BTwwggQkoAMCAQICFHi1VaEzvYMlf+rz54y3pIMcl/owMA0GCSqGSIb3DQEBBQUA
MIHLMQswCQYDVQQGEwJBVDENMAsGA1UEBxMER3JhejEZMBcGA1UECRMQSW5mZmVs
ZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xP
R1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFBy
b2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMSEwHwYDVQQDExhJQUlLIEV1cm9Q
S0kgSW50cmFuZXQgQ0EwHhcNMDAxMjE5MTEyMTQ3WhcNMDIxMjMwMjI1OTMwWjCB
xDELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNI
Tk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlv
biBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEhMB8GA1UECxMYSUFJSyBF
dXJvUEtJIElOVFJBTkVUIENBMSEwHwYDVQQDExhJQUlLIEV1cm9QS0kgVFUtR1JB
WiBTSUcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDxWjtQORZimthv
kSAAJlIL97tgPeJ8+151iGCyd44WFAyjHsP9oQrZHxazVAB+o8clYdPpp/ECognU
41o40iafdgkNIfsjyFMm3VvcWNx+F4vKYTHoLQascxRJUULgub+B4k4pb9A4URQn
xkrMriQlISoFXeEY1l2Mv4DlXHF3qOEMiLW5B1vmZZaEpNvH/me8fuvJYLi9FWA+
Ojk/UybbrGybkeJY3RAq+FImnWkaB9BAoAhdROR+GXU8YvqZTzqUndKog1KccBKa
FTBKwSz9RxOVPFORs1VLGItlnGRCn25uOiDTDfrU2D4D9cyFEVU+Qd55RzD6PfgP
8BbeUyTxAgMBAAGjggEbMIIBFzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB
/wQEAwIBxjAfBgNVHSMEGDAWgBSEWAP+T9cNWn701+2abEq0uxAz0jBUBgNVHSAE
TTBLMEkGDCsGAQQBlRIBAgIBATA5MDcGCCsGAQUFBwIBFitodHRwOi8vZXVyb3Br
aS5pYWlrLmF0L2NhL2ludHJhbmV0L2Nwcy8xLjEvMEgGA1UdHwRBMD8wPaA7oDmG
N2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaW50cmFuZXQvY3JsL2lhaWtfZXVy
b3BraS5jcmwwEQYJYIZIAYb4QgEBBAQDAgACMB0GA1UdDgQWBBR4tVWhM72DJX/q
8+eMt6OflXOqezANBgkqhkiG9w0BAQUFAAOCAQEAscTGRuY2BJizRRfug1JU1qha
LVOjZvYPOikXleQuPBPXFSoT9jwbzDkyN76QMnondlgf0F1Gr+w4LqljFKAdjqFG
SXJxAzGjMFbjTjyv7mit0Ppk7wKohXM/c8ThDCEBnnAYcTgg504BtJhBmN0ThyL6
tAXYfRFqHsgn1rj58bS+6lAa6n9iepn/yznhnFWr24imSVvef8nbI2GwphBAhNXh
+Jq+BWR1pr5uUJ9ilzL44elcZ+Omh4lsILiUf6YR1xR9+d3G4VQMMOmpfgf0GJVK
NKcelVlK4PW/0VgvDxoyQQFVE2hiLd5r/jUzT4zlLy+5hk3FnxSUgnl14w/u3DCC
BLMwggOboAMCAQICFQCEWAP+T9cNWn701+2abEuYPjyavTANBgkqhkiG9w0BAQUF
ADBSMQswCQYDVQQGEwJBVDEQMA4GA1UEChMHRXVyb1BLSTExMC8GA1UEAxMoRXVy
b1BLSSBBdXN0cmlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDEyMTgx
NjUyMzFaFw0wMjEyMzAyMjU5MzBaMIHLMQswCQYDVQQGEwJBVDENMAsGA1UEBxME
R3JhejEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV
TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB
cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z
MSEwHwYDVQQDExhJQUlLIEV1cm9QS0kgSW50cmFuZXQgQ0EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDPwrEj1RtzPWRZUGptWv2/KsgPQ0FyMHHYemhn
/+QjUv51aD9fmcqqUU/CgroJE6sLtN6cZoQ91gnxIS/Gw95PNhUX6jZfN4PF5K/G
Xz3ZUx/bcvcm4tjFGG12jxWT4IN9d3oT5SMMjh1Aw0BE35yySnlqBcfWHR7gtBps
dAovw1Txy8Bt8vmBrhe27dY0d3bJitULO1CG19G0Q374rnJ/CY9ZEHsz0498Ej5+
eFnefSEilJ7kQNDNU2zCx7xuu0jdu0yrb5Y1+RBdgJHCoMldUbOA2HkNOz9YLyiY
WPWRxT9fcPgXv9jSYu+t+DB0MMPz53ZcYILVsopsjhKduVO5AgMBAAGjggEEMIIB
ADAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAfBgNVHSMEGDAWgBQA
emdURVCCrBm2toURUbtpOdgt1DBWBgNVHSAETzBNMEsGDCsGAQQBlRIBAgEBATA7
MDkGCCsGAQUFBwIBFi1odHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2V1cm9wa2kt
YXQvY3BzLzEuMS8wRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2V1cm9wa2kuaWFp
ay5hdC9jYS9ldXJvcGtpLWF0L2NybC9hdXN0cmlhLmNybDAdBgNVHQ4EFgQUhFgD
/k/XDVp+9NftmmxKtLsQM9IwDQYJKoZIhvcNAQEFBQADggEBAC8BA5jJSByaJAeD
xiEW4O8mJJdSsuO/KyoEJVjcAyyMx9lJdHNtgwabhFHR2cUZz++vKkJFpmA+A7jg
jRO5IwQxiMTordze8X7rxmBlZvizFJfxUwalTAUbJ9iaLjJza42qTwjRRPSEji4b
9hcg+6PpK4pOdZ++SrIrE1qIvRqx3fFqEo8LHkkR8ZHKB/tT4GKQck/tUfeuotfQ
I/XlprqctmgzmjRC0giMEurV2Ogf6kxz9BzmibwGBtCqG0GLN5XKCr6fNBAD3W+X
t0FoujZfZlJqK3bt6re712rdZnztVlOaCc6gSB9WY7ZrNFhAm9+a2HzlTc7ZS+eP
jC8yLW4wggRQMIIDOKADAgECAgEJMA0GCSqGSIb3DQEBBAUAMEExEDAOBgNVBAoT
B0V1cm9QS0kxLTArBgNVBAMTJEV1cm9QS0kgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eTAeFw0wMDExMjMxNDI0NDVaFw0wMjEyMzExMjAwMDBaMFIxCzAJBgNV
BAYTAkFUMRAwDgYDVQQKEwdFdXJvUEtJMTEwLwYDVQQDEyhFdXJvUEtJIEF1c3Ry
aWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAoE5gWK44kT3O3Yenp0GT6+gkypmIAlhqYAcmokavl3WaQ4Bh
BlAv4ORtBF/hVObG1ugPCep7cTNyoXZ+sNIbmlLzBxzrRpT4nYQIEu3IXR108c6A
PycH+9vbYIUQrsCKx8Qs/csU5rdOxc15pHsZLJiiCYATB0GWyrcbVcoNgAj6crv7
Lx37SlENgMAssOoG4E3/2wrCQ2n/QiqBEosscpnEqQs6ABvdQiLKSpfVQJA77l9u
jQ1C/ugtlYwAr5GrtSOhOTYvKB4tuVleqlHFzJoA6XaWQRpD4Oy4ymF0+5IAe9q+
lOQ6U57rWIZ0MMr8xAmf7VZtmk0KJYCkAl3DPwIDAQABo4IBQDCCATwwTAYJYIZI
AYb4QgENBD8WPUlzc3VlZCB1bmRlciBwb2xpY3k6CiBodHRwOi8vd3d3LmV1cm9w
a2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wOwYDVR0fBDQwMjAwoC6gLIYqaHR0cDov
L3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2NybC9jcmwuZGVyMA8GA1UdEwEB/wQF
MAMBAf8wTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0
dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAOBgNVHQ8BAf8E
BAMCAf4wHQYDVR0OBBYEFAB6Z1RFUIKsGba2hRFRu2k52C3UMB8GA1UdIwQYMBaA
FIzci7GlSpDnTohzGDyd1V5+5LLNMA0GCSqGSIb3DQEBBAUAA4IBAQD0VfvB2KWA
/FyENfhXDK7/YQwRxdAJj/3VzpdvUPb9mHW9O1kry3ZeM9IfcYqbFPdP9ZvW/g2m
WQI9k4vMKDtePnzQuy+ZUuvxuKlJ7taWAAHkiXTBbJoscHetWVlIINuPYCQF33DT
d5otjcOxsE+U9xjqP5tCLMzQEmnmTaUdZYWZFIjfKzoLC2JEaeVjDUQrYYwL6OUY
P6aWoML1gqUP2PFzRKQK/EMSjRQzTU9ZZLVvc+FS797ki6f8zRxPGqheV4EyjFXR
bY03/4fjcZ5pwictxM97tFYmmlkmWmkEvI+7ToPZ/WtPyqXciKJ9ZT/OJWWWzfXg
iz5ECXNBlO0DMIIDYDCCAkigAwIBAgIBADANBgkqhkiG9w0BAQQFADBBMRAwDgYD
VQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRFdXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkwHhcNOTkxMjI5MTczMDM5WhcNMTAxMjMxMTIwMDAwWjBBMRAw
DgYDVQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRFdXJvUEtJIFJvb3QgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD/
L/zLh4UggkIiJA2Jmuwd6/TLOoToZz3Dr0FoCgehip+ZNrX1ehBw0esCK6Z18SfD
OeyDB+ia3qWaltedQVttLUQnVPdXmzubIVapWFoHm1u3oLhBgSp1mHBmAsKmGvHV
/IYF4t709tUQlpeZgjIzpbjzN799Xoa2X2yJqGGBADzHKiJn5p80LsMnx3VR/UyI
XZJEq611UlADfJH1qhwUzNa0F80j0tk7/paLhnWrZDsfZNGkAugQLBDUi+nBKUu4
FicpfYL7HGX4fRmtg+oLuQ1vHlYe2YVs+UGI47e7jd4Yf1vbjinQ0OUrx2nx8z+x
o47lgXwMbEJ7VwrECjS3AgMBAAGjYzBhMB8GA1UdIwQYMBaAFIzci7GlSpDnTohz
GDyd1V5+5LLNMB0GA1UdDgQWBBSM3IuxpUqQ506Icxg8ndVefuSyzTAOBgNVHQ8B
Af8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOCAQEAW2j/
nnW9QhtCe1iQdV9KFy9rnOpKH43tHFjuUBlgpgvNv01/rXMXLn/W81nuLTmZwdhY
cjldUZZR6WUGLtArOLQaUkTQMHjc/EkU/s0v8MuWNg5vhC3ZsFFNVtfR8iWa2a+g
A4uBH17cXd6PuzqD0HMFA75P32kes3xblFWZ5qSYGQvy4aWoT/FDsbeJG/Upp8Fb
Z2Z0pSqfi9cAWGqzRYlT0dgu8Z2RFwwd/vPvVpQldB1ScRkfpL6PCLvmmfMRHq8Z
g0JMcqmIXYYg0PcPdJ+ECikSYd/7G50/uIfJDDZEOIkmpXVn3cQmcMDRauhvwsoR
6B2lCX/cEI0PEnMBaDCCBNkwggPBoAMCAQICFD9EDnR1EdQ3xFRjSEwGBggogBmx
MA0GCSqGSIb3DQEBBQUAMIHGMQswCQYDVQQGEwJBVDEmMCQGA1UEChMdR1JBWiBV
TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB
cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z
MSEwHwYDVQQLExhJQUlLIEV1cm9QS0kgSU5UUkFORVQgQ0ExIzAhBgNVBAMTGklB
SUsgRXVyb1BLSSBUVS1HUkFaIENSWVBUMB4XDTAxMTEyOTEzMjUwMVoXDTAyMTIz
MDIyMDAwMFowgZoxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGjAYBgNV
BAMTEVN0ZWZhbiBLcmF4YmVyZ2VyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDEVxohomk0KckxKIduxV98fR68UbG7oAhiZas5KwNmw/eIWTWowzjNm7wEoIse
tBq6fVNKHBIhIn47XqTk+N76hjoADWnNn1QAVztCxXDNZVfc7+1vUioJu1QYcWPZ
NyAJskap8JOS9AKje5Hdnmnd5tWPxCigbo8QiEtLIcD8wQIDAQABo4IBazCCAWcw
DAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBDAwHwYDVR0jBBgwFoAUmikZ1hee
wVHfzGeDobfkvw+4Qx0wVAYDVR0gBE0wSzBJBgwrBgEEAZUSAQICAQIwOTA3Bggr
BgEFBQcCARYraHR0cDovL2V1cm9wa2kuaWFpay5hdC9jYS9pbnRyYW5ldC9jcHMv
MS4yLzBOBgNVHR8ERzBFMEOgQaA/hj1odHRwOi8vZXVyb3BraS5pYWlrLmF0L2Nh
L2ludHJhbmV0L2NybC9pYWlrX2V1cm9wa2lfY3J5cHQuY3JsMBEGCWCGSAGG+EIB
AQQEAwIAIDAoBglghkgBhvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5F
VDAkBgNVHREEHTAbgRlzdGVmYW4ua3JheGJlcmdlckBpYWlrLmF0MB0GA1UdDgQW
BBQ/RA50dRHUN8RUY0hMBgUdsDjWPjANBgkqhkiG9w0BAQUFAAOCAQEACK/LT4Q5
JodHhwc98Yuyv7wZfymxAOFyRJsO1sseOriRFPpp9WAjZORNRUTYRPMuhd9RS3BR
/jTn79AlsHevONt06xO4eatRoU01qZXQjoDZBOYsPIeId2Egs/7IWqC4iY5RBS8X
6Y3Tne/OGhzMTNiiRh0J573yPNqTUO0JK6yeYq0nNb2W4An6z+VPOW2mDEJcEj3H
/PjbR/sRbhi2DjkiN4JkjRDt4aRvT3yfnlqefoQqD4kakmdllaA98VasPjS9RLjh
rXKNixXlu+zzIbs0tRsN+ewLsVAUgSWl6SFOgSzPa5vTXurFbLaLRkrus6k+J19J
slSUkAIajSKpmTCCBT8wggQnoAMCAQICFQCaKRnWF57BUd/MZ4Oht+WilucS8TAN
BgkqhkiG9w0BAQUFADCByzELMAkGA1UEBhMCQVQxDTALBgNVBAcTBEdyYXoxGTAX
BgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lU
WSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJ
bmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEhMB8GA1UE
AxMYSUFJSyBFdXJvUEtJIEludHJhbmV0IENBMB4XDTAwMTIxOTExMzMxMVoXDTAy
MTIzMDIyNTkzMFowgcYxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZF
UlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxp
ZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxITAf
BgNVBAsTGElBSUsgRXVyb1BLSSBJTlRSQU5FVCBDQTEjMCEGA1UEAxMaSUFJSyBF
dXJvUEtJIFRVLUdSQVogQ1JZUFQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDWIkt24ac2iD1RZW0BzsolEcM7k6C5Pb8EHxVojWsjJsscBB32XS9H2h2/
XmjVOLtCPoNiEaqm8WrqFky29IdoktkLdV6bvW4gN32k17mvPUNCPmqO78idaqXC
m//ocXRMwUHpMCv1NN+5KUMJ18BDchltI/Zj1btYA7cZy4Ax01k6Z2zHUJkoAc7/
+x95o8Cm/1D9JxxZ5o6tHdiAYgyUjCA6Q3L0DmNQgLPOMWU5ZfcANDWfMTAH71c3
oRJaKIum3yCKzThyX24X7iSU/SI1mA2uJnOerEweuLNhmu5kJzH+079B2Jyscr92
1fzcz6KEEjEoEtnF8VSUvhFWxb2bAgMBAAGjggEbMIIBFzASBgNVHRMBAf8ECDAG
AQH/AgEAMA4GA1UdDwEB/wQEAwIBxjAfBgNVHSMEGDAWgBSEWAP+T9cNWn701+2a
bEq0uxAz0jBUBgNVHSAETTBLMEkGDCsGAQQBlRIBAgIBATA5MDcGCCsGAQUFBwIB
FitodHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2ludHJhbmV0L2Nwcy8xLjEvMEgG
A1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaW50cmFu
ZXQvY3JsL2lhaWtfZXVyb3BraS5jcmwwEQYJYIZIAYb4QgEBBAQDAgACMB0GA1Ud
DgQWBBSaKRnWF57BUd/MZ4Oht+S/D7hDHTANBgkqhkiG9w0BAQUFAAOCAQEAQJx9
PjiaQ085JR96Xq1xrjg5YYZJZzOm39jim/QXlHhc2i9OOHl17kKql9mHUUHbDM+C
eBz8oN7nkPXK0W3p9jrQbGij6v3MSPztnfkwbZl7askTeeyrmI3rC/jR6mWTL/AC
Cxn7btTc8U/9IJIFv1OQM+I9o1L68CzxsbddTSgGn6hjzZO6TnkMW+I8aWQe+uOj
tthe/1Erhl9YGSHv8EkqLOWfJroKc9mmKs2iYNcEbT8VFg7K5+/cCqqpp68vFLsY
Jtmlyq7vU60XNFMSaA5mgzc4wrB8ObMO98roBRJsMfKSAirSXugiKkRRyoPdC+rx
siaVKay2Xd7GDSu5pDGCAy0wggMpAgEBMIHeMIHEMQswCQYDVQQGEwJBVDEmMCQG
A1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPklu
c2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENv
bW11bmljYXRpb25zMSEwHwYDVQQLExhJQUlLIEV1cm9QS0kgSU5UUkFORVQgQ0Ex
ITAfBgNVBAMTGElBSUsgRXVyb1BLSSBUVS1HUkFaIFNJRwIVALcdZLj+LTeZueHs
DelqAsq/elCpMAkGBSsOAwIaBQCgggGkMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDQwODExNDIxMVowIwYJKoZIhvcNAQkEMRYE
FNzKztAnOnLTi/PXNudpDix2mLeiMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo
MAcGBSsOAwIHMIHwBgkrBgEEAYI3EAQxgeIwgd8wgcYxCzAJBgNVBAYTAkFUMSYw
JAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+
SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQg
Q29tbXVuaWNhdGlvbnMxITAfBgNVBAsTGElBSUsgRXVyb1BLSSBJTlRSQU5FVCBD
QTEjMCEGA1UEAxMaSUFJSyBFdXJvUEtJIFRVLUdSQVogQ1JZUFQCFD9EDnR1EdQ3
xFRjSEwGBggogBmxMA0GCSqGSIb3DQEBAQUABIGAVRyLzHSGixp9f+rVHtFm4nag
nASRzYUnoKmmCXRM/+qj7UHaPzpCU6t6YqJBVhbq6kIzMnT5h9H7n61bW8U0Iklh
qaIOR3HfNriJGto0bJkagkWI2gXCI+gDsY+OeSIftmzyYbDtVADjIN6jvDMUKcS4
QNx9+QhDAJNKgNbnNxgAAAAAAAA=
----IAIK.SMIME.MAPPER.67B06B63----



Received: by above.proper.com (8.11.6/8.11.3) id g38BAup04999 for ietf-pkix-bks; Mon, 8 Apr 2002 04:10:56 -0700 (PDT)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38BApm04990 for <[e-mail]>; Mon, 8 Apr 2002 04:10:51 -0700 (PDT)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA24554; Mon, 8 Apr 2002 13:10:30 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 8 Apr 2002 13:10:30 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id NAA27895; Mon, 8 Apr 2002 13:10:29 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id NAA05894; Mon, 8 Apr 2002 13:10:28 +0200 (MET DST)
Date: Mon, 8 Apr 2002 13:10:28 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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>

> 
> Jim:
> 
> I am not talking about trust in the X.500 system.  I am talking about trust 
> in a DPV server.  In my mind, the client asks one DPV server to perform an 
> action.  The response should come back, signed by that DPV server, or it is 
> an error from the client's perspective.

I'd say this in a slightly slightly different way.  

A client MUST be able to authenticate the response at the moment when
he receives it. The authentication method should be as simple as possible.
Possible authentication methods include a signature (e.g. CMS
signedData), TLS/SSL authentication or evel lower layers.

Whenever there is a need that another entity needs to reverify
a response "later" (which may not be necessary in all
circumstances), an appropriate method to authenticate
the response MUST be available, i.e., a combination
of protocol data and services MUST be available to ensure
this feature.  

> I see no reason for the client to be made aware of an chaining or multicasting.
I'd say that the response MUST include all essential
element that have contributed to the decision, this MAY mean to
include some responses or the identities of entities that
have contributed to the response. 
 
> I do not think that we should include referrals in the DPV system at all.
I'm rather reluctant to have a referral type of mode, but Stephen Farrell
gave an interesting example that may be slightly modified as
follows:

 End user A  ask  server S1 "validate cert".
 S1 asks service S2. 
 S2 answers : Don't know, please go to service S3, here is a trustworthy cert of S3.
 S1 answers S3 
 S3 gives a signed response. 
 S1 validates the response agains the cert received by S3 and creates a final reponse
    to end user. 

I can imagine that there may be servers like S2 that would like to operate
that way. 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g38ADME29852 for ietf-pkix-bks; Mon, 8 Apr 2002 03:13:22 -0700 (PDT)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g38ADGm29847 for <[e-mail]>; Mon, 8 Apr 2002 03:13:17 -0700 (PDT)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g38ADGb27611 for <[e-mail]>; Mon, 8 Apr 2002 11:13:16 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Mon, 8 Apr 2002 11:07:53 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA31699; Mon, 8 Apr 2002 11:13:07 +0100
Message-ID: <[e-mail]>
Date: Mon, 08 Apr 2002 11:13:12 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: Tim Polk <[e-mail]>, [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]>
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>

Hi Russ,

I do tend to agree that re-direct/referral carries some complexity 
and therefore adding it might not be warranted at this stage. However,
if we are adding relay (though I'm not sure what requirement on a 
protocol is being added - is it: "MAY have the ability to be used in 
relaying fashion"?) then thinking about re-direct/referral seems
appropriate.

I would think that the closest-to-real use case for this is actually
a combination of relaying and referral as in:

Alice -> Bob - is this a good key?
    Robert -> Charlie - is this a good key? (relaying)
    Chaz -> Robert - I dunno, ask Denis (re-direct/referral)
    Robbie -> Denis - is this a good key?
    Denis -> Rob - I strongly disagree (with apologies:-)
Robert -> Alice - Nope

That has some nice properties for hiding internal structure, using
fewer trust points, avoiding firewall problems, not making the client
more complicated than necessary etc that I think you don't get with 
relaying alone.

I also agree that the following is an intresting question that 
would have to be answered by any protocol that claimed to support
re-direct/referral: "if I trust you for DPV, does it follow that
I trust you to tell me who else I trust for DPV?". On the one
hand the client is no more exposed since the first DPV server can 
always cheat, on the other hand, this smacks of some meta-protocol, 
so I don't know the answer. 

Cheers,
Stephen.


"Housley, Russ" wrote:
> 
> Steve:
> 
> In the X.500 directory, they two communication models are called chaining
> referrals.  Peter has asked for chaining support.  You are asking whether
> referrals should also be supported.
> 
> I can see cases where chaining might be helpful.  It does not change the
> client's trust model.  It asks a particular DPV server for a response, and
> it gets one (signed by the same server that it asked).
> 
> I think that referrals complicate the trust model.  The client asks one DPV
> server, then that server suggests that a different server might be better
> able to help.  If the client chooses to ask that server, it will get back a
> response signed by the second server.  Does the client trust it only
> because the first server made a referral?  What information need to be
> stored by the client to prove that it was referred to this server? All of
> this is more complication than I want.
> 
> Russ
> 
> At 02:21 PM 4/5/2002 +0100, Stephen Farrell wrote:
> 
> >*If* relaying support/capability is to be considered as a
> >MUST/SHOULD/MAY requirement for a DPV protocol, then should
> >re-direction be handled similarly? (Note: I'm not proposing
> >that it should be, just asking!)
> >
> >By re-direction I mean:
> >
> >Alice: Hey Bob - is this key good?
> >Robert: Dunno Alice - but Charlie might know.
> >Alice: Hey Charles - is this key good?
> >Chaz: Yep.
> >
> >Stephen.
> >
> >Tim Polk wrote:
> > >
> > > Peter Sylvester has stated a requirement for DPV servers to relay requests
> > > to one another:
> > >
> > >  >
> > >  >There is a requirement, similar as for OCSP caches,
> > >  >that server just relays a request to another. This had been
> > >  >discussed several times, the differences had only been to
> > >  >what degree the relaying should become visible; whether one
> > >  >server can rewrite/resigns the answers of another etc.
> > >  >Relaying via cache is an obvious feature in many OCSP implementation,
> > >  >how do they protect itself against loops between two servers?
> > >  >
> > >
> > > I believe this is an open issue, and would like to start a new discussion
> > > thread limited to this topic.
> > >
> > > As I understand Peter's scenario, there are three mutually trusting DPV
> > > servers.  If a server cannot satisfy a request directly, it may relay the
> > > request to a different server.  We'll assume the server is smart enough not
> > > to relay a request back to the requester.  (That is, if server A relays a
> > > request to Server B, B may relay it to Server C but not A.)
> > >
> > > (1) Assume Alice requests a valid path for Bob's certificate from Server A,
> > > when none exists.
> > > (2) Server A relays the request to Server B, since it cannot satisfy it
> > > directly. (A could have chosen Server C; it is irrelevant.)
> > > (3) Server B relays the request to Server C, since it cannot satisfy it
> > > directly.  (C could not choose A, since it was the requester.)
> > > (4) Server C relays the request to Server A, since it cannot satisfy it
> > > directly.  (A could not choose B, since it was the requester.)
> > >
> > > At this point, either A must maintain state and recognize that the request
> > > has cycled around or the protocol has to handle this by maintaining a
> > > history list.
> > >
> > > Peter, please confirm that I have characterized the problem correctly (or
> > > post the right scenario)!  I am not personally convinced that blind
> > > relaying amongst DPV servers is a requirement.
> > >
> > > IMHO, DPV relaying would be limited to the scenario where each Server was
> > > authoritative for a particular community (perhaps based on privately held
> > > status information).  Alice directs all requests to Server A to simplify
> > > her life.  Server A would be able to determine which server (B or C) could
> > > possibly satisfy the request based on Bob's certificate.
> > >
> > > Even though relaying occurred, Server A acted as a simple DPV client,
> > > imposing no additional requirements...
> > >
> > > Thanks,
> > >
> > > Tim Polk
> >
> >--
> >____________________________________________________________
> >Stephen Farrell
> >Baltimore Technologies,   tel: (direct line) [phone]
> >39 Parkgate Street,                     fax: [phone]
> >Dublin 8.                mailto:[e-mail]
> >Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g36E9Yx08987 for ietf-pkix-bks; Sat, 6 Apr 2002 06:09:34 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g36E9Wm08982 for <[e-mail]>; Sat, 6 Apr 2002 06:09:32 -0800 (PST)
Received: from tsg1 ([12.81.65.90]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020406140926.EVKP38.mtiwmhc22.worldnet.att.net@tsg1>; Sat, 6 Apr 2002 14:09:26 +0000
Message-ID: <001901c1dd74$8d26a730$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Williams" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: NEW THREAD: Too Complex - WAS - Re: Open issue: DPV relay
Date: Sat, 6 Apr 2002 06:06:40 -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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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 - All - I agree with you to some extent but let me also that there is
another side and its about a bigger picture.  And in this bigger picture
PKIX is way out of control. What it really needs is to have a thread of
commonality drawn through all that PKIX produces. What I mean by that is
that the entire process of  complex-decision-support and evidentiary
processing of x.509 certs is out of control.

What we as a culture really need is something like CDSA only for PKIX. What
I would conceptually propose as the PKIX streamlined PKI architecture. A
common PKIX transaction architecture and process model. A simpler one, and
one that does not allow recursion or ambiguity that is unchecked. What PKIX
needs to do is to simplify everything it does.

The intent would be to identify:

    1)    Is there any value in making all this PKI ware at the Network
Transport Level. I.e will the evidentiary needs of the world need and use
what we are proposing. Will it fit into Human Law and Process currently
accepted or, like the TSA, will it need artificial stimulus in the form of
something like Italy's mandating some EU approved timestamp process without
understanding exactly what the TSA provides relative to simple receipts
(i.e. not much at this point but we should spin that off as a separate
thread!).

    2)    How can the same services be used for both Evidentiary Service
Models and for Decision Support (Hey Stephen - I going Cap Crazy!)...

    3)    And who we are going to work with.

What has happened so far is that with its key architects, this WG has come
up with so many pieces that it is freakin impossible to come to any gross
agreements about anything. Take this argument - "Should DPV servers refer
their requests to another node in a chain if local policy is failed or
exceeded?" - it is totally constrained by how this system is being used and
what types of legal frameworks are manding functionality under it.

This is more than a problem with PKIX and people submitting technologies
that while the use seems mechanically cool, do not satisfy the existing
legal or process framework. And to that end PKIX and the IETF force the
world to tau-tau to its goals rather that the IETF doing what its supposed
to and that is to build protocols for the real world. Well the real world is
commercial transaction processing and without it there would be no Internet.

Todd
----- Original Message -----
From: "Peter Williams" <[e-mail]>
To: "'todd glassey'" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, April 05, 2002 5:28 PM
Subject: RE: Open issue: DPV relay


>
> Todd,
>
> I do not believe we should formulate any
> particular use-model at this time, for DPV REQUIREMENTS;
> leaving aside the philosophical issue of
> whether use-modeling would or would not help IETF standards
> adoption. The requirements should prepare for
> protocol-specification, not establish operational
> usage constraints.
>
> The only valuable use-issues topics I can forsee that might
> serve us (in contradiction to the above) are precisely
> those that Ambarish mentioned: do what OCSP did,
> so succesfully in the Internet environment... for the
> same issue; and dont lets sucumb to the temptation to
> over-architect!
>
> --------------
>
> In my view, on Russ side comment, constraining DPV to
> require users to interact
> with a service provider at a single access-point is
> like setting the clock back on X.509, and requiring
> the world to adopt the Entrust use-model
> of PKC key management. Entrust's use-model makes
> for a fine and highly-manageable system, but it
> competes (successfully) with other domain-management
> models that are equally succesful in the wider Internet
> environment we server.
>
> The only trust issue for DPV requirments I can see
> is this:
>
> Just, as Sharon recently indicated, PMI's SOAs
> are trusted as authoritative for their policy
> scope, so DPV servers are trusted. PMI deals
> with privileges; DPV deals with remote processing
> of chains against validation policies. The two
> authority models are really identical, otherwise.
>
> Lets note that PMI didnt constrain an AC verifier to use
> only a single SOA-headed source of AC paths. So
> should the DPV requirements not constrain the
> DPV client from accepting results from
> any  set of (possibly (out of IETF scope) constained) DPV
> servers - whose service is provided at the
> access point to which the client is bound (including
> that operated, perhaps, by a simple-proxing or a
> chaining&resigning DPV server).
>
>
> -----Original Message-----
> From: todd glassey [mailto:[e-mail]]
> Sent: Friday, April 05, 2002 3:52 PM
> To: Housley, Russ; jim
> Cc: [e-mail]; Tim Polk; [e-mail]
> Subject: Re: Open issue: DPV relay
>
>
>
> Russ is 100% dead on  but this is about the mechanics of the use model
more
> than anything - let me demonstrate...
>
> ----- Original Message -----
> From: "Housley, Russ" <[e-mail]>
> To: "jim" <[e-mail]>
> Cc: <[e-mail]>; "Tim Polk" <[e-mail]>;
> <[e-mail]>
> Sent: Friday, April 05, 2002 12:42 PM
> Subject: Re: Open issue: DPV relay
>
>
> >
> > Jim:
> >
> > I am not talking about trust in the X.500 system.  I am talking about
> trust
> > in a DPV server.  In my mind, the client asks one DPV server to perform
an
> > action.  The response should come back, signed by that DPV server, or it
> is
> > an error from the client's perspective.
> >
> > I see no reason for the client to be made aware of an chaining or
> multicasting.
> >
> > I do not think that we should include referrals in the DPV system at
all.
>
> The only way this would not want to be true is if the trust model between
> the requesting agents and the supplying agents had a pre-existing
agreement
> that the trust supplying agent could look beyond its own services as
sources
> of the trust model its looking for from this DPV server. It would then
stand
> as a referred trust provider when it cannot satisfy the trust request
> itself.
>
> In fact from a use model perspective, it would seem that only the client
> could authotize this  for privacy reasons, and it seems that it would need
> to be on a per transaction basis (I.e. the Trust provider says " my trust
> processes cannon fulfill this request so I have passed it onward to
someone
> that can" ... the only problem is that you run the potential that the
next
> link in the trust envelope would also not be able to satisfy this request
> either or coupdl get locked in a loop... so where does it stop???)
>
> The "what" of what you have now is a situation where the referring agent
is
> going around and shopping for an external DPV agent who can and is willing
> to satisfy this trust validation request.  And this seems at best kinda
> clunky and potentially a real problem  over privacy and context
information
> from the actual agent requesting this validation service.
>
> I suggest that becuase of this, that unless specifically authorized or
> requested from the client, that the DPV services should be restruicted to
> stay on a single platform... and it be the Client's responsibility to
> hierarchicly check out the trust element in question.
>
> >
> > Russ
>
> SNIP
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g36E9PM08980 for ietf-pkix-bks; Sat, 6 Apr 2002 06:09:25 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g36E9Nm08976 for <[e-mail]>; Sat, 6 Apr 2002 06:09:23 -0800 (PST)
Received: from tsg1 ([12.81.65.90]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020406140915.EVID38.mtiwmhc22.worldnet.att.net@tsg1>; Sat, 6 Apr 2002 14:09:15 +0000
Message-ID: <001801c1dd74$8703c2c0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Williams" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Open issue: DPV relay
Date: Sat, 6 Apr 2002 06:03:02 -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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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 -
----- Original Message -----
From: "Peter Williams" <[e-mail]>
To: "'todd glassey'" <[e-mail]>
Cc: <[e-mail]>
Sent: Friday, April 05, 2002 5:28 PM
Subject: RE: Open issue: DPV relay


> Todd,
>
> I do not believe we should formulate any
> particular use-model at this time, for DPV REQUIREMENTS;

Then how can we make a determination on what its supposed to do in the real
world and how the policy is supposed to work? This one especially, I think,
needs a use model.

o-    Jane calls DPV server with the embedded clients in her document or
event authenticator applet.

o-    The applet transfers the query to the DPV server and then awaits
response. (and how is gross DPV discovery done anyhow?)

o-    Server responds - "No data, sorry Jane. But I do want to ask "should I
forward this request to the next link in the chain or what?"

o-    Jane responds through her applet - "Yeah go ahead and forward it."
(except that I see Safe Harbor violations in this so large that no one in
their right mind uses it without constraints.)


> leaving aside the philosophical issue of
> whether use-modeling would or would not help IETF standards
> adoption.

Yes lets as Stephen will not be happy if I or you open that can of worms
again (anyone else or an Earthworm?)

> The requirements should prepare for
> protocol-specification, not establish operational
> usage constraints.

Except that this context is supposed to carry data that is directly impacted
by any number of already in place legal regimens. The concept that Safe
Harmor is not relative to what PKIX does is more than stupid its negligent
as no protocol that would violate what these laws were setup to do will fly.

>
> The only valuable use-issues topics I can forsee that might
> serve us (in contradiction to the above) are precisely
> those that Ambarish mentioned: do what OCSP did,

OCSP also suffers the same set of problems but to a lessor degree. By the
way  Myers -I never complimented you on OCSP but it is a stroke of genius.
Especially since it can be used as the policy control transport itself of a
transaction process. (Sorry for the rathole there.)

> so succesfully in the Internet environment... for the
> same issue; and dont lets sucumb to the temptation to
> over-architect!
>
> --------------
>
> In my view, on Russ side comment, constraining DPV to
> require users to interact
> with a service provider at a single access-point is
> like setting the clock back on X.509, and requiring
> the world to adopt the Entrust use-model
> of PKC key management.

Sure from a mechanical standpoint but the world is not a totally meshed set
of governments and we are still a planet of individual laws and
jurisdictions and so not paying attention to tools that could have impact
there is more than dumb. Its dumber.

> Entrust's use-model makes
> for a fine and highly-manageable system, but it
> competes (successfully) with other domain-management
> models that are equally succesful in the wider Internet
> environment we server.

That's the point.

>
> The only trust issue for DPV requirments I can see
> is this:
>
> Just, as Sharon recently indicated, PMI's SOAs
> are trusted as authoritative for their policy
> scope, so DPV servers are trusted.

OK then should the source of the trust have the ability to refer you to
another trust node as the source of the trust its proferring to you. Remeber
that the request and servicing of a trust process may in many legal senses
be a contract and as such it has peculiar nuances that we as technogeeks are
usually unconcerned with. But its time to wake up and get concerned.

So lets look what actually happens to a contract model wherein the end-node
trust service refers that trust process to a second or follow-on server...
The contract is still between the first two players, eh? - not likely  - so
then what is the difference in DPV being driven by the Client Side as
opposed to authmatically being referred onward to the next node in a web of
trust? Simple - If the client is responsible for all escalation of the/up
the  DPV Proofing Chain (thats my term for the identified chain of trust
verifiers for any given "D"), then the legal issues become more one for the
client application to address and this is a much safer method of dealing
with the process I think.


> PMI deals
> with privileges; DPV deals with remote processing
> of chains against validation policies. The two
> authority models are really identical, otherwise.
>
> Lets note that PMI didnt constrain an AC verifier to use
> only a single SOA-headed source of AC paths. So
> should the DPV requirements not constrain the
> DPV client from accepting results from
> any  set of (possibly (out of IETF scope) constained) DPV
> servers - whose service is provided at the
> access point to which the client is bound (including
> that operated, perhaps, by a simple-proxing or a
> chaining&resigning DPV server).
>
>
> -----Original Message-----
> From: todd glassey [mailto:[e-mail]]
> Sent: Friday, April 05, 2002 3:52 PM
> To: Housley, Russ; jim
> Cc: [e-mail]; Tim Polk; [e-mail]
> Subject: Re: Open issue: DPV relay
>
>
>
> Russ is 100% dead on  but this is about the mechanics of the use model
more
> than anything - let me demonstrate...
>
> ----- Original Message -----
> From: "Housley, Russ" <[e-mail]>
> To: "jim" <[e-mail]>
> Cc: <[e-mail]>; "Tim Polk" <[e-mail]>;
> <[e-mail]>
> Sent: Friday, April 05, 2002 12:42 PM
> Subject: Re: Open issue: DPV relay
>
>
> >
> > Jim:
> >
> > I am not talking about trust in the X.500 system.  I am talking about
> trust
> > in a DPV server.  In my mind, the client asks one DPV server to perform
an
> > action.  The response should come back, signed by that DPV server, or it
> is
> > an error from the client's perspective.
> >
> > I see no reason for the client to be made aware of an chaining or
> multicasting.
> >
> > I do not think that we should include referrals in the DPV system at
all.
>
> The only way this would not want to be true is if the trust model between
> the requesting agents and the supplying agents had a pre-existing
agreement
> that the trust supplying agent could look beyond its own services as
sources
> of the trust model its looking for from this DPV server. It would then
stand
> as a referred trust provider when it cannot satisfy the trust request
> itself.
>
> In fact from a use model perspective, it would seem that only the client
> could authotize this  for privacy reasons, and it seems that it would need
> to be on a per transaction basis (I.e. the Trust provider says " my trust
> processes cannon fulfill this request so I have passed it onward to
someone
> that can" ... the only problem is that you run the potential that the
next
> link in the trust envelope would also not be able to satisfy this request
> either or coupdl get locked in a loop... so where does it stop???)
>
> The "what" of what you have now is a situation where the referring agent
is
> going around and shopping for an external DPV agent who can and is willing
> to satisfy this trust validation request.  And this seems at best kinda
> clunky and potentially a real problem  over privacy and context
information
> from the actual agent requesting this validation service.
>
> I suggest that becuase of this, that unless specifically authorized or
> requested from the client, that the DPV services should be restruicted to
> stay on a single platform... and it be the Client's responsibility to
> hierarchicly check out the trust element in question.
>
> >
> > Russ
>
> SNIP
>
>



Received: by above.proper.com (8.11.6/8.11.3) id g3620ZK18725 for ietf-pkix-bks; Fri, 5 Apr 2002 18:00:35 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3620Xm18721 for <[e-mail]>; Fri, 5 Apr 2002 18:00:33 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g3620PC28174; Sat, 6 Apr 2002 02:00:25 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020405172059.01743dd8@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 05 Apr 2002 18:00:36 -0800
To: Christopher Oliva <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Cc: David Chadwick <[e-mail]>, Mark Wahl <[e-mail]>, [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
In-Reply-To: <[e-mail] .com>
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>

At 03:27 PM 2002-04-05, Christopher Oliva wrote:
>I don't believe there is agreement on your supposition that the 3 cases you have outlined are non conformant. 

Well, I rather not rehash the whole discussion, but I believe
each actually is.

>Here are some observations on the three cases: 
>
>a) and b) 
>RFC 2252 clause 6.5 only mandates a binary encoding.
>As previously pointed out by others, there is no absolute imperative that requires the use of the ";binary" option.

How else would you indicate that the "binary" encoding was
requested/used instead of the "string" encoding?


>The part referring to the userCertificiate;binary and caCertificate;binary are merely examples of how one could generate the binary encoding.
>If one were to include the use of the attribute descriptions as part of the absolute imperative, this would make it impossible to construct legal add and modify messages since this clause only allows the requesting and returning of attributes.

So, trimming the imperative down to its essence:
   Values in this syntax MUST only be transferred using the
   binary encoding.

RFC 2251 says:
   If the "binary" option is present in an AttributeDescription, it
   overrides any string-based encoding representation defined for that
   attribute in [5]. Instead the attribute is to be transferred as a
   binary value encoded using the Basic Encoding Rules [11]. 

That is, if ;binary is not present, the string-based ("native")
encoding is used.

>I'm sure you are referring to the "MUST NOT expect" clause of RFC 2251 
>clause 4.1.5.1.

No, I'm referring to the technical specification as a whole.
In particular the first paragraph of RFC 2251, 4.1.5.1 and
RFC 2252, 4.3.

>c) 
>Nowhere in the ldapv3 RFCs is there a description of the behavior for this case. There is no justification to label this as non conformant.

You are right in that the RFC does not explicit state this.

But it should be obvious that "CN;binary" should not be
returned unless "CN;binary" was requested.  Same goes
for userCertificate.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g361TFX18316 for ietf-pkix-bks; Fri, 5 Apr 2002 17:29:15 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g361TDm18310 for <[e-mail]>; Fri, 5 Apr 2002 17:29:13 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 5 Apr 2002 17:27:03 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 05 Apr 2002 17:27:03 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <H570P4QP>; Fri, 05 Apr 2002 17:28:39 -0800
Content-return: allowed
Date: Fri, 05 Apr 2002 17:28:38 -0800
From: Peter Williams <[e-mail]>
Subject: RE: Open issue: DPV relay
To: "'todd glassey'" <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="iso-8859-1"
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>

Todd,

I do not believe we should formulate any
particular use-model at this time, for DPV REQUIREMENTS; 
leaving aside the philosophical issue of 
whether use-modeling would or would not help IETF standards 
adoption. The requirements should prepare for 
protocol-specification, not establish operational
usage constraints.

The only valuable use-issues topics I can forsee that might
serve us (in contradiction to the above) are precisely
those that Ambarish mentioned: do what OCSP did,
so succesfully in the Internet environment... for the 
same issue; and dont lets sucumb to the temptation to
over-architect!

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

In my view, on Russ side comment, constraining DPV to 
require users to interact
with a service provider at a single access-point is 
like setting the clock back on X.509, and requiring
the world to adopt the Entrust use-model
of PKC key management. Entrust's use-model makes
for a fine and highly-manageable system, but it 
competes (successfully) with other domain-management 
models that are equally succesful in the wider Internet
environment we server.

The only trust issue for DPV requirments I can see
is this:

Just, as Sharon recently indicated, PMI's SOAs
are trusted as authoritative for their policy
scope, so DPV servers are trusted. PMI deals
with privileges; DPV deals with remote processing
of chains against validation policies. The two
authority models are really identical, otherwise.

Lets note that PMI didnt constrain an AC verifier to use
only a single SOA-headed source of AC paths. So
should the DPV requirements not constrain the
DPV client from accepting results from
any  set of (possibly (out of IETF scope) constained) DPV 
servers - whose service is provided at the
access point to which the client is bound (including 
that operated, perhaps, by a simple-proxing or a 
chaining&resigning DPV server).


-----Original Message-----
From: todd glassey [mailto:[e-mail]]
Sent: Friday, April 05, 2002 3:52 PM
To: Housley, Russ; jim
Cc: [e-mail]; Tim Polk; [e-mail]
Subject: Re: Open issue: DPV relay



Russ is 100% dead on  but this is about the mechanics of the use model more
than anything - let me demonstrate...

----- Original Message -----
From: "Housley, Russ" <[e-mail]>
To: "jim" <[e-mail]>
Cc: <[e-mail]>; "Tim Polk" <[e-mail]>;
<[e-mail]>
Sent: Friday, April 05, 2002 12:42 PM
Subject: Re: Open issue: DPV relay


>
> Jim:
>
> I am not talking about trust in the X.500 system.  I am talking about
trust
> in a DPV server.  In my mind, the client asks one DPV server to perform an
> action.  The response should come back, signed by that DPV server, or it
is
> an error from the client's perspective.
>
> I see no reason for the client to be made aware of an chaining or
multicasting.
>
> I do not think that we should include referrals in the DPV system at all.

The only way this would not want to be true is if the trust model between
the requesting agents and the supplying agents had a pre-existing agreement
that the trust supplying agent could look beyond its own services as sources
of the trust model its looking for from this DPV server. It would then stand
as a referred trust provider when it cannot satisfy the trust request
itself.

In fact from a use model perspective, it would seem that only the client
could authotize this  for privacy reasons, and it seems that it would need
to be on a per transaction basis (I.e. the Trust provider says " my trust
processes cannon fulfill this request so I have passed it onward to someone
that can" ... the only problem is that you run the potential that the  next
link in the trust envelope would also not be able to satisfy this request
either or coupdl get locked in a loop... so where does it stop???)

The "what" of what you have now is a situation where the referring agent is
going around and shopping for an external DPV agent who can and is willing
to satisfy this trust validation request.  And this seems at best kinda
clunky and potentially a real problem  over privacy and context information
from the actual agent requesting this validation service.

I suggest that becuase of this, that unless specifically authorized or
requested from the client, that the DPV services should be restruicted to
stay on a single platform... and it be the Client's responsibility to
hierarchicly check out the trust element in question.

>
> Russ

SNIP



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35NuSh16850 for ietf-pkix-bks; Fri, 5 Apr 2002 15:56:28 -0800 (PST)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35NuQm16846 for <[e-mail]>; Fri, 5 Apr 2002 15:56:27 -0800 (PST)
Received: from tsg1 ([12.81.79.244]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020405235623.QQJS8815.mtiwmhc23.worldnet.att.net@tsg1>; Fri, 5 Apr 2002 23:56:23 +0000
Message-ID: <005e01c1dcfd$61ec7e90$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "jim" <[e-mail]>
Cc: <[e-mail]>, "Tim Polk" <[e-mail]>, <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Subject: Re: Open issue: DPV relay
Date: Fri, 5 Apr 2002 15:52:17 -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 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
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 is 100% dead on  but this is about the mechanics of the use model more
than anything - let me demonstrate...

----- Original Message -----
From: "Housley, Russ" <[e-mail]>
To: "jim" <[e-mail]>
Cc: <[e-mail]>; "Tim Polk" <[e-mail]>;
<[e-mail]>
Sent: Friday, April 05, 2002 12:42 PM
Subject: Re: Open issue: DPV relay


>
> Jim:
>
> I am not talking about trust in the X.500 system.  I am talking about
trust
> in a DPV server.  In my mind, the client asks one DPV server to perform an
> action.  The response should come back, signed by that DPV server, or it
is
> an error from the client's perspective.
>
> I see no reason for the client to be made aware of an chaining or
multicasting.
>
> I do not think that we should include referrals in the DPV system at all.

The only way this would not want to be true is if the trust model between
the requesting agents and the supplying agents had a pre-existing agreement
that the trust supplying agent could look beyond its own services as sources
of the trust model its looking for from this DPV server. It would then stand
as a referred trust provider when it cannot satisfy the trust request
itself.

In fact from a use model perspective, it would seem that only the client
could authotize this  for privacy reasons, and it seems that it would need
to be on a per transaction basis (I.e. the Trust provider says " my trust
processes cannon fulfill this request so I have passed it onward to someone
that can" ... the only problem is that you run the potential that the  next
link in the trust envelope would also not be able to satisfy this request
either or coupdl get locked in a loop... so where does it stop???)

The "what" of what you have now is a situation where the referring agent is
going around and shopping for an external DPV agent who can and is willing
to satisfy this trust validation request.  And this seems at best kinda
clunky and potentially a real problem  over privacy and context information
from the actual agent requesting this validation service.

I suggest that becuase of this, that unless specifically authorized or
requested from the client, that the DPV services should be restruicted to
stay on a single platform... and it be the Client's responsibility to
hierarchicly check out the trust element in question.

>
> Russ

SNIP




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35NSDp16340 for ietf-pkix-bks; Fri, 5 Apr 2002 15:28:13 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35NSCm16334 for <[e-mail]>; Fri, 5 Apr 2002 15:28:12 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <2LVTBGAJ>; Fri, 5 Apr 2002 18:28:00 -0500
Message-ID: <[e-mail]>
From: Christopher Oliva <[e-mail]>
To: "'Kurt D. Zeilenga'" <[e-mail]>, David Chadwick <[e-mail]>
Cc: Mark Wahl <[e-mail]>, [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Date: Fri, 5 Apr 2002 18:27:59 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCF9.85BDF230"
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_01C1DCF9.85BDF230
Content-Type: text/plain;
	charset="iso-8859-1"


I don't believe there is agreement on your supposition that the 3 cases you
have outlined are non conformant.

Here are some observations on the three cases:

a) and b)
RFC 2252 clause 6.5 only mandates a binary encoding. As previously pointed
out by others, there is no absolute imperative that requires the use of the
";binary" option. The part referring to the userCertificiate;binary and
caCertificate;binary are merely examples of how one could generate the
binary encoding. If one were to include the use of the attribute
descriptions as part of the absolute imperative, this would make it
impossible to construct legal add and modify messages since this clause only
allows the requesting and returning of attributes.

I'm sure you are referring to the "MUST NOT expect" clause of RFC 2251
clause 4.1.5.1. Nowhere does the RFC explain how to apply this clause to an
implementation of the protocol specification (the precise impact of "MUST
NOT expect" in an implementation is undefined). The query is legal and
nothing prohibits the server from replying. If the intent had been to
disallow this query, the specification would have said something like " ...
if the client performs a query for an attribute by name without the ;binary
option, the server MUST NOT return the value in the binary encoding."

c)
Nowhere in the ldapv3 RFCs is there a description of the behavior for this
case. There is no justification to label this as non conformant.

Chris.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[e-mail]]
Sent: Friday, April 05, 2002 3:35 PM
To: David Chadwick
Cc: Mark Wahl; [e-mail]; 'LDAP BIS'; 'PKIX'
Subject: Re: LDAP Certificate transfer syntax


I think adding a LDAP-specific "native" encoding to certificate
is a bad idea and will actually cause more problems than it
solves.

AFAIK, there are no interoperability problem between clients
and servers which adhere to the technical specification.  Things
are basically okay.

This I-D attempts to resolve interoperability problems between
non-conforming implementations and conforming implementations
by altering the specification to require conforming implementations
to accept and support the syntax and semantics of non-conforming
implementations.  However, there are a number of different
ways implementations have not conformed to the specification.

I have seen, in the wild, clients which:
	a) request "userCertificate" and expect the return of
	"userCertificate" using the (updated) LDAPv2 native
	string encoding.
	b) request "userCertificate" and expect the return of
	"userCertificate;binary" using binary transfer.
	c) request "*" and expect the return of
	"userCertificate;binary" using binary transfer.

This I-D caters to case a) in a manner which disallows servers
from supporting case b) and c).   I believe cases b) and c)
are actually for more common than case a).  I know of
implemenations which are liberal in accepting b) or c).  While
there may be implementations which are liberal in accepting
a), it should be noted that a) requires the server not to
be strict in what it sends.

I also note that b) and c) are generally the result of
the specification not be as clear as it should have been.
Where a) is the result of someone apply LDAPv2 syntax and
semantics to LDAPv3.

However, my objection to adding this I-D is that it that
client and server implementations of it won't interoperate
with existing server and client implementations which
conform to the existing specification.

I suggest we only make the minimal changes necessary to
resolve the issues which caused this schema to be removed
from the LDAP "core" technical specification.  It was
removed become of normative reference issues (e.g.,
2nd v 3rd v ... edition of X.500) and to align the
schema with that provided by X.509 (e.g., matching rules).

I note that it was NOT removed because of lack of multiple
independently developed implementations.  We need to
be careful to not to require changes to implementations
which have already demonstrated interoperability.

Kurt

------_=_NextPart_001_01C1DCF9.85BDF230
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: LDAP Certificate transfer syntax</TITLE>
</HEAD>
<BODY>
<BR>

<P><FONT SIZE=3D2>I don't believe there is agreement on your =
supposition that the 3 cases you have outlined are non =
conformant.</FONT>
</P>

<P><FONT SIZE=3D2>Here are some observations on the three cases:</FONT>
</P>

<P><FONT SIZE=3D2>a) and b)</FONT>
<BR><FONT SIZE=3D2>RFC 2252 clause 6.5 only mandates a binary encoding. =
As previously pointed out by others, there is no absolute imperative =
that requires the use of the &quot;;binary&quot; option. The part =
referring to the userCertificiate;binary and caCertificate;binary are =
merely examples of how one could generate the binary encoding. If one =
were to include the use of the attribute descriptions as part of the =
absolute imperative, this would make it impossible to construct legal =
add and modify messages since this clause only allows the requesting =
and returning of attributes.</FONT></P>

<P><FONT SIZE=3D2>I'm sure you are referring to the &quot;MUST NOT =
expect&quot; clause of RFC 2251 clause 4.1.5.1. Nowhere does the RFC =
explain how to apply this clause to an implementation of the protocol =
specification (the precise impact of &quot;MUST NOT expect&quot; in an =
implementation is undefined). The query is legal and nothing prohibits =
the server from replying. If the intent had been to disallow this =
query, the specification would have said something like &quot; ... if =
the client performs a query for an attribute by name without the =
;binary option, the server MUST NOT return the value in the binary =
encoding.&quot;</FONT></P>

<P><FONT SIZE=3D2>c)</FONT>
<BR><FONT SIZE=3D2>Nowhere in the ldapv3 RFCs is there a description of =
the behavior for this case. There is no justification to label this as =
non conformant.</FONT></P>

<P><FONT SIZE=3D2>Chris.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Kurt D. Zeilenga [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Friday, April 05, 2002 3:35 PM</FONT>
<BR><FONT SIZE=3D2>To: David Chadwick</FONT>
<BR><FONT SIZE=3D2>Cc: Mark Wahl; [e-mail]; 'LDAP =
BIS'; 'PKIX'</FONT>
<BR><FONT SIZE=3D2>Subject: Re: LDAP Certificate transfer syntax</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I think adding a LDAP-specific &quot;native&quot; =
encoding to certificate</FONT>
<BR><FONT SIZE=3D2>is a bad idea and will actually cause more problems =
than it</FONT>
<BR><FONT SIZE=3D2>solves.</FONT>
</P>

<P><FONT SIZE=3D2>AFAIK, there are no interoperability problem between =
clients</FONT>
<BR><FONT SIZE=3D2>and servers which adhere to the technical =
specification.&nbsp; Things</FONT>
<BR><FONT SIZE=3D2>are basically okay.</FONT>
</P>

<P><FONT SIZE=3D2>This I-D attempts to resolve interoperability =
problems between</FONT>
<BR><FONT SIZE=3D2>non-conforming implementations and conforming =
implementations</FONT>
<BR><FONT SIZE=3D2>by altering the specification to require conforming =
implementations</FONT>
<BR><FONT SIZE=3D2>to accept and support the syntax and semantics of =
non-conforming</FONT>
<BR><FONT SIZE=3D2>implementations.&nbsp; However, there are a number =
of different</FONT>
<BR><FONT SIZE=3D2>ways implementations have not conformed to the =
specification.</FONT>
</P>

<P><FONT SIZE=3D2>I have seen, in the wild, clients which:</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a) =
request &quot;userCertificate&quot; and expect the return of</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;userCertificate&quot; using the (updated) LDAPv2 =
native</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>string =
encoding.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>b) =
request &quot;userCertificate&quot; and expect the return of</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;userCertificate;binary&quot; using binary =
transfer.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>c) =
request &quot;*&quot; and expect the return of</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>&quot;userCertificate;binary&quot; using binary =
transfer.</FONT>
</P>

<P><FONT SIZE=3D2>This I-D caters to case a) in a manner which =
disallows servers</FONT>
<BR><FONT SIZE=3D2>from supporting case b) and c).&nbsp;&nbsp; I =
believe cases b) and c)</FONT>
<BR><FONT SIZE=3D2>are actually for more common than case a).&nbsp; I =
know of</FONT>
<BR><FONT SIZE=3D2>implemenations which are liberal in accepting b) or =
c).&nbsp; While</FONT>
<BR><FONT SIZE=3D2>there may be implementations which are liberal in =
accepting</FONT>
<BR><FONT SIZE=3D2>a), it should be noted that a) requires the server =
not to</FONT>
<BR><FONT SIZE=3D2>be strict in what it sends.</FONT>
</P>

<P><FONT SIZE=3D2>I also note that b) and c) are generally the result =
of</FONT>
<BR><FONT SIZE=3D2>the specification not be as clear as it should have =
been.</FONT>
<BR><FONT SIZE=3D2>Where a) is the result of someone apply LDAPv2 =
syntax and</FONT>
<BR><FONT SIZE=3D2>semantics to LDAPv3.</FONT>
</P>

<P><FONT SIZE=3D2>However, my objection to adding this I-D is that it =
that</FONT>
<BR><FONT SIZE=3D2>client and server implementations of it won't =
interoperate</FONT>
<BR><FONT SIZE=3D2>with existing server and client implementations =
which</FONT>
<BR><FONT SIZE=3D2>conform to the existing specification.</FONT>
</P>

<P><FONT SIZE=3D2>I suggest we only make the minimal changes necessary =
to</FONT>
<BR><FONT SIZE=3D2>resolve the issues which caused this schema to be =
removed</FONT>
<BR><FONT SIZE=3D2>from the LDAP &quot;core&quot; technical =
specification.&nbsp; It was</FONT>
<BR><FONT SIZE=3D2>removed become of normative reference issues =
(e.g.,</FONT>
<BR><FONT SIZE=3D2>2nd v 3rd v ... edition of X.500) and to align =
the</FONT>
<BR><FONT SIZE=3D2>schema with that provided by X.509 (e.g., matching =
rules).</FONT>
</P>

<P><FONT SIZE=3D2>I note that it was NOT removed because of lack of =
multiple</FONT>
<BR><FONT SIZE=3D2>independently developed implementations.&nbsp; We =
need to</FONT>
<BR><FONT SIZE=3D2>be careful to not to require changes to =
implementations</FONT>
<BR><FONT SIZE=3D2>which have already demonstrated =
interoperability.</FONT>
</P>

<P><FONT SIZE=3D2>Kurt</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1DCF9.85BDF230--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35MNr312952 for ietf-pkix-bks; Fri, 5 Apr 2002 14:23:53 -0800 (PST)
Received: from mail.cablespeed.com (mail.cablespeed.com [216.45.96.99]) by above.proper.com (8.11.6/8.11.3) with SMTP id g35MNpm12948 for <[e-mail]>; Fri, 5 Apr 2002 14:23:51 -0800 (PST)
Received: (qmail 29309 invoked by uid 0); 5 Apr 2002 22:23:49 -0000
Received: from unknown (HELO cablespeed.com) (216.45.82.31) by mail.cablespeed.com with SMTP; 5 Apr 2002 22:23:49 -0000
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 17:27:18 -0500
From: jim <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]> <[e-mail]>
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>

Russ,
    But the exact point is that if you decide that creating trust with directories
is the key instead of trust with the certificate holders and issuers, then the only
type of directory interaction that can occur is referral, which increases system
overhead, delays based on directory response times, and a general inability to grow
large systems in which any individual cross-certifying PKI has a single directory
to address.  Every individual PKI implementation would have to have not only a
central directory, but also border directories and each border directory would have
to hold the same level of trust as the central directory.  This implies constant
near-real-time updating of border directories or the threat of failed validation.
Help me to understand how you envision the directory system that successfully can
respond to a multitude of simultaneous or near-simultaneous requests for
validation.  Thanks.  Feel free to reply just to me if you wish as not everyone may
be interested from this point forward.
Jim

"Housley, Russ" wrote:

> Jim:
>
> I am not talking about trust in the X.500 system.  I am talking about trust
> in a DPV server.  In my mind, the client asks one DPV server to perform an
> action.  The response should come back, signed by that DPV server, or it is
> an error from the client's perspective.
>
> I see no reason for the client to be made aware of an chaining or multicasting.
>
> I do not think that we should include referrals in the DPV system at all.
>
> Russ
>
> At 02:50 PM 4/5/2002 -0500, jim wrote:
> >A small addition, but X.500 directories also have the ability for
> >multicasting in
> >which case a number of other directories are queried for a certificate at
> >the same
> >time.  Multicasting requires the greatest amount of directory and system
> >overhead,
> >but gets the quickest returns; where chaining requires the least and
> >referral is
> >the slowest, so there should be support for all three in the DPV
> >capability.  There
> >are no associated trust issues with use of either of the three methods as
> >far as I
> >know.
> >Jim
> >
> >"Housley, Russ" wrote:
> >
> > > Steve:
> > >
> > > In the X.500 directory, they two communication models are called chaining
> > > referrals.  Peter has asked for chaining support.  You are asking whether
> > > referrals should also be supported.
> > >
> > > I can see cases where chaining might be helpful.  It does not change the
> > > client's trust model.  It asks a particular DPV server for a response, and
> > > it gets one (signed by the same server that it asked).
> > >
> > > I think that referrals complicate the trust model.  The client asks one DPV
> > > server, then that server suggests that a different server might be better
> > > able to help.  If the client chooses to ask that server, it will get back a
> > > response signed by the second server.  Does the client trust it only
> > > because the first server made a referral?  What information need to be
> > > stored by the client to prove that it was referred to this server? All of
> > > this is more complication than I want.
> > >
> > > Russ
> > >
> > > At 02:21 PM 4/5/2002 +0100, Stephen Farrell wrote:
> > >
> > > >*If* relaying support/capability is to be considered as a
> > > >MUST/SHOULD/MAY requirement for a DPV protocol, then should
> > > >re-direction be handled similarly? (Note: I'm not proposing
> > > >that it should be, just asking!)
> > > >
> > > >By re-direction I mean:
> > > >
> > > >Alice: Hey Bob - is this key good?
> > > >Robert: Dunno Alice - but Charlie might know.
> > > >Alice: Hey Charles - is this key good?
> > > >Chaz: Yep.
> > > >
> > > >Stephen.
> > > >
> > > >Tim Polk wrote:
> > > > >
> > > > > Peter Sylvester has stated a requirement for DPV servers to relay
> > requests
> > > > > to one another:
> > > > >
> > > > >  >
> > > > >  >There is a requirement, similar as for OCSP caches,
> > > > >  >that server just relays a request to another. This had been
> > > > >  >discussed several times, the differences had only been to
> > > > >  >what degree the relaying should become visible; whether one
> > > > >  >server can rewrite/resigns the answers of another etc.
> > > > >  >Relaying via cache is an obvious feature in many OCSP implementation,
> > > > >  >how do they protect itself against loops between two servers?
> > > > >  >
> > > > >
> > > > > I believe this is an open issue, and would like to start a new
> > discussion
> > > > > thread limited to this topic.
> > > > >
> > > > > As I understand Peter's scenario, there are three mutually trusting DPV
> > > > > servers.  If a server cannot satisfy a request directly, it may
> > relay the
> > > > > request to a different server.  We'll assume the server is smart
> > enough not
> > > > > to relay a request back to the requester.  (That is, if server A
> > relays a
> > > > > request to Server B, B may relay it to Server C but not A.)
> > > > >
> > > > > (1) Assume Alice requests a valid path for Bob's certificate from
> > Server A,
> > > > > when none exists.
> > > > > (2) Server A relays the request to Server B, since it cannot satisfy it
> > > > > directly. (A could have chosen Server C; it is irrelevant.)
> > > > > (3) Server B relays the request to Server C, since it cannot satisfy it
> > > > > directly.  (C could not choose A, since it was the requester.)
> > > > > (4) Server C relays the request to Server A, since it cannot satisfy it
> > > > > directly.  (A could not choose B, since it was the requester.)
> > > > >
> > > > > At this point, either A must maintain state and recognize that the
> > request
> > > > > has cycled around or the protocol has to handle this by maintaining a
> > > > > history list.
> > > > >
> > > > > Peter, please confirm that I have characterized the problem
> > correctly (or
> > > > > post the right scenario)!  I am not personally convinced that blind
> > > > > relaying amongst DPV servers is a requirement.
> > > > >
> > > > > IMHO, DPV relaying would be limited to the scenario where each
> > Server was
> > > > > authoritative for a particular community (perhaps based on
> > privately held
> > > > > status information).  Alice directs all requests to Server A to
> > simplify
> > > > > her life.  Server A would be able to determine which server (B or
> > C) could
> > > > > possibly satisfy the request based on Bob's certificate.
> > > > >
> > > > > Even though relaying occurred, Server A acted as a simple DPV client,
> > > > > imposing no additional requirements...
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Tim Polk
> > > >
> > > >--
> > > >____________________________________________________________
> > > >Stephen Farrell
> > > >Baltimore Technologies,   tel: (direct line) [phone]
> > > >39 Parkgate Street,                     fax: [phone]
> > > >Dublin 8.                mailto:[e-mail]
> > > >Ireland                             http://www.baltimore.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35Kgic10021 for ietf-pkix-bks; Fri, 5 Apr 2002 12:42:44 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g35Kggm10016 for <[e-mail]>; Fri, 5 Apr 2002 12:42:42 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Apr 2002 20:41:47 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id PAA03631; Fri, 5 Apr 2002 15:41:37 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g35KggX27266; Fri, 5 Apr 2002 15:42:43 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1P1Y1>; Fri, 5 Apr 2002 15:40:18 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.12]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1P1YB; Fri, 5 Apr 2002 15:40:13 -0500
From: "Housley, Russ" <[e-mail]>
To: jim <[e-mail]>
Cc: [e-mail], Tim Polk <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 05 Apr 2002 15:42:31 -0500
Subject: Re: Open issue: DPV relay
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>

Jim:

I am not talking about trust in the X.500 system.  I am talking about trust 
in a DPV server.  In my mind, the client asks one DPV server to perform an 
action.  The response should come back, signed by that DPV server, or it is 
an error from the client's perspective.

I see no reason for the client to be made aware of an chaining or multicasting.

I do not think that we should include referrals in the DPV system at all.

Russ

At 02:50 PM 4/5/2002 -0500, jim wrote:
>A small addition, but X.500 directories also have the ability for 
>multicasting in
>which case a number of other directories are queried for a certificate at 
>the same
>time.  Multicasting requires the greatest amount of directory and system 
>overhead,
>but gets the quickest returns; where chaining requires the least and 
>referral is
>the slowest, so there should be support for all three in the DPV 
>capability.  There
>are no associated trust issues with use of either of the three methods as 
>far as I
>know.
>Jim
>
>"Housley, Russ" wrote:
>
> > Steve:
> >
> > In the X.500 directory, they two communication models are called chaining
> > referrals.  Peter has asked for chaining support.  You are asking whether
> > referrals should also be supported.
> >
> > I can see cases where chaining might be helpful.  It does not change the
> > client's trust model.  It asks a particular DPV server for a response, and
> > it gets one (signed by the same server that it asked).
> >
> > I think that referrals complicate the trust model.  The client asks one DPV
> > server, then that server suggests that a different server might be better
> > able to help.  If the client chooses to ask that server, it will get back a
> > response signed by the second server.  Does the client trust it only
> > because the first server made a referral?  What information need to be
> > stored by the client to prove that it was referred to this server? All of
> > this is more complication than I want.
> >
> > Russ
> >
> > At 02:21 PM 4/5/2002 +0100, Stephen Farrell wrote:
> >
> > >*If* relaying support/capability is to be considered as a
> > >MUST/SHOULD/MAY requirement for a DPV protocol, then should
> > >re-direction be handled similarly? (Note: I'm not proposing
> > >that it should be, just asking!)
> > >
> > >By re-direction I mean:
> > >
> > >Alice: Hey Bob - is this key good?
> > >Robert: Dunno Alice - but Charlie might know.
> > >Alice: Hey Charles - is this key good?
> > >Chaz: Yep.
> > >
> > >Stephen.
> > >
> > >Tim Polk wrote:
> > > >
> > > > Peter Sylvester has stated a requirement for DPV servers to relay 
> requests
> > > > to one another:
> > > >
> > > >  >
> > > >  >There is a requirement, similar as for OCSP caches,
> > > >  >that server just relays a request to another. This had been
> > > >  >discussed several times, the differences had only been to
> > > >  >what degree the relaying should become visible; whether one
> > > >  >server can rewrite/resigns the answers of another etc.
> > > >  >Relaying via cache is an obvious feature in many OCSP implementation,
> > > >  >how do they protect itself against loops between two servers?
> > > >  >
> > > >
> > > > I believe this is an open issue, and would like to start a new 
> discussion
> > > > thread limited to this topic.
> > > >
> > > > As I understand Peter's scenario, there are three mutually trusting DPV
> > > > servers.  If a server cannot satisfy a request directly, it may 
> relay the
> > > > request to a different server.  We'll assume the server is smart 
> enough not
> > > > to relay a request back to the requester.  (That is, if server A 
> relays a
> > > > request to Server B, B may relay it to Server C but not A.)
> > > >
> > > > (1) Assume Alice requests a valid path for Bob's certificate from 
> Server A,
> > > > when none exists.
> > > > (2) Server A relays the request to Server B, since it cannot satisfy it
> > > > directly. (A could have chosen Server C; it is irrelevant.)
> > > > (3) Server B relays the request to Server C, since it cannot satisfy it
> > > > directly.  (C could not choose A, since it was the requester.)
> > > > (4) Server C relays the request to Server A, since it cannot satisfy it
> > > > directly.  (A could not choose B, since it was the requester.)
> > > >
> > > > At this point, either A must maintain state and recognize that the 
> request
> > > > has cycled around or the protocol has to handle this by maintaining a
> > > > history list.
> > > >
> > > > Peter, please confirm that I have characterized the problem 
> correctly (or
> > > > post the right scenario)!  I am not personally convinced that blind
> > > > relaying amongst DPV servers is a requirement.
> > > >
> > > > IMHO, DPV relaying would be limited to the scenario where each 
> Server was
> > > > authoritative for a particular community (perhaps based on 
> privately held
> > > > status information).  Alice directs all requests to Server A to 
> simplify
> > > > her life.  Server A would be able to determine which server (B or 
> C) could
> > > > possibly satisfy the request based on Bob's certificate.
> > > >
> > > > Even though relaying occurred, Server A acted as a simple DPV client,
> > > > imposing no additional requirements...
> > > >
> > > > Thanks,
> > > >
> > > > Tim Polk
> > >
> > >--
> > >____________________________________________________________
> > >Stephen Farrell
> > >Baltimore Technologies,   tel: (direct line) [phone]
> > >39 Parkgate Street,                     fax: [phone]
> > >Dublin 8.                mailto:[e-mail]
> > >Ireland                             http://www.baltimore.com


Received: by above.proper.com (8.11.6/8.11.3) id g35KZO109879 for ietf-pkix-bks; Fri, 5 Apr 2002 12:35:24 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35KZNm09874 for <[e-mail]>; Fri, 5 Apr 2002 12:35:23 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g35KZCC26866; Fri, 5 Apr 2002 20:35:12 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020405110554.027a9008@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 05 Apr 2002 12:35:23 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
Cc: Mark Wahl <[e-mail]>, [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <001001c1db7f$751e3cd0$[e-mail]> <[e-mail]> <[e-mail]>
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>

I think adding a LDAP-specific "native" encoding to certificate
is a bad idea and will actually cause more problems than it
solves.

AFAIK, there are no interoperability problem between clients
and servers which adhere to the technical specification.  Things
are basically okay.

This I-D attempts to resolve interoperability problems between
non-conforming implementations and conforming implementations
by altering the specification to require conforming implementations
to accept and support the syntax and semantics of non-conforming
implementations.  However, there are a number of different
ways implementations have not conformed to the specification.

I have seen, in the wild, clients which:
	a) request "userCertificate" and expect the return of
	"userCertificate" using the (updated) LDAPv2 native
	string encoding.
	b) request "userCertificate" and expect the return of
	"userCertificate;binary" using binary transfer.
	c) request "*" and expect the return of
	"userCertificate;binary" using binary transfer.

This I-D caters to case a) in a manner which disallows servers
from supporting case b) and c).   I believe cases b) and c)
are actually for more common than case a).  I know of
implemenations which are liberal in accepting b) or c).  While
there may be implementations which are liberal in accepting
a), it should be noted that a) requires the server not to
be strict in what it sends.

I also note that b) and c) are generally the result of
the specification not be as clear as it should have been.
Where a) is the result of someone apply LDAPv2 syntax and
semantics to LDAPv3.

However, my objection to adding this I-D is that it that
client and server implementations of it won't interoperate
with existing server and client implementations which
conform to the existing specification.

I suggest we only make the minimal changes necessary to
resolve the issues which caused this schema to be removed
from the LDAP "core" technical specification.  It was
removed become of normative reference issues (e.g.,
2nd v 3rd v ... edition of X.500) and to align the
schema with that provided by X.509 (e.g., matching rules).

I note that it was NOT removed because of lack of multiple
independently developed implementations.  We need to
be careful to not to require changes to implementations
which have already demonstrated interoperability.

Kurt



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35Jke803204 for ietf-pkix-bks; Fri, 5 Apr 2002 11:46:40 -0800 (PST)
Received: from mail.cablespeed.com (mail.cablespeed.com [216.45.96.99]) by above.proper.com (8.11.6/8.11.3) with SMTP id g35Jkcm03199 for <[e-mail]>; Fri, 5 Apr 2002 11:46:39 -0800 (PST)
Received: (qmail 23274 invoked by uid 0); 5 Apr 2002 19:46:32 -0000
Received: from unknown (HELO cablespeed.com) (216.45.82.31) by mail.cablespeed.com with SMTP; 5 Apr 2002 19:46:32 -0000
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 14:50:02 -0500
From: jim <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail], Tim Polk <[e-mail]>, [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]>
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>

A small addition, but X.500 directories also have the ability for multicasting in
which case a number of other directories are queried for a certificate at the same
time.  Multicasting requires the greatest amount of directory and system overhead,
but gets the quickest returns; where chaining requires the least and referral is
the slowest, so there should be support for all three in the DPV capability.  There
are no associated trust issues with use of either of the three methods as far as I
know.
Jim

"Housley, Russ" wrote:

> Steve:
>
> In the X.500 directory, they two communication models are called chaining
> referrals.  Peter has asked for chaining support.  You are asking whether
> referrals should also be supported.
>
> I can see cases where chaining might be helpful.  It does not change the
> client's trust model.  It asks a particular DPV server for a response, and
> it gets one (signed by the same server that it asked).
>
> I think that referrals complicate the trust model.  The client asks one DPV
> server, then that server suggests that a different server might be better
> able to help.  If the client chooses to ask that server, it will get back a
> response signed by the second server.  Does the client trust it only
> because the first server made a referral?  What information need to be
> stored by the client to prove that it was referred to this server? All of
> this is more complication than I want.
>
> Russ
>
> At 02:21 PM 4/5/2002 +0100, Stephen Farrell wrote:
>
> >*If* relaying support/capability is to be considered as a
> >MUST/SHOULD/MAY requirement for a DPV protocol, then should
> >re-direction be handled similarly? (Note: I'm not proposing
> >that it should be, just asking!)
> >
> >By re-direction I mean:
> >
> >Alice: Hey Bob - is this key good?
> >Robert: Dunno Alice - but Charlie might know.
> >Alice: Hey Charles - is this key good?
> >Chaz: Yep.
> >
> >Stephen.
> >
> >Tim Polk wrote:
> > >
> > > Peter Sylvester has stated a requirement for DPV servers to relay requests
> > > to one another:
> > >
> > >  >
> > >  >There is a requirement, similar as for OCSP caches,
> > >  >that server just relays a request to another. This had been
> > >  >discussed several times, the differences had only been to
> > >  >what degree the relaying should become visible; whether one
> > >  >server can rewrite/resigns the answers of another etc.
> > >  >Relaying via cache is an obvious feature in many OCSP implementation,
> > >  >how do they protect itself against loops between two servers?
> > >  >
> > >
> > > I believe this is an open issue, and would like to start a new discussion
> > > thread limited to this topic.
> > >
> > > As I understand Peter's scenario, there are three mutually trusting DPV
> > > servers.  If a server cannot satisfy a request directly, it may relay the
> > > request to a different server.  We'll assume the server is smart enough not
> > > to relay a request back to the requester.  (That is, if server A relays a
> > > request to Server B, B may relay it to Server C but not A.)
> > >
> > > (1) Assume Alice requests a valid path for Bob's certificate from Server A,
> > > when none exists.
> > > (2) Server A relays the request to Server B, since it cannot satisfy it
> > > directly. (A could have chosen Server C; it is irrelevant.)
> > > (3) Server B relays the request to Server C, since it cannot satisfy it
> > > directly.  (C could not choose A, since it was the requester.)
> > > (4) Server C relays the request to Server A, since it cannot satisfy it
> > > directly.  (A could not choose B, since it was the requester.)
> > >
> > > At this point, either A must maintain state and recognize that the request
> > > has cycled around or the protocol has to handle this by maintaining a
> > > history list.
> > >
> > > Peter, please confirm that I have characterized the problem correctly (or
> > > post the right scenario)!  I am not personally convinced that blind
> > > relaying amongst DPV servers is a requirement.
> > >
> > > IMHO, DPV relaying would be limited to the scenario where each Server was
> > > authoritative for a particular community (perhaps based on privately held
> > > status information).  Alice directs all requests to Server A to simplify
> > > her life.  Server A would be able to determine which server (B or C) could
> > > possibly satisfy the request based on Bob's certificate.
> > >
> > > Even though relaying occurred, Server A acted as a simple DPV client,
> > > imposing no additional requirements...
> > >
> > > Thanks,
> > >
> > > Tim Polk
> >
> >--
> >____________________________________________________________
> >Stephen Farrell
> >Baltimore Technologies,   tel: (direct line) [phone]
> >39 Parkgate Street,                     fax: [phone]
> >Dublin 8.                mailto:[e-mail]
> >Ireland                             http://www.baltimore.com



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35IH5n28840 for ietf-pkix-bks; Fri, 5 Apr 2002 10:17:05 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35IH4m28832 for <[e-mail]>; Fri, 5 Apr 2002 10:17:04 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g35IH3C26301; Fri, 5 Apr 2002 18:17:03 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020405092657.026c3970@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 05 Apr 2002 10:17:14 -0800
To: "Ramsay, Ron" <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: LDAPbis scope issue (Was: LDAP Certificate transfer syntax)
Cc: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
In-Reply-To: <[e-mail]>
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>

At 06:38 PM 2002-04-04, Ramsay, Ron wrote:
>Quite apart from the meaning of "core", the last sentence above seems to be
>your way of offering carte blanche to the certificate work?

The PKIX WG has undertaken the engineering of the PKI
schema for LDAP specification.  LDAPbis is providing review.
No carte blanche is (nor can be) given.

Kurt



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35HjHU27515 for ietf-pkix-bks; Fri, 5 Apr 2002 09:45:17 -0800 (PST)
Received: from poseidon.coastside.net (poseidon.coastside.net [207.213.212.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35HjGm27511 for <[e-mail]>; Fri, 5 Apr 2002 09:45:16 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g35HjCkI029513; Fri, 5 Apr 2002 09:45:13 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Tim Polk" <[e-mail]>, "Denis Pinkas" <[e-mail]>, "Ambarish Malpani" <[e-mail]>
Cc: "'Housley, Russ'" <[e-mail]>, "Santosh Chokhani" <[e-mail]>, <[e-mail]>
Subject: RE: One last comment on DPD requirements
Date: Fri, 5 Apr 2002 09:42:28 -0800
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 V5.50.4133.2400
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 think I agree with Denis (at least if I'm reading him
correctly).

One of the needs that drove DPD into existence in the first
place was the observation that a DPV server, due to its use of a
signing key, would fall within scope of various trusted systems
certification programs while a server strictly limited in its
design and implementation to DPD functionality could arguably
avoid that.

Thus, a DPV server would be trusted from a system certification
perspective even though a client of that server may choose not
to fully delegate its trust to that server.  Not to say that DPD
server could not also be so certified, but the value of doing so
would be minimal.

This is all hypothetical of course since it's not within our
scope in this forum to set rules for what does and does not
require such certification, but predictable enough that Stephen,
Carlisle and I went around and around on the issues way back
when and thus why DPD was initially proposed to the WG as
basically a subset of a DPV functionality.

Just thought that context might be useful FWIW.

Mike



> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Tim Polk
> Sent: Friday, April 05, 2002 7:30 AM
> To: Denis Pinkas; Ambarish Malpani
> Cc: 'Housley, Russ'; Santosh Chokhani; [e-mail]
> Subject: Re: One last comment on DPD requirements
>
>
>
> Denis,
>
> At 02:50 PM 4/5/02 +0200, Denis Pinkas wrote:
>
> >Ambarish,
> >
> > > Russ,
> >
> > >     A minor nit - a DPD server might also be a
> DPV server, who
> > > a client is not willing to trust (and whose work
> the client wants
> > > to verify for itself).
> >
> >This is not a minor nit. A DPV server is always
> trusted by the client, while
> >a DPD server does not need to be trusted.  A DPV
> server is not necessarily
> >trusted by *other* clients. So the case of an
> untrusted DPV server, as
> >mentionned, does not exist.
>
> I disagree strongly.  If a client requests that a DPV
> server return the
> certification path, it may do so for either of two reasons:
> (1) it wishes to cache the information for audit purposes; or
> (2) the client does not trust the DPV server for this
> application, and will
> perform the path validation locally as well.
>
> The same client may trust the DPV server for low
> value applications (e.g.,
> email) but organizational policy may demand that the
> client perform path
> validation locally for funds transfer or other high
> value applications.  It
> makes perfect sense for the client to use the DPV
> server in both cases.
>
> Note that only the client can tell which mode it
> operates in...
>
> Thanks,
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35GxkW26020 for ietf-pkix-bks; Fri, 5 Apr 2002 08:59:46 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g35Gxjm26015 for <[e-mail]>; Fri, 5 Apr 2002 08:59:45 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Apr 2002 16:58:49 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA11993; Fri, 5 Apr 2002 11:58:42 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g35Gxmn01540; Fri, 5 Apr 2002 11:59:48 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1PALV>; Fri, 5 Apr 2002 11:57:23 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.145]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1PALT; Fri, 5 Apr 2002 11:57:18 -0500
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: Tim Polk <[e-mail]>, [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 05 Apr 2002 11:54:39 -0500
Subject: Re: Open issue: DPV relay
In-Reply-To: <[e-mail]>
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>

Steve:

In the X.500 directory, they two communication models are called chaining 
referrals.  Peter has asked for chaining support.  You are asking whether 
referrals should also be supported.

I can see cases where chaining might be helpful.  It does not change the 
client's trust model.  It asks a particular DPV server for a response, and 
it gets one (signed by the same server that it asked).

I think that referrals complicate the trust model.  The client asks one DPV 
server, then that server suggests that a different server might be better 
able to help.  If the client chooses to ask that server, it will get back a 
response signed by the second server.  Does the client trust it only 
because the first server made a referral?  What information need to be 
stored by the client to prove that it was referred to this server? All of 
this is more complication than I want.

Russ

At 02:21 PM 4/5/2002 +0100, Stephen Farrell wrote:


>*If* relaying support/capability is to be considered as a
>MUST/SHOULD/MAY requirement for a DPV protocol, then should
>re-direction be handled similarly? (Note: I'm not proposing
>that it should be, just asking!)
>
>By re-direction I mean:
>
>Alice: Hey Bob - is this key good?
>Robert: Dunno Alice - but Charlie might know.
>Alice: Hey Charles - is this key good?
>Chaz: Yep.
>
>Stephen.
>
>Tim Polk wrote:
> >
> > Peter Sylvester has stated a requirement for DPV servers to relay requests
> > to one another:
> >
> >  >
> >  >There is a requirement, similar as for OCSP caches,
> >  >that server just relays a request to another. This had been
> >  >discussed several times, the differences had only been to
> >  >what degree the relaying should become visible; whether one
> >  >server can rewrite/resigns the answers of another etc.
> >  >Relaying via cache is an obvious feature in many OCSP implementation,
> >  >how do they protect itself against loops between two servers?
> >  >
> >
> > I believe this is an open issue, and would like to start a new discussion
> > thread limited to this topic.
> >
> > As I understand Peter's scenario, there are three mutually trusting DPV
> > servers.  If a server cannot satisfy a request directly, it may relay the
> > request to a different server.  We'll assume the server is smart enough not
> > to relay a request back to the requester.  (That is, if server A relays a
> > request to Server B, B may relay it to Server C but not A.)
> >
> > (1) Assume Alice requests a valid path for Bob's certificate from Server A,
> > when none exists.
> > (2) Server A relays the request to Server B, since it cannot satisfy it
> > directly. (A could have chosen Server C; it is irrelevant.)
> > (3) Server B relays the request to Server C, since it cannot satisfy it
> > directly.  (C could not choose A, since it was the requester.)
> > (4) Server C relays the request to Server A, since it cannot satisfy it
> > directly.  (A could not choose B, since it was the requester.)
> >
> > At this point, either A must maintain state and recognize that the request
> > has cycled around or the protocol has to handle this by maintaining a
> > history list.
> >
> > Peter, please confirm that I have characterized the problem correctly (or
> > post the right scenario)!  I am not personally convinced that blind
> > relaying amongst DPV servers is a requirement.
> >
> > IMHO, DPV relaying would be limited to the scenario where each Server was
> > authoritative for a particular community (perhaps based on privately held
> > status information).  Alice directs all requests to Server A to simplify
> > her life.  Server A would be able to determine which server (B or C) could
> > possibly satisfy the request based on Bob's certificate.
> >
> > Even though relaying occurred, Server A acted as a simple DPV client,
> > imposing no additional requirements...
> >
> > Thanks,
> >
> > Tim Polk
>
>--
>____________________________________________________________
>Stephen Farrell
>Baltimore Technologies,   tel: (direct line) [phone]
>39 Parkgate Street,                     fax: [phone]
>Dublin 8.                mailto:[e-mail]
>Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35GkMM25368 for ietf-pkix-bks; Fri, 5 Apr 2002 08:46:22 -0800 (PST)
Received: from poseidon.coastside.net (poseidon.coastside.net [207.213.212.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35GkLm25364 for <[e-mail]>; Fri, 5 Apr 2002 08:46:21 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g35GkBkI023966; Fri, 5 Apr 2002 08:46:11 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Tim Polk" <[e-mail]>, <[e-mail]>
Cc: "Peter Sylvester" <[e-mail]>
Subject: RE: Open issue: DPV relay
Date: Fri, 5 Apr 2002 08:43:26 -0800
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]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
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,

FWIW I think relay should be supported.  Is the core question
stateful servers vs. stateful protocol?

Mike



Michael Myers
t: +415.819.1362
e: mailto:[e-mail]
w: http://www.traceroutesecurity.com

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Tim Polk
> Sent: Thursday, April 04, 2002 3:11 PM
> To: [e-mail]
> Cc: Peter Sylvester
> Subject: Open issue: DPV relay
>
>
>
> Peter Sylvester has stated a requirement for DPV
> servers to relay requests
> to one another:
>
>  >
>  >There is a requirement, similar as for OCSP caches,
>  >that server just relays a request to another. This had been
>  >discussed several times, the differences had only been to
>  >what degree the relaying should become visible; whether one
>  >server can rewrite/resigns the answers of another etc.
>  >Relaying via cache is an obvious feature in many
> OCSP implementation,
>  >how do they protect itself against loops between
> two servers?
>  >
>
> I believe this is an open issue, and would like to
> start a new discussion
> thread limited to this topic.
>
> As I understand Peter's scenario, there are three
> mutually trusting DPV
> servers.  If a server cannot satisfy a request
> directly, it may relay the
> request to a different server.  We'll assume the
> server is smart enough not
> to relay a request back to the requester.  (That is,
> if server A relays a
> request to Server B, B may relay it to Server C but not A.)
>
> (1) Assume Alice requests a valid path for Bob's
> certificate from Server A,
> when none exists.
> (2) Server A relays the request to Server B, since it
> cannot satisfy it
> directly. (A could have chosen Server C; it is irrelevant.)
> (3) Server B relays the request to Server C, since it
> cannot satisfy it
> directly.  (C could not choose A, since it was the requester.)
> (4) Server C relays the request to Server A, since it
> cannot satisfy it
> directly.  (A could not choose B, since it was the requester.)
>
> At this point, either A must maintain state and
> recognize that the request
> has cycled around or the protocol has to handle this
> by maintaining a
> history list.
>
> Peter, please confirm that I have characterized the
> problem correctly (or
> post the right scenario)!  I am not personally
> convinced that blind
> relaying amongst DPV servers is a requirement.
>
> IMHO, DPV relaying would be limited to the scenario
> where each Server was
> authoritative for a particular community (perhaps
> based on privately held
> status information).  Alice directs all requests to
> Server A to simplify
> her life.  Server A would be able to determine which
> server (B or C) could
> possibly satisfy the request based on Bob's certificate.
>
> Even though relaying occurred, Server A acted as a
> simple DPV client,
> imposing no additional requirements...
>
> Thanks,
>
> Tim Polk
>
>



Received: by above.proper.com (8.11.6/8.11.3) id g35G3t221050 for ietf-pkix-bks; Fri, 5 Apr 2002 08:03:55 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g35G3rm21043 for <[e-mail]>; Fri, 5 Apr 2002 08:03:53 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Apr 2002 16:02:57 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA06496 for <[e-mail]>; Fri, 5 Apr 2002 11:02:51 -0500 (EST)
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g35G3uX25067 for <[e-mail]>; Fri, 5 Apr 2002 11:03:56 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <FVAZ1NA9>; Fri, 5 Apr 2002 08:03:52 -0800
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.145]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX13024; Fri, 5 Apr 2002 11:01:25 -0500
From: "Housley, Russ" <[e-mail]>
To: "Jacoby, Jeffrey" <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Fri, 05 Apr 2002 11:00:56 -0500
Subject: Re: One last comment on DPD requirements
In-Reply-To: <[e-mail]>
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>

Jeff:

> > Tim Polk and I just discussed this on the phone.  I will share my
> > conclusion form the conversation (which might be different than Tim's
> > conclusion).  I think that we need to allow for multiple certificates to
> > be
> > returned, but the default should be to return just one.  If the client
> > wants more than one, it needs to explicitly request them (up to a
> > maximum
> > number).  If the server does not support returning extra certificates,
> > then
> > it should just return one, but it should include a status code that
> > says,
> > "I do not support the option you requested, but I thought that I should
> > give you one just in case it meets your needs."
>
>I think such a status code may be unnecessary.  If a multi-path-capable 
>client
>gets only one path back -- either because there really was only one path, 
>or the
>server couldn't support multiple paths -- what can it usefully do with 
>that status code?
>In other words, what would/could it do differently if it saw that status 
>code or  not?

Recall that we are discussing DPD (not DPV).  So, if the client finds that 
the single path that was returned is unacceptable, then the client could go 
to a different (untrusted) DPD server in the hopes of getting a collection 
of paths (or at least a different one).  Clearly, this is not 
optimal.  But, the client needs to know that the first server did not even 
try to find more than one path.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35G3GG21029 for ietf-pkix-bks; Fri, 5 Apr 2002 08:03:16 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35G3Fm21025 for <[e-mail]>; Fri, 5 Apr 2002 08:03:15 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 5 Apr 2002 08:01:05 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 05 Apr 2002 08:01:05 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <H570PRZL>; Fri, 05 Apr 2002 08:02:41 -0800
Content-return: allowed
Date: Fri, 05 Apr 2002 08:02:40 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Open issue: DPV relay
To: "'Peter Sylvester'" <[e-mail]>, [e-mail], [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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 Peter,
    I agree with your desire to have a DPV response included where
one would allow CRLs or OCSP responses to be included to prove
how a server obtained the status of a certificate.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Peter Sylvester [mailto:[e-mail]]
> Sent: Friday, April 05, 2002 4:02 AM
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: Re: Open issue: DPV relay
> 
> 
... (Stuff deleted)

> 
> *** Issue 2 ***:
> 
> 
> A DPV server may want to determine the validity status of 
> an intermediate CA certificate, (or even obtain responses
> from other DPV servers confirming a validity decision).
> 
> Another scenario is a company server that validates an
> certificate of another company, it asks the other companies
> server, and obtains a result.  The server *may* choose to
> create its own response withour revealing the response
> from the other server (blind relaying?), but it may also 
> choose to give the answer back to the client allow to maintain
> a proof that the 'other company' has cooperated. 
>  
> Simular to OCSP responses or CRLs which represent
> assertions about the validity of some cert, a DPV response
> is also such kind of assertion. 
> 
> I see a requirement that a server may want to add 
> DPV responses in his response in order to create a complete 
> picture of all the assertions he obtained. 
> 
> Answers from Denis always seem to indicate that
> a DPV response MUST NOT be included in a final response
> (since *we* do not support relaying). 
> 
> I do not see an essential difference between 
> a CRL repository, an OCSP response and a DPV response.
> There I propose to add behind  
> 
> "...  As an 
> example, an S/MIME message might include such information, and the 
> client can simply copy that information into the DPV request."
> 
> the text:  
> 
> DPV responses may use information obtained by other DPV transactions 
> performed by the DPV server in order to determine the validity of 
> some certificate in the path. The server MUST be able to include 
> such response in its own final response. 
> 
> Or to replace in the preceding paragraph 'revocation information'
> by "'status information' such an revocation information of CRLs
> or OCSP but also other DPV responses.".  
> 
> 
> *** A little nit-picking:
> 
> Would the authors try and avoid characters like "AE" instead 
> of "'" as in DPV serverAEs. 
> 
> 
> 
> 
> 
>    
>  
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35Fts020482 for ietf-pkix-bks; Fri, 5 Apr 2002 07:55:54 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35Ftqm20478 for <[e-mail]>; Fri, 5 Apr 2002 07:55:52 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA25986; Fri, 5 Apr 2002 17:58:20 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040517553579:243 ; Fri, 5 Apr 2002 17:55:35 +0200 
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 17:55:14 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: One last comment on DPD requirements
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 17:55:35, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 17:55:50, Serialize complete at 05/04/2002 17:55:50
Content-Transfer-Encoding: 7bit
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>

Tim,

> Denis,
> 
> At 02:50 PM 4/5/02 +0200, Denis Pinkas wrote:
> 
> >Ambarish,
> >
> > > Russ,
> >
> > >     A minor nit - a DPD server might also be a DPV server, who
> > > a client is not willing to trust (and whose work the client wants
> > > to verify for itself).
> >
> >This is not a minor nit. A DPV server is always trusted by the client, while
> >a DPD server does not need to be trusted.  A DPV server is not necessarily
> >trusted by *other* clients. So the case of an untrusted DPV server, as
> >mentionned, does not exist.
> 
> I disagree strongly.  

What a strong word for a "minor nit" !

:-)

> If a client requests that a DPV server return the
> certification path, it may do so for either of two reasons:

> (1) it wishes to cache the information for audit purposes; or

Not exactly. Audit is not the reason. The reason is that *another* party
will not necessarilly trust the "valid" answer from that server. However
that other party might want to test the validity of the certificate later on
and may not trust the same DPV server. Since later on all the information to
do the validation may not be available, it is captured with the "valid
answer" so that this other party can use it as as "useful information" with
a request made later on to another DPV server that it trusts.  

> (2) the client does not trust the DPV server for this application, and will
> perform the path validation locally as well.

DPV is first designed for thin clients or clients unable to perform the path
validation themselves. If they would, then they would use DPD. Now, nothing
would prevent an application to do what you say, but it does not make sense.

> The same client may trust the DPV server for low value applications (e.g.,
> email) but organizational policy may demand that the client perform path
> validation locally for funds transfer or other high value applications.  It
> makes perfect sense for the client to use the DPV server in both cases.

I would disagree as well.

Now, I do not remember that this comment was raised during the last call
period ... or could you refer to which comment number it relates ?

Thanks,

Denis
 
> Note that only the client can tell which mode it operates in...
> 
> Thanks,
> 
> Tim
> 
> >Denis
> >
> >
> > > To summarize, what I think what I hear you, Santosh and Steve say
> > > is that it might make sense to require a DPD server to return a
> > > single path back, but if we want to enable that, we need to let
> > > the client specify his requirements more precisely. Is that
> > > correct?
> > >
> > > It would make sense to show (in the protocol doc), what those
> > > requirements are for protocols like S/MIME, TLS, IPSec and let
> > > other protocols define their own requirements if they can't
> > > fit into one of the three above.
> > >
> > > Does that make sense to you? What about others on the list?
> > >
> > > Regards,
> > > Ambarish
> > >
> > > ---------------------------------------------------------------------
> > > Ambarish Malpani
> > > Chief Architect                                          650.567.5457
> > > ValiCert, Inc.                                  [e-mail]
> > > 1215 Terra Bella Ave.                         http://www.valicert.com
> > > Mountain View, CA 94043
> > >
> > > > -----Original Message-----
> > > > From: Housley, Russ [mailto:[e-mail]]
> > > > Sent: Thursday, April 04, 2002 7:00 AM
> > > > To: Santosh Chokhani
> > > > Cc: [e-mail]
> > > > Subject: RE: One last comment on DPD requirements
> > > >
> > > >
> > > >
> > > > Santosh:
> > > >
> > > > I think that a DPD server will likely perform path
> > > > validation.  Clients
> > > > will not be happy if the paths that they are given are often
> > > > invalid.  Clearly, the DPD server cannot know all of the
> > > > parameters that
> > > > the client will use for path validation (otherwise it would be a DPV
> > > > server), but it can make some very reasonable assumptions to
> > > > ensure that
> > > > grossly invalid paths are not returned.
> > > >
> > > > Russ
> > > >
> > > > At 08:20 PM 4/3/2002 -0500, Santosh Chokhani wrote:
> > > > >Russ:
> > > > >
> > > > >I agree with you, but for a different reason.  I do not think this is
> > > > >application specific issue.  I think it is the path
> > > > validation issue.  I
> > > > >do not think that the DPD server can know which paths are
> > > > good without
> > > > >doing a validation also, specially to see if there will be any name
> > > > >constraints or certificate policy related failures.
> > > > >
> > > > >-----Original Message-----
> > > > >From: [e-mail]
> > > > [mailto:[e-mail]]
> > > > >On Behalf Of Housley, Russ
> > > > >Sent: Wednesday, April 03, 2002 2:12 PM
> > > > >To: Ambarish Malpani; Stephen Kent
> > > > >Cc: [e-mail]
> > > > >Subject: Re: One last comment on DPD requirements
> > > > >
> > > > >
> > > > >
> > > > >Steve & Ambarish:
> > > > >
> > > > > >>Hi Group,
> > > > > >>     One last (slightly late) comment on the DPD
> > > > requirements that has
> > > > >
> > > > > >>been troubling me:
> > > > > >>
> > > > > >>In the DPD requirements, there is a reasonable amount of text that
> > > > > >>talks about how a server can return multiple paths back
> > > > to the client
> > > > > >>(to allow the client to decide which path is the best).
> > > > > >>
> > > > > >>The main goal of DPD is to try and simplify the client.
> > > > In how many
> > > > > >>cases do people really want multiple paths back from the
> > > > server. While
> > > > >
> > > > > >>it is the right requirement in principal, do folks really think
> > > > > >>clients will want multiple paths back from a DPD server?
> > > > Are we adding
> > > > >
> > > > > >>the additional flexiblity/complexity just for technical purity?
> > > > > >>
> > > > > >>Comments will be appreciated.
> > > > > >>
> > > > > >>Regards,
> > > > > >>Ambarish
> > > > > >
> > > > > >I too would favor simplifying the protocol requirement
> > > > here. Some folks
> > > > > >have suggested motivations for multiple paths, but this
> > > > does seem to
> > > > > >conflict with the fundamental goal of creating a protocol
> > > > to satisfy
> > > > >the
> > > > > >needs of thin clients.
> > > > > >
> > > > > >Steve
> > > > >
> > > > >I agree with your goal.  It is far better for the client to tell the
> > > > >server
> > > > >what it wants, then get back a single path that satisfies all of the
> > > > >requirements.  To do this, we need to be able to fully specify the
> > > > >clients
> > > > >criteria and send them to the server.  I think that we know how to do
> > > > >this
> > > > >for many PKI-enabled applications, but I am not sure that we
> > > > know how to
> > > > >do
> > > > >it for all applications, especially ones that are yet to be
> > > > developed.
> > > > >
> > > > >This leaves us with two choices.  Either the protocol
> > > > returns multiple
> > > > >certification paths (the approach in the current document) or the
> > > > >protocol
> > > > >requires the client to adequately specify its criteria.
> > > > This could be
> > > > >done
> > > > >with the path discovery policy.  If we adopt this
> > > > alternative, we should
> > > > >
> > > > >include additional text so that implements expect
> > > > application-specific
> > > > >(perhaps several application-specific path discovery policy
> > > > if there are
> > > > >
> > > > >multiple roles in the application).
> > > > >
> > > > >Russ
> > > >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35FrRB20375 for ietf-pkix-bks; Fri, 5 Apr 2002 07:53:27 -0800 (PST)
Received: from poseidon.coastside.net (poseidon.coastside.net [207.213.212.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35FrQm20371 for <[e-mail]>; Fri, 5 Apr 2002 07:53:26 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g35FrHkI020032; Fri, 5 Apr 2002 07:53:17 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: A few comments re: dpv-dpd requirements
Date: Fri, 5 Apr 2002 07:50:34 -0800
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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

> -----Original Message-----
> > 
> > "The DPV response MUST indicate one of the following three
> > status alternatives:
> > 
> > 1) the certificate is valid according to the 
> validation policy.
> > 2) the certificate is not valid according to the validation
> > policy.
> > 3) the certificate is unknown to the validation server."
> 
> I do not think you really mean this, but rather:
> 
> 3) the validity of the certificate is unknown 
> according to the 
>    validation policy.
> 
> 
> Denis


Denis,

That is fine.

Mike


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35FVNv18299 for ietf-pkix-bks; Fri, 5 Apr 2002 07:31:23 -0800 (PST)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35FVKm18289 for <[e-mail]>; Fri, 5 Apr 2002 07:31:20 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g35FVICl003369; Fri, 5 Apr 2002 10:31:18 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Fri, 05 Apr 2002 10:29:40 -0500
To: Denis Pinkas <[e-mail]>, Ambarish Malpani <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Re: One last comment on DPD requirements
Cc: "'Housley, Russ'" <[e-mail]>, Santosh Chokhani <[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
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,

At 02:50 PM 4/5/02 +0200, Denis Pinkas wrote:

>Ambarish,
>
> > Russ,
>
> >     A minor nit - a DPD server might also be a DPV server, who
> > a client is not willing to trust (and whose work the client wants
> > to verify for itself).
>
>This is not a minor nit. A DPV server is always trusted by the client, while
>a DPD server does not need to be trusted.  A DPV server is not necessarily
>trusted by *other* clients. So the case of an untrusted DPV server, as
>mentionned, does not exist.

I disagree strongly.  If a client requests that a DPV server return the 
certification path, it may do so for either of two reasons:
(1) it wishes to cache the information for audit purposes; or
(2) the client does not trust the DPV server for this application, and will 
perform the path validation locally as well.

The same client may trust the DPV server for low value applications (e.g., 
email) but organizational policy may demand that the client perform path 
validation locally for funds transfer or other high value applications.  It 
makes perfect sense for the client to use the DPV server in both cases.

Note that only the client can tell which mode it operates in...

Thanks,

Tim

>Denis
>
>
> > To summarize, what I think what I hear you, Santosh and Steve say
> > is that it might make sense to require a DPD server to return a
> > single path back, but if we want to enable that, we need to let
> > the client specify his requirements more precisely. Is that
> > correct?
> >
> > It would make sense to show (in the protocol doc), what those
> > requirements are for protocols like S/MIME, TLS, IPSec and let
> > other protocols define their own requirements if they can't
> > fit into one of the three above.
> >
> > Does that make sense to you? What about others on the list?
> >
> > Regards,
> > Ambarish
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Chief Architect                                          650.567.5457
> > ValiCert, Inc.                                  [e-mail]
> > 1215 Terra Bella Ave.                         http://www.valicert.com
> > Mountain View, CA 94043
> >
> > > -----Original Message-----
> > > From: Housley, Russ [mailto:[e-mail]]
> > > Sent: Thursday, April 04, 2002 7:00 AM
> > > To: Santosh Chokhani
> > > Cc: [e-mail]
> > > Subject: RE: One last comment on DPD requirements
> > >
> > >
> > >
> > > Santosh:
> > >
> > > I think that a DPD server will likely perform path
> > > validation.  Clients
> > > will not be happy if the paths that they are given are often
> > > invalid.  Clearly, the DPD server cannot know all of the
> > > parameters that
> > > the client will use for path validation (otherwise it would be a DPV
> > > server), but it can make some very reasonable assumptions to
> > > ensure that
> > > grossly invalid paths are not returned.
> > >
> > > Russ
> > >
> > > At 08:20 PM 4/3/2002 -0500, Santosh Chokhani wrote:
> > > >Russ:
> > > >
> > > >I agree with you, but for a different reason.  I do not think this is
> > > >application specific issue.  I think it is the path
> > > validation issue.  I
> > > >do not think that the DPD server can know which paths are
> > > good without
> > > >doing a validation also, specially to see if there will be any name
> > > >constraints or certificate policy related failures.
> > > >
> > > >-----Original Message-----
> > > >From: [e-mail]
> > > [mailto:[e-mail]]
> > > >On Behalf Of Housley, Russ
> > > >Sent: Wednesday, April 03, 2002 2:12 PM
> > > >To: Ambarish Malpani; Stephen Kent
> > > >Cc: [e-mail]
> > > >Subject: Re: One last comment on DPD requirements
> > > >
> > > >
> > > >
> > > >Steve & Ambarish:
> > > >
> > > > >>Hi Group,
> > > > >>     One last (slightly late) comment on the DPD
> > > requirements that has
> > > >
> > > > >>been troubling me:
> > > > >>
> > > > >>In the DPD requirements, there is a reasonable amount of text that
> > > > >>talks about how a server can return multiple paths back
> > > to the client
> > > > >>(to allow the client to decide which path is the best).
> > > > >>
> > > > >>The main goal of DPD is to try and simplify the client.
> > > In how many
> > > > >>cases do people really want multiple paths back from the
> > > server. While
> > > >
> > > > >>it is the right requirement in principal, do folks really think
> > > > >>clients will want multiple paths back from a DPD server?
> > > Are we adding
> > > >
> > > > >>the additional flexiblity/complexity just for technical purity?
> > > > >>
> > > > >>Comments will be appreciated.
> > > > >>
> > > > >>Regards,
> > > > >>Ambarish
> > > > >
> > > > >I too would favor simplifying the protocol requirement
> > > here. Some folks
> > > > >have suggested motivations for multiple paths, but this
> > > does seem to
> > > > >conflict with the fundamental goal of creating a protocol
> > > to satisfy
> > > >the
> > > > >needs of thin clients.
> > > > >
> > > > >Steve
> > > >
> > > >I agree with your goal.  It is far better for the client to tell the
> > > >server
> > > >what it wants, then get back a single path that satisfies all of the
> > > >requirements.  To do this, we need to be able to fully specify the
> > > >clients
> > > >criteria and send them to the server.  I think that we know how to do
> > > >this
> > > >for many PKI-enabled applications, but I am not sure that we
> > > know how to
> > > >do
> > > >it for all applications, especially ones that are yet to be
> > > developed.
> > > >
> > > >This leaves us with two choices.  Either the protocol
> > > returns multiple
> > > >certification paths (the approach in the current document) or the
> > > >protocol
> > > >requires the client to adequately specify its criteria.
> > > This could be
> > > >done
> > > >with the path discovery policy.  If we adopt this
> > > alternative, we should
> > > >
> > > >include additional text so that implements expect
> > > application-specific
> > > >(perhaps several application-specific path discovery policy
> > > if there are
> > > >
> > > >multiple roles in the application).
> > > >
> > > >Russ
> > >



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35E4hZ15495 for ietf-pkix-bks; Fri, 5 Apr 2002 06:04:43 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35E4em15491 for <[e-mail]>; Fri, 5 Apr 2002 06:04:41 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g35E4ab17047 for <[e-mail]>; Fri, 5 Apr 2002 15:04:36 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Fri, 5 Apr 2002 14:59:16 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id PAA01965; Fri, 5 Apr 2002 15:04:33 +0100
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 15:04:35 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]> <[e-mail]>
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>

Denis,

Denis Pinkas wrote:
> 
> Steve,
> 
> > *If* relaying support/capability is to be considered as a
> > MUST/SHOULD/MAY requirement for a DPV protocol, then should
> > re-direction be handled similarly? (Note: I'm not proposing
> > that it should be, just asking!)
> >
> > By re-direction I mean:
> >
> > Alice: Hey Bob - is this key good?
> > Robert: Dunno Alice - but Charlie might know.
> > Alice: Hey Charles - is this key good?
> > Chaz: Yep.
> 
> This is not relaying, but referral. 

Depends whether you're of DAP or HTTP vintage I guess:-)

> Referral is not supported.

That is one possible answer and may well be the concensus, I guess
we'll see. 

In any case, re-direct/referral would only be an issue depending
on what happens with relaying is my guess.

Stephen.

> 
> Denis
> 
> > Stephen.
> >
> > Tim Polk wrote:
> > >
> > > Peter Sylvester has stated a requirement for DPV servers to relay requests
> > > to one another:
> > >
> > >  >
> > >  >There is a requirement, similar as for OCSP caches,
> > >  >that server just relays a request to another. This had been
> > >  >discussed several times, the differences had only been to
> > >  >what degree the relaying should become visible; whether one
> > >  >server can rewrite/resigns the answers of another etc.
> > >  >Relaying via cache is an obvious feature in many OCSP implementation,
> > >  >how do they protect itself against loops between two servers?
> > >  >
> > >
> > > I believe this is an open issue, and would like to start a new discussion
> > > thread limited to this topic.
> > >
> > > As I understand Peter's scenario, there are three mutually trusting DPV
> > > servers.  If a server cannot satisfy a request directly, it may relay the
> > > request to a different server.  We'll assume the server is smart enough not
> > > to relay a request back to the requester.  (That is, if server A relays a
> > > request to Server B, B may relay it to Server C but not A.)
> > >
> > > (1) Assume Alice requests a valid path for Bob's certificate from Server A,
> > > when none exists.
> > > (2) Server A relays the request to Server B, since it cannot satisfy it
> > > directly. (A could have chosen Server C; it is irrelevant.)
> > > (3) Server B relays the request to Server C, since it cannot satisfy it
> > > directly.  (C could not choose A, since it was the requester.)
> > > (4) Server C relays the request to Server A, since it cannot satisfy it
> > > directly.  (A could not choose B, since it was the requester.)
> > >
> > > At this point, either A must maintain state and recognize that the request
> > > has cycled around or the protocol has to handle this by maintaining a
> > > history list.
> > >
> > > Peter, please confirm that I have characterized the problem correctly (or
> > > post the right scenario)!  I am not personally convinced that blind
> > > relaying amongst DPV servers is a requirement.
> > >
> > > IMHO, DPV relaying would be limited to the scenario where each Server was
> > > authoritative for a particular community (perhaps based on privately held
> > > status information).  Alice directs all requests to Server A to simplify
> > > her life.  Server A would be able to determine which server (B or C) could
> > > possibly satisfy the request based on Bob's certificate.
> > >
> > > Even though relaying occurred, Server A acted as a simple DPV client,
> > > imposing no additional requirements...
> > >
> > > Thanks,
> > >
> > > Tim Polk
> >
> > --
> > ____________________________________________________________
> > Stephen Farrell
> > Baltimore Technologies,   tel: (direct line) [phone]
> > 39 Parkgate Street,                     fax: [phone]
> > Dublin 8.                mailto:[e-mail]
> > Ireland                             http://www.baltimore.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35DXLK11941 for ietf-pkix-bks; Fri, 5 Apr 2002 05:33:21 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35DXJm11937 for <[e-mail]>; Fri, 5 Apr 2002 05:33:20 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA12680; Fri, 5 Apr 2002 15:35:48 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040515324718:215 ; Fri, 5 Apr 2002 15:32:47 +0200 
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 15:32:38 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 15:32:47, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 15:33:18, Serialize complete at 05/04/2002 15:33:18
Content-Transfer-Encoding: 7bit
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>

Steve,

> *If* relaying support/capability is to be considered as a
> MUST/SHOULD/MAY requirement for a DPV protocol, then should
> re-direction be handled similarly? (Note: I'm not proposing
> that it should be, just asking!)
> 
> By re-direction I mean:
> 
> Alice: Hey Bob - is this key good?
> Robert: Dunno Alice - but Charlie might know.
> Alice: Hey Charles - is this key good?
> Chaz: Yep.

This is not relaying, but referral. The issue was about relaying, 
not referral. Referral is not supported. 

Denis
 
> Stephen.
> 
> Tim Polk wrote:
> >
> > Peter Sylvester has stated a requirement for DPV servers to relay requests
> > to one another:
> >
> >  >
> >  >There is a requirement, similar as for OCSP caches,
> >  >that server just relays a request to another. This had been
> >  >discussed several times, the differences had only been to
> >  >what degree the relaying should become visible; whether one
> >  >server can rewrite/resigns the answers of another etc.
> >  >Relaying via cache is an obvious feature in many OCSP implementation,
> >  >how do they protect itself against loops between two servers?
> >  >
> >
> > I believe this is an open issue, and would like to start a new discussion
> > thread limited to this topic.
> >
> > As I understand Peter's scenario, there are three mutually trusting DPV
> > servers.  If a server cannot satisfy a request directly, it may relay the
> > request to a different server.  We'll assume the server is smart enough not
> > to relay a request back to the requester.  (That is, if server A relays a
> > request to Server B, B may relay it to Server C but not A.)
> >
> > (1) Assume Alice requests a valid path for Bob's certificate from Server A,
> > when none exists.
> > (2) Server A relays the request to Server B, since it cannot satisfy it
> > directly. (A could have chosen Server C; it is irrelevant.)
> > (3) Server B relays the request to Server C, since it cannot satisfy it
> > directly.  (C could not choose A, since it was the requester.)
> > (4) Server C relays the request to Server A, since it cannot satisfy it
> > directly.  (A could not choose B, since it was the requester.)
> >
> > At this point, either A must maintain state and recognize that the request
> > has cycled around or the protocol has to handle this by maintaining a
> > history list.
> >
> > Peter, please confirm that I have characterized the problem correctly (or
> > post the right scenario)!  I am not personally convinced that blind
> > relaying amongst DPV servers is a requirement.
> >
> > IMHO, DPV relaying would be limited to the scenario where each Server was
> > authoritative for a particular community (perhaps based on privately held
> > status information).  Alice directs all requests to Server A to simplify
> > her life.  Server A would be able to determine which server (B or C) could
> > possibly satisfy the request based on Bob's certificate.
> >
> > Even though relaying occurred, Server A acted as a simple DPV client,
> > imposing no additional requirements...
> >
> > Thanks,
> >
> > Tim Polk
> 
> --
> ____________________________________________________________
> Stephen Farrell
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35DLDf11660 for ietf-pkix-bks; Fri, 5 Apr 2002 05:21:13 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35DLAm11654 for <[e-mail]>; Fri, 5 Apr 2002 05:21:11 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g35DLAb15914 for <[e-mail]>; Fri, 5 Apr 2002 14:21:10 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Fri, 5 Apr 2002 14:15:50 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA01188; Fri, 5 Apr 2002 14:21:07 +0100
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 14:21:09 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: Open issue: DPV relay
References: <[e-mail]>
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>

*If* relaying support/capability is to be considered as a 
MUST/SHOULD/MAY requirement for a DPV protocol, then should 
re-direction be handled similarly? (Note: I'm not proposing 
that it should be, just asking!)

By re-direction I mean:

Alice: Hey Bob - is this key good?
Robert: Dunno Alice - but Charlie might know.
Alice: Hey Charles - is this key good?
Chaz: Yep.

Stephen.

Tim Polk wrote:
> 
> Peter Sylvester has stated a requirement for DPV servers to relay requests
> to one another:
> 
>  >
>  >There is a requirement, similar as for OCSP caches,
>  >that server just relays a request to another. This had been
>  >discussed several times, the differences had only been to
>  >what degree the relaying should become visible; whether one
>  >server can rewrite/resigns the answers of another etc.
>  >Relaying via cache is an obvious feature in many OCSP implementation,
>  >how do they protect itself against loops between two servers?
>  >
> 
> I believe this is an open issue, and would like to start a new discussion
> thread limited to this topic.
> 
> As I understand Peter's scenario, there are three mutually trusting DPV
> servers.  If a server cannot satisfy a request directly, it may relay the
> request to a different server.  We'll assume the server is smart enough not
> to relay a request back to the requester.  (That is, if server A relays a
> request to Server B, B may relay it to Server C but not A.)
> 
> (1) Assume Alice requests a valid path for Bob's certificate from Server A,
> when none exists.
> (2) Server A relays the request to Server B, since it cannot satisfy it
> directly. (A could have chosen Server C; it is irrelevant.)
> (3) Server B relays the request to Server C, since it cannot satisfy it
> directly.  (C could not choose A, since it was the requester.)
> (4) Server C relays the request to Server A, since it cannot satisfy it
> directly.  (A could not choose B, since it was the requester.)
> 
> At this point, either A must maintain state and recognize that the request
> has cycled around or the protocol has to handle this by maintaining a
> history list.
> 
> Peter, please confirm that I have characterized the problem correctly (or
> post the right scenario)!  I am not personally convinced that blind
> relaying amongst DPV servers is a requirement.
> 
> IMHO, DPV relaying would be limited to the scenario where each Server was
> authoritative for a particular community (perhaps based on privately held
> status information).  Alice directs all requests to Server A to simplify
> her life.  Server A would be able to determine which server (B or C) could
> possibly satisfy the request based on Bob's certificate.
> 
> Even though relaying occurred, Server A acted as a simple DPV client,
> imposing no additional requirements...
> 
> Thanks,
> 
> Tim Polk

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35DJBd11608 for ietf-pkix-bks; Fri, 5 Apr 2002 05:19:11 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35DJ9m11603 for <[e-mail]>; Fri, 5 Apr 2002 05:19:09 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <225VAPKC>; Fri, 5 Apr 2002 08:18:55 -0500
Message-ID: <[e-mail]>
From: Tim Moses <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'Tim Polk'" <[e-mail]>, [e-mail]
Cc: Peter Sylvester <[e-mail]>
Subject: RE: Open issue: DPV relay
Date: Fri, 5 Apr 2002 08:18:54 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DCA4.6F83F230"
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_01C1DCA4.6F83F230
Content-Type: text/plain;
	charset="iso-8859-1"

Colleagues - For the sake of generality, I prefer that the protocol be
designed to handle paths of arbitrary length, rather than being "hard-wired"
to a length of two.  As Tim points out, this can be achieved quite easily by
allowing a "trace" field in the request.  All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: [phone]


-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, April 04, 2002 8:44 PM
To: 'Tim Polk'; [e-mail]
Cc: Peter Sylvester
Subject: RE: Open issue: DPV relay




Tim,
    I agree on this - DPV relaying should be supported. I don't
think it imposes any additional requirements on the protocol.
You wouldn't normally get into loops unless a server were pretty
badly misconfigured.

In general, the way most OCSP servers work is that they respond
for a set of CAs. For others, they either go to a URL specified
by the client application or one configured in the server itself.

It is possible to set up loops that can have server A ask B who asks
A, but I haven't seen this happen practically.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Tim Polk [mailto:[e-mail]]
> Sent: Thursday, April 04, 2002 3:11 PM
> To: [e-mail]
> Cc: Peter Sylvester
> Subject: Open issue: DPV relay
> 
> 
> 
> Peter Sylvester has stated a requirement for DPV servers to 
> relay requests 
> to one another:
> 
>  >
>  >There is a requirement, similar as for OCSP caches,
>  >that server just relays a request to another. This had been
>  >discussed several times, the differences had only been to
>  >what degree the relaying should become visible; whether one
>  >server can rewrite/resigns the answers of another etc.
>  >Relaying via cache is an obvious feature in many OCSP 
> implementation,
>  >how do they protect itself against loops between two servers?
>  >
> 
> I believe this is an open issue, and would like to start a 
> new discussion 
> thread limited to this topic.
> 
> As I understand Peter's scenario, there are three mutually 
> trusting DPV 
> servers.  If a server cannot satisfy a request directly, it 
> may relay the 
> request to a different server.  We'll assume the server is 
> smart enough not 
> to relay a request back to the requester.  (That is, if 
> server A relays a 
> request to Server B, B may relay it to Server C but not A.)
> 
> (1) Assume Alice requests a valid path for Bob's certificate 
> from Server A, 
> when none exists.
> (2) Server A relays the request to Server B, since it cannot 
> satisfy it 
> directly. (A could have chosen Server C; it is irrelevant.)
> (3) Server B relays the request to Server C, since it cannot 
> satisfy it 
> directly.  (C could not choose A, since it was the requester.)
> (4) Server C relays the request to Server A, since it cannot 
> satisfy it 
> directly.  (A could not choose B, since it was the requester.)
> 
> At this point, either A must maintain state and recognize 
> that the request 
> has cycled around or the protocol has to handle this by maintaining a 
> history list.
> 
> Peter, please confirm that I have characterized the problem 
> correctly (or 
> post the right scenario)!  I am not personally convinced that blind 
> relaying amongst DPV servers is a requirement.
> 
> IMHO, DPV relaying would be limited to the scenario where 
> each Server was 
> authoritative for a particular community (perhaps based on 
> privately held 
> status information).  Alice directs all requests to Server A 
> to simplify 
> her life.  Server A would be able to determine which server 
> (B or C) could 
> possibly satisfy the request based on Bob's certificate.
> 
> Even though relaying occurred, Server A acted as a simple DPV client, 
> imposing no additional requirements...
> 
> Thanks,
> 
> Tim Polk
> 

------_=_NextPart_001_01C1DCA4.6F83F230
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Open issue: DPV relay</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Colleagues - For the sake of generality, I prefer =
that the protocol be designed to handle paths of arbitrary length, =
rather than being &quot;hard-wired&quot; to a length of two.&nbsp; As =
Tim points out, this can be achieved quite easily by allowing a =
&quot;trace&quot; field in the request.&nbsp; All the best.&nbsp; =
Tim.</FONT></P>

<P><FONT SIZE=3D2>-----------------------------------------</FONT>
<BR><FONT SIZE=3D2>Tim Moses</FONT>
<BR><FONT SIZE=3D2>Tel: [phone]</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ambarish Malpani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, April 04, 2002 8:44 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Tim Polk'; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Cc: Peter Sylvester</FONT>
<BR><FONT SIZE=3D2>Subject: RE: Open issue: DPV relay</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Tim,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; I agree on this - DPV relaying =
should be supported. I don't</FONT>
<BR><FONT SIZE=3D2>think it imposes any additional requirements on the =
protocol.</FONT>
<BR><FONT SIZE=3D2>You wouldn't normally get into loops unless a server =
were pretty</FONT>
<BR><FONT SIZE=3D2>badly misconfigured.</FONT>
</P>

<P><FONT SIZE=3D2>In general, the way most OCSP servers work is that =
they respond</FONT>
<BR><FONT SIZE=3D2>for a set of CAs. For others, they either go to a =
URL specified</FONT>
<BR><FONT SIZE=3D2>by the client application or one configured in the =
server itself.</FONT>
</P>

<P><FONT SIZE=3D2>It is possible to set up loops that can have server A =
ask B who asks</FONT>
<BR><FONT SIZE=3D2>A, but I haven't seen this happen =
practically.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Ambarish</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
------</FONT>
<BR><FONT SIZE=3D2>Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>Chief =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>1215 Terra Bella =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>Mountain View, CA 94043</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Tim Polk [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, April 04, 2002 3:11 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: Peter Sylvester</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Open issue: DPV relay</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Peter Sylvester has stated a requirement for =
DPV servers to </FONT>
<BR><FONT SIZE=3D2>&gt; relay requests </FONT>
<BR><FONT SIZE=3D2>&gt; to one another:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;There is a requirement, similar as =
for OCSP caches,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;that server just relays a request to =
another. This had been</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;discussed several times, the =
differences had only been to</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;what degree the relaying should =
become visible; whether one</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;server can rewrite/resigns the =
answers of another etc.</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;Relaying via cache is an obvious =
feature in many OCSP </FONT>
<BR><FONT SIZE=3D2>&gt; implementation,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;how do they protect itself against =
loops between two servers?</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I believe this is an open issue, and would like =
to start a </FONT>
<BR><FONT SIZE=3D2>&gt; new discussion </FONT>
<BR><FONT SIZE=3D2>&gt; thread limited to this topic.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; As I understand Peter's scenario, there are =
three mutually </FONT>
<BR><FONT SIZE=3D2>&gt; trusting DPV </FONT>
<BR><FONT SIZE=3D2>&gt; servers.&nbsp; If a server cannot satisfy a =
request directly, it </FONT>
<BR><FONT SIZE=3D2>&gt; may relay the </FONT>
<BR><FONT SIZE=3D2>&gt; request to a different server.&nbsp; We'll =
assume the server is </FONT>
<BR><FONT SIZE=3D2>&gt; smart enough not </FONT>
<BR><FONT SIZE=3D2>&gt; to relay a request back to the requester.&nbsp; =
(That is, if </FONT>
<BR><FONT SIZE=3D2>&gt; server A relays a </FONT>
<BR><FONT SIZE=3D2>&gt; request to Server B, B may relay it to Server C =
but not A.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; (1) Assume Alice requests a valid path for =
Bob's certificate </FONT>
<BR><FONT SIZE=3D2>&gt; from Server A, </FONT>
<BR><FONT SIZE=3D2>&gt; when none exists.</FONT>
<BR><FONT SIZE=3D2>&gt; (2) Server A relays the request to Server B, =
since it cannot </FONT>
<BR><FONT SIZE=3D2>&gt; satisfy it </FONT>
<BR><FONT SIZE=3D2>&gt; directly. (A could have chosen Server C; it is =
irrelevant.)</FONT>
<BR><FONT SIZE=3D2>&gt; (3) Server B relays the request to Server C, =
since it cannot </FONT>
<BR><FONT SIZE=3D2>&gt; satisfy it </FONT>
<BR><FONT SIZE=3D2>&gt; directly.&nbsp; (C could not choose A, since it =
was the requester.)</FONT>
<BR><FONT SIZE=3D2>&gt; (4) Server C relays the request to Server A, =
since it cannot </FONT>
<BR><FONT SIZE=3D2>&gt; satisfy it </FONT>
<BR><FONT SIZE=3D2>&gt; directly.&nbsp; (A could not choose B, since it =
was the requester.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; At this point, either A must maintain state and =
recognize </FONT>
<BR><FONT SIZE=3D2>&gt; that the request </FONT>
<BR><FONT SIZE=3D2>&gt; has cycled around or the protocol has to handle =
this by maintaining a </FONT>
<BR><FONT SIZE=3D2>&gt; history list.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Peter, please confirm that I have characterized =
the problem </FONT>
<BR><FONT SIZE=3D2>&gt; correctly (or </FONT>
<BR><FONT SIZE=3D2>&gt; post the right scenario)!&nbsp; I am not =
personally convinced that blind </FONT>
<BR><FONT SIZE=3D2>&gt; relaying amongst DPV servers is a =
requirement.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; IMHO, DPV relaying would be limited to the =
scenario where </FONT>
<BR><FONT SIZE=3D2>&gt; each Server was </FONT>
<BR><FONT SIZE=3D2>&gt; authoritative for a particular community =
(perhaps based on </FONT>
<BR><FONT SIZE=3D2>&gt; privately held </FONT>
<BR><FONT SIZE=3D2>&gt; status information).&nbsp; Alice directs all =
requests to Server A </FONT>
<BR><FONT SIZE=3D2>&gt; to simplify </FONT>
<BR><FONT SIZE=3D2>&gt; her life.&nbsp; Server A would be able to =
determine which server </FONT>
<BR><FONT SIZE=3D2>&gt; (B or C) could </FONT>
<BR><FONT SIZE=3D2>&gt; possibly satisfy the request based on Bob's =
certificate.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Even though relaying occurred, Server A acted =
as a simple DPV client, </FONT>
<BR><FONT SIZE=3D2>&gt; imposing no additional requirements...</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thanks,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Tim Polk</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1DCA4.6F83F230--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35D2lp11300 for ietf-pkix-bks; Fri, 5 Apr 2002 05:02:47 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35D2jm11296 for <[e-mail]>; Fri, 5 Apr 2002 05:02:45 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA26098; Fri, 5 Apr 2002 15:05:14 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040515022123:209 ; Fri, 5 Apr 2002 15:02:21 +0200 
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 15:02:16 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tim Polk <[e-mail]>
CC: [e-mail]
Subject: Re: Summary:open issues for draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 15:02:21, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 15:02:43, Serialize complete at 05/04/2002 15:02:43
Content-Transfer-Encoding: 7bit
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>

Tim,

> Folks,
> 
> I think the discussion is converging here, and thought a summary was in
> order.
> 
> There are a number of issues that were raised on the list and have
> demonstrated consensus on the list.  (I will not enumerate them.)
> Proposed text has been submitted to the list and I sense general
> satisfaction with that text.
> 
> However, there are two open issues that must be resolved before we forward
> the document to the Area Directors.
 
> Open Issue #1
 
> The first issue involves "DPV relay".  Peter Sylvester has stated a
> requirement for DPV servers to relay requests to one another:
 
> >There is a requirement, similar as for OCSP caches,
> >that server just relays a request to another. This had been
> >discussed several times, the differences had only been to
> >what degree the relaying should become visible; whether one
> >server can rewrite/resigns the answers of another etc.
> >Relaying via cache is an obvious feature in many OCSP implementation,
> >how do they protect itself against loops between two servers?
 
> I understand this issue remains open.

The proposed resolution to close this issue is the following:

  " In case a DPV server chooses to relay the request to another server 
  using the same protocol, a method to detect loops MUST be supported 
  by that relaying server."

 
> Open Issue #2
 
> The second issue is conformance requirements for multiple paths in the DPD
> service.  As I read it, the current draft requires support for multiple
> paths at the server, but not the client.  The client may request a maximum
> number of paths N; if the request does not specify N, it defaults to one.
> The DPD server includes zero, one, or up to N paths in a response.  If the
> number of paths is less than N, this indicates that the server could not
> find as many paths as the client requested.
 
> Since the DPD process is performed with respect to a policy, just as in
> DPV, 

Not exactly. A validation policy does not equate a path discovery policy. A
validation policy shall be set to return a path that meets all the criteria
from the requester since one and only path valid path is returned. A path
discovery policy may be much more simple and, for example, only specify one
trust anchor and say that all CRLs that may be found should be returned. So
in that case, many certification paths could be returned and the client will
locally apply additional criteria.

> it has been suggested that a DPD server could be designed to always
> return a single path.  

The suggestion has been made, but this does not work. See the argument
above.

> If the specified policy matches the path validation
> process performed at the client (e.g., same certificate policies and same
> trust anchor) the client should be able to use that path.
 
> However, this could result in an ambiguity.  How does the DPD client that
> requested three paths tell the difference between the following answers:
>         "I gave you one path because it is the only one that exists"
>      and
>         "I gave you one path 'cause that's the way I was designed"
> 
> In the case where the single path failed, a client may need to know the
> difference!

This problem would exist *if* the suggestion that a DPD server could be
designed to always return a single path was valid, but it is not. No change 
to the current wording of the document is needed.

I hope we can close this issue too.

Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35CpQ911055 for ietf-pkix-bks; Fri, 5 Apr 2002 04:51:26 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35CpOm11051 for <[e-mail]>; Fri, 5 Apr 2002 04:51:24 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA20988; Fri, 5 Apr 2002 14:53:39 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040514505421:207 ; Fri, 5 Apr 2002 14:50:54 +0200 
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 14:50:50 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'Housley, Russ'" <[e-mail]>, Santosh Chokhani <[e-mail]>, [e-mail]
Subject: Re: One last comment on DPD requirements
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 14:50:54, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 14:51:09, Serialize complete at 05/04/2002 14:51:09
Content-Transfer-Encoding: 7bit
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>

Ambarish,

> Russ,

>     A minor nit - a DPD server might also be a DPV server, who
> a client is not willing to trust (and whose work the client wants
> to verify for itself).

This is not a minor nit. A DPV server is always trusted by the client, while
a DPD server does not need to be trusted.  A DPV server is not necessarily
trusted by *other* clients. So the case of an untrusted DPV server, as
mentionned, does not exist. 

Denis

 
> To summarize, what I think what I hear you, Santosh and Steve say
> is that it might make sense to require a DPD server to return a
> single path back, but if we want to enable that, we need to let
> the client specify his requirements more precisely. Is that
> correct?
> 
> It would make sense to show (in the protocol doc), what those
> requirements are for protocols like S/MIME, TLS, IPSec and let
> other protocols define their own requirements if they can't
> fit into one of the three above.
> 
> Does that make sense to you? What about others on the list?
> 
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Chief Architect                                          650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043
> 
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> > Sent: Thursday, April 04, 2002 7:00 AM
> > To: Santosh Chokhani
> > Cc: [e-mail]
> > Subject: RE: One last comment on DPD requirements
> >
> >
> >
> > Santosh:
> >
> > I think that a DPD server will likely perform path
> > validation.  Clients
> > will not be happy if the paths that they are given are often
> > invalid.  Clearly, the DPD server cannot know all of the
> > parameters that
> > the client will use for path validation (otherwise it would be a DPV
> > server), but it can make some very reasonable assumptions to
> > ensure that
> > grossly invalid paths are not returned.
> >
> > Russ
> >
> > At 08:20 PM 4/3/2002 -0500, Santosh Chokhani wrote:
> > >Russ:
> > >
> > >I agree with you, but for a different reason.  I do not think this is
> > >application specific issue.  I think it is the path
> > validation issue.  I
> > >do not think that the DPD server can know which paths are
> > good without
> > >doing a validation also, specially to see if there will be any name
> > >constraints or certificate policy related failures.
> > >
> > >-----Original Message-----
> > >From: [e-mail]
> > [mailto:[e-mail]]
> > >On Behalf Of Housley, Russ
> > >Sent: Wednesday, April 03, 2002 2:12 PM
> > >To: Ambarish Malpani; Stephen Kent
> > >Cc: [e-mail]
> > >Subject: Re: One last comment on DPD requirements
> > >
> > >
> > >
> > >Steve & Ambarish:
> > >
> > > >>Hi Group,
> > > >>     One last (slightly late) comment on the DPD
> > requirements that has
> > >
> > > >>been troubling me:
> > > >>
> > > >>In the DPD requirements, there is a reasonable amount of text that
> > > >>talks about how a server can return multiple paths back
> > to the client
> > > >>(to allow the client to decide which path is the best).
> > > >>
> > > >>The main goal of DPD is to try and simplify the client.
> > In how many
> > > >>cases do people really want multiple paths back from the
> > server. While
> > >
> > > >>it is the right requirement in principal, do folks really think
> > > >>clients will want multiple paths back from a DPD server?
> > Are we adding
> > >
> > > >>the additional flexiblity/complexity just for technical purity?
> > > >>
> > > >>Comments will be appreciated.
> > > >>
> > > >>Regards,
> > > >>Ambarish
> > > >
> > > >I too would favor simplifying the protocol requirement
> > here. Some folks
> > > >have suggested motivations for multiple paths, but this
> > does seem to
> > > >conflict with the fundamental goal of creating a protocol
> > to satisfy
> > >the
> > > >needs of thin clients.
> > > >
> > > >Steve
> > >
> > >I agree with your goal.  It is far better for the client to tell the
> > >server
> > >what it wants, then get back a single path that satisfies all of the
> > >requirements.  To do this, we need to be able to fully specify the
> > >clients
> > >criteria and send them to the server.  I think that we know how to do
> > >this
> > >for many PKI-enabled applications, but I am not sure that we
> > know how to
> > >do
> > >it for all applications, especially ones that are yet to be
> > developed.
> > >
> > >This leaves us with two choices.  Either the protocol
> > returns multiple
> > >certification paths (the approach in the current document) or the
> > >protocol
> > >requires the client to adequately specify its criteria.
> > This could be
> > >done
> > >with the path discovery policy.  If we adopt this
> > alternative, we should
> > >
> > >include additional text so that implements expect
> > application-specific
> > >(perhaps several application-specific path discovery policy
> > if there are
> > >
> > >multiple roles in the application).
> > >
> > >Russ
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35Cj1g10768 for ietf-pkix-bks; Fri, 5 Apr 2002 04:45:01 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35Cj0m10757 for <[e-mail]>; Fri, 5 Apr 2002 04:45:00 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA20958; Fri, 5 Apr 2002 14:47:26 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040514444595:206 ; Fri, 5 Apr 2002 14:44:45 +0200 
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 14:44:42 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>, Ambarish Malpani <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 14:44:46, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 14:44:55, Serialize complete at 05/04/2002 14:44:55
Content-Transfer-Encoding: 7bit
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>

> Ambarish:
 
> I am fine with this.

.. but I am not.
 
> Russ
> 
> At 11:35 AM 4/4/2002 -0800, Ambarish Malpani wrote:
> 
> >Denis, Russ,
> >     I agree with the first phrase:
> >
> > > "The protocol MUST prevent replay attacks, and the replay prevention
> > > mechanism employed by the protocol MUST NOT rely on clocks being
> > > synchronized with UTC."

> >I don't agree with the requirement that a response needs to
> >contain all the information from the query in itself. That could
> >result in a lot of extra information that needs to be carried in
> >the response over what might be a bandwidth constrained channel.

The proposal does not mandate this. The proposal from Russ (and I fully
agree with his proposal) is:

"The DPV client MUST be able to confirm that the DPV server-generated
response was constructed from the client's request.  When the
response indicates certificate validity, the response MUST allow the
DPV client to readily confirm that the response was made for the requested
certificate and for the requested validation policy, including associated
parameters, if any."

The first sentence is easily met using a hash from the request. Hence the
response does not need to contain all the information from the query.

> >In all cases, being able to tie the response to the request does
> >the job. If a client needs to be able to show that this response
> >was for a particular certificate, it can retain the original
> >request. 

This is exactly what is *not* desirable for thin clients, because the
argument you raised would then apply: this would result in a lot of extra
information that needs to be kept by the thin client.

> If the client doesn't need to be able to prove that, it
> >can discard the request after it gets the response. I don't see
> >why the response needs to contain
> >      "the requested validation policy, including associated
> >       parameters, if any."

Exactly for the reason that it is not desirable to keep the whole request, 
e.g. when it is needed to prove two years later that you got a valid
response. 

Hence the reason to maintain the second sentence:

"When the response indicates certificate validity, the response MUST allow 
the DPV client to readily confirm that the response was made for the
requested certificate and for the requested validation policy, including
associated parameters, if any."

Denis


> >I would prefer the second statement to read:
> >
> >The DPV client MUST be able to confirm that the DPV server-generated
> >response was constructed for the client's request.
> >
> >(NOTE: I changed Russ's "from" to "for")
> >
> >A
> >
> >
> >
> >
> >---------------------------------------------------------------------
> >Ambarish Malpani
> >Chief Architect                                          650.567.5457
> >ValiCert, Inc.                                  [e-mail]
> >1215 Terra Bella Ave.                         http://www.valicert.com
> >Mountain View, CA 94043
> >
> >
> > > -----Original Message-----
> > > From: Housley, Russ [mailto:[e-mail]]
> > > Sent: Thursday, April 04, 2002 8:21 AM
> > > To: Denis Pinkas
> > > Cc: [e-mail]; [e-mail]
> > > Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
> > >
> > >
> > > Denis:
> > >
> > > I prefer the following wording.  I think it provides the same
> > > end result.
> > >
> > > "The protocol MUST prevent replay attacks, and the replay prevention
> > > mechanism employed by the protocol MUST NOT rely on clocks being
> > > synchronized with UTC."
> > >
> > > (...)
> > >
> > > The DPV client MUST be able to confirm that the DPV server-generated
> > > response was constructed from the client's request.  When the
> > > response
> > > indicates certificate validity, the response MUST allow the
> > > DPV client to
> > > readily confirm that the response was made for the requested
> > > certificate
> > > and for the requested validation policy, including associated
> > > parameters,
> > > if any."
> > >
> > > Russ
> > >
> > >
> > > At 03:30 PM 4/4/2002 +0200, Denis Pinkas wrote:
> > > >"The protocol MUST prevent replay attacks, including for the
> > > case where
> > > >the client does not have a clock synchronized with UTC.
> > > >
> > > >(...)
> > > >
> > > >The requester MUST be able to verify that the response was
> > > constructed
> > > >taking into consideration all the parameters from the
> > > request. In addition,
> > > >without the need to store the request, a requester SHALL be
> > > able to prove
> > > >that a valid DPV response was made for a given certificate
> > > and for a given
> > > >validation policy, including associated parameters, if any."
> > >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35CcL610368 for ietf-pkix-bks; Fri, 5 Apr 2002 04:38:21 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35CcJm10363 for <[e-mail]>; Fri, 5 Apr 2002 04:38:19 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA06706; Fri, 5 Apr 2002 14:40:42 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040514380521:204 ; Fri, 5 Apr 2002 14:38:05 +0200 
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 14:38:01 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: Ambarish Malpani <[e-mail]>, [e-mail]
Subject: Re: One last comment on DPD requirements
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 14:38:05, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 14:38:12, Serialize complete at 05/04/2002 14:38:12
Content-Transfer-Encoding: 7bit
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>

Russ,

> Ambarish:
> 
> Tim Polk and I just discussed this on the phone.  I will share my
> conclusion form the conversation (which might be different than Tim's
> conclusion).  I think that we need to allow for multiple certificates to be
> returned, but the default should be to return just one.  If the client
> wants more than one, it needs to explicitly request them (up to a maximum
> number).  

I fully agree.

> If the server does not support returning extra certificates, then

Hum ... I guess, this is not what you mean. A DPD server returns
certification paths, not certificates. 

> it should just return one, but it should include a status code that says,
> "I do not support the option you requested, but I thought that I should
> give you one just in case it meets your needs."

I have problems with that complicated meaning. All returned paths must meet
the criteria set by the path discovery policy. Paths that do not meet the
criteria are not returned. Such a (complicated) status is not needed.

Denis
 
> Russ
> 
> At 11:11 AM 4/4/2002 -0800, Ambarish Malpani wrote:
> 
> >Russ,
> >     A minor nit - a DPD server might also be a DPV server, who
> >a client is not willing to trust (and whose work the client wants
> >to verify for itself).
> >
> >To summarize, what I think what I hear you, Santosh and Steve say
> >is that it might make sense to require a DPD server to return a
> >single path back, but if we want to enable that, we need to let
> >the client specify his requirements more precisely. Is that
> >correct?
> >
> >It would make sense to show (in the protocol doc), what those
> >requirements are for protocols like S/MIME, TLS, IPSec and let
> >other protocols define their own requirements if they can't
> >fit into one of the three above.
> >
> >Does that make sense to you? What about others on the list?
> >
> >Regards,
> >Ambarish
> >
> >
> >
> >---------------------------------------------------------------------
> >Ambarish Malpani
> >Chief Architect                                          650.567.5457
> >ValiCert, Inc.                                  [e-mail]
> >1215 Terra Bella Ave.                         http://www.valicert.com
> >Mountain View, CA 94043
> >
> >
> > > -----Original Message-----
> > > From: Housley, Russ [mailto:[e-mail]]
> > > Sent: Thursday, April 04, 2002 7:00 AM
> > > To: Santosh Chokhani
> > > Cc: [e-mail]
> > > Subject: RE: One last comment on DPD requirements
> > >
> > >
> > >
> > > Santosh:
> > >
> > > I think that a DPD server will likely perform path
> > > validation.  Clients
> > > will not be happy if the paths that they are given are often
> > > invalid.  Clearly, the DPD server cannot know all of the
> > > parameters that
> > > the client will use for path validation (otherwise it would be a DPV
> > > server), but it can make some very reasonable assumptions to
> > > ensure that
> > > grossly invalid paths are not returned.
> > >
> > > Russ
> > >
> > > At 08:20 PM 4/3/2002 -0500, Santosh Chokhani wrote:
> > > >Russ:
> > > >
> > > >I agree with you, but for a different reason.  I do not think this is
> > > >application specific issue.  I think it is the path
> > > validation issue.  I
> > > >do not think that the DPD server can know which paths are
> > > good without
> > > >doing a validation also, specially to see if there will be any name
> > > >constraints or certificate policy related failures.
> > > >
> > > >-----Original Message-----
> > > >From: [e-mail]
> > > [mailto:[e-mail]]
> > > >On Behalf Of Housley, Russ
> > > >Sent: Wednesday, April 03, 2002 2:12 PM
> > > >To: Ambarish Malpani; Stephen Kent
> > > >Cc: [e-mail]
> > > >Subject: Re: One last comment on DPD requirements
> > > >
> > > >
> > > >
> > > >Steve & Ambarish:
> > > >
> > > > >>Hi Group,
> > > > >>     One last (slightly late) comment on the DPD
> > > requirements that has
> > > >
> > > > >>been troubling me:
> > > > >>
> > > > >>In the DPD requirements, there is a reasonable amount of text that
> > > > >>talks about how a server can return multiple paths back
> > > to the client
> > > > >>(to allow the client to decide which path is the best).
> > > > >>
> > > > >>The main goal of DPD is to try and simplify the client.
> > > In how many
> > > > >>cases do people really want multiple paths back from the
> > > server. While
> > > >
> > > > >>it is the right requirement in principal, do folks really think
> > > > >>clients will want multiple paths back from a DPD server?
> > > Are we adding
> > > >
> > > > >>the additional flexiblity/complexity just for technical purity?
> > > > >>
> > > > >>Comments will be appreciated.
> > > > >>
> > > > >>Regards,
> > > > >>Ambarish
> > > > >
> > > > >I too would favor simplifying the protocol requirement
> > > here. Some folks
> > > > >have suggested motivations for multiple paths, but this
> > > does seem to
> > > > >conflict with the fundamental goal of creating a protocol
> > > to satisfy
> > > >the
> > > > >needs of thin clients.
> > > > >
> > > > >Steve
> > > >
> > > >I agree with your goal.  It is far better for the client to tell the
> > > >server
> > > >what it wants, then get back a single path that satisfies all of the
> > > >requirements.  To do this, we need to be able to fully specify the
> > > >clients
> > > >criteria and send them to the server.  I think that we know how to do
> > > >this
> > > >for many PKI-enabled applications, but I am not sure that we
> > > know how to
> > > >do
> > > >it for all applications, especially ones that are yet to be
> > > developed.
> > > >
> > > >This leaves us with two choices.  Either the protocol
> > > returns multiple
> > > >certification paths (the approach in the current document) or the
> > > >protocol
> > > >requires the client to adequately specify its criteria.
> > > This could be
> > > >done
> > > >with the path discovery policy.  If we adopt this
> > > alternative, we should
> > > >
> > > >include additional text so that implements expect
> > > application-specific
> > > >(perhaps several application-specific path discovery policy
> > > if there are
> > > >
> > > >multiple roles in the application).
> > > >
> > > >Russ
> > >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35C1xn08506 for ietf-pkix-bks; Fri, 5 Apr 2002 04:01:59 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35C1um08502 for <[e-mail]>; Fri, 5 Apr 2002 04:01:56 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA14636; Fri, 5 Apr 2002 14:01:55 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 5 Apr 2002 14:01:55 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA18628; Fri, 5 Apr 2002 14:01:54 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA04885; Fri, 5 Apr 2002 14:01:54 +0200 (MET DST)
Date: Fri, 5 Apr 2002 14:01:54 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Open issue: DPV relay
Cc: [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>

Thanks Tim for trying to summarize the open points:


Actually there are two open issues concerning 'relaying'.   

*** Issue 1 ***: 

This is about loop detection and control (of blind relaying??)

> 
> At this point, either A must maintain state and recognize that the request 
> has cycled around or the protocol has to handle this by maintaining a 
> history list.

You can already have a loop between two entities. The protocol
is not necessairily symmetric. You may not necessarily know that the
entity you get the request from is the same that you will contact
via an URL etc. 

Yes, and I see a difficulty to maintain state, since the only information
you might count on, is the certificate to be validated, and there could be
two valid requests for the same cert. 
 
> Peter, please confirm that I have characterized the problem correctly (or 
> post the right scenario)!  I am not personally convinced that blind 
> relaying amongst DPV servers is a requirement.
What do you mean by 'blind relaying'?  

> IMHO, DPV relaying would be limited to the scenario where each Server was 
> authoritative for a particular community (perhaps based on privately held 
> status information).  Alice directs all requests to Server A to simplify 
> her life.  Server A would be able to determine which server (B or C) could 
> possibly satisfy the request based on Bob's certificate.
> 
> Even though relaying occurred, Server A acted as a simple DPV client, 
> imposing no additional requirements...
Even if A know that either B or C will finally satisfy a request, A
cannot know whether B or C will try to contact another server etc.
for whatever reason. 

Thus, some mechanisms of state keeping or trace or hop count or 
is needed, statekeeping would require ... left as an exercise
to developpers.

Thanks to Ambarish's message about potential OCSP problems. The
fact that in real life it doesn't happen very often happens ... :-)


I'd propose to add a text somewhere?

  In case a DPV (or DPD) service chooses to relay the request to
  another service, a method to detect and prohibit loops MUST
  be applied. 

 

*** Issue 2 ***:


A DPV server may want to determine the validity status of 
an intermediate CA certificate, (or even obtain responses
from other DPV servers confirming a validity decision).

Another scenario is a company server that validates an
certificate of another company, it asks the other companies
server, and obtains a result.  The server *may* choose to
create its own response withour revealing the response
from the other server (blind relaying?), but it may also 
choose to give the answer back to the client allow to maintain
a proof that the 'other company' has cooperated. 
 
Simular to OCSP responses or CRLs which represent
assertions about the validity of some cert, a DPV response
is also such kind of assertion. 

I see a requirement that a server may want to add 
DPV responses in his response in order to create a complete 
picture of all the assertions he obtained. 

Answers from Denis always seem to indicate that
a DPV response MUST NOT be included in a final response
(since *we* do not support relaying). 

I do not see an essential difference between 
a CRL repository, an OCSP response and a DPV response.
There I propose to add behind  

"...  As an 
example, an S/MIME message might include such information, and the 
client can simply copy that information into the DPV request."

the text:  

DPV responses may use information obtained by other DPV transactions 
performed by the DPV server in order to determine the validity of 
some certificate in the path. The server MUST be able to include 
such response in its own final response. 

Or to replace in the preceding paragraph 'revocation information'
by "'status information' such an revocation information of CRLs
or OCSP but also other DPV responses.".  


*** A little nit-picking:

Would the authors try and avoid characters like "Æ" instead 
of "'" as in DPV serverÆs. 





   
 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g35AcTw01859 for ietf-pkix-bks; Fri, 5 Apr 2002 02:38:29 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g35AcRm01855 for <[e-mail]>; Fri, 5 Apr 2002 02:38:27 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA20362; Fri, 5 Apr 2002 12:40:48 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040512374604:184 ; Fri, 5 Apr 2002 12:37:46 +0200 
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 12:37:45 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: A few comments re: dpv-dpd requirements
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 12:37:46, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 12:38:21, Serialize complete at 05/04/2002 12:38:21
Content-Transfer-Encoding: 7bit
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>

Michael,

> Russ, Denis:
> 
> The state "unknown" is missing in Section 4, "Delegated Path
> Validation Protocol Requirements".  The -03 draft currently
> reads:
> 
> "The DPV response MUST indicate one of the following two status
> alternatives:
> 
> 1) the certificate is valid according to the validation policy.
> 2) the certificate is not valid according to the validation
> policy."
> 
> I think -04 should read:
> 
> "The DPV response MUST indicate one of the following three
> status alternatives:
> 
> 1) the certificate is valid according to the validation policy.
> 2) the certificate is not valid according to the validation
> policy.
> 3) the certificate is unknown to the validation server."

I do not think you really mean this, but rather:

3) the validity of the certificate is unknown according to the 
   validation policy.


Denis

 
> Thus we remain at {valid, invalid, unknown} as primary initial
> states per list-based consensus.  Apologies for digging into
> this, but it has relevance to the design of state machines.
> 
> Mike


Received: by above.proper.com (8.11.6/8.11.3) id g358AYP12403 for ietf-pkix-bks; Fri, 5 Apr 2002 00:10:34 -0800 (PST)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g358AXm12394 for <[e-mail]>; Fri, 5 Apr 2002 00:10:33 -0800 (PST)
Received: from sit.fraunhofer.de (pc-pisa [141.12.37.18]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id KAA19731; Fri, 5 Apr 2002 10:09:46 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 10:10:44 +0200
From: Brian Hunter <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Steve Hanna <[e-mail]>
CC: Denis Pinkas <[e-mail]>, "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

> Actually, trust anchors are *never* part of the path for son-of-2459.
> See section 6.1, which defines the valid path as "a sequence of n
> certificates [that] satisfies the following conditions:

<snip>

> So non-self-signed trust anchors (and self-signed trust anchors)
> should NOT be considered part of the path for the purposes of
> DPD/DPV.
True.  And thanks for correcting my oversight.

Brian


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g357b9p06729 for ietf-pkix-bks; Thu, 4 Apr 2002 23:37:09 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g357b8m06718 for <[e-mail]>; Thu, 4 Apr 2002 23:37:08 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA24192; Fri, 5 Apr 2002 09:35:42 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040509325257:142 ; Fri, 5 Apr 2002 09:32:52 +0200 
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 09:32:51 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "=?iso-8859-1?Q?Jos=E9?= A. =?iso-8859-1?Q?Ma=F1as?=" <[e-mail]>
CC: "hermes3.si.c-s.fr" <[e-mail]>, [e-mail]
Subject: Re: Comment on RFC 3161
References: <EBZWTNRLKXVMH3WE9ZUOKEY3143.3cabe72d@saturne> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 09:32:52, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 05/04/2002 09:33:11, Serialize complete at 05/04/2002 09:33:11
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g357b9m06723
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>

Good catch !

Here is a proposal to fix it and replace the whole 4.1 :

      When the reason code extension indicates keyCompromise then all 
      the tokens that have been signed with the corresponding private 
      key SHALL be considered as invalid.

      When the reason code extension indicates other reasons like 
      affiliationChanged (3) or cessationOfOperation (5), then this 
      reason code is definitive. However, should a key compromise 
      happen later on, it will not be reported by the CA. A good 
      practice will be for the TSA to warn its subscribers in advance 
      for a future revocation, so that they can apply another 
      time-stamp token over the previous one and capture the CRL from 
      the CA that has issued the certificate to the previous time-
      stamping unit.

Denis

Note: ISO is working on an extension that will allow to announce in advance
the revocation of one certificate or a set of certificates. Once this is
done we could consider to support this extension in PKIX.

 
> I think you are right,
> and I think it is a problem with any signature:
> the status of the cert must be ok when the verification is run.
> 
> For the case of time-stamping,
> there is renewal procedure such that an old time-stamp token
> is enveloped within a new token thus extending the value
> of the first token from the original instant to the
> end of the validity of the enveloping token.
> If renewal is applied regularly
> (always before the outmost key is compromised)
> the value may be extended indefinitely.
> 
> Hope it helps,
> jam
> 
> "hermes3.si.c-s.fr" wrote:
> >
> > Hi!
> >
> > I wonder something about the first security considerations of RFC 3161 (§4.1).
> >
> > It says that if the TSA private key shall not be used any more and
> > is not compromised ,
> > the corresponding certificate shall be revoked with a reason code.
> > Thus any token signed with the corresponding key before the revocation time
> > will remain valid.
> >
> > However we could imagine that the key becomes compromised after the
> > revocation, allowing
> > the "hacker" to generate time-stamp tokens with a date previous to
> > the revocation time.
> > Thus false tokens will be consider as valid...
> >
> > The point is how to get the crucial "before" in " ... before the
> > revocation time" .
> >
> > If someone can help ...
> >
> > Antoine Bourrouilh
> 
> --
> -----------------------------------------------------------
> Prof. Jose A. Manas                mailto:[e-mail]
> Dpt. Telematica                http://www.dit.upm.es/~pepe/
> E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
> Ciudad Universitaria                gsm: [+34] 607 73 38 94
> E-28040 Madrid                      gsm: [+34] 609 62 70 98
> SPAIN                               fax: [+34] 91.336 73 33


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g356lV327921 for ietf-pkix-bks; Thu, 4 Apr 2002 22:47:31 -0800 (PST)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g356lTm27915 for <[e-mail]>; Thu, 4 Apr 2002 22:47:29 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g356hUVq333732; Fri, 5 Apr 2002 01:43:30 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g356ks0146078; Fri, 5 Apr 2002 01:46:54 -0500
Importance: Normal
Sensitivity: 
Subject: Re: WG Last Call: Roadmap
To: "todd glassey" <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Fri, 5 Apr 2002 01:46:45 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/05/2002 01:46:54 AM
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>

      Responses below, set off by [Tom] - no initials, for obvious reasons.
I don't actually understand why a self-signed certificate is preferable to
a cross certificate with constraints as a trust anchor in cases where both
exist and refer to the same CA.

            Tom Gindin

"todd glassey" <[e-mail]> on 04/04/2002 12:33:29 PM

To:    "Denis Pinkas" <[e-mail]>, Tom Gindin/Watson/IBM@IBMUS
cc:    <[e-mail]>
Subject:    Re: WG Last Call: Roadmap



----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, April 03, 2002 8:15 AM
Subject: Re: WG Last Call: Roadmap


>
> Tom,
>
> >       I have a few issues with this, and some corrections as well.
>
> >       In comment 12, I have two issues.  The first one, which is minor,
is
> > that  "one or more Top CA's may be trusted" should refer to root CA's
> > instead - the two terms mean the same thing more often than not, but
when
> > they differ the trust point is the root rather than the top.

Perhaps but I would like to point out that the terminology invites
confusion. It should refer to whatever is the trust anchor here.

The key problem with this use is that the indemnetor or guarantor of the
trust may not be the systems operator and so then the "CA's uses only" will
stand for first-person models.

[Tom] Actually, Todd, the main purpose of distinguishing "root" from "Top"
here is to define "root" as equivalent to trust anchor.  Perhaps using
near-synonyms for these terms is a bad idea, but it's surely better than
using the same word for both.

>
> PKIX-1 states:
>
>    " - Top CA - A CA that is at the top of a PKI hierarchy.
>
>    Note: This is often also called a "Root CA," since in data structures
>    terms and in graph theory, the node at the top of a tree is the
>    "root." However, to minimize confusion in this document, we elect to
>    call this node a "Top CA," and reserve "Root CA" for the CA directly
>    trusted by the EE."
>
> The problem lies with the last sentence, i.e. "*the* CA directly trusted
by
> the EE.". The singular is being used which means that there is a single
> one, multiple roots are not permitted, while multiple Top-CAs are
permitted.
>
> >       The second is less minor.  Is it truly intended that a signing EE
> > be permitted to specify the set of trusted CA's for an RP to use in
> > verifying a signature?  At a minimum, an RP in this model is
responsible
> > for validating the the set of rules is identical to one it has already
> > decided to trust, but there is no reference in the model description to
> > any active role for the RP.
>
> A verifier (not a signing EE as you mentioned) does not know what an
anchor
> is, but may know what a policy is. So by selecting the policy that
applies
> to the application, indirectly trust anchors (and much more) are
selected.
> Remember that the same verifier may verify digital signatures in various
> contexts, e.g. for a Bank transaction or for a green reservation in a
Golf
> Club. The trust conditions are not necessarilly identical. Note also that
a
> verifier does not need to be a signer and may not have any certificate of
> its own.
>
> The case of a single (root) CA trusted for any kind of application is a
very
> specific case and cannot be considered as the general case.
>
> >       In your comment 5 (on page 15), replace "date of issue" by "date
and
> > time of issue".
>
> This is fine.
>
> >       At a slightly more substantive level, shouldn't the clarification
of
> > the definition of Top CA on page 4 end "and reserve 'root CA' for a CA
> > directly trusted by the EE."?  This wording permits multiple trusted
roots.
>
> I do not think that PKIX-1 allows for this. See the quote above.
>
> >       In your comment 4, shouldn't "CA certificate" be "hierarchical CA
> > certificate"?  Surely a Top CA's self-signed certificate is also a "CA
> > certificate", and your definition excludes it.  Then the sentence "Some
> > people in the WG believe that a cross certificate is a special kind of
CA
> > certificate." is reversed to "... believe that a hierarchical CA
> > certificate is a special kind of cross certificate".

Here again we might refer to the Trust Anchor for this transaction rather
than the CA itself. There is too much complexity in a free form trust
system
that has no global standards for its use to date.

A better solution would be to use a more general and as such higher level
language about the Anchoring process or otherwise use of the certificates.

[Tom] This particular comment distinguishes types of CA certificates.  We
do go into trust anchors at other points, but being specific about CA's is
useful here.

>
> You say that the definition excludes the fact that a Top CA's self-signed
> certificate is also a CA-certificate. This is correct, ... but was not
> intended.
>
> So what about this full correction ?
>
> [2459bis] defines a cross-certificate as "a certificate issued by one CA
to
> another CA". [2459bis] does not provide a formal definition of a CA
> certificate but implictly means a certificate where the subject of the
> certificate is a CA.

> This means that self-signed certificates are CA
> certificates but are not cross-certificates.

cant or better yet, shouldn't the ultimate source of any trust chain have a
self-signed cert as its core anchor? Just makes sense I think.

[Tom] Why is a self-signed certificate a better anchor than a
cross-certificate with constraints in it?  This question is most applicable
to cases where the trust anchor is NOT a top CA.

> Some people in the WG believe
> that a cross certificate is a special kind of CA certificate issued by a
CA
> under one Top CA for another CA under a different Top CA.

these are use rules and have little to do with the protocol itself.

> CAs in the same
> hierarchy usually have part of their names imposed by the Top CA or by
the
> CAs under that Top CAs. When a cross certificate is issued, there is no
> relationship between the names of the CAs.
>
> >       In comment 11, the i.e. should remain "what are the root CA's"
rather
> > than "what are the Top CA's", for the same reason as in comment 12.
>








Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g352d9o21021 for ietf-pkix-bks; Thu, 4 Apr 2002 18:39:09 -0800 (PST)
Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g352d8m21017 for <[e-mail]>; Thu, 4 Apr 2002 18:39:08 -0800 (PST)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id <H5DC15DK>; Fri, 5 Apr 2002 12:37:30 +1000
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: "Kurt D. Zeilenga" <[e-mail]>
Cc: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: RE: LDAPbis scope issue (Was: LDAP Certificate transfer syntax)
Date: Fri, 5 Apr 2002 12:38:40 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
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'm not getting a feeling for the meaning of 'core':
 The certificate IDs "can be independently progressed from the rest of the
"core" specification."
 The "the engineers may consider "new features" (something which LDAPbis
cannot do)."

Quite apart from the meaning of "core", the last sentence above seems to be
your way of offering carte blanche to the certificate work?

Ron.

-----Original Message-----
From: Kurt D. Zeilenga [mailto:[e-mail]]
Sent: Friday, 5 April 2002 3:45
To: Ramsay, Ron
Cc: Mark Wahl; LDAP BIS; PKIX
Subject: LDAPbis scope issue (Was: LDAP Certificate transfer syntax)


At 05:02 PM 2002-04-03, Ramsay, Ron wrote:
>I thought certificate syntax was being removed from the LDAP v3 specs and,
>therefore, certificate syntax was not an issue for DLAPbis?

The LDAPbis WG is chartered specifically to revise the LDAP
"core" technical specification (RFC 2251-2256, 2829-2830).
This schema is part of that "core" specification.

The WG has decided to split the certificate schema into
separate I-Ds that can be independently progressed from
the rest of the "core" specification and to allow individuals
and/or the PKIX WG to taken on this work while LDAPbis
focuses on the rest of the "core".   As the engineering
is being done outside of LDAPbis, the engineers may consider
"new features" (something which LDAPbis cannot do).

However, LDAPbis is still responsible for the "core"
specification and should provide review for any I-D
updating the "core" specification.  This I-D will update
both RFC 2252 and RFC 2256 (if published before LDAPbis
works are published) and, hence, should be subject to
a LDAPbis WG review.

To this end, the PKIX and LDAPbis chairs have agreed that
this work be subject to a joint PKIX/LDAPbis WG Last Call.

Kurt, LDAPbis co-chair


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g351j1I19778 for ietf-pkix-bks; Thu, 4 Apr 2002 17:45:01 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g351j0m19774 for <[e-mail]>; Thu, 4 Apr 2002 17:45:00 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 4 Apr 2002 17:42:54 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 04 Apr 2002 17:42:53 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <H570PPM0>; Thu, 04 Apr 2002 17:44:30 -0800
Content-return: allowed
Date: Thu, 04 Apr 2002 17:44:27 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Open issue: DPV relay
To: "'Tim Polk'" <[e-mail]>, [e-mail]
Cc: Peter Sylvester <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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 agree on this - DPV relaying should be supported. I don't
think it imposes any additional requirements on the protocol.
You wouldn't normally get into loops unless a server were pretty
badly misconfigured.

In general, the way most OCSP servers work is that they respond
for a set of CAs. For others, they either go to a URL specified
by the client application or one configured in the server itself.

It is possible to set up loops that can have server A ask B who asks
A, but I haven't seen this happen practically.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Tim Polk [mailto:[e-mail]]
> Sent: Thursday, April 04, 2002 3:11 PM
> To: [e-mail]
> Cc: Peter Sylvester
> Subject: Open issue: DPV relay
> 
> 
> 
> Peter Sylvester has stated a requirement for DPV servers to 
> relay requests 
> to one another:
> 
>  >
>  >There is a requirement, similar as for OCSP caches,
>  >that server just relays a request to another. This had been
>  >discussed several times, the differences had only been to
>  >what degree the relaying should become visible; whether one
>  >server can rewrite/resigns the answers of another etc.
>  >Relaying via cache is an obvious feature in many OCSP 
> implementation,
>  >how do they protect itself against loops between two servers?
>  >
> 
> I believe this is an open issue, and would like to start a 
> new discussion 
> thread limited to this topic.
> 
> As I understand Peter's scenario, there are three mutually 
> trusting DPV 
> servers.  If a server cannot satisfy a request directly, it 
> may relay the 
> request to a different server.  We'll assume the server is 
> smart enough not 
> to relay a request back to the requester.  (That is, if 
> server A relays a 
> request to Server B, B may relay it to Server C but not A.)
> 
> (1) Assume Alice requests a valid path for Bob's certificate 
> from Server A, 
> when none exists.
> (2) Server A relays the request to Server B, since it cannot 
> satisfy it 
> directly. (A could have chosen Server C; it is irrelevant.)
> (3) Server B relays the request to Server C, since it cannot 
> satisfy it 
> directly.  (C could not choose A, since it was the requester.)
> (4) Server C relays the request to Server A, since it cannot 
> satisfy it 
> directly.  (A could not choose B, since it was the requester.)
> 
> At this point, either A must maintain state and recognize 
> that the request 
> has cycled around or the protocol has to handle this by maintaining a 
> history list.
> 
> Peter, please confirm that I have characterized the problem 
> correctly (or 
> post the right scenario)!  I am not personally convinced that blind 
> relaying amongst DPV servers is a requirement.
> 
> IMHO, DPV relaying would be limited to the scenario where 
> each Server was 
> authoritative for a particular community (perhaps based on 
> privately held 
> status information).  Alice directs all requests to Server A 
> to simplify 
> her life.  Server A would be able to determine which server 
> (B or C) could 
> possibly satisfy the request based on Bob's certificate.
> 
> Even though relaying occurred, Server A acted as a simple DPV client, 
> imposing no additional requirements...
> 
> Thanks,
> 
> Tim Polk
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g351PmV19152 for ietf-pkix-bks; Thu, 4 Apr 2002 17:25:48 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g351Pkm19148 for <[e-mail]>; Thu, 4 Apr 2002 17:25:46 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 5 Apr 2002 01:24:53 UT
Received: from tuna.rsa.com (tuna.rsa.com [10.80.211.153]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id UAA21290; Thu, 4 Apr 2002 20:24:46 -0500 (EST)
Received: from rsasecurity.com (vanquish.rsa.com [10.81.217.242]) by tuna.rsa.com (8.8.8+Sun/8.8.8) with ESMTP id RAA15835; Thu, 4 Apr 2002 17:30:40 -0800 (PST)
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 17:24:44 -0800
From: Jeff Jacoby <[e-mail]>
Organization: RSA Security, Inc.
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: One last comment on DPD requirements
References: <[e-mail]>
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>

Russ,

"Housley, Russ" wrote:
> 
> Ambarish:
> 
> Tim Polk and I just discussed this on the phone.  I will share my
> conclusion form the conversation (which might be different than Tim's
> conclusion).  I think that we need to allow for multiple certificates to
> be
> returned, but the default should be to return just one.  If the client
> wants more than one, it needs to explicitly request them (up to a
> maximum
> number).  If the server does not support returning extra certificates,
> then
> it should just return one, but it should include a status code that
> says,
> "I do not support the option you requested, but I thought that I should
> give you one just in case it meets your needs."

I think such a status code may be unnecessary.  If a multi-path-capable
client 
gets only one path back -- either because there really was only one
path, or the
server couldn't support multiple paths -- what can it usefully do with
that status code?  
In other words, what would/could it do differently if it saw that status
code or 
not?

> 
> Russ
> 
> At 11:11 AM 4/4/2002 -0800, Ambarish Malpani wrote:
> 
> >Russ,
> >     A minor nit - a DPD server might also be a DPV server, who
> >a client is not willing to trust (and whose work the client wants
> >to verify for itself).
> >
> >To summarize, what I think what I hear you, Santosh and Steve say
> >is that it might make sense to require a DPD server to return a
> >single path back, but if we want to enable that, we need to let
> >the client specify his requirements more precisely. Is that
> >correct?
> >
> >It would make sense to show (in the protocol doc), what those
> >requirements are for protocols like S/MIME, TLS, IPSec and let
> >other protocols define their own requirements if they can't
> >fit into one of the three above.
> >
> >Does that make sense to you? What about others on the list?
> >
> >Regards,
> >Ambarish

[big snippage]

Jeff
-- 
Jeff Jacoby, Sr. Programmer                
RSA Security Inc., SMDC                    [e-mail]
2955 Campus Dr., Ste. 400                  [phone]
San Mateo, CA  94403


Received: by above.proper.com (8.11.6/8.11.3) id g350rHB18489 for ietf-pkix-bks; Thu, 4 Apr 2002 16:53:17 -0800 (PST)
Received: from poseidon.coastside.net (poseidon.coastside.net [207.213.212.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g350rGm18485 for <[e-mail]>; Thu, 4 Apr 2002 16:53:16 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by poseidon.coastside.net  with SMTP id g350rHkI027836 for <[e-mail]>; Thu, 4 Apr 2002 16:53:17 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: A few comments re: dpv-dpd requirements
Date: Thu, 4 Apr 2002 16:50:31 -0800
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)
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
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>

Russ, Denis:

The state "unknown" is missing in Section 4, "Delegated Path
Validation Protocol Requirements".  The -03 draft currently
reads:

"The DPV response MUST indicate one of the following two status
alternatives:

1) the certificate is valid according to the validation policy.
2) the certificate is not valid according to the validation
policy."

I think -04 should read:

"The DPV response MUST indicate one of the following three
status alternatives:

1) the certificate is valid according to the validation policy.
2) the certificate is not valid according to the validation
policy.
3) the certificate is unknown to the validation server."

Thus we remain at {valid, invalid, unknown} as primary initial
states per list-based consensus.  Apologies for digging into
this, but it has relevance to the design of state machines.

Mike




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34NM0F16478 for ietf-pkix-bks; Thu, 4 Apr 2002 15:22:00 -0800 (PST)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34NLwm16470 for <[e-mail]>; Thu, 4 Apr 2002 15:21:58 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g34NM1Cl023303 for <[e-mail]>; Thu, 4 Apr 2002 18:22:01 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 04 Apr 2002 18:20:25 -0500
To: <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: Open Issue: Multiple paths in DPD service (Was RE: One last comment on DPD requirements)
In-Reply-To: <002a01c1dc0f$9a260e50$a300a8c0@Chokhani>
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>

Folks,

I posted the following summary of this thread/issue in a summary for 
DPD/DPV, and identified it as one of the two FINAL issues to be resolved so 
that we can forward this specification.

Please take a look at my summary, and correct it where appropriate!

Open Issue #2

The second issue is conformance requirements for multiple paths in the DPD 
service.  As I read it, the current draft requires support for multiple 
paths at the server, but not the client.  The client may request a maximum 
number of paths N; if the request does not specify N, it defaults to 
one.  The DPD server includes zero, one, or up to N paths in a 
response.  If the number of paths is less than N, this indicates that the 
server could not find as many paths as the client requested.

Since the DPD process is performed with respect to a policy, just as in 
DPV, it has been suggested that a DPD server could be designed to always 
return a single path.  If the specified policy matches the path validation 
process performed at the client (e.g., same certificate policies and same 
trust anchor) the client should be able to use that path.

However, this could result in an ambiguity.  How does the DPD client that 
requested three paths tell the difference between the following answers:
	"I gave you one path because it is the only one that exists"
      and
	"I gave you one path 'cause that's the way I was designed"

In the case where the single path failed, a client may need to know the 
difference!

Careful selection of conformance requirements and error condition 
statements will be required to permit building single answer DPD servers.

---

Have I characterized this correctly?  It seems that permitting single 
answer DPD servers demands an ability to clarify a response with M paths 
where M < N the requested number of paths.  Given that, can we reach 
consensus that a conforming DPD server may be designed to always return a 
single path?

Thanks,

Tim Polk


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34NDBa16315 for ietf-pkix-bks; Thu, 4 Apr 2002 15:13:11 -0800 (PST)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34ND9m16310 for <[e-mail]>; Thu, 4 Apr 2002 15:13:10 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g34ND4Cl013463; Thu, 4 Apr 2002 18:13:04 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 04 Apr 2002 18:11:28 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Open issue: DPV relay
Cc: Peter Sylvester <[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>

Peter Sylvester has stated a requirement for DPV servers to relay requests 
to one another:

 >
 >There is a requirement, similar as for OCSP caches,
 >that server just relays a request to another. This had been
 >discussed several times, the differences had only been to
 >what degree the relaying should become visible; whether one
 >server can rewrite/resigns the answers of another etc.
 >Relaying via cache is an obvious feature in many OCSP implementation,
 >how do they protect itself against loops between two servers?
 >

I believe this is an open issue, and would like to start a new discussion 
thread limited to this topic.

As I understand Peter's scenario, there are three mutually trusting DPV 
servers.  If a server cannot satisfy a request directly, it may relay the 
request to a different server.  We'll assume the server is smart enough not 
to relay a request back to the requester.  (That is, if server A relays a 
request to Server B, B may relay it to Server C but not A.)

(1) Assume Alice requests a valid path for Bob's certificate from Server A, 
when none exists.
(2) Server A relays the request to Server B, since it cannot satisfy it 
directly. (A could have chosen Server C; it is irrelevant.)
(3) Server B relays the request to Server C, since it cannot satisfy it 
directly.  (C could not choose A, since it was the requester.)
(4) Server C relays the request to Server A, since it cannot satisfy it 
directly.  (A could not choose B, since it was the requester.)

At this point, either A must maintain state and recognize that the request 
has cycled around or the protocol has to handle this by maintaining a 
history list.

Peter, please confirm that I have characterized the problem correctly (or 
post the right scenario)!  I am not personally convinced that blind 
relaying amongst DPV servers is a requirement.

IMHO, DPV relaying would be limited to the scenario where each Server was 
authoritative for a particular community (perhaps based on privately held 
status information).  Alice directs all requests to Server A to simplify 
her life.  Server A would be able to determine which server (B or C) could 
possibly satisfy the request based on Bob's certificate.

Even though relaying occurred, Server A acted as a simple DPV client, 
imposing no additional requirements...

Thanks,

Tim Polk



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34N7jf16197 for ietf-pkix-bks; Thu, 4 Apr 2002 15:07:45 -0800 (PST)
Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34N7hm16187 for <[e-mail]>; Thu, 4 Apr 2002 15:07:43 -0800 (PST)
Received: from salford.ac.uk ([213.107.136.218]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Fri, 5 Apr 2002 00:07:44 +0100
Message-ID: <[e-mail]>
Date: Fri, 05 Apr 2002 00:11:43 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail], [e-mail], Jim Sermersheim <[e-mail]>, [e-mail], [e-mail]
Subject: Re: LDAP Certificate transfer syntax  [Virus checked]
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------EDC8A52A63C717DDF957B824"
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.
--------------EDC8A52A63C717DDF957B824
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit



[e-mail] wrote:
> 
> I am puzzled. Within the PKI projects that I did participate, and those
> that I am aware of, retrieving certificates from an directory, either one
> dedicated to the use of PKI or an PKI-enhanced corporate directory, has
> never been a problem once the correct node has been known. Neither with
> special applications nor with standard ones like the popular e-mail clients
> Outlook (Express) or Netscape. So Certificate transfer syntax is not a
> problem, all applications that I am aware of are happily expecting a
> DER-encoded X.509 certificate binary blob as the certificate, and that is a
> workable solution obviously, no need for a change. 

Unfortunately some PKIs are having problems e.g, with a mixture of
LDAPv2 and v3 clients from multiple vendors, using multiple servers from
different vendors.

>The only "standard" that
> we are missing is a directory profile that allows us in a standardized way
> to look up user certificates by typical search items like e-mail adress or
> username (a de-facto standard ldap search query is implemented in Outlook,

this is precisely what the PKIX LDAP schema ID is defining - matching
rules that allow you to search for certificates based on their internal
fields.


> Netscape and Lotus Notes), and CA certificates (and CA nodes) by a given
> issuer name (no de-facto standard is existing). The solution proposed in
> this thread  "DIT DN match subject DN" does not resolve the "retrieve a
> user certificate by search item" problem, and is for reasons already been
> given by others on this list a bad solution for retrieving CA nodes by
> issuer DN. What we really need is an extension of the objectClass pkiCA or
> certificationAuthority by an standard attribute of type DN containing the
> subject name of the CA certificate. 

this is a simplistic solution that does not cater for searching for
certificates with particular expiry dates, or key usage fields, or
alternate subject names, or particular CRL distribution points etc.
Further it requires someone to pull the CA name out of the cert and to
stick it in a separate attribute. What the LDAP schema ID is defining is
a general mechanism to allow a client to store a certificate on its own
(no extra attributes are needed) and then search for it based on ANY of
its embedded fields. We have started to implement this now in OpenLDAP.

>In our projects we are currently
> (mis)using the objectClass "organizationalRole" for that purpose as it
> contains an attribute "RoleOccupant" with the appropriate type at least.. We
> are probably missing the semantics of that class here, but it is working.
> 

Yes, its a short term quick fix that works. Lets hope you wont have to
use it for too long.

> Whatever you do with LDAP specs, do not break existing systems, especially
> not existing PKI-aware applications on the market.

Thanks for this. We should not do this of course, but we also need to
address existing problems today as well.

David

> _____________________________________________________
> 
> Olaf Schlüter
> Professional Services PKI
> 
> Secartis AG -- eSolutions by Giesecke & Devrient
> Bretonischer Ring 3, D-85630 Grasbrunn, Germany
> 
> Phone: [phone], Fax; [phone]
> Mobile: [phone],
> Email: [e-mail], Home: www.secartis.com
> _____________________________________________________
> 
> 
>                     David Chadwick
>                     <d.w.chadwick@salf       To:     Jim Sermersheim <[e-mail]>
>                     ord.ac.uk>               cc:     [e-mail], [e-mail], [e-mail]
>                     Sent by:                 Subject:     Re: LDAP Certificate transfer syntax  [Virus checked]
>                     owner-ietf-pkix@ma
>                     il.imc.org
> 
> 
>                     04.04.2002 14:52
> 
> 
> 
> Jim
> 
> these are very good points that you make. They go part way to showing
> that a reason for the confused situation we have gotten into is by not
> previously being precise enough about certificate syntax definitions (in
> fact there was not a workable one defined). I hope the new PKIX schema
> ID can be precise enough to ensure that future problems dont occur. Do
> you have any suggestions to the proposed wording that I sent out
> 
> David
> 
> Jim Sermersheim wrote:
> >
> > I note that 2252 and 2256 both have problems with the language used to
> > specify this.
> >
> > 2252 says that values of the Certificate syntax MUST be transferred
> > using the binary encoding. It then gives two attribute descriptions
> > "userCertificate;binary" and caCertificate;binary". If I create an
> > attribute called printerCertificate, what am I supposed to refer to it
> > as?
> >
> > It can be argued that the MUST here refers to the encoding, and the
> > attribute descriptions are merely examples of the day.
> >
> > 2256 says "This attribute is to be stored and requested in the binary
> > form, as 'userCertificate;binary'". Am I to believe that I must somehow
> > store the ;binary option in my database? Aside from that sillines, there
> > is no MUST imperative here.
> >
> > Jim
> >
> > >>> "Kurt D. Zeilenga" <[e-mail]> 04/03/02 11:36AM >>>
> > This text does not clearly "MUST" the use of ;binary as
> > RFC 2252 and RFC 2256 did.  As previously noted, this
> > "MUST" should not be dropped as doing so will cause
> > interoperability problems between implementations of
> > the current technical specification and the revised
> > technical specification.
> >
> > Kurt
> >
> > At 05:29 AM 2002-04-01, David Chadwick wrote:
> > >Colleagues
> > >
> > >Here is my proposed change to the section describing the LDAP syntax
> > for
> > >cerificates in the PKIX id
> > ><draft-pkix-ldap-schema-03.txt> which should be published before the
> > end
> > >of April. As this is likely to be the most contentious part of the
> > new
> > >ID, I thought it would be useful to distribute this text at the
> > earlier
> > >possible moment.
> > >
> > >All constructive comments welcomed
> > >
> > >David
> > >
> > >
> > >3.3  Certificate Syntax
> > >
> > >A value in this transfer syntax is the binary octet string that
> > results
> > >from BER or DER-encoding of an X.509 public key certificate.  The
> > >following string states the OID assigned to this syntax:
> > >
> > >      ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
> > >
> > >Servers must preserve values in this syntax exactly as given when
> > >storing and retrieving them.
> > >
> > >Note. Due to the changes from X.509(1988) to X.509(1993) and
> > subsequent
> > >changes to the ASN.1 definition to support certificate extensions in
> > >X.509(1997), no character string transfer syntax is defined for
> > >certificates. The BNF notation in RFC 1778 [12] for "User
> > Certificate"
> > >MUST NOT be used. Values in this syntax MUST be transferred as BER or
> > >DER encoded octets. The use of the ;binary encoding option, i.e. by
> > >requesting or returning the attributes with descriptions
> > >"userCertificate;binary" or "caCertificate;binary" has no effect on
> > the
> > >transfer syntax.
> 
> --
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************
> (See attached file: d.w.chadwick.vcf)

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------EDC8A52A63C717DDF957B824
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------EDC8A52A63C717DDF957B824--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34N2nE16094 for ietf-pkix-bks; Thu, 4 Apr 2002 15:02:49 -0800 (PST)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34N2lm16090 for <[e-mail]>; Thu, 4 Apr 2002 15:02:47 -0800 (PST)
Received: from st25 (st25.ncsl.nist.gov [129.6.54.67]) by email.nist.gov (8.12.2/8.12.2) with ESMTP id g34N2lCl001090 for <[e-mail]>; Thu, 4 Apr 2002 18:02:47 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 
Date: Thu, 04 Apr 2002 18:01:06 -0500
To: [e-mail]
From: Tim Polk <[e-mail]>
Subject: Summary:open issues for draft-ietf-pkix-dpv-dpd-req-03.txt
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>
Folks,<br>
<br>
I think the discussion is converging here, and thought a summary was in
order.<br>
<br>
There are a number of issues that were raised on the list and have
demonstrated consensus on the list.&nbsp; (I will not enumerate
them.)&nbsp; Proposed text has been submitted to the list and I sense
general satisfaction with that text.<br>
<br>
However, there are two open issues that must be resolved before we
forward the document to the Area Directors.<br>
<br>
<u>Open Issue #1<br>
<br>
</u>The first issue involves &quot;DPV relay&quot;.&nbsp; Peter Sylvester
has stated a requirement for DPV servers to relay requests to one
another:<br>
<br>
&gt;<br>
&gt;There is a requirement, similar as for OCSP caches, <br>
&gt;that server just relays a request to another. This had been <br>
&gt;discussed several times, the differences had only been to <br>
&gt;what degree the relaying should become visible; whether one <br>
&gt;server can rewrite/resigns the answers of another etc. <br>
&gt;Relaying via cache is an obvious feature in many OCSP implementation,
<br>
&gt;how do they protect itself against loops between two servers? <br>
&gt;<br>
<br>
I understand this issue remains open.<br>
<br>
<u>Open Issue #2<br>
<br>
</u>The second issue is conformance requirements for multiple paths in
the DPD service.&nbsp; As I read it, the current draft requires support
for multiple paths at the server, but not the client.&nbsp; The client
may request a maximum number of paths N; if the request does not specify
N, it defaults to one.&nbsp; The DPD server includes zero, one, or up to
N paths in a response.&nbsp; If the number of paths is less than N, this
indicates that the server could not find as many paths as the client
requested.<br>
<br>
Since the DPD process is performed with respect to a policy, just as in
DPV, it has been suggested that a DPD server could be designed to always
return a single path.&nbsp; If the specified policy matches the path
validation process performed at the client (e.g., same certificate
policies and same trust anchor) the client should be able to use that
path.<br>
<br>
However, this could result in an ambiguity.&nbsp; How does the DPD client
that requested three paths tell the difference between the following
answers:<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&quot;I
gave you one path because it is the only one that exists&quot;<br>
&nbsp;&nbsp;&nbsp;&nbsp; and<br>
<x-tab>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</x-tab>&quot;I
gave you one path 'cause that's the way I was designed&quot;<br>
<br>
In the case where the single path failed, a client may need to know the
difference!<br>
<br>
Careful selection of conformance requirements and error condition
statements will be required to permit building single answer DPD
servers.<br>
<br>
<u>Moving Forward<br>
<br>
</u>Here is my plan for moving forward...<br>
<br>
I will start two threads for the remaining open issues.&nbsp; I consider
all other issues regarding the DPD/DPV requirements to be resolved.<br>
<br>
Once the last two issues are resolved, I will ask the editors to post an
-04 draft incorporating the currently agreed changes and the resolution
to the two open issues.&nbsp; The -04 draft will be forwarded to the
ADs.<br>
<br>
Hope this works for everyone.<br>
<br>
Thanks,<br>
<br>
Tim Polk</html>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34MtjW15320 for ietf-pkix-bks; Thu, 4 Apr 2002 14:55:45 -0800 (PST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34Mthm15313 for <[e-mail]>; Thu, 4 Apr 2002 14:55:43 -0800 (PST)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Apr 2002 14:55:40 -0800
Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 04 Apr 2002 14:55:41 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Apr 2002 14:55:41 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Thu, 4 Apr 2002 14:55:40 -0800
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3604.0); Thu, 4 Apr 2002 14:52:05 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: One last comment on DPD requirements
Date: Thu, 4 Apr 2002 14:52:07 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: One last comment on DPD requirements
thread-index: AcHb6dGvuYYHKUuoQoqQesCN7n0qDgAQbWZA
From: "Trevor Freeman" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 04 Apr 2002 22:52:05.0125 (UTC) FILETIME=[57686B50:01C1DC2B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g34Mthm15315
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 Steve,
I agree having the server return a flag if there are more chains
available if the client only requested a single chain be returned makes
sense.
Trevor
-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Thursday, April 04, 2002 7:05 AM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: One last comment on DPD requirements


At 4:25 PM -0800 4/3/02, Trevor Freeman wrote:
>To state that a client has to be exacting over its specification and 
>only wants one chain returned is presupposing the application model. 
>There are applications which are more comfortable with making a vague 
>request, getting back multiple chains to which they apply their own 
>policy. One of the specifications to the server can be find me all 
>paths that meet these criteria. I think the simple case on only wanting

>a single chain is the most common so making that the default is fine.

Trevor,

That may a good way to reconcile this issue.  Make single path return 
the default and require support for that by all clients.  Require a 
client that wants multiple paths, and is capable of using them, to 
explicitly enable a multi-path return option, so that only such 
clients receive multiple paths.  Maybe we also could have a return 
code to signal that even though only one path was returned, as per 
the client's (default) request, that other paths are available from 
the server (relative to this request).

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34Mph514724 for ietf-pkix-bks; Thu, 4 Apr 2002 14:51:43 -0800 (PST)
Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34Mpfm14718 for <[e-mail]>; Thu, 4 Apr 2002 14:51:42 -0800 (PST)
Received: from salford.ac.uk ([213.107.136.218]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Thu, 4 Apr 2002 23:51:43 +0100
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 23:55:42 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark Wahl <[e-mail]>
CC: [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <001001c1db7f$751e3cd0$[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------1AF941EC9AD3712F35B81790"
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.
--------------1AF941EC9AD3712F35B81790
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Mark Wahl wrote:
> 
> David Chadwick wrote:
> > But this does raise the more general issue of how does a user who asks
> > for "all" attributes, deal with those which are returned, whose native
> > encoding he is unfamiliar with.
> 
> An application which asks for all attributes will need to expect to see
> returned in the search result entry some attributes whose syntax OID is not
> one known to it.

thats fine. But it does not quite go far enough. There are multiple
cases to consider by the server (irrespective of what the client knows
or does not know). The server might receive on an Add operation

i) an attribute whose LDAP syntax OID is known to the server and whose
native encoding is known e.g telephoneNumber
ii) an attribute whose LDAP syntax OID is known and whose native
encoding is not defined e.g. certificates and Steven Legg's multiple
examples of ACI etc (although it seems a bit odd to allocate an LDAP
syntax OID and not define what it means)
iii) an attribute whose syntax OID is not known and is sent to the
server as ;binary e.g. foobar;binary
iv) an attribute whose syntax OID is not known and is sent to the server
in a native encoding known to the client e.g foobar

I suspect that the server must reject case iv). I dont know what it will
do in case iii) when such an attribute is recieved. The server could
just store it as a binary BER blob (assuming the attribute type has been
configured in), or refuse to accept it. In fact case ii) and iii) dont
appear to be too dissimilar to me, since the LDAP syntax OID is not
passed in protocol, and in case ii) it is a pretty meaningless thing to
have as it is not defined? So a server could treat case ii) and iii) the
same. Can you clarify this for me Mark please.

The client submitting the attribute might well be different to the one
retrieving it, and have different amounts of schema knowledge. A dumb
client might not know any schema definitions!

So in general a client might expect to recieve

i) an attribute whose native encoding it knows, in native encoding e.g
telephoneNumber
ii) an attribute whose native encoding it knows, in ;binary encoding
e.g. telephoneNumber;binary
iii) an attribute whose native encoding it does not know, in native
encoding e.g. foobar
iv) an attribute whose native encoding it does not know, in binary
encoding e.g. foobar;binary

All of the above 8 cases (both receipt by the server and the client)
need to be described in the LDAPbis documents as they are general cases
independent of the certificate discussion. Dont you agree?


> 
> RFC 2256 section 4.3.1 states that clients which request that all
> attributes be returned from entries MUST be prepared to receive values
> in binary (e.g. userCertificate;binary) and SHOULD NOT simply display
> binary or unrecognized values to users.
> 
> What the application does with this is analogous to an email or web client
> that receives a Content-Type: application/x-foo-bar.  It might
>  - ignore it,
>  - report an error,
>  - save the bytes to the file,
>  - attempt to 'guess' (e.g. if all the bytes are in a pattern that matches
>    the UTF-8 rules, then maybe it is UTF-8).
> 
> > Does the server assume the client knows (in which case ;binary will only
> > be used on those attributes with no native encoding defined) or does not
> > know (in which case ;binary will need to be used on all attributes that
> > are not defined in Internet  standard RFCs).
> 
> A server knows nothing about client's schema capabilities.  There is no
> operation for a client to 'upload' a syntax table to the server.  The
> ;binary is used when the client requests it, either on the Add or Modify
> which introduces the attribute and value to the entry, or when the client
> requests it in the search's attribute description list.

What happens if a client Adds telephoneNumber;binary? This should be
readable in either native format or ;binary format, shouldn't it? One
could interpret what you said above that once submitted in the ;binary
form it is only ever readable in ;binary format. You did not imply this
did you?

Thanks

David

> 
> Mark Wahl
> Sun Microsystems Inc.

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------1AF941EC9AD3712F35B81790
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------1AF941EC9AD3712F35B81790--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34Lw9512392 for ietf-pkix-bks; Thu, 4 Apr 2002 13:58:09 -0800 (PST)
Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34Lw8m12388 for <[e-mail]>; Thu, 4 Apr 2002 13:58:08 -0800 (PST)
Received: from salford.ac.uk ([213.107.136.218]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Thu, 4 Apr 2002 22:58:10 +0100
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 23:02:08 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <001001c1db7f$751e3cd0$[e-mail]> <5.1.0.14.0.20020404091310.02796bc0@127.0.0.1>
Content-Type: multipart/mixed; boundary="------------44013F5621BF9142B96E031A"
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.
--------------44013F5621BF9142B96E031A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Kurt D. Zeilenga" wrote:

> I think it very important certificate schema not be a 'special
> case'.

Yes I agree with this. I think there really should be no special cases,
and that the core LDAPv3 specs should be able to cater for all
eventualities, such as native encoding exists, native encoding does not
exist, how to handle "any" in both cases etc.


>  I am concerned that adding a 'native' encoding to
> certificate schema will necessity the need for a 'special case'.
> In particular, in the handling of '*' as the general handling
> is to return the native encoding (no transfer option) if one
> is defined and supported.
> 

The special case will be needed by the enhanced LDAPv3 server that
understands the certificate native encoding, so does not need to provide
;binary in the response, but might do so as to be backwards compatible
with clients that expect ;binary (ie. do not know the native encoding).
But this special case is not really so special anyway, because

a) is not mandatory so the server does not have to keep this backwards
compatibility if it does not want to and
b) this case is no different to a server that knows about a private
attribute "foobar" with a locally defined native encoding, when
returning this to a remote client from another domain. The server does
not have to provide ;binary encoding, but ought to because the remote
client wont know the native encoding. This is why I said that ;binary
can only be ignored for attributes whose native syntax is defined in an
RFC, and is internationally known, but not for locally defined
attributes.

David


> >Seems like ASN.1 DAP had some advantages after all :-)
> 
> DAP, in many ways, is lighter than LDAP.  :-(
> 
> Kurt

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------44013F5621BF9142B96E031A
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------44013F5621BF9142B96E031A--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34LkgU12147 for ietf-pkix-bks; Thu, 4 Apr 2002 13:46:42 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g34Lkem12143 for <[e-mail]>; Thu, 4 Apr 2002 13:46:41 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Apr 2002 21:45:46 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA06553 for <[e-mail]>; Thu, 4 Apr 2002 16:45:40 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g34LkiZ06410 for <[e-mail]>; Thu, 4 Apr 2002 16:46:44 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX13WDT>; Thu, 4 Apr 2002 16:44:20 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.139]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX13WDR; Thu, 4 Apr 2002 16:44:13 -0500
From: "Housley, Russ" <[e-mail]>
To: Ambarish Malpani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 04 Apr 2002 16:42:48 -0500
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
In-Reply-To: <[e-mail]. com>
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>

Ambarish:

I am fine with this.

Russ


At 11:35 AM 4/4/2002 -0800, Ambarish Malpani wrote:

>Denis, Russ,
>     I agree with the first phrase:
>
> > "The protocol MUST prevent replay attacks, and the replay prevention
> > mechanism employed by the protocol MUST NOT rely on clocks being
> > synchronized with UTC."
>
>I don't agree with the requirement that a response needs to
>contain all the information from the query in itself. That could
>result in a lot of extra information that needs to be carried in
>the response over what might be a bandwidth constrained channel.
>
>In all cases, being able to tie the response to the request does
>the job. If a client needs to be able to show that this response
>was for a particular certificate, it can retain the original
>request. If the client doesn't need to be able to prove that, it
>can discard the request after it gets the response. I don't see
>why the response needs to contain
>      "the requested validation policy, including associated
>       parameters, if any."
>
>I would prefer the second statement to read:
>
>The DPV client MUST be able to confirm that the DPV server-generated
>response was constructed for the client's request.
>
>(NOTE: I changed Russ's "from" to "for")
>
>A
>
>
>
>
>---------------------------------------------------------------------
>Ambarish Malpani
>Chief Architect                                          650.567.5457
>ValiCert, Inc.                                  [e-mail]
>1215 Terra Bella Ave.                         http://www.valicert.com
>Mountain View, CA 94043
>
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> > Sent: Thursday, April 04, 2002 8:21 AM
> > To: Denis Pinkas
> > Cc: [e-mail]; [e-mail]
> > Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
> >
> >
> > Denis:
> >
> > I prefer the following wording.  I think it provides the same
> > end result.
> >
> > "The protocol MUST prevent replay attacks, and the replay prevention
> > mechanism employed by the protocol MUST NOT rely on clocks being
> > synchronized with UTC."
> >
> > (...)
> >
> > The DPV client MUST be able to confirm that the DPV server-generated
> > response was constructed from the client's request.  When the
> > response
> > indicates certificate validity, the response MUST allow the
> > DPV client to
> > readily confirm that the response was made for the requested
> > certificate
> > and for the requested validation policy, including associated
> > parameters,
> > if any."
> >
> > Russ
> >
> >
> > At 03:30 PM 4/4/2002 +0200, Denis Pinkas wrote:
> > >"The protocol MUST prevent replay attacks, including for the
> > case where
> > >the client does not have a clock synchronized with UTC.
> > >
> > >(...)
> > >
> > >The requester MUST be able to verify that the response was
> > constructed
> > >taking into consideration all the parameters from the
> > request. In addition,
> > >without the need to store the request, a requester SHALL be
> > able to prove
> > >that a valid DPV response was made for a given certificate
> > and for a given
> > >validation policy, including associated parameters, if any."
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34Lefn11986 for ietf-pkix-bks; Thu, 4 Apr 2002 13:40:41 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g34Lecm11980 for <[e-mail]>; Thu, 4 Apr 2002 13:40:39 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Apr 2002 21:39:44 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id QAA06019 for <[e-mail]>; Thu, 4 Apr 2002 16:39:38 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g34LegK05755 for <[e-mail]>; Thu, 4 Apr 2002 16:40:42 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX13WAA>; Thu, 4 Apr 2002 16:38:17 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.139]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX13V00; Thu, 4 Apr 2002 16:38:15 -0500
From: "Housley, Russ" <[e-mail]>
To: Ambarish Malpani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 04 Apr 2002 16:40:34 -0500
Subject: RE: One last comment on DPD requirements
In-Reply-To: <[e-mail]. com>
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>

Ambarish:

Tim Polk and I just discussed this on the phone.  I will share my 
conclusion form the conversation (which might be different than Tim's 
conclusion).  I think that we need to allow for multiple certificates to be 
returned, but the default should be to return just one.  If the client 
wants more than one, it needs to explicitly request them (up to a maximum 
number).  If the server does not support returning extra certificates, then 
it should just return one, but it should include a status code that says, 
"I do not support the option you requested, but I thought that I should 
give you one just in case it meets your needs."

Russ

At 11:11 AM 4/4/2002 -0800, Ambarish Malpani wrote:

>Russ,
>     A minor nit - a DPD server might also be a DPV server, who
>a client is not willing to trust (and whose work the client wants
>to verify for itself).
>
>To summarize, what I think what I hear you, Santosh and Steve say
>is that it might make sense to require a DPD server to return a
>single path back, but if we want to enable that, we need to let
>the client specify his requirements more precisely. Is that
>correct?
>
>It would make sense to show (in the protocol doc), what those
>requirements are for protocols like S/MIME, TLS, IPSec and let
>other protocols define their own requirements if they can't
>fit into one of the three above.
>
>Does that make sense to you? What about others on the list?
>
>Regards,
>Ambarish
>
>
>
>---------------------------------------------------------------------
>Ambarish Malpani
>Chief Architect                                          650.567.5457
>ValiCert, Inc.                                  [e-mail]
>1215 Terra Bella Ave.                         http://www.valicert.com
>Mountain View, CA 94043
>
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> > Sent: Thursday, April 04, 2002 7:00 AM
> > To: Santosh Chokhani
> > Cc: [e-mail]
> > Subject: RE: One last comment on DPD requirements
> >
> >
> >
> > Santosh:
> >
> > I think that a DPD server will likely perform path
> > validation.  Clients
> > will not be happy if the paths that they are given are often
> > invalid.  Clearly, the DPD server cannot know all of the
> > parameters that
> > the client will use for path validation (otherwise it would be a DPV
> > server), but it can make some very reasonable assumptions to
> > ensure that
> > grossly invalid paths are not returned.
> >
> > Russ
> >
> > At 08:20 PM 4/3/2002 -0500, Santosh Chokhani wrote:
> > >Russ:
> > >
> > >I agree with you, but for a different reason.  I do not think this is
> > >application specific issue.  I think it is the path
> > validation issue.  I
> > >do not think that the DPD server can know which paths are
> > good without
> > >doing a validation also, specially to see if there will be any name
> > >constraints or certificate policy related failures.
> > >
> > >-----Original Message-----
> > >From: [e-mail]
> > [mailto:[e-mail]]
> > >On Behalf Of Housley, Russ
> > >Sent: Wednesday, April 03, 2002 2:12 PM
> > >To: Ambarish Malpani; Stephen Kent
> > >Cc: [e-mail]
> > >Subject: Re: One last comment on DPD requirements
> > >
> > >
> > >
> > >Steve & Ambarish:
> > >
> > > >>Hi Group,
> > > >>     One last (slightly late) comment on the DPD
> > requirements that has
> > >
> > > >>been troubling me:
> > > >>
> > > >>In the DPD requirements, there is a reasonable amount of text that
> > > >>talks about how a server can return multiple paths back
> > to the client
> > > >>(to allow the client to decide which path is the best).
> > > >>
> > > >>The main goal of DPD is to try and simplify the client.
> > In how many
> > > >>cases do people really want multiple paths back from the
> > server. While
> > >
> > > >>it is the right requirement in principal, do folks really think
> > > >>clients will want multiple paths back from a DPD server?
> > Are we adding
> > >
> > > >>the additional flexiblity/complexity just for technical purity?
> > > >>
> > > >>Comments will be appreciated.
> > > >>
> > > >>Regards,
> > > >>Ambarish
> > > >
> > > >I too would favor simplifying the protocol requirement
> > here. Some folks
> > > >have suggested motivations for multiple paths, but this
> > does seem to
> > > >conflict with the fundamental goal of creating a protocol
> > to satisfy
> > >the
> > > >needs of thin clients.
> > > >
> > > >Steve
> > >
> > >I agree with your goal.  It is far better for the client to tell the
> > >server
> > >what it wants, then get back a single path that satisfies all of the
> > >requirements.  To do this, we need to be able to fully specify the
> > >clients
> > >criteria and send them to the server.  I think that we know how to do
> > >this
> > >for many PKI-enabled applications, but I am not sure that we
> > know how to
> > >do
> > >it for all applications, especially ones that are yet to be
> > developed.
> > >
> > >This leaves us with two choices.  Either the protocol
> > returns multiple
> > >certification paths (the approach in the current document) or the
> > >protocol
> > >requires the client to adequately specify its criteria.
> > This could be
> > >done
> > >with the path discovery policy.  If we adopt this
> > alternative, we should
> > >
> > >include additional text so that implements expect
> > application-specific
> > >(perhaps several application-specific path discovery policy
> > if there are
> > >
> > >multiple roles in the application).
> > >
> > >Russ
> >


Received: by above.proper.com (8.11.6/8.11.3) id g34KUUb09746 for ietf-pkix-bks; Thu, 4 Apr 2002 12:30:30 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34KUTm09742 for <[e-mail]>; Thu, 4 Apr 2002 12:30:29 -0800 (PST)
Received: from rowlf.Central.Sun.COM ([129.153.131.70]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA27014; Thu, 4 Apr 2002 12:30:29 -0800 (PST)
Received: from sun.com (dhcp-aus09-222 [129.153.130.222]) by rowlf.Central.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id g34KUQe03767; Thu, 4 Apr 2002 14:30:27 -0600 (CST)
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 14:31:06 -0600
From: Mark Wahl <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
CC: [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <001001c1db7f$751e3cd0$[e-mail]> <[e-mail]>
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>

David Chadwick wrote:
> 
> Steven
> 
> thanks for your messages that have clearly stated the case that ;binary
> is needed as a general transfer encoding, and that many attributes exist
> without a native LDAP encoding being defined for them.
> 
> But this does raise the more general issue of how does a user who asks
> for "all" attributes, deal with those which are returned, whose native
> encoding he is unfamiliar with. 

An application which asks for all attributes will need to expect to see
returned in the search result entry some attributes whose syntax OID is not 
one known to it.

RFC 2256 section 4.3.1 states that clients which request that all 
attributes be returned from entries MUST be prepared to receive values
in binary (e.g. userCertificate;binary) and SHOULD NOT simply display
binary or unrecognized values to users.

What the application does with this is analogous to an email or web client 
that receives a Content-Type: application/x-foo-bar.  It might
 - ignore it, 
 - report an error,
 - save the bytes to the file,
 - attempt to 'guess' (e.g. if all the bytes are in a pattern that matches
   the UTF-8 rules, then maybe it is UTF-8).

> Does the server assume the client knows (in which case ;binary will only
> be used on those attributes with no native encoding defined) or does not 
> know (in which case ;binary will need to be used on all attributes that 
> are not defined in Internet  standard RFCs).

A server knows nothing about client's schema capabilities.  There is no 
operation for a client to 'upload' a syntax table to the server.  The
;binary is used when the client requests it, either on the Add or Modify
which introduces the attribute and value to the entry, or when the client
requests it in the search's attribute description list.

Mark Wahl
Sun Microsystems Inc.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34KJOd09456 for ietf-pkix-bks; Thu, 4 Apr 2002 12:19:24 -0800 (PST)
Received: from fw1.gdm.de (fw1.gdm.de [193.108.184.254]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34KJMm09448; Thu, 4 Apr 2002 12:19:23 -0800 (PST)
Received: (from root@localhost) by fw1.gdm.de (8.11.6/8.11.6) id g34KIZT12684; Thu, 4 Apr 2002 22:18:35 +0200 (CEST)
Received: (from localhost) by fw1.gdm.de (MSCAN) id 3/fw1.gdm.de/smtp-gw/mscan; Thu Apr  4 22:18:35 2002
Subject: Re: LDAP Certificate transfer syntax  [Virus checked]
To: David Chadwick <[e-mail]>
Cc: [e-mail], [e-mail], Jim Sermersheim <[e-mail]>, [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.07a  May 14, 2001
Message-ID: <[e-mail]>
From: [e-mail]
Date: Thu, 4 Apr 2002 22:14:35 +0200
X-MIMETrack: Serialize by Router on NOTESDMZ1/SRV/GuD(Release 5.0.8 |June 18, 2001) at 04/04/2002 10:21:59 PM
MIME-Version: 1.0
Content-type: multipart/mixed;  Boundary="0__=C1256B91006CEB198f9e8a93df938690918cC1256B91006CEB19"
Content-Disposition: inline
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.
Since your mail reader does not understand
this format, some or all of this message may not be legible.

--0__=C1256B91006CEB198f9e8a93df938690918cC1256B91006CEB19
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable



I am puzzled. Within the PKI projects that I did participate, and those=

that I am aware of, retrieving certificates from an directory, either o=
ne
dedicated to the use of PKI or an PKI-enhanced corporate directory, has=

never been a problem once the correct node has been known. Neither with=

special applications nor with standard ones like the popular e-mail cli=
ents
Outlook (Express) or Netscape. So Certificate transfer syntax is not a
problem, all applications that I am aware of are happily expecting a
DER-encoded X.509 certificate binary blob as the certificate, and that =
is a
workable solution obviously, no need for a change. The only "standard" =
that
we are missing is a directory profile that allows us in a standardized =
way
to look up user certificates by typical search items like e-mail adress=
 or
username (a de-facto standard ldap search query is implemented in Outlo=
ok,
Netscape and Lotus Notes), and CA certificates (and CA nodes) by a give=
n
issuer name (no de-facto standard is existing). The solution proposed i=
n
this thread  "DIT DN match subject DN" does not resolve the "retrieve a=

user certificate by search item" problem, and is for reasons already be=
en
given by others on this list a bad solution for retrieving CA nodes by
issuer DN. What we really need is an extension of the objectClass pkiCA=
 or
certificationAuthority by an standard attribute of type DN containing t=
he
subject name of the CA certificate. In our projects we are currently
(mis)using the objectClass "organizationalRole" for that purpose as it
contains an attribute "RoleOccupant" with the appropriate type at least=
.. We
are probably missing the semantics of that class here, but it is workin=
g.

Whatever you do with LDAP specs, do not break existing systems, especia=
lly
not existing PKI-aware applications on the market.
_____________________________________________________

Olaf Schl=FCter
Professional Services PKI

Secartis AG -- eSolutions by Giesecke & Devrient
Bretonischer Ring 3, D-85630 Grasbrunn, Germany

Phone: [phone], Fax; [phone]
Mobile: [phone],
Email: [e-mail], Home: www.secartis.com
_____________________________________________________



                                                                       =
                                               =20
                    David Chadwick                                     =
                                               =20
                    <d.w.chadwick@salf       To:     Jim Sermersheim <J=
[e-mail]>                               =20
                    ord.ac.uk>               cc:     [e-mail],=
 [e-mail], [e-mail]  =20
                    Sent by:                 Subject:     Re: LDAP Cert=
ificate transfer syntax  [Virus checked]       =20
                    owner-ietf-pkix@ma                                 =
                                               =20
                    il.imc.org                                         =
                                               =20
                                                                       =
                                               =20
                                                                       =
                                               =20
                    04.04.2002 14:52                                   =
                                               =20
                                                                       =
                                               =20
                                                                       =
                                               =20




Jim

these are very good points that you make. They go part way to showing
that a reason for the confused situation we have gotten into is by not
previously being precise enough about certificate syntax definitions (i=
n
fact there was not a workable one defined). I hope the new PKIX schema
ID can be precise enough to ensure that future problems dont occur. Do
you have any suggestions to the proposed wording that I sent out

David


Jim Sermersheim wrote:
>
> I note that 2252 and 2256 both have problems with the language used t=
o
> specify this.
>
> 2252 says that values of the Certificate syntax MUST be transferred
> using the binary encoding. It then gives two attribute descriptions
> "userCertificate;binary" and caCertificate;binary". If I create an
> attribute called printerCertificate, what am I supposed to refer to i=
t
> as?
>
> It can be argued that the MUST here refers to the encoding, and the
> attribute descriptions are merely examples of the day.
>
> 2256 says "This attribute is to be stored and requested in the binary=

> form, as 'userCertificate;binary'". Am I to believe that I must someh=
ow
> store the ;binary option in my database? Aside from that sillines, th=
ere
> is no MUST imperative here.
>
> Jim
>
> >>> "Kurt D. Zeilenga" <[e-mail]> 04/03/02 11:36AM >>>
> This text does not clearly "MUST" the use of ;binary as
> RFC 2252 and RFC 2256 did.  As previously noted, this
> "MUST" should not be dropped as doing so will cause
> interoperability problems between implementations of
> the current technical specification and the revised
> technical specification.
>
> Kurt
>
> At 05:29 AM 2002-04-01, David Chadwick wrote:
> >Colleagues
> >
> >Here is my proposed change to the section describing the LDAP syntax=

> for
> >cerificates in the PKIX id
> ><draft-pkix-ldap-schema-03.txt> which should be published before the=

> end
> >of April. As this is likely to be the most contentious part of the
> new
> >ID, I thought it would be useful to distribute this text at the
> earlier
> >possible moment.
> >
> >All constructive comments welcomed
> >
> >David
> >
> >
> >3.3  Certificate Syntax
> >
> >A value in this transfer syntax is the binary octet string that
> results
> >from BER or DER-encoding of an X.509 public key certificate.  The
> >following string states the OID assigned to this syntax:
> >
> >      ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
> >
> >Servers must preserve values in this syntax exactly as given when
> >storing and retrieving them.
> >
> >Note. Due to the changes from X.509(1988) to X.509(1993) and
> subsequent
> >changes to the ASN.1 definition to support certificate extensions in=

> >X.509(1997), no character string transfer syntax is defined for
> >certificates. The BNF notation in RFC 1778 [12] for "User
> Certificate"
> >MUST NOT be used. Values in this syntax MUST be transferred as BER o=
r
> >DER encoded octets. The use of the ;binary encoding option, i.e. by
> >requesting or returning the attributes with descriptions
> >"userCertificate;binary" or "caCertificate;binary" has no effect on
> the
> >transfer syntax.

--
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
(See attached file: d.w.chadwick.vcf)

=

--0__=C1256B91006CEB198f9e8a93df938690918cC1256B91006CEB19
Content-type: application/octet-stream; 
	name="=?iso-8859-1?Q?d.w.chadwick.vcf?="
Content-Disposition: attachment; filename="=?iso-8859-1?Q?d.w.chadwick.vcf?="
Content-transfer-encoding: base64

YmVnaW46dmNhcmQgDQpuOkNoYWR3aWNrO0RhdmlkDQp0ZWw7Y2VsbDorNDQgNzcgOTYgNDQgNzE4
NA0KdGVsO2ZheDorNDQgMTQ4NCA1MzI5MzANCnRlbDtob21lOis0NCAxNDg0IDM1MjIzOA0KdGVs
O3dvcms6KzQ0IDE2MSAyOTUgNTM1MQ0KeC1tb3ppbGxhLWh0bWw6RkFMU0UNCnVybDpodHRwOi8v
d3d3LnNhbGZvcmQuYWMudWsvaXRzMDI0L2NoYWR3aWNrLmh0bQ0Kb3JnOlVuaXZlcnNpdHkgb2Yg
U2FsZm9yZDtJUyBJbnN0aXR1dGUNCnZlcnNpb246Mi4xDQplbWFpbDtpbnRlcm5ldDpkLncuY2hh
ZHdpY2tAc2FsZm9yZC5hYy51aw0KdGl0bGU6UHJvZmVzc29yIG9mIEluZm9ybWF0aW9uIFNlY3Vy
aXR5DQphZHI7cXVvdGVkLXByaW50YWJsZTo7O1RoZSBDcmVzY2VudD0wRD0wQTtTYWxmb3JkO0dy
ZWF0ZXIgTWFuY2hlc3RlcjtNNSA0V1Q7RW5nbGFuZA0Kbm90ZTtxdW90ZWQtcHJpbnRhYmxlOlJl
c2VhcmNoIFByb2plY3RzOiBodHRwOi8vc2VjLmlzaS5zYWxmb3JkLmFjLnVrLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi49MEQ9MEE9MEQ9MEFVbmRlcnN0YW5kaW5nIFguNTAwOiAgaHR0cDovL3d3dy5z
YWxmb3JkLmFjLnVrL2l0czAyNC9YNTAwLmh0bSAuLi4uLi4uLi4uLi4uLi4uLi4uLi4uLj0wRD0w
QT0wRD0wQVguNTAwL0xEQVAgU2VtaW5hcnM6IGh0dHA6Ly93d3cuc2FsZm9yZC5hYy51ay9pdHMw
MjQvc2VtaW5hcnMuaHRtLi4uLi4uLi4uLi4uLi4uLi4uLj0wRD0wQT0wRD0wQUVudHJ1c3Qga2V5
IHZhbGlkYXRpb24gc3RyaW5nOiBDSjk0LUxLV0QtQlNYQiAuLi4uLi4uLi4uLj0wRD0wQT0wRD0w
QVBHUCBLZXkgSUQgaXMgMHhCQzIzOERFNQ0KeC1tb3ppbGxhLWNwdDo7LTQ4NTYNCmZuOkRhdmlk
IENoYWR3aWNrDQplbmQ6dmNhcmQNCg==

--0__=C1256B91006CEB198f9e8a93df938690918cC1256B91006CEB19--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34JZmf05665 for ietf-pkix-bks; Thu, 4 Apr 2002 11:35:48 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34JZlm05661 for <[e-mail]>; Thu, 4 Apr 2002 11:35:47 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 4 Apr 2002 11:33:40 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 04 Apr 2002 11:33:40 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <H570PNWK>; Thu, 04 Apr 2002 11:35:16 -0800
Content-return: allowed
Date: Thu, 04 Apr 2002 11:35:14 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
To: "'Housley, Russ'" <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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, Russ,
    I agree with the first phrase:

> "The protocol MUST prevent replay attacks, and the replay prevention 
> mechanism employed by the protocol MUST NOT rely on clocks being 
> synchronized with UTC."

I don't agree with the requirement that a response needs to
contain all the information from the query in itself. That could
result in a lot of extra information that needs to be carried in
the response over what might be a bandwidth constrained channel.

In all cases, being able to tie the response to the request does
the job. If a client needs to be able to show that this response
was for a particular certificate, it can retain the original
request. If the client doesn't need to be able to prove that, it
can discard the request after it gets the response. I don't see
why the response needs to contain
     "the requested validation policy, including associated 
      parameters, if any."

I would prefer the second statement to read:

The DPV client MUST be able to confirm that the DPV server-generated 
response was constructed for the client's request.

(NOTE: I changed Russ's "from" to "for")

A




---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Thursday, April 04, 2002 8:21 AM
> To: Denis Pinkas
> Cc: [e-mail]; [e-mail]
> Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
> 
> 
> Denis:
> 
> I prefer the following wording.  I think it provides the same 
> end result.
> 
> "The protocol MUST prevent replay attacks, and the replay prevention 
> mechanism employed by the protocol MUST NOT rely on clocks being 
> synchronized with UTC."
> 
> (...)
> 
> The DPV client MUST be able to confirm that the DPV server-generated 
> response was constructed from the client's request.  When the 
> response 
> indicates certificate validity, the response MUST allow the 
> DPV client to 
> readily confirm that the response was made for the requested 
> certificate 
> and for the requested validation policy, including associated 
> parameters, 
> if any."
> 
> Russ
> 
> 
> At 03:30 PM 4/4/2002 +0200, Denis Pinkas wrote:
> >"The protocol MUST prevent replay attacks, including for the 
> case where
> >the client does not have a clock synchronized with UTC.
> >
> >(...)
> >
> >The requester MUST be able to verify that the response was 
> constructed
> >taking into consideration all the parameters from the 
> request. In addition,
> >without the need to store the request, a requester SHALL be 
> able to prove
> >that a valid DPV response was made for a given certificate 
> and for a given
> >validation policy, including associated parameters, if any."
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34JVra05593 for ietf-pkix-bks; Thu, 4 Apr 2002 11:31:53 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34JVqm05589 for <[e-mail]>; Thu, 4 Apr 2002 11:31:52 -0800 (PST)
Received: from Chokhani ([12.78.128.169]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020404193148.YJYY38.mtiwmhc22.worldnet.att.net@Chokhani>; Thu, 4 Apr 2002 19:31:48 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'Housley, Russ'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: One last comment on DPD requirements
Date: Thu, 4 Apr 2002 14:33:30 -0500
Message-ID: <002a01c1dc0f$9a260e50$a300a8c0@Chokhani>
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, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
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>

Ambarish:

Your language is acceptable to me as long as the returned path will
satisfy the client requirements for certification path validation.

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Thursday, April 04, 2002 2:12 PM
To: 'Housley, Russ'; Santosh Chokhani
Cc: [e-mail]
Subject: RE: One last comment on DPD requirements



Russ,
    A minor nit - a DPD server might also be a DPV server, who a client
is not willing to trust (and whose work the client wants to verify for
itself).

To summarize, what I think what I hear you, Santosh and Steve say is
that it might make sense to require a DPD server to return a single path
back, but if we want to enable that, we need to let the client specify
his requirements more precisely. Is that correct?

It would make sense to show (in the protocol doc), what those
requirements are for protocols like S/MIME, TLS, IPSec and let other
protocols define their own requirements if they can't fit into one of
the three above.

Does that make sense to you? What about others on the list?

Regards,
Ambarish



---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Thursday, April 04, 2002 7:00 AM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: RE: One last comment on DPD requirements
> 
> 
> 
> Santosh:
> 
> I think that a DPD server will likely perform path
> validation.  Clients 
> will not be happy if the paths that they are given are often 
> invalid.  Clearly, the DPD server cannot know all of the 
> parameters that 
> the client will use for path validation (otherwise it would be a DPV 
> server), but it can make some very reasonable assumptions to 
> ensure that 
> grossly invalid paths are not returned.
> 
> Russ
> 
> At 08:20 PM 4/3/2002 -0500, Santosh Chokhani wrote:
> >Russ:
> >
> >I agree with you, but for a different reason.  I do not think this is

> >application specific issue.  I think it is the path
> validation issue.  I
> >do not think that the DPD server can know which paths are
> good without
> >doing a validation also, specially to see if there will be any name 
> >constraints or certificate policy related failures.
> >
> >-----Original Message-----
> >From: [e-mail]
> [mailto:[e-mail]]
> >On Behalf Of Housley, Russ
> >Sent: Wednesday, April 03, 2002 2:12 PM
> >To: Ambarish Malpani; Stephen Kent
> >Cc: [e-mail]
> >Subject: Re: One last comment on DPD requirements
> >
> >
> >
> >Steve & Ambarish:
> >
> > >>Hi Group,
> > >>     One last (slightly late) comment on the DPD
> requirements that has
> >
> > >>been troubling me:
> > >>
> > >>In the DPD requirements, there is a reasonable amount of text that

> > >>talks about how a server can return multiple paths back
> to the client
> > >>(to allow the client to decide which path is the best).
> > >>
> > >>The main goal of DPD is to try and simplify the client.
> In how many
> > >>cases do people really want multiple paths back from the
> server. While
> >
> > >>it is the right requirement in principal, do folks really think 
> > >>clients will want multiple paths back from a DPD server?
> Are we adding
> >
> > >>the additional flexiblity/complexity just for technical purity?
> > >>
> > >>Comments will be appreciated.
> > >>
> > >>Regards,
> > >>Ambarish
> > >
> > >I too would favor simplifying the protocol requirement
> here. Some folks
> > >have suggested motivations for multiple paths, but this
> does seem to
> > >conflict with the fundamental goal of creating a protocol
> to satisfy
> >the
> > >needs of thin clients.
> > >
> > >Steve
> >
> >I agree with your goal.  It is far better for the client to tell the 
> >server what it wants, then get back a single path that satisfies all 
> >of the requirements.  To do this, we need to be able to fully specify

> >the clients
> >criteria and send them to the server.  I think that we know how to do
> >this
> >for many PKI-enabled applications, but I am not sure that we 
> know how to
> >do
> >it for all applications, especially ones that are yet to be
> developed.
> >
> >This leaves us with two choices.  Either the protocol
> returns multiple
> >certification paths (the approach in the current document) or the 
> >protocol requires the client to adequately specify its criteria.
> This could be
> >done
> >with the path discovery policy.  If we adopt this
> alternative, we should
> >
> >include additional text so that implements expect
> application-specific
> >(perhaps several application-specific path discovery policy
> if there are
> >
> >multiple roles in the application).
> >
> >Russ
> 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34JCMK05076 for ietf-pkix-bks; Thu, 4 Apr 2002 11:12:22 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34JCMm05072 for <[e-mail]>; Thu, 4 Apr 2002 11:12:22 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 4 Apr 2002 11:10:15 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 04 Apr 2002 11:10:14 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <H570PNQZ>; Thu, 04 Apr 2002 11:11:50 -0800
Content-return: allowed
Date: Thu, 04 Apr 2002 11:11:49 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: One last comment on DPD requirements
To: "'Housley, Russ'" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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,
    A minor nit - a DPD server might also be a DPV server, who
a client is not willing to trust (and whose work the client wants
to verify for itself).

To summarize, what I think what I hear you, Santosh and Steve say
is that it might make sense to require a DPD server to return a
single path back, but if we want to enable that, we need to let
the client specify his requirements more precisely. Is that
correct?

It would make sense to show (in the protocol doc), what those
requirements are for protocols like S/MIME, TLS, IPSec and let
other protocols define their own requirements if they can't
fit into one of the three above.

Does that make sense to you? What about others on the list?

Regards,
Ambarish



---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Thursday, April 04, 2002 7:00 AM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: RE: One last comment on DPD requirements
> 
> 
> 
> Santosh:
> 
> I think that a DPD server will likely perform path 
> validation.  Clients 
> will not be happy if the paths that they are given are often 
> invalid.  Clearly, the DPD server cannot know all of the 
> parameters that 
> the client will use for path validation (otherwise it would be a DPV 
> server), but it can make some very reasonable assumptions to 
> ensure that 
> grossly invalid paths are not returned.
> 
> Russ
> 
> At 08:20 PM 4/3/2002 -0500, Santosh Chokhani wrote:
> >Russ:
> >
> >I agree with you, but for a different reason.  I do not think this is
> >application specific issue.  I think it is the path 
> validation issue.  I
> >do not think that the DPD server can know which paths are 
> good without
> >doing a validation also, specially to see if there will be any name
> >constraints or certificate policy related failures.
> >
> >-----Original Message-----
> >From: [e-mail] 
> [mailto:[e-mail]]
> >On Behalf Of Housley, Russ
> >Sent: Wednesday, April 03, 2002 2:12 PM
> >To: Ambarish Malpani; Stephen Kent
> >Cc: [e-mail]
> >Subject: Re: One last comment on DPD requirements
> >
> >
> >
> >Steve & Ambarish:
> >
> > >>Hi Group,
> > >>     One last (slightly late) comment on the DPD 
> requirements that has
> >
> > >>been troubling me:
> > >>
> > >>In the DPD requirements, there is a reasonable amount of text that
> > >>talks about how a server can return multiple paths back 
> to the client
> > >>(to allow the client to decide which path is the best).
> > >>
> > >>The main goal of DPD is to try and simplify the client. 
> In how many
> > >>cases do people really want multiple paths back from the 
> server. While
> >
> > >>it is the right requirement in principal, do folks really think
> > >>clients will want multiple paths back from a DPD server? 
> Are we adding
> >
> > >>the additional flexiblity/complexity just for technical purity?
> > >>
> > >>Comments will be appreciated.
> > >>
> > >>Regards,
> > >>Ambarish
> > >
> > >I too would favor simplifying the protocol requirement 
> here. Some folks
> > >have suggested motivations for multiple paths, but this 
> does seem to
> > >conflict with the fundamental goal of creating a protocol 
> to satisfy
> >the
> > >needs of thin clients.
> > >
> > >Steve
> >
> >I agree with your goal.  It is far better for the client to tell the
> >server
> >what it wants, then get back a single path that satisfies all of the
> >requirements.  To do this, we need to be able to fully specify the
> >clients
> >criteria and send them to the server.  I think that we know how to do
> >this
> >for many PKI-enabled applications, but I am not sure that we 
> know how to
> >do
> >it for all applications, especially ones that are yet to be 
> developed.
> >
> >This leaves us with two choices.  Either the protocol 
> returns multiple
> >certification paths (the approach in the current document) or the
> >protocol
> >requires the client to adequately specify its criteria.  
> This could be
> >done
> >with the path discovery policy.  If we adopt this 
> alternative, we should
> >
> >include additional text so that implements expect 
> application-specific
> >(perhaps several application-specific path discovery policy 
> if there are
> >
> >multiple roles in the application).
> >
> >Russ
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34J6qX04953 for ietf-pkix-bks; Thu, 4 Apr 2002 11:06:52 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34J6pm04949 for <[e-mail]>; Thu, 4 Apr 2002 11:06:51 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 4 Apr 2002 11:04:44 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 04 Apr 2002 11:04:44 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <H570PNP7>; Thu, 04 Apr 2002 11:06:20 -0800
Content-return: allowed
Date: Thu, 04 Apr 2002 11:06:19 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: One last comment on DPD requirements
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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>

Steve,
    I think our goal with both DPV and DPD is to simplify the
client. Yes, we can all come up with outlying cases where the
only way to make things work is to return multiple paths - but
if 99% of the clients don't care about those configurations/cases,
why should we address them in DPV/DPD?

Let's make things easier for the majority of apps. If an app wants
to deal with a really complicated PKI - let them do their own
path gathering and validation.

Makes sense?

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Stephen Farrell [mailto:[e-mail]]
> Sent: Thursday, April 04, 2002 2:35 AM
> To: [e-mail]
> Subject: Re: One last comment on DPD requirements
> 
> 
> 
> 
> And adding another reason: multiple paths may exist which only 
> really differ in their validity fields. Unless the requirements
> call for a pretty complex time specifier in the request the 
> simplest thing is for the server to send back all such paths
> found and let the client sort it out (i.e. even if the client 
> picks a single point in time, there may still be >1 path such 
> that the paths only differ in validity; to close this down some 
> fairly hairy time specifier in the request would have to be
> defined and no clients would bother filling that in properly
> in any case).
> 
> Stephen.
> 
> Santosh Chokhani wrote:
> > 
> > Russ:
> > 
> > I agree with you, but for a different reason.  I do not 
> think this is
> > application specific issue.  I think it is the path 
> validation issue.  I
> > do not think that the DPD server can know which paths are 
> good without
> > doing a validation also, specially to see if there will be any name
> > constraints or certificate policy related failures.
> > 
> > -----Original Message-----
> > From: [e-mail] 
> [mailto:[e-mail]]
> > On Behalf Of Housley, Russ
> > Sent: Wednesday, April 03, 2002 2:12 PM
> > To: Ambarish Malpani; Stephen Kent
> > Cc: [e-mail]
> > Subject: Re: One last comment on DPD requirements
> > 
> > Steve & Ambarish:
> > 
> > >>Hi Group,
> > >>     One last (slightly late) comment on the DPD 
> requirements that has
> > 
> > >>been troubling me:
> > >>
> > >>In the DPD requirements, there is a reasonable amount of text that
> > >>talks about how a server can return multiple paths back 
> to the client
> > >>(to allow the client to decide which path is the best).
> > >>
> > >>The main goal of DPD is to try and simplify the client. 
> In how many
> > >>cases do people really want multiple paths back from the 
> server. While
> > 
> > >>it is the right requirement in principal, do folks really think
> > >>clients will want multiple paths back from a DPD server? 
> Are we adding
> > 
> > >>the additional flexiblity/complexity just for technical purity?
> > >>
> > >>Comments will be appreciated.
> > >>
> > >>Regards,
> > >>Ambarish
> > >
> > >I too would favor simplifying the protocol requirement 
> here. Some folks
> > >have suggested motivations for multiple paths, but this 
> does seem to
> > >conflict with the fundamental goal of creating a protocol 
> to satisfy
> > the
> > >needs of thin clients.
> > >
> > >Steve
> > 
> > I agree with your goal.  It is far better for the client to tell the
> > server
> > what it wants, then get back a single path that satisfies all of the
> > requirements.  To do this, we need to be able to fully specify the
> > clients
> > criteria and send them to the server.  I think that we know 
> how to do
> > this
> > for many PKI-enabled applications, but I am not sure that 
> we know how to
> > do
> > it for all applications, especially ones that are yet to be 
> developed.
> > 
> > This leaves us with two choices.  Either the protocol 
> returns multiple
> > certification paths (the approach in the current document) or the
> > protocol
> > requires the client to adequately specify its criteria.  
> This could be
> > done
> > with the path discovery policy.  If we adopt this 
> alternative, we should
> > 
> > include additional text so that implements expect 
> application-specific
> > (perhaps several application-specific path discovery policy 
> if there are
> > 
> > multiple roles in the application).
> > 
> > Russ
> 
> -- 
> ____________________________________________________________
> Stephen Farrell         				   
> Baltimore Technologies,   tel: (direct line) [phone]
> 39 Parkgate Street,                     fax: [phone]
> Dublin 8.                mailto:[e-mail]
> Ireland                             http://www.baltimore.com
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34Hxcn00549 for ietf-pkix-bks; Thu, 4 Apr 2002 09:59:38 -0800 (PST)
Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34Hxam00544 for <[e-mail]>; Thu, 4 Apr 2002 09:59:37 -0800 (PST)
Received: from sunlabs.East.Sun.COM ([129.148.75.250]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA29471; Thu, 4 Apr 2002 10:59:38 -0700 (MST)
Received: from sun.com (dhcp75-167 [129.148.75.167]) by sunlabs.East.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.2) with ESMTP id MAA14052; Thu, 4 Apr 2002 12:59:37 -0500 (EST)
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 12:56:40 -0500
From: Steve Hanna <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Brian Hunter <[e-mail]>, "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

Actually, trust anchors are *never* part of the path for son-of-2459.
See section 6.1, which defines the valid path as "a sequence of n
certificates [that] satisfies the following conditions:

    (a)  for all x in {1, ..., n-1}, the subject of certificate x is
    the issuer of certificate x+1;

    (b)  certificate 1 is issued by the trust anchor;"

The text quoted by Brian is just a clarification that a self-signed
certificate is not part of the path, even though it could meet the
criteria given above.

So non-self-signed trust anchors (and self-signed trust anchors)
should NOT be considered part of the path for the purposes of
DPD/DPV.

-Steve

Denis Pinkas wrote:
> 
> Brian,
> 
> I concur.
> 
> Denis
> 
> > Russ,
> >
> > > >5. Section 5 Para 4
> > > Trust anchors can be established using self-signed certificates or by other
> > > means, either way, the  trust anchor is not included.  Perhaps this point
> > > is only adding confusion.
> >
> > Not including non-self-signed trust anchors is contrary to Denis' change
> > sent to Ambarish.  I agree with Denis' clarification because it aligns
> > DPD with path validation in 2459bis section 6.1 para 7:
> >
> > "When the trust anchor is provided in the form of a self-signed
> > certificate, this self-signed certificate is not included as part of the
> > prospective certification path."
> >
> > > >9. Section 9 Last paragraph point (3)
> > > >     Is it intended that the validation time should be adjusted for only
> > > >one of the four points, hence the use of "or" after point three? I would
> > > >suggest the use of "and".
> > >
> > > I disagree.  The time could be adjusted for one or more of these
> > > reasons.  It is an inclusive or.
> >
> > See Denis' response to me agreeing with the change to "and".
> > All in all, I think this is a small point, in the scope of this
> > document, but to clarify the meaning, perhaps the use of "and/or" would
> > be appropriate.
> >
> > Brian


Received: by above.proper.com (8.11.6/8.11.3) id g34HjYq00136 for ietf-pkix-bks; Thu, 4 Apr 2002 09:45:34 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34HjXm00130 for <[e-mail]>; Thu, 4 Apr 2002 09:45:33 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g34HjUC18726; Thu, 4 Apr 2002 17:45:30 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020404092415.028b0bd0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 04 Apr 2002 09:45:08 -0800
To: "Ramsay, Ron" <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: LDAPbis scope issue (Was: LDAP Certificate transfer syntax)
Cc: Mark Wahl <[e-mail]>, LDAP BIS <[e-mail]>, PKIX <[e-mail]>
In-Reply-To: <[e-mail]>
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>

At 05:02 PM 2002-04-03, Ramsay, Ron wrote:
>I thought certificate syntax was being removed from the LDAP v3 specs and,
>therefore, certificate syntax was not an issue for DLAPbis?

The LDAPbis WG is chartered specifically to revise the LDAP
"core" technical specification (RFC 2251-2256, 2829-2830).
This schema is part of that "core" specification.

The WG has decided to split the certificate schema into
separate I-Ds that can be independently progressed from
the rest of the "core" specification and to allow individuals
and/or the PKIX WG to taken on this work while LDAPbis
focuses on the rest of the "core".   As the engineering
is being done outside of LDAPbis, the engineers may consider
"new features" (something which LDAPbis cannot do).

However, LDAPbis is still responsible for the "core"
specification and should provide review for any I-D
updating the "core" specification.  This I-D will update
both RFC 2252 and RFC 2256 (if published before LDAPbis
works are published) and, hence, should be subject to
a LDAPbis WG review.

To this end, the PKIX and LDAPbis chairs have agreed that
this work be subject to a joint PKIX/LDAPbis WG Last Call.

Kurt, LDAPbis co-chair



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34HYGL29796 for ietf-pkix-bks; Thu, 4 Apr 2002 09:34:16 -0800 (PST)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34HYFm29792 for <[e-mail]>; Thu, 4 Apr 2002 09:34:15 -0800 (PST)
Received: from tsg1 ([12.81.79.27]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020404173410.XJSY8815.mtiwmhc23.worldnet.att.net@tsg1>; Thu, 4 Apr 2002 17:34:10 +0000
Message-ID: <005401c1dbfe$d6e4cea0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Tom Gindin" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: WG Last Call: Roadmap
Date: Thu, 4 Apr 2002 09:33:29 -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.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
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: "Denis Pinkas" <[e-mail]>
To: "Tom Gindin" <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, April 03, 2002 8:15 AM
Subject: Re: WG Last Call: Roadmap


>
> Tom,
>
> >       I have a few issues with this, and some corrections as well.
>
> >       In comment 12, I have two issues.  The first one, which is minor,
is
> > that  "one or more Top CA's may be trusted" should refer to root CA's
> > instead - the two terms mean the same thing more often than not, but
when
> > they differ the trust point is the root rather than the top.

Perhaps but I would like to point out that the terminology invites
confusion. It should refer to whatever is the trust anchor here.

The key problem with this use is that the indemnetor or guarantor of the
trust may not be the systems operator and so then the "CA's uses only" will
stand for first-person models.



>
> PKIX-1 states:
>
>    " - Top CA - A CA that is at the top of a PKI hierarchy.
>
>    Note: This is often also called a "Root CA," since in data structures
>    terms and in graph theory, the node at the top of a tree is the
>    "root." However, to minimize confusion in this document, we elect to
>    call this node a "Top CA," and reserve "Root CA" for the CA directly
>    trusted by the EE."
>
> The problem lies with the last sentence, i.e. "*the* CA directly trusted
by
> the EE.". The singular is being used which means that there is a single
> one, multiple roots are not permitted, while multiple Top-CAs are
permitted.
>
> >       The second is less minor.  Is it truly intended that a signing EE
> > be permitted to specify the set of trusted CA's for an RP to use in
> > verifying a signature?  At a minimum, an RP in this model is responsible
> > for validating the the set of rules is identical to one it has already
> > decided to trust, but there is no reference in the model description to
> > any active role for the RP.
>
> A verifier (not a signing EE as you mentioned) does not know what an
anchor
> is, but may know what a policy is. So by selecting the policy that applies
> to the application, indirectly trust anchors (and much more) are selected.
> Remember that the same verifier may verify digital signatures in various
> contexts, e.g. for a Bank transaction or for a green reservation in a Golf
> Club. The trust conditions are not necessarilly identical. Note also that
a
> verifier does not need to be a signer and may not have any certificate of
> its own.
>
> The case of a single (root) CA trusted for any kind of application is a
very
> specific case and cannot be considered as the general case.
>
> >       In your comment 5 (on page 15), replace "date of issue" by "date
and
> > time of issue".
>
> This is fine.
>
> >       At a slightly more substantive level, shouldn't the clarification
of
> > the definition of Top CA on page 4 end "and reserve 'root CA' for a CA
> > directly trusted by the EE."?  This wording permits multiple trusted
roots.
>
> I do not think that PKIX-1 allows for this. See the quote above.
>
> >       In your comment 4, shouldn't "CA certificate" be "hierarchical CA
> > certificate"?  Surely a Top CA's self-signed certificate is also a "CA
> > certificate", and your definition excludes it.  Then the sentence "Some
> > people in the WG believe that a cross certificate is a special kind of
CA
> > certificate." is reversed to "... believe that a hierarchical CA
> > certificate is a special kind of cross certificate".

Here again we might refer to the Trust Anchor for this transaction rather
than the CA itself. There is too much complexity in a free form trust system
that has no global standards for its use to date.

A better solution would be to use a more general and as such higher level
language about the Anchoring process or otherwise use of the certificates.

>
> You say that the definition excludes the fact that a Top CA's self-signed
> certificate is also a CA-certificate. This is correct, ... but was not
> intended.
>
> So what about this full correction ?
>
> [2459bis] defines a cross-certificate as "a certificate issued by one CA
to
> another CA". [2459bis] does not provide a formal definition of a CA
> certificate but implictly means a certificate where the subject of the
> certificate is a CA.

> This means that self-signed certificates are CA
> certificates but are not cross-certificates.

cant or better yet, shouldn't the ultimate source of any trust chain have a
self-signed cert as its core anchor? Just makes sense I think.

> Some people in the WG believe
> that a cross certificate is a special kind of CA certificate issued by a
CA
> under one Top CA for another CA under a different Top CA.

these are use rules and have little to do with the protocol itself.

> CAs in the same
> hierarchy usually have part of their names imposed by the Top CA or by the
> CAs under that Top CAs. When a cross certificate is issued, there is no
> relationship between the names of the CAs.
>
> >       In comment 11, the i.e. should remain "what are the root CA's"
rather
> > than "what are the Top CA's", for the same reason as in comment 12.
>




Received: by above.proper.com (8.11.6/8.11.3) id g34HMtf29518 for ietf-pkix-bks; Thu, 4 Apr 2002 09:22:55 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34HMsm29514 for <[e-mail]>; Thu, 4 Apr 2002 09:22:54 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g34HMkC18627; Thu, 4 Apr 2002 17:22:46 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020404091310.02796bc0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 04 Apr 2002 09:22:58 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
Cc: [e-mail], "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <001001c1db7f$751e3cd0$[e-mail]>
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>

At 05:09 AM 2002-04-04, David Chadwick wrote:
>thanks for your messages that have clearly stated the case that ;binary
>is needed as a general transfer encoding, and that many attributes exist
>without a native LDAP encoding being defined for them.
>
>But this does raise the more general issue of how does a user who asks
>for "all" attributes, deal with those which are returned, whose native
>encoding he is unfamiliar with. Does the server assume the client knows
>(in which case ;binary will only be used on those attributes with no
>native encoding defined) or does not know (in which case ;binary will
>need to be used on all attributes that are not defined in Internet
>standard RFCs).

This is being addressed, in general, in the LDAPbis protocol I-D
(draft-ietf-ldapbis-protocol-xx.txt).

I think we have consensus on the handling of options, including
transfer options, in general.  However, IIRC, Jim needs to revise
the text slightly to address a couple of cases (such as handling
of '*').

I think it very important certificate schema not be a 'special
case'.   I am concerned that adding a 'native' encoding to
certificate schema will necessity the need for a 'special case'.
In particular, in the handling of '*' as the general handling
is to return the native encoding (no transfer option) if one
is defined and supported.


>Seems like ASN.1 DAP had some advantages after all :-)

DAP, in many ways, is lighter than LDAP.  :-(

Kurt



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34GLU925345 for ietf-pkix-bks; Thu, 4 Apr 2002 08:21:30 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g34GLTm25338 for <[e-mail]>; Thu, 4 Apr 2002 08:21:29 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Apr 2002 16:20:34 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA03172; Thu, 4 Apr 2002 11:20:28 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g34GLW426986; Thu, 4 Apr 2002 11:21:32 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX13PZ7>; Thu, 4 Apr 2002 11:19:08 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.66]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX13PZ6; Thu, 4 Apr 2002 11:19:06 -0500
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 04 Apr 2002 11:21:25 -0500
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
In-Reply-To: <[e-mail]>
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>

Denis:

I prefer the following wording.  I think it provides the same end result.

"The protocol MUST prevent replay attacks, and the replay prevention 
mechanism employed by the protocol MUST NOT rely on clocks being 
synchronized with UTC."

(...)

The DPV client MUST be able to confirm that the DPV server-generated 
response was constructed from the client's request.  When the response 
indicates certificate validity, the response MUST allow the DPV client to 
readily confirm that the response was made for the requested certificate 
and for the requested validation policy, including associated parameters, 
if any."

Russ


At 03:30 PM 4/4/2002 +0200, Denis Pinkas wrote:
>"The protocol MUST prevent replay attacks, including for the case where
>the client does not have a clock synchronized with UTC.
>
>(...)
>
>The requester MUST be able to verify that the response was constructed
>taking into consideration all the parameters from the request. In addition,
>without the need to store the request, a requester SHALL be able to prove
>that a valid DPV response was made for a given certificate and for a given
>validation policy, including associated parameters, if any."


Received: by above.proper.com (8.11.6/8.11.3) id g34GGl624555 for ietf-pkix-bks; Thu, 4 Apr 2002 08:16:47 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g34GGem24535 for <[e-mail]>; Thu, 4 Apr 2002 08:16:40 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Apr 2002 16:15:45 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA02653; Thu, 4 Apr 2002 11:15:39 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g34GGhv26343; Thu, 4 Apr 2002 11:16:43 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX13PW2>; Thu, 4 Apr 2002 11:14:19 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.66]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX13PWF; Thu, 4 Apr 2002 11:14:16 -0500
From: "Housley, Russ" <[e-mail]>
To: Brian Hunter <[e-mail]>
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 04 Apr 2002 10:59:35 -0500
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.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>

Brian:

> > >5. Section 5 Para 4
> > Trust anchors can be established using self-signed certificates or by other
> > means, either way, the  trust anchor is not included.  Perhaps this point
> > is only adding confusion.
>
>Not including non-self-signed trust anchors is contrary to Denis' change
>sent to Ambarish.  I agree with Denis' clarification because it aligns
>DPD with path validation in 2459bis section 6.1 para 7:
>
>"When the trust anchor is provided in the form of a self-signed
>certificate, this self-signed certificate is not included as part of the
>prospective certification path."

Fine.

> > >9. Section 9 Last paragraph point (3)
> > >     Is it intended that the validation time should be adjusted for only
> > >one of the four points, hence the use of "or" after point three? I would
> > >suggest the use of "and".
> >
> > I disagree.  The time could be adjusted for one or more of these
> > reasons.  It is an inclusive or.
>
>See Denis' response to me agreeing with the change to "and".
>All in all, I think this is a small point, in the scope of this
>document, but to clarify the meaning, perhaps the use of "and/or" would
>be appropriate.

I can live with "and/or"

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34F6LP20744 for ietf-pkix-bks; Thu, 4 Apr 2002 07:06:21 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34F6Jm20738 for <[e-mail]>; Thu, 4 Apr 2002 07:06:20 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id KAA06053; Thu, 4 Apr 2002 10:06:14 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100300b8d151bd0ef5@[128.89.88.34]>
In-Reply-To:  <[e-mail] v.microsoft.com>
References:  <[e-mail] v.microsoft.com>
Date: Thu, 4 Apr 2002 10:05:12 -0500
To: "Trevor Freeman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: One last comment on DPD requirements
Cc: <[e-mail]>
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>

At 4:25 PM -0800 4/3/02, Trevor Freeman wrote:
>To state that a client has to be exacting over its specification and
>only wants one chain returned is presupposing the application model.
>There are applications which are more comfortable with making a vague
>request, getting back multiple chains to which they apply their own
>policy. One of the specifications to the server can be find me all paths
>that meet these criteria. I think the simple case on only wanting a
>single chain is the most common so making that the default is fine.

Trevor,

That may a good way to reconcile this issue.  Make single path return 
the default and require support for that by all clients.  Require a 
client that wants multiple paths, and is capable of using them, to 
explicitly enable a multi-path return option, so that only such 
clients receive multiple paths.  Maybe we also could have a return 
code to signal that even though only one path was returned, as per 
the client's (default) request, that other paths are available from 
the server (relative to this request).

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34Exsv20455 for ietf-pkix-bks; Thu, 4 Apr 2002 06:59:54 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g34Exqm20451 for <[e-mail]>; Thu, 4 Apr 2002 06:59:52 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 4 Apr 2002 14:58:57 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id JAA23259 for <[e-mail]>; Thu, 4 Apr 2002 09:58:51 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g34ExtZ15144 for <[e-mail]>; Thu, 4 Apr 2002 09:59:55 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX133C1>; Thu, 4 Apr 2002 09:57:31 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.181]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX133CA; Thu, 4 Apr 2002 09:57:25 -0500
From: "Housley, Russ" <[e-mail]>
To: Santosh Chokhani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 04 Apr 2002 09:59:43 -0500
Subject: RE: One last comment on DPD requirements
In-Reply-To: <003b01c1db76$ee825fb0$a300a8c0@Chokhani>
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>

Santosh:

I think that a DPD server will likely perform path validation.  Clients 
will not be happy if the paths that they are given are often 
invalid.  Clearly, the DPD server cannot know all of the parameters that 
the client will use for path validation (otherwise it would be a DPV 
server), but it can make some very reasonable assumptions to ensure that 
grossly invalid paths are not returned.

Russ

At 08:20 PM 4/3/2002 -0500, Santosh Chokhani wrote:
>Russ:
>
>I agree with you, but for a different reason.  I do not think this is
>application specific issue.  I think it is the path validation issue.  I
>do not think that the DPD server can know which paths are good without
>doing a validation also, specially to see if there will be any name
>constraints or certificate policy related failures.
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>On Behalf Of Housley, Russ
>Sent: Wednesday, April 03, 2002 2:12 PM
>To: Ambarish Malpani; Stephen Kent
>Cc: [e-mail]
>Subject: Re: One last comment on DPD requirements
>
>
>
>Steve & Ambarish:
>
> >>Hi Group,
> >>     One last (slightly late) comment on the DPD requirements that has
>
> >>been troubling me:
> >>
> >>In the DPD requirements, there is a reasonable amount of text that
> >>talks about how a server can return multiple paths back to the client
> >>(to allow the client to decide which path is the best).
> >>
> >>The main goal of DPD is to try and simplify the client. In how many
> >>cases do people really want multiple paths back from the server. While
>
> >>it is the right requirement in principal, do folks really think
> >>clients will want multiple paths back from a DPD server? Are we adding
>
> >>the additional flexiblity/complexity just for technical purity?
> >>
> >>Comments will be appreciated.
> >>
> >>Regards,
> >>Ambarish
> >
> >I too would favor simplifying the protocol requirement here. Some folks
> >have suggested motivations for multiple paths, but this does seem to
> >conflict with the fundamental goal of creating a protocol to satisfy
>the
> >needs of thin clients.
> >
> >Steve
>
>I agree with your goal.  It is far better for the client to tell the
>server
>what it wants, then get back a single path that satisfies all of the
>requirements.  To do this, we need to be able to fully specify the
>clients
>criteria and send them to the server.  I think that we know how to do
>this
>for many PKI-enabled applications, but I am not sure that we know how to
>do
>it for all applications, especially ones that are yet to be developed.
>
>This leaves us with two choices.  Either the protocol returns multiple
>certification paths (the approach in the current document) or the
>protocol
>requires the client to adequately specify its criteria.  This could be
>done
>with the path discovery policy.  If we adopt this alternative, we should
>
>include additional text so that implements expect application-specific
>(perhaps several application-specific path discovery policy if there are
>
>multiple roles in the application).
>
>Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34EHb818476 for ietf-pkix-bks; Thu, 4 Apr 2002 06:17:37 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34EHYm18472 for <[e-mail]>; Thu, 4 Apr 2002 06:17:34 -0800 (PST)
Received: from stsIBMT20.addtrust.com ([213.64.0.113]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 4 Apr 2002 16:17:27 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 04 Apr 2002 16:10:51 +0200
To: Denis Pinkas <[e-mail]>, "Housley, Russ" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
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-OriginalArrivalTime: 04 Apr 2002 14:17:28.0383 (UTC) FILETIME=[736F7CF0:01C1DBE3]
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 absolutely welcome a technical discussion and my last mail was not 
intended to offend you by any means.

I'll try to answer all "technical" questions I can find.

At 17:55 2002-04-03 +0200, Denis Pinkas wrote:

>Russ,
>
>Thank you for this long reply ... that did not convinced me.
>The argumentation you provided is not crystal clear to me.
>
>See my comments below.
>
> > Denis:
> >
> > I fear that you have missed the point of the logotypes draft
> > altogether.  The authors recognize that the introduction needs to be
> > expanded, so we may be to blame for any misunderstanding.  To try and clear
> > up the misunderstanding, I offer some general observations before
> > responding to your specific comments.
> >
> > The logotype extension will aid in two situations:
> >         1.  Certificate-based Identification
> >         2.  Selection of Certificates
> >
> > In the first case, the need for human recognition
>
>1) Recognition of what ? or of which characteristics ?
>    Please be precise.
>
>2) Recognized by which entity ? Please be precise.
>    I would guess a human being acting as a relying party.

Yes.

> > depends on the manner in
> > which certificates are used and whether certificates need to be visible to
> > human users. If certificates are to be used in open environments and in
> > applications that bring the user in conscious contact with the result of a
> > certificate-based identification process, then human recognition is highly
> > relevant, and it may be a necessity.
> >
> > Most applications provide the human user with an opportunity to view the
> > results of a successful certificate-based identification process.  When the
> > user takes the steps necessary to view these results, the user is presented
> > with a view of a certificate. This solution has two major problems.  First,
> > the function to view a certificate is often rather hard to find for a
> > non-technical user. Second, the presentation of the certificate is rather
> > technical; it is not user friendly. It contains no graphic symbols or
> > logotypes to enhance human recognition.
>
> > In the second case, there are software applications that expose human users
> > to certificates for the selection of a single certificate from a portfolio
> > of certificates. In some circumstances, the software application can use
> > information within the certificates to determine suitability; however, the
> > user must be queried if more than one certificate is suitable. The human
> > user must select one of them.
>
>I would guess that is that case it is a recognition by the subscriber.
>Is it what you mean ? Are there other cases you are thinking of ?
>Please be precise.

Can't understand your question. Please clarify.

> > This situation is comparable to a person selecting a suitable plastic card
> > from his wallet. In this situation, substantial assistance is provided by
> > card color, location, and branding.
> >
> > In order provide similar support for certificate selection, the users need
> > tools to easily recognize and distinguish certificates. Introduction of
> > logotypes into certificates provides the necessary graphic.
>
> > Now, for your specific comments.
> >
> > COMMENT 1: Subject logotype.
> >
> > Currently a "subject organization logotype" is proposed. It definition is
> > as follows: "a logotype representing the organization identified in the
> > subject name in the certificate".
> >
> >  From this definition only a single logotype would be allowed for a
> > subject. It can make sense to attach more that one logotype to a subject,
> > that does not reflect necessarily the organization a user belongs to (e.g.
> > an individual is a Red Cross member) so the definition should be changed
> > to:
> >
> > "subject logotype" "a logotype representing any characteristic of the
> > entity identified in the subject name in the certificate".
> >
> > RESPONSE 1.
> >
> > We are allowing a graphical identity of the user to facilitate certificate
> > selection or acceptance. We are not trying to graphically represent every
> > attribute of the user.  We certainly do not want to overwhelm the designers
> > of graphic user interfaces.  We need to keep it simple.
>
>I do not buy this argument. The current proposal limits to logo type to the
>logo of the organization, whereas this limitation is not appropriate. A
>subject may even have no O (Organization) component in the DN and there
>could
>be other logos attached to the subject field.

Not a technical issue but an issue regarding the intent of the solution. 
The intent of the solution is to represent the subject organization.

If you have other usage scenarios please describe them in more clarity.


> > COMMENT 2: Issuer logotype.
> >
> > Currently an "issuer organization logotype" is proposed. It definition is
> > as follows: "a logotype representing the organization identified as part of
> > the issuer name in the certificate".
> >
> >  From this definition a single logotype would be allowed for an issuer. It
> > can make sense to attach more that one logotype to an issuer, that does not
> > reflect necessarily the organization an issuer belongs to (e.g. an issuer
> > may support a "Privacy Policy" and be a member from two different trade
> > associations), so the definition should be changed to:
> >
> > "issuer logotype: a logotype representing any characteristic of the issuer
> > identified as part of the issuer name in the certificate".
> >
> > RESPONSE 2.
> >
> > Again, we are allowing a graphical identity of the user to facilitate
> > certificate selection or acceptance. We are not trying to graphically
> > represent every attribute of the issuer.
>
>I do not buy this argument. The current proposal limits to logo type to the
>logo of the issuer, whereas this limitation is not appropriate. See my
>examples again.
>
> > COMMENT 3: The "concept logotype", also renamed "community logotype" during
> > the last IETF meeting or " shared community logotype" in the minutes from
> > the same meeting is more hazy.
> >
> > The current text states:" Many issuers may use the concept logotypes to
> > co-brand with a global concept in order to gain global recognition of its
> > local service provision. This type of concept branding is very common in
> > credit card business where local independent card issuers issue cards
> > within a globally branded concept (such as VISA and MasterCard)".
> >
> > The current text also states: " the relationship between the issuer and
> > either the issuer  organization logotype or the concept logotype".
> >
> > A logotype is adding "human processable" information to enhance the
> > properties of an already existing field from a certificate. To this respect
> > it is sensible to add one (or more) logotypes that characterizes the issuer
> > and the subject. The real question is to which field the "concept
> > logotype / community logotype / shared community logotype" relates.
> >
> > It may relate :
> >    - either to the issuer, to state that an issuer belongs to some 
> group, or
> >    - to the certificate policy to state that the policy under which the
> >      certificate is issued obeys to some rules imposed by the organization
> >      whose logo is referenced.
> >
> > This leads to two possible ways:
> >     1) only consider two logotypes: issuer logotype and subject logotypes.
> >     2) consider three logotypes: issuer logotypes, subject logotypes and
> >        policy logotypes.
> >
> > I would favor the former, but would have no major problem to go with the
> > later. In that case the policy logotype would be defined as follows:
> >
> > "Policy logotype: a logotype representing any characteristic of the
> > certificate policy under which the certificate is issued".
> >
> > RESPONSE 3.
> >
> > Policy implies the wrong connotation. We are not trying to graphically
> > represent a certificate policy or anything about how the certificate was
> > issued. The community (or concept) logotype simply allows CA to enter into
> > collective branding relationships.
>
>A branding of what ?  Please be precise.
>
> > I suppose that a large group that share a common security policy could
> > register a logo for that policy and use it as a community logo.  While this
> > was not the model that we considered, it certainly is accommodated.
> >
> > COMMENT 4: Logotypes are not "claimed" by the issuer, but always *verified*
> > to some extend by the issuer. The current text is misleading:
> >
> >     "The relationship between the subject organization and the subject
> >     organization logotype and the relationship between the issuer and
> >     either the issuer organization logotype or the concept logotype, are
> >     relationships *claimed* by the issuer."
> >
> > RESPONSE 4.
> >
> > The issuer is responsible for the verification of anything that is included
> > in the certificate.  After all, the issuer signature covers it.  Thus, the
> > issuer is claiming that the logotypes are appropriate.
>
>Don't twist the wording.  :-)
>
>We agree on the concept, but we should try to use another wording and avoid
>to use the word "claim".
>
> > COMMENT 5: During the meeting, it has been proposed to add a small image of
> > the logotype in the certificate itself. In this WG we always have had a
> > concern about the size of the certificate, so that it can be lodged in some
> > small devices. So I would not favor to allow such provision in a
> > extension standardized by this WG.
> >
> > RESPONSE 5.
> >
> > There are environments where the client cannot access the Internet until
> > after the certificate is used.  Consider certificate-based authentication
> > to an ISP.  A small logotype in the certificate could be useful to aid
> > certificate selection in this situation.  The inclusion of a small logotype
> > is, of course, optional.
>
>...and instead of certificates between 1 K and 2 K bytes, have certificates
>with at least one more K !
>
>Denis

This issue is a matter of balance between space and functionality.I don't 
believe you can argue that there is any right and wrong here.

Personally I believe that the space used is worth it in many cases.

Do you have any "technical" issues with this. e.g. cases where this would 
create certain problems we should be aware about.

>
> > COMMENT 6: It should be made clear that this extension in non-critical.
> >
> > RESPONSE 6.
> >
> > Agree.  The logotype extension was never intended to be critical.
> >
> > COMMENT 7: The document includes many typos to be corrected.
> >
> > RESPONSE 7.
> >
> > We will make every effort to correct them before the next draft is 
> published.
> >
> > Russ


/Stefan



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34DegP15939 for ietf-pkix-bks; Thu, 4 Apr 2002 05:40:42 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34Deem15933 for <[e-mail]>; Thu, 4 Apr 2002 05:40:40 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA21668; Thu, 4 Apr 2002 15:42:58 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040415401478:69 ; Thu, 4 Apr 2002 15:40:14 +0200 
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 15:35:29 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, Ambarish Malpani <[e-mail]>, Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: One last comment on DPD requirements
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/04/2002 15:40:14, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/04/2002 15:40:29, Serialize complete at 04/04/2002 15:40:29
Content-Transfer-Encoding: 7bit
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>

Trevor,

I agree with you.

The current text states that some forms of path discovery policy can be
simple. This is because rough selection criteria can be set for DPD, 
while more precise are needed for DPV. It does make sense to return multiple
path, if specifially requested.

Denis 

 
> To state that a client has to be exacting over its specification and
> only wants one chain returned is presupposing the application model.
> There are applications which are more comfortable with making a vague
> request, getting back multiple chains to which they apply their own
> policy. One of the specifications to the server can be find me all paths
> that meet these criteria. I think the simple case on only wanting a
> single chain is the most common so making that the default is fine.
> 
> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Wednesday, April 03, 2002 11:12 AM
> To: Ambarish Malpani; Stephen Kent
> Cc: [e-mail]
> Subject: Re: One last comment on DPD requirements
> 
> Steve & Ambarish:
> 
> >>Hi Group,
> >>     One last (slightly late) comment on the DPD requirements that
> >>has been troubling me:
> >>
> >>In the DPD requirements, there is a reasonable amount of text that
> >>talks about how a server can return multiple paths back to the
> >>client (to allow the client to decide which path is the best).
> >>
> >>The main goal of DPD is to try and simplify the client. In how many
> >>cases do people really want multiple paths back from the server.
> >>While it is the right requirement in principal, do folks really
> >>think clients will want multiple paths back from a DPD server? Are
> >>we adding the additional flexiblity/complexity just for
> >>technical purity?
> >>
> >>Comments will be appreciated.
> >>
> >>Regards,
> >>Ambarish
> >
> >I too would favor simplifying the protocol requirement here. Some folks
> 
> >have suggested motivations for multiple paths, but this does seem to
> >conflict with the fundamental goal of creating a protocol to satisfy
> the
> >needs of thin clients.
> >
> >Steve
> 
> I agree with your goal.  It is far better for the client to tell the
> server
> what it wants, then get back a single path that satisfies all of the
> requirements.  To do this, we need to be able to fully specify the
> clients
> criteria and send them to the server.  I think that we know how to do
> this
> for many PKI-enabled applications, but I am not sure that we know how to
> do
> it for all applications, especially ones that are yet to be developed.
> 
> This leaves us with two choices.  Either the protocol returns multiple
> certification paths (the approach in the current document) or the
> protocol
> requires the client to adequately specify its criteria.  This could be
> done
> with the path discovery policy.  If we adopt this alternative, we should
> 
> include additional text so that implements expect application-specific
> (perhaps several application-specific path discovery policy if there are
> 
> multiple roles in the application).
> 
> Russ


Received: by above.proper.com (8.11.6/8.11.3) id g34DaLw15428 for ietf-pkix-bks; Thu, 4 Apr 2002 05:36:21 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34DaKm15422 for <[e-mail]>; Thu, 4 Apr 2002 05:36:20 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA03646; Thu, 4 Apr 2002 15:38:45 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040415354326:67 ; Thu, 4 Apr 2002 15:35:43 +0200 
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 15:30:59 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/04/2002 15:35:43, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/04/2002 15:36:15, Serialize complete at 04/04/2002 15:36:15
Content-Transfer-Encoding: 7bit
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>

Ambarish,

> > If the protocol does choose to return the requestHash in the response, do
> > you see any benefit to adding a requestNonce in the response? If not, the
> > requirement should go. I think it would be better for the requirements doc
> > to say what is desired: "Prevent replay attacks on responses" and let the
> > protocol decide how to do it.
> >
> I seem to agree with Ambarish that the current texts is an overspecification.
 
> Thus, a simple text like: "The protocol MUST provide a means to
> protect itself against replay attacks." seems sufficient for this
> document.

The current text is:

"In order to prevent replay attacks, the DPV client MUST be able to 
include a nonce in the DPV request. When the nonce is present in the 
request, then the DPV server MUST include the same nonce in the 
response.

(...)

The DPV response MUST be bound to the DPV request. This can be 
accomplished by repeating the important components from the request in 
the response or by including a one-way hash of the request in the 
response."

The new proposal is:

"The protocol MUST prevent replay attacks, including for the case where 
the client does not have a clock synchronized with UTC.

(...)

The requester MUST be able to verify that the response was constructed 
taking into consideration all the parameters from the request. In addition, 
without the need to store the request, a requester SHALL be able to prove 
that a valid DPV response was made for a given certificate and for a given 
validation policy, including associated parameters, if any." 

Now, a few explanations:

1) The sentence "including for the case where the client does not have a
clock synchronized with UTC" implies the use of a nonce. 

2) Placing a requestHash in the response is fine to make sure that no
information has been dropped or changed on its way to the server. However
this is not sufficient. Clients would like to store valid responses, without
the need to store the whole request as well, that may include a bunch of
certificates, CRLs and OCSP responses. In many cases, clients want to store
the "YES" answer and only prove that the YES is about THIS certificate and
THIS validation POLICY. Hence the need to include in the response both the
reference of the certificate and the reference of the policy to keep the
response as short as possible (in particular for thin clients).  

It is anticipated that in many applications, clients will only need a valid
DPV response, without the path and the associated revocation information.

Denis
 
> Peter


Received: by above.proper.com (8.11.6/8.11.3) id g34DXdU15198 for ietf-pkix-bks; Thu, 4 Apr 2002 05:33:39 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34DXbm15194 for <[e-mail]>; Thu, 4 Apr 2002 05:33:37 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA17964; Thu, 4 Apr 2002 15:35:57 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040415330081:65 ; Thu, 4 Apr 2002 15:33:00 +0200 
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 15:28:20 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Brian Hunter <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/04/2002 15:33:00, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/04/2002 15:33:27, Serialize complete at 04/04/2002 15:33:27
Content-Transfer-Encoding: 7bit
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>

Brian,

I concur.

Denis


> Russ,
> 
> > >5. Section 5 Para 4
> > Trust anchors can be established using self-signed certificates or by other
> > means, either way, the  trust anchor is not included.  Perhaps this point
> > is only adding confusion.
> 
> Not including non-self-signed trust anchors is contrary to Denis' change
> sent to Ambarish.  I agree with Denis' clarification because it aligns
> DPD with path validation in 2459bis section 6.1 para 7:
> 
> "When the trust anchor is provided in the form of a self-signed
> certificate, this self-signed certificate is not included as part of the
> prospective certification path."
> 
> > >9. Section 9 Last paragraph point (3)
> > >     Is it intended that the validation time should be adjusted for only
> > >one of the four points, hence the use of "or" after point three? I would
> > >suggest the use of "and".
> >
> > I disagree.  The time could be adjusted for one or more of these
> > reasons.  It is an inclusive or.
> 
> See Denis' response to me agreeing with the change to "and".
> All in all, I think this is a small point, in the scope of this
> document, but to clarify the meaning, perhaps the use of "and/or" would
> be appropriate.
> 
> Brian


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34DWqZ15075 for ietf-pkix-bks; Thu, 4 Apr 2002 05:32:52 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34DWom15067 for <[e-mail]>; Thu, 4 Apr 2002 05:32:50 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA10372; Thu, 4 Apr 2002 15:35:15 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040415323433:64 ; Thu, 4 Apr 2002 15:32:34 +0200 
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 15:27:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Stefan Santesson <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/04/2002 15:32:34, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 04/04/2002 15:32:45, Serialize complete at 04/04/2002 15:32:45
Content-Transfer-Encoding: 7bit
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,

Your "feeling" is wrong. At the Minneapolis meeting you welcomed a technical
discussion on that topic. Please, go back to a technical discussion.

Regards,

Denis


> Denis,
> 
> Generally I have some problems with your way of arguing. My observation is
> that you ask us to be precise where there is no point in being precise and
> you fail to be precise yourself where your arguments need to be backed by
> facts and examples.
> 
> At least I think it would be fair of you to try to understand what the
> draft was written to solve and either argue that we try to find a solution
> to the wrong problem or that we try to solve the right problem the wrong way.
> 
> Right now I feel that you claim that we solve the wrong problem the wrong
> way, which is a rather hopeless originating discussion point.
> 
> /Stefan
> 
> At 17:55 2002-04-03 +0200, Denis Pinkas wrote:
> 
> >Russ,
> >
> >Thank you for this long reply ... that did not convinced me.
> >The argumentation you provided is not crystal clear to me.
> >
> >See my comments below.
> >
> > > Denis:
> > >
> > > I fear that you have missed the point of the logotypes draft
> > > altogether.  The authors recognize that the introduction needs to be
> > > expanded, so we may be to blame for any misunderstanding.  To try and clear
> > > up the misunderstanding, I offer some general observations before
> > > responding to your specific comments.
> > >
> > > The logotype extension will aid in two situations:
> > >         1.  Certificate-based Identification
> > >         2.  Selection of Certificates
> > >
> > > In the first case, the need for human recognition
> >
> >1) Recognition of what ? or of which characteristics ?
> >    Please be precise.
> >
> >2) Recognized by which entity ? Please be precise.
> >    I would guess a human being acting as a relying party.
> >
> > > depends on the manner in
> > > which certificates are used and whether certificates need to be visible to
> > > human users. If certificates are to be used in open environments and in
> > > applications that bring the user in conscious contact with the result of a
> > > certificate-based identification process, then human recognition is highly
> > > relevant, and it may be a necessity.
> > >
> > > Most applications provide the human user with an opportunity to view the
> > > results of a successful certificate-based identification process.  When the
> > > user takes the steps necessary to view these results, the user is presented
> > > with a view of a certificate. This solution has two major problems.  First,
> > > the function to view a certificate is often rather hard to find for a
> > > non-technical user. Second, the presentation of the certificate is rather
> > > technical; it is not user friendly. It contains no graphic symbols or
> > > logotypes to enhance human recognition.
> >
> > > In the second case, there are software applications that expose human users
> > > to certificates for the selection of a single certificate from a portfolio
> > > of certificates. In some circumstances, the software application can use
> > > information within the certificates to determine suitability; however, the
> > > user must be queried if more than one certificate is suitable. The human
> > > user must select one of them.
> >
> >I would guess that is that case it is a recognition by the subscriber.
> >Is it what you mean ? Are there other cases you are thinking of ?
> >Please be precise.
> >
> > > This situation is comparable to a person selecting a suitable plastic card
> > > from his wallet. In this situation, substantial assistance is provided by
> > > card color, location, and branding.
> > >
> > > In order provide similar support for certificate selection, the users need
> > > tools to easily recognize and distinguish certificates. Introduction of
> > > logotypes into certificates provides the necessary graphic.
> >
> > > Now, for your specific comments.
> > >
> > > COMMENT 1: Subject logotype.
> > >
> > > Currently a "subject organization logotype" is proposed. It definition is
> > > as follows: "a logotype representing the organization identified in the
> > > subject name in the certificate".
> > >
> > >  From this definition only a single logotype would be allowed for a
> > > subject. It can make sense to attach more that one logotype to a subject,
> > > that does not reflect necessarily the organization a user belongs to (e.g.
> > > an individual is a Red Cross member) so the definition should be changed
> > > to:
> > >
> > > "subject logotype" "a logotype representing any characteristic of the
> > > entity identified in the subject name in the certificate".
> > >
> > > RESPONSE 1.
> > >
> > > We are allowing a graphical identity of the user to facilitate certificate
> > > selection or acceptance. We are not trying to graphically represent every
> > > attribute of the user.  We certainly do not want to overwhelm the designers
> > > of graphic user interfaces.  We need to keep it simple.
> >
> >I do not buy this argument. The current proposal limits to logo type to the
> >logo of the organization, whereas this limitation is not appropriate. A
> >subject may even have no O (Organization) component in the DN and there
> >could
> >be other logos attached to the subject field.
> >
> > > COMMENT 2: Issuer logotype.
> > >
> > > Currently an "issuer organization logotype" is proposed. It definition is
> > > as follows: "a logotype representing the organization identified as part of
> > > the issuer name in the certificate".
> > >
> > >  From this definition a single logotype would be allowed for an issuer. It
> > > can make sense to attach more that one logotype to an issuer, that does not
> > > reflect necessarily the organization an issuer belongs to (e.g. an issuer
> > > may support a "Privacy Policy" and be a member from two different trade
> > > associations), so the definition should be changed to:
> > >
> > > "issuer logotype: a logotype representing any characteristic of the issuer
> > > identified as part of the issuer name in the certificate".
> > >
> > > RESPONSE 2.
> > >
> > > Again, we are allowing a graphical identity of the user to facilitate
> > > certificate selection or acceptance. We are not trying to graphically
> > > represent every attribute of the issuer.
> >
> >I do not buy this argument. The current proposal limits to logo type to the
> >logo of the issuer, whereas this limitation is not appropriate. See my
> >examples again.
> >
> > > COMMENT 3: The "concept logotype", also renamed "community logotype" during
> > > the last IETF meeting or " shared community logotype" in the minutes from
> > > the same meeting is more hazy.
> > >
> > > The current text states:" Many issuers may use the concept logotypes to
> > > co-brand with a global concept in order to gain global recognition of its
> > > local service provision. This type of concept branding is very common in
> > > credit card business where local independent card issuers issue cards
> > > within a globally branded concept (such as VISA and MasterCard)".
> > >
> > > The current text also states: " the relationship between the issuer and
> > > either the issuer  organization logotype or the concept logotype".
> > >
> > > A logotype is adding "human processable" information to enhance the
> > > properties of an already existing field from a certificate. To this respect
> > > it is sensible to add one (or more) logotypes that characterizes the issuer
> > > and the subject. The real question is to which field the "concept
> > > logotype / community logotype / shared community logotype" relates.
> > >
> > > It may relate :
> > >    - either to the issuer, to state that an issuer belongs to some
> > group, or
> > >    - to the certificate policy to state that the policy under which the
> > >      certificate is issued obeys to some rules imposed by the organization
> > >      whose logo is referenced.
> > >
> > > This leads to two possible ways:
> > >     1) only consider two logotypes: issuer logotype and subject logotypes.
> > >     2) consider three logotypes: issuer logotypes, subject logotypes and
> > >        policy logotypes.
> > >
> > > I would favor the former, but would have no major problem to go with the
> > > later. In that case the policy logotype would be defined as follows:
> > >
> > > "Policy logotype: a logotype representing any characteristic of the
> > > certificate policy under which the certificate is issued".
> > >
> > > RESPONSE 3.
> > >
> > > Policy implies the wrong connotation. We are not trying to graphically
> > > represent a certificate policy or anything about how the certificate was
> > > issued. The community (or concept) logotype simply allows CA to enter into
> > > collective branding relationships.
> >
> >A branding of what ?  Please be precise.
> >
> > > I suppose that a large group that share a common security policy could
> > > register a logo for that policy and use it as a community logo.  While this
> > > was not the model that we considered, it certainly is accommodated.
> > >
> > > COMMENT 4: Logotypes are not "claimed" by the issuer, but always *verified*
> > > to some extend by the issuer. The current text is misleading:
> > >
> > >     "The relationship between the subject organization and the subject
> > >     organization logotype and the relationship between the issuer and
> > >     either the issuer organization logotype or the concept logotype, are
> > >     relationships *claimed* by the issuer."
> > >
> > > RESPONSE 4.
> > >
> > > The issuer is responsible for the verification of anything that is included
> > > in the certificate.  After all, the issuer signature covers it.  Thus, the
> > > issuer is claiming that the logotypes are appropriate.
> >
> >Don't twist the wording.  :-)
> >
> >We agree on the concept, but we should try to use another wording and avoid
> >to use the word "claim".
> >
> > > COMMENT 5: During the meeting, it has been proposed to add a small image of
> > > the logotype in the certificate itself. In this WG we always have had a
> > > concern about the size of the certificate, so that it can be lodged in some
> > > small devices. So I would not favor to allow such provision in a
> > > extension standardized by this WG.
> > >
> > > RESPONSE 5.
> > >
> > > There are environments where the client cannot access the Internet until
> > > after the certificate is used.  Consider certificate-based authentication
> > > to an ISP.  A small logotype in the certificate could be useful to aid
> > > certificate selection in this situation.  The inclusion of a small logotype
> > > is, of course, optional.
> >
> >...and instead of certificates between 1 K and 2 K bytes, have certificates
> >with at least one more K !
> >
> >Denis
> >
> >
> > > COMMENT 6: It should be made clear that this extension in non-critical.
> > >
> > > RESPONSE 6.
> > >
> > > Agree.  The logotype extension was never intended to be critical.
> > >
> > > COMMENT 7: The document includes many typos to be corrected.
> > >
> > > RESPONSE 7.
> > >
> > > We will make every effort to correct them before the next draft is
> > published.
> > >
> > > Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34D5Tb13737 for ietf-pkix-bks; Thu, 4 Apr 2002 05:05:29 -0800 (PST)
Received: from mta02-svc.ntlworld.com (mta02-svc.ntlworld.com [62.253.162.42]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34D5Rm13733 for <[e-mail]>; Thu, 4 Apr 2002 05:05:27 -0800 (PST)
Received: from salford.ac.uk ([213.107.136.218]) by mta02-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Thu, 4 Apr 2002 14:05:27 +0100
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 14:09:26 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <001001c1db7f$751e3cd0$[e-mail]>
Content-Type: multipart/mixed; boundary="------------FE6E2BACF90276BB15E89ADB"
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.
--------------FE6E2BACF90276BB15E89ADB
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Steven

thanks for your messages that have clearly stated the case that ;binary
is needed as a general transfer encoding, and that many attributes exist
without a native LDAP encoding being defined for them.

But this does raise the more general issue of how does a user who asks
for "all" attributes, deal with those which are returned, whose native
encoding he is unfamiliar with. Does the server assume the client knows
(in which case ;binary will only be used on those attributes with no
native encoding defined) or does not know (in which case ;binary will
need to be used on all attributes that are not defined in Internet
standard RFCs).

Seems like ASN.1 DAP had some advantages after all :-)

David

Steven Legg wrote:
> 
> David,
> 
> David Chadwick wrote:
> > Sent: Thursday, 4 April 2002 8:45
> > To: Kurt D. Zeilenga
> > Cc: Sharon Boeyen; 'Mark Wahl'; Mark C Smith; LDAP BIS; PKIX
> > Subject: Re: LDAP Certificate transfer syntax
> 
> > > In David's table, he shows that existing LDAPv3 implementations
> > > are "OK".   That is, LDAPv3 is not broken in this regard.  The
> > > specification is clear and there multiple interoperable
> > > LDAPv3 implementations.
> > >
> >
> > But LDAP (v2 and v3) is deficient in that it has never specified a
> > workable "native" transfer encoding for certificates. The
> > LDAPv2 attempt
> > was broken as we know, and v3 never replaced it - until my
> > proposed text
> > now. Are certificates the only commonly used attributes without a
> > "native" encoding? I cant think of any others.
> 
> I commonly use entryACI, prescriptiveACI and subentry ACI (ACI Item
> syntax) and subtreeSpecification (Subtree Specification syntax).
> Neither of the syntaxes for these attributes has a defined
> LDAP-specific (i.e. native) encoding in RFC 2252 or RFC 2256.
> 
> > So this is a deficiency
> > that should be rectified in my opinion.
> 
> Recent I-Ds have proposed human readable character string encodings
> for both the ACI Item syntax and the Subtree Specification syntax,
> by referencing the Generic String Encoding Rules, to correct the
> deficiency in these syntaxes. This is in keeping with the statement
> in RFC 2252 that "The encoding rules defined for a given attribute
> syntax must produce octet strings. To the greatest extent possible,
> encoded octet strings should be usable in their native encoded form
> for display purposes".
> 
> Thus a "right" way to fix the Certificate syntax is to define
> the LDAP-specific/native encoding to be the GSER encoding :-).
> 
> Had the ACI Item and Subtree Specification syntaxes previously been
> defined such that their LDAP-specific encoding was the same as
> their ;binary encoding it would not now be possible to define the
> default format to be a human readable character string encoding.
> 
> > > That is, this suggest change will implementations to updated to
> > > support it.  This will include some clients (such as those which
> > > as for "*" and expect userCertificate;binary)
> >
> > agreed, if a server is to be consistent it probably would not put
> > ;binary on any returned attributes, although I believe that todays
> > LDAPv3 servers will put ;binary on certificates because of the MUST
> > requirement. If they continued to do this in the future it would not
> > cause any problems with the clients, but would be inconsistent
> > behaviour.
> >
> > >and most (if not
> > > all) servers.  That's bad!
> > >
> >
> > I think the change would not have been necessary if all existing
> > products had implemented the current spec. And thats bad!!
> 
> The fault is in the incorrectly implemented products. The obligation
> to change is on them, not the correctly implemented products.
> 
> > > Hence, for LDAPv3 interoperability sake, the specification needs
> > > to continue to MUST the use of ;binary for these attributes except
> > > where the client and server have a prior agreement that the
> > > OPTIONAL native encoding is to be used.
> > >
> >
> > As a general rule I think that continuing to mandate one particular
> > tranfer encoding just for certificates is wrong and leaves us
> > in hole in
> > the future if new transfer encodings are developed, such as XML (which
> > incidentally has now been standardised for certificates). So how would
> > you propose to cater for XML encodings in the future?
> 
> One way is to provide an update to the Certificate syntax to say that
> values in the syntax MUST NOT be requested or returned without an
> explicit transfer option. We could also say that now, in the current
> draft.
> 
> > > Of course, one ought to wonder why any LDAPv3 implementation
> > > would support this OPTIONAL native encoding when the REQUIRED
> > > encoding is more broadly implemented and provides the same
> > > functionality.   It seems redundant to me.
> > >
> >
> > Clearly there is redundancy once a native encoding is
> > specified and this
> > happens to be the same as the ;binary encoding, that is not in doubt.
> > But who is to say which one is the redundant one? It could be
> > the use of
> > ;binary. Maybe this transfer encoding is no longer needed by LDAPv3
> > (just being devil's advocate here :-)
> 
> Only about a third of the syntaxes I support have defined LDAP-specific
> encodings. I need a standard way to represent attribute values of the
> other two thirds in LDAP and LDIF. The ;binary option serves that
> purpose. Now if someone were to mandate that all additional LDAP syntaxes
> must use GSER for the LDAP-specific encoding then I wouldn't need ;binary.
> 
> Regards,
> Steven
> 
> >
> > David
> >
> >
> > > Kurt
> >
> > --
> > *****************************************************************
> >
> > David W. Chadwick, BSc PhD
> > Professor of Information Systems Security
> > IS Institute, University of Salford, Salford M5 4WT
> > Tel: [phone]  Fax [phone]
> > Mobile: [phone]
> > Email: [e-mail]
> > Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> > Research Projects: http://sec.isi.salford.ac.uk
> > Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> > X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> > Entrust key validation string: MLJ9-DU5T-HV8J
> > PGP Key ID is 0xBC238DE5
> >
> > *****************************************************************

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------FE6E2BACF90276BB15E89ADB
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------FE6E2BACF90276BB15E89ADB--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34Cpje13387 for ietf-pkix-bks; Thu, 4 Apr 2002 04:51:45 -0800 (PST)
Received: from e1.esmtp.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34Cphm13383 for <[e-mail]>; Thu, 4 Apr 2002 04:51:43 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.esmtp.ibm.com (8.12.2/8.12.2) with ESMTP id g34ClbDc421248; Thu, 4 Apr 2002 07:47:37 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g34Cp1044960; Thu, 4 Apr 2002 07:51:01 -0500
Importance: Normal
Sensitivity: 
Subject: Re: WG Last Call: Roadmap
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Thu, 4 Apr 2002 07:50:50 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/04/2002 07:51:02 AM
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>

      Responses below.  The issue of who specifies the verifier's policy is
rather serious.  If the policy to be used is expected to be the same as RFC
3126's SignaturePolicy, we need to specify a step in which the verifier has
the right to reject such a policy or to consider it inapplicable to the
verifier's own current context.

            Tom Gindin

Denis Pinkas <[e-mail]> on 04/03/2002 11:15:54 AM

To:    Tom Gindin/Watson/IBM@IBMUS
cc:    [e-mail]
Subject:    Re: WG Last Call: Roadmap


Tom,

>       I have a few issues with this, and some corrections as well.

>       In comment 12, I have two issues.  The first one, which is minor,
is
> that  "one or more Top CA's may be trusted" should refer to root CA's
> instead - the two terms mean the same thing more often than not, but when
> they differ the trust point is the root rather than the top.

PKIX-1 states:

   " - Top CA - A CA that is at the top of a PKI hierarchy.

   Note: This is often also called a "Root CA," since in data structures
   terms and in graph theory, the node at the top of a tree is the
   "root." However, to minimize confusion in this document, we elect to
   call this node a "Top CA," and reserve "Root CA" for the CA directly
   trusted by the EE."

The problem lies with the last sentence, i.e. "*the* CA directly trusted by
the EE.". The singular is being used which means that there is a single
one, multiple roots are not permitted, while multiple Top-CAs are
permitted.

[TG] Where in PKIX-1 is this?  I can't find the phrase "directly trusted"
in either RFC 2459 or in draft 12 of new-pkix-1.  Furthermore, if it does
appear in such a draft I hope that it will be with reference to a
particular validation path.  Since one normally performs validation against
a specific context, only one trusted root is evaluated at a time.

>       The second is less minor.  Is it truly intended that a signing EE
> be permitted to specify the set of trusted CA's for an RP to use in
> verifying a signature?  At a minimum, an RP in this model is responsible
> for validating the the set of rules is identical to one it has already
> decided to trust, but there is no reference in the model description to
> any active role for the RP.

A verifier (not a signing EE as you mentioned) does not know what an anchor
is, but may know what a policy is. So by selecting the policy that applies
to the application, indirectly trust anchors (and much more) are selected.
Remember that the same verifier may verify digital signatures in various
contexts, e.g. for a Bank transaction or for a green reservation in a Golf
Club. The trust conditions are not necessarilly identical. Note also that a
verifier does not need to be a signer and may not have any certificate of
its own.

[TG] My point is that the policy used to verify a signature is something
which the VERIFIER must decide on, rather than the signer, and signature
policies are things which you have defined as being specified by a signer
(see your own RFC 3126).  A verifier is as likely to know what an anchor is
as what a signature policy is.  If a signature policy includes a
specification of the trust anchors as well as of the verification mechanism
a user who does not know what a trust anchor is operating blindly in
accepting or choosing a signature policy.

The case of a single (root) CA trusted for any kind of application is a
very
specific case and cannot be considered as the general case.

>       In your comment 5 (on page 15), replace "date of issue" by "date
and
> time of issue".

This is fine.

>       At a slightly more substantive level, shouldn't the clarification
of
> the definition of Top CA on page 4 end "and reserve 'root CA' for a CA
> directly trusted by the EE."?  This wording permits multiple trusted
roots.

I do not think that PKIX-1 allows for this. See the quote above.

>       In your comment 4, shouldn't "CA certificate" be "hierarchical CA
> certificate"?  Surely a Top CA's self-signed certificate is also a "CA
> certificate", and your definition excludes it.  Then the sentence "Some
> people in the WG believe that a cross certificate is a special kind of CA
> certificate." is reversed to "... believe that a hierarchical CA
> certificate is a special kind of cross certificate".

You say that the definition excludes the fact that a Top CA's self-signed
certificate is also a CA-certificate. This is correct, ... but was not
intended.

So what about this full correction ?

[2459bis] defines a cross-certificate as "a certificate issued by one CA to
another CA". [2459bis] does not provide a formal definition of a CA
certificate but implictly means a certificate where the subject of the
certificate is a CA. This means that self-signed certificates are CA
certificats but are not cross-certificates. Some people in the WG believe
that a cross certificate is a special kind of CA certificate issued by a CA
under one Top CA for another CA under a different Top CA. CAs in the same
hierarchy usually have part of their names imposed by the Top CA or by the
CAs under that Top CAs. When a cross certificate is issued, there is no
relationship between the names of the CAs.

>       In comment 11, the i.e. should remain "what are the root CA's"
rather
> than "what are the Top CA's", for the same reason as in comment 12.

I do not think so. See my first comment.

Regards,

Denis


>             Tom Gindin
>
> Denis Pinkas <[e-mail]>@mail.imc.org on 03/26/2002 12:11:50
PM
>
> Sent by:    [e-mail]
>
> To:    [e-mail]
> cc:    Carlisle Adams <[e-mail]>
> Subject:    Re: WG Last Call: Roadmap
>
> Comments on the roadmap document draft-ietf-pkix-roadmap-07.txt
>
> (snip)
> COMMENT 3. A sentence states: "However, to minimize confusion in this
> document, we elect to call this node a "Top CA," and reserve "Root CA"
for
> the CA directly trusted by the EE". Since an EE may trust more than one
Top
> CA, shouldn't we say:
>
> "However, to minimize confusion in this document, we elect to call this
> node
> a "Top CA," and reserve "Root CA" when there is a single CA directly
> trusted
> by the EE."
>
> COMMENT 4. On page 14. A clarification needs to be done between
> cross-certificates and CA certificates. The text currently states:
>
>    A cross-certificate is a PKC issued by one CA to another CA which
>    contains a public CA key associated with the private CA signature key
>    used for issuing PKCs. Typically, a cross-certificate is used to
>    allow client systems or end entities in one administrative domain to
>    communicate securely with client systems or end users in another
>    administrative domain. Use of a cross-certificate issued from CA_1 to
>    CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob,
>    which was issued by CA_2. Cross-certificates can also be issued from
>    one CA to another CA in the same administrative domain, if required.
>
> I would propose instead the following:
>
> " A CA certificate is a certificate in a hierarchy that is neither a
> self-signed certificate, nor an end-entity certificate. [2459bis] does
not
> make a difference between a CA certificate and a cross certificate since
it
> defines a cross-certificate as "a certificate issued by one CA to another
> CA". Some people in the WG believe that a cross certificate is a special
> kind of CA certificate. A cross certificate is issued by a CA under one
> Top CA for another CA under a different Top CA. CAs in the same hierarchy
> have part of their names imposed by the Top CA or by the CAs under that
> Top CAS. When a cross certificate is issued, there is no relationship
> between the names of the CAS.
>
> Typically, a cross-certificate is used to allow client systems or end
> entities in one administrative domain to communicate securely with client
> systems or end users in another administrative domain. Use of a
> cross-certificate issued from CA_1 to CA_2 allows user Alice, who trusts
> CA_1, to accept a PKC used by Bob, which was issued by CA_2.
> Cross-certificates can also be issued from one CA to another CA in the
same
> administrative domain, if required."
>
> COMMENT 5. On page 15, the text states: "A CRL is a time stamped list
> identifying revoked PKCs that is signed by a CA and made freely available
> in a public repository."
>
> I would prefer to avoid to use "time-stamped" in that context and thus I
> would propose the following wording:
>
> "A CRL is a list that identifies the references of revoked PKCs. This
list
> contains a date of issue and is signed by a CA and made freely available
in
> a public repository."
>
> (snip)
>
> COMMENT 11. On page 47. Section 5.5 talks about trust model, but only
> consider a single trust point:
>
> "  An important design decision is where a particular EE's trust point
>    is located (i.e., where is the EE's Root CA). There are a number of
>    models that have been developed and depending on the environment some
>    models may be more suited than others. The following provides some
>    background on the models."
>
> I would rather propose to change it into:
>
> " An important design decision is, for a given application, where the
> particular EE's trust points are located (i.e. what are the Top CAs).
> There are a number of models that have been developed and depending on
> the environment some models may be more suited than others. The following
> provides some background on the models."
>
> COMMENT 12. On page 49. Section 5.5 I would propose to add another model.
>
> 5.5.5 Validation policies
>
> Another model considers a set of rules that apply to an application
> context.
> Every application context may have a different set of rules. When
choosing
> to use certificates in the context of that application, the EE selects
the
> set of rules for that context. In a set of rules, one or more Top CAs may
> be
> trusted, each one may be associated with different constraints, like the
> certificate policies that are trusted or the naming constraints that
apply.
> These constrains may be specified either in self-signed certificates or
in
> addition to self-signed certificates when they do not incorporate these
> constraints. This set of rules is called a validation policy (when
> validating a certificate) or a signature policy (when validating a
digital
> signature).
>
> Regards,
>
> Denis






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34CnrS13341 for ietf-pkix-bks; Thu, 4 Apr 2002 04:49:53 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34Ch5m13130; Thu, 4 Apr 2002 04:43:06 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g34Ch6b18330; Thu, 4 Apr 2002 13:43:06 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]>; Thu, 4 Apr 2002 13:37:46 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id NAA16409; Thu, 4 Apr 2002 13:43:01 +0100
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 13:43:03 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: xme <[e-mail]>, Shivaram Mysore <[e-mail]>
Subject: xkms requirements document last call
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>

Hi,

This mail is to ask for your comments on the W3C XKMS 
requirements document. See below for details.

Sorry for the short notice - however, we will welcome comments 
for a while after the official end of the last-call period.

Thanks,
Stephen.

On behalf of the W3C XML Key Managment Service WG [1], we are 
pleased to announce the publication of the "XKMS Requirements" 
Last Call Working Draft.  This is one of the deliverables of 
the WG.  The document address is:

  http://www.w3.org/TR/xkms2-req

Abstract 

This document lists the design principles, scope and requirements 
for XML Key Management specifications and trust server key management 
implementations. It includes requirements as they relate to the key 
management syntax, processing, security and coordination with other 
standards activities. 

Status of this Document 

This is the Last Call for the requirements Working Draft of the XML Key 
Management Working Group (Activity Statement). This version represents the 
consensus of the Working Group. The last call period is 3 weeks, ending on 
15 April 2002.

Please send review comments by that date to the editors - [e-mail], 
[e-mail] and cc: [e-mail], [e-mail], 
[e-mail]

[1]  http://www.w3.org/2001/XKMS

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34Cm5w13301 for ietf-pkix-bks; Thu, 4 Apr 2002 04:48:05 -0800 (PST)
Received: from mta05-svc.ntlworld.com (mta05-svc.ntlworld.com [62.253.162.45]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34Cm4m13297 for <[e-mail]>; Thu, 4 Apr 2002 04:48:04 -0800 (PST)
Received: from salford.ac.uk ([213.107.136.218]) by mta05-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Thu, 4 Apr 2002 13:48:03 +0100
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 13:52:03 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Jim Sermersheim <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: LDAP Certificate transfer syntax
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------B98CD197C7340D1E49FA4375"
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.
--------------B98CD197C7340D1E49FA4375
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Jim

these are very good points that you make. They go part way to showing
that a reason for the confused situation we have gotten into is by not
previously being precise enough about certificate syntax definitions (in
fact there was not a workable one defined). I hope the new PKIX schema
ID can be precise enough to ensure that future problems dont occur. Do
you have any suggestions to the proposed wording that I sent out

David


Jim Sermersheim wrote:
> 
> I note that 2252 and 2256 both have problems with the language used to
> specify this.
> 
> 2252 says that values of the Certificate syntax MUST be transferred
> using the binary encoding. It then gives two attribute descriptions
> "userCertificate;binary" and caCertificate;binary". If I create an
> attribute called printerCertificate, what am I supposed to refer to it
> as?
> 
> It can be argued that the MUST here refers to the encoding, and the
> attribute descriptions are merely examples of the day.
> 
> 2256 says "This attribute is to be stored and requested in the binary
> form, as 'userCertificate;binary'". Am I to believe that I must somehow
> store the ;binary option in my database? Aside from that sillines, there
> is no MUST imperative here.
> 
> Jim
> 
> >>> "Kurt D. Zeilenga" <[e-mail]> 04/03/02 11:36AM >>>
> This text does not clearly "MUST" the use of ;binary as
> RFC 2252 and RFC 2256 did.  As previously noted, this
> "MUST" should not be dropped as doing so will cause
> interoperability problems between implementations of
> the current technical specification and the revised
> technical specification.
> 
> Kurt
> 
> At 05:29 AM 2002-04-01, David Chadwick wrote:
> >Colleagues
> >
> >Here is my proposed change to the section describing the LDAP syntax
> for
> >cerificates in the PKIX id
> ><draft-pkix-ldap-schema-03.txt> which should be published before the
> end
> >of April. As this is likely to be the most contentious part of the
> new
> >ID, I thought it would be useful to distribute this text at the
> earlier
> >possible moment.
> >
> >All constructive comments welcomed
> >
> >David
> >
> >
> >3.3  Certificate Syntax
> >
> >A value in this transfer syntax is the binary octet string that
> results
> >from BER or DER-encoding of an X.509 public key certificate.  The
> >following string states the OID assigned to this syntax:
> >
> >      ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
> >
> >Servers must preserve values in this syntax exactly as given when
> >storing and retrieving them.
> >
> >Note. Due to the changes from X.509(1988) to X.509(1993) and
> subsequent
> >changes to the ASN.1 definition to support certificate extensions in
> >X.509(1997), no character string transfer syntax is defined for
> >certificates. The BNF notation in RFC 1778 [12] for "User
> Certificate"
> >MUST NOT be used. Values in this syntax MUST be transferred as BER or
> >DER encoded octets. The use of the ;binary encoding option, i.e. by
> >requesting or returning the attributes with descriptions
> >"userCertificate;binary" or "caCertificate;binary" has no effect on
> the
> >transfer syntax.

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------B98CD197C7340D1E49FA4375
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------B98CD197C7340D1E49FA4375--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34ArOa04248 for ietf-pkix-bks; Thu, 4 Apr 2002 02:53:24 -0800 (PST)
Received: from mail.dit.upm.es (IDENT:[e-mail] [138.4.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34ArNm04244 for <[e-mail]>; Thu, 4 Apr 2002 02:53:23 -0800 (PST)
Received: from jungla.dit.upm.es (IDENT:[e-mail] [138.4.5.11]) by mail.dit.upm.es (8.11.6/8.9.3) with ESMTP id g34ArJ911326; Thu, 4 Apr 2002 12:53:19 +0200
Received: from dit.upm.es (toro-2.dit.upm.es [138.4.21.2]) by jungla.dit.upm.es (8.11.6/8.9.3) with ESMTP id g34ArHi11288; Thu, 4 Apr 2002 12:53:17 +0200
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 12:53:26 +0200
From: "=?iso-8859-1?Q?Jos=E9?= A. =?iso-8859-1?Q?Ma=F1as?=" <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "hermes3.si.c-s.fr" <[e-mail]>
CC: [e-mail]
Subject: Re: Comment on RFC 3161
References: <EBZWTNRLKXVMH3WE9ZUOKEY3143.3cabe72d@saturne>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g34ArOm04245
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 you are right,
and I think it is a problem with any signature:
the status of the cert must be ok when the verification is run.

For the case of time-stamping,
there is renewal procedure such that an old time-stamp token
is enveloped within a new token thus extending the value
of the first token from the original instant to the
end of the validity of the enveloping token.
If renewal is applied regularly
(always before the outmost key is compromised)
the value may be extended indefinitely.

Hope it helps,
jam


"hermes3.si.c-s.fr" wrote:
> 
> Hi!
> 
> I wonder something about the first security considerations of RFC 3161 (§4.1).
> 
> It says that if the TSA private key shall not be used any more and
> is not compromised ,
> the corresponding certificate shall be revoked with a reason code.
> Thus any token signed with the corresponding key before the revocation time
> will remain valid.
> 
> However we could imagine that the key becomes compromised after the
> revocation, allowing
> the "hacker" to generate time-stamp tokens with a date previous to
> the revocation time.
> Thus false tokens will be consider as valid...
> 
> The point is how to get the crucial "before" in " ... before the
> revocation time" .
> 
> If someone can help ...
> 
> Antoine Bourrouilh

-- 
-----------------------------------------------------------
Prof. Jose A. Manas                mailto:[e-mail]
Dpt. Telematica                http://www.dit.upm.es/~pepe/
E.T.S.I. Telecomunicacion           tel: [+34] 91 336 73 25
Ciudad Universitaria                gsm: [+34] 607 73 38 94
E-28040 Madrid                      gsm: [+34] 609 62 70 98
SPAIN                               fax: [+34] 91.336 73 33


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34AYxT03739 for ietf-pkix-bks; Thu, 4 Apr 2002 02:34:59 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34AYum03735 for <[e-mail]>; Thu, 4 Apr 2002 02:34:56 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g34AYtb15625 for <[e-mail]>; Thu, 4 Apr 2002 11:34:55 +0100
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Thu, 4 Apr 2002 11:29:36 +0100
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id LAA14559 for <[e-mail]>; Thu, 4 Apr 2002 11:34:52 +0100
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 11:34:53 +0100
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: One last comment on DPD requirements
References: <003b01c1db76$ee825fb0$a300a8c0@Chokhani>
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>

And adding another reason: multiple paths may exist which only 
really differ in their validity fields. Unless the requirements
call for a pretty complex time specifier in the request the 
simplest thing is for the server to send back all such paths
found and let the client sort it out (i.e. even if the client 
picks a single point in time, there may still be >1 path such 
that the paths only differ in validity; to close this down some 
fairly hairy time specifier in the request would have to be
defined and no clients would bother filling that in properly
in any case).

Stephen.

Santosh Chokhani wrote:
> 
> Russ:
> 
> I agree with you, but for a different reason.  I do not think this is
> application specific issue.  I think it is the path validation issue.  I
> do not think that the DPD server can know which paths are good without
> doing a validation also, specially to see if there will be any name
> constraints or certificate policy related failures.
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Housley, Russ
> Sent: Wednesday, April 03, 2002 2:12 PM
> To: Ambarish Malpani; Stephen Kent
> Cc: [e-mail]
> Subject: Re: One last comment on DPD requirements
> 
> Steve & Ambarish:
> 
> >>Hi Group,
> >>     One last (slightly late) comment on the DPD requirements that has
> 
> >>been troubling me:
> >>
> >>In the DPD requirements, there is a reasonable amount of text that
> >>talks about how a server can return multiple paths back to the client
> >>(to allow the client to decide which path is the best).
> >>
> >>The main goal of DPD is to try and simplify the client. In how many
> >>cases do people really want multiple paths back from the server. While
> 
> >>it is the right requirement in principal, do folks really think
> >>clients will want multiple paths back from a DPD server? Are we adding
> 
> >>the additional flexiblity/complexity just for technical purity?
> >>
> >>Comments will be appreciated.
> >>
> >>Regards,
> >>Ambarish
> >
> >I too would favor simplifying the protocol requirement here. Some folks
> >have suggested motivations for multiple paths, but this does seem to
> >conflict with the fundamental goal of creating a protocol to satisfy
> the
> >needs of thin clients.
> >
> >Steve
> 
> I agree with your goal.  It is far better for the client to tell the
> server
> what it wants, then get back a single path that satisfies all of the
> requirements.  To do this, we need to be able to fully specify the
> clients
> criteria and send them to the server.  I think that we know how to do
> this
> for many PKI-enabled applications, but I am not sure that we know how to
> do
> it for all applications, especially ones that are yet to be developed.
> 
> This leaves us with two choices.  Either the protocol returns multiple
> certification paths (the approach in the current document) or the
> protocol
> requires the client to adequately specify its criteria.  This could be
> done
> with the path discovery policy.  If we adopt this alternative, we should
> 
> include additional text so that implements expect application-specific
> (perhaps several application-specific path discovery policy if there are
> 
> multiple roles in the application).
> 
> Russ

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) [phone]
39 Parkgate Street,                     fax: [phone]
Dublin 8.                mailto:[e-mail]
Ireland                             http://www.baltimore.com


Received: by above.proper.com (8.11.6/8.11.3) id g349AAo22564 for ietf-pkix-bks; Thu, 4 Apr 2002 01:10:10 -0800 (PST)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g349A3m22530 for <[e-mail]>; Thu, 4 Apr 2002 01:10:04 -0800 (PST)
Received: from sit.fraunhofer.de (pc-pisa [141.12.37.18]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id LAA19865; Thu, 4 Apr 2002 11:09:19 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Thu, 04 Apr 2002 11:10:17 +0200
From: Brian Hunter <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]> <[e-mail]>
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>

Russ,

> >5. Section 5 Para 4
> Trust anchors can be established using self-signed certificates or by other
> means, either way, the  trust anchor is not included.  Perhaps this point
> is only adding confusion.

Not including non-self-signed trust anchors is contrary to Denis' change
sent to Ambarish.  I agree with Denis' clarification because it aligns
DPD with path validation in 2459bis section 6.1 para 7:

"When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of the
prospective certification path."

> >9. Section 9 Last paragraph point (3)
> >     Is it intended that the validation time should be adjusted for only
> >one of the four points, hence the use of "or" after point three? I would
> >suggest the use of "and".
> 
> I disagree.  The time could be adjusted for one or more of these
> reasons.  It is an inclusive or.

See Denis' response to me agreeing with the change to "and".
All in all, I think this is a small point, in the scope of this
document, but to clarify the meaning, perhaps the use of "and/or" would
be appropriate.

Brian


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g348JuL14901 for ietf-pkix-bks; Thu, 4 Apr 2002 00:19:56 -0800 (PST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g348Jrm14889 for <[e-mail]>; Thu, 4 Apr 2002 00:19:53 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.2/8.12.2) with ESMTP id g348J7Xv028204; Thu, 4 Apr 2002 20:19:07 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id UAA127153; Thu, 4 Apr 2002 20:19:03 +1200 (NZST) (sender [e-mail])
Date: Thu, 4 Apr 2002 20:19:03 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: LDAP Certificate transfer syntax
Cc: [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>

Phil Griffin <[e-mail]> writes:

>It is only when someone tries to reconstruct the certificate from its values
>using the strict DER subset of BER that a mismatch with the signature due to
>BER/DER differences in the encoding can arise.

This would be a problem if anyone actually did this.  Anyone mad enough to even
try it quickly finds that 90% of signatures fail to verify after the re-
coding, and falls back to doing what everyone else does, which is treat the
signed object as a blob which you don't touch (the same with DNs in certs and
many other things).

Peter (who actually tried re-coding DNs into the correct form for awhile, but
       quickly gave up, and who never even tried with certs).


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g345ssj28825 for ietf-pkix-bks; Wed, 3 Apr 2002 21:54:54 -0800 (PST)
Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g345sqm28820 for <[e-mail]>; Wed, 3 Apr 2002 21:54:52 -0800 (PST)
Received: (qmail 23712 invoked from network); 4 Apr 2002 05:51:48 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 4 Apr 2002 05:51:47 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: "'Ramsay, Ron'" <[e-mail]>
Cc: "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Date: Thu, 4 Apr 2002 15:53:32 +1000
Message-ID: <001401c1db9d$0e50f6a0$[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 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
In-Reply-To: <[e-mail]>
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>

Ron,

Ramsay, Ron wrote:
> Sent: Thursday, 4 April 2002 12:52
> To: [e-mail]; 'David Chadwick'
> Cc: 'LDAP BIS'; 'PKIX'
> Subject: RE: LDAP Certificate transfer syntax
> 
> 
> Steven,
> 
> > I need a standard way to represent attribute values of the
> > other two thirds in LDAP and LDIF. The ;binary option serves that
> > purpose.
> 
> I don't see this as logical. Do you simply mean the use of 
> ;binary means you
> don't have to define another encoding? For, surely, defining 
> the behaviour
> to be same for ;binary as without it achieves the same end?

I was taking David's comment in the context of just the Certificate
and related syntaxes, where the use of ;binary is currently mandated.
If these syntaxes have their LDAP-specific encodings defined to be
the same as the ;binary encoding that still leaves me with a large
number of syntaxes where the LDAP-specific encoding is undefined.

A blanket specification that the LDAP-specific encoding for *all*
other syntaxes is the same as ;binary (or GSER, or whatever) is
outside the scope of LDAPbis and the PKIX LDAP Schema, and runs
into the immediate problem of quantifying which are the "other"
syntaxes.

Given some X.500-style attribute definition, there may or may not
be a relevant LDAP syntax specification for its syntax, and I may
not be aware of the specification if one does exist. If my server
doesn't know the LDAP-specific encoding for some syntax but assumes
it is the BER encoding there will be problems interoperating
with implementations that do know the LDAP-specific encoding, if
that encoding has been formally specified somewhere as some
character string encoding.

On the other hand, two implementations will agree on what the ;binary
encoding is, even if one of them doesn't have complete information
about the LDAP-specific encoding.

Regards,
Steven

> 
> Ron.
> 
> -----Original Message-----
> From: Steven Legg [mailto:[e-mail]]
> Sent: Thursday, 4 April 2002 12:22
> To: 'David Chadwick'
> Cc: 'LDAP BIS'; 'PKIX'
> Subject: RE: LDAP Certificate transfer syntax
> 
> 
> 
> David,
> 
> David Chadwick wrote:
> > Sent: Thursday, 4 April 2002 8:45
> > To: Kurt D. Zeilenga
> > Cc: Sharon Boeyen; 'Mark Wahl'; Mark C Smith; LDAP BIS; PKIX
> > Subject: Re: LDAP Certificate transfer syntax
> 
> > > In David's table, he shows that existing LDAPv3 implementations
> > > are "OK".   That is, LDAPv3 is not broken in this regard.  The
> > > specification is clear and there multiple interoperable
> > > LDAPv3 implementations.
> > > 
> > 
> > But LDAP (v2 and v3) is deficient in that it has never specified a
> > workable "native" transfer encoding for certificates. The 
> > LDAPv2 attempt
> > was broken as we know, and v3 never replaced it - until my 
> > proposed text
> > now. Are certificates the only commonly used attributes without a
> > "native" encoding? I cant think of any others.
> 
> I commonly use entryACI, prescriptiveACI and subentry ACI (ACI Item
> syntax) and subtreeSpecification (Subtree Specification syntax).
> Neither of the syntaxes for these attributes has a defined
> LDAP-specific (i.e. native) encoding in RFC 2252 or RFC 2256.
> 
> > So this is a deficiency
> > that should be rectified in my opinion.
> 
> Recent I-Ds have proposed human readable character string encodings
> for both the ACI Item syntax and the Subtree Specification syntax,
> by referencing the Generic String Encoding Rules, to correct the
> deficiency in these syntaxes. This is in keeping with the statement
> in RFC 2252 that "The encoding rules defined for a given attribute
> syntax must produce octet strings. To the greatest extent possible,
> encoded octet strings should be usable in their native encoded form
> for display purposes".
> 
> Thus a "right" way to fix the Certificate syntax is to define
> the LDAP-specific/native encoding to be the GSER encoding :-).
> 
> Had the ACI Item and Subtree Specification syntaxes previously been
> defined such that their LDAP-specific encoding was the same as
> their ;binary encoding it would not now be possible to define the
> default format to be a human readable character string encoding.
> 
> 
> > > That is, this suggest change will implementations to updated to
> > > support it.  This will include some clients (such as those which
> > > as for "*" and expect userCertificate;binary) 
> > 
> > agreed, if a server is to be consistent it probably would not put
> > ;binary on any returned attributes, although I believe that todays
> > LDAPv3 servers will put ;binary on certificates because of the MUST
> > requirement. If they continued to do this in the future it would not
> > cause any problems with the clients, but would be inconsistent
> > behaviour.
> > 
> > >and most (if not
> > > all) servers.  That's bad!
> > > 
> > 
> > I think the change would not have been necessary if all existing
> > products had implemented the current spec. And thats bad!!
> 
> The fault is in the incorrectly implemented products. The obligation
> to change is on them, not the correctly implemented products.
> 
> 
> > > Hence, for LDAPv3 interoperability sake, the specification needs
> > > to continue to MUST the use of ;binary for these attributes except
> > > where the client and server have a prior agreement that the
> > > OPTIONAL native encoding is to be used.
> > > 
> > 
> > As a general rule I think that continuing to mandate one particular
> > tranfer encoding just for certificates is wrong and leaves us 
> > in hole in
> > the future if new transfer encodings are developed, such as 
> XML (which
> > incidentally has now been standardised for certificates). 
> So how would
> > you propose to cater for XML encodings in the future?
> 
> One way is to provide an update to the Certificate syntax to say that
> values in the syntax MUST NOT be requested or returned without an
> explicit transfer option. We could also say that now, in the current
> draft.
> 
> 
> > > Of course, one ought to wonder why any LDAPv3 implementation
> > > would support this OPTIONAL native encoding when the REQUIRED
> > > encoding is more broadly implemented and provides the same
> > > functionality.   It seems redundant to me.
> > > 
> > 
> > Clearly there is redundancy once a native encoding is 
> > specified and this
> > happens to be the same as the ;binary encoding, that is not 
> in doubt.
> > But who is to say which one is the redundant one? It could be 
> > the use of
> > ;binary. Maybe this transfer encoding is no longer needed by LDAPv3
> > (just being devil's advocate here :-)
> 
> Only about a third of the syntaxes I support have defined 
> LDAP-specific
> encodings. I need a standard way to represent attribute values of the
> other two thirds in LDAP and LDIF. The ;binary option serves that
> purpose. Now if someone were to mandate that all additional 
> LDAP syntaxes
> must use GSER for the LDAP-specific encoding then I wouldn't 
> need ;binary.
> 
> Regards,
> Steven
> 
> > 
> > David
> > 
> > 
> > > Kurt
> > 
> > -- 
> > *****************************************************************
> > 
> > David W. Chadwick, BSc PhD
> > Professor of Information Systems Security
> > IS Institute, University of Salford, Salford M5 4WT
> > Tel: [phone]  Fax [phone]
> > Mobile: [phone]
> > Email: [e-mail]
> > Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> > Research Projects: http://sec.isi.salford.ac.uk
> > Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> > X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> > Entrust key validation string: MLJ9-DU5T-HV8J
> > PGP Key ID is 0xBC238DE5
> > 
> > *****************************************************************
> 



Received: by above.proper.com (8.11.6/8.11.3) id g345fhh28581 for ietf-pkix-bks; Wed, 3 Apr 2002 21:41:43 -0800 (PST)
Received: from pegase1.cie-signaux.fr (pegase1.cie-signaux.fr [194.2.40.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g345fgm28577 for <[e-mail]>; Wed, 3 Apr 2002 21:41:42 -0800 (PST)
Received: from pegase0.si.c-s.fr by pegase1.cie-signaux.fr  with ESMTP id HAA23974 for <[e-mail]>; Thu, 4 Apr 2002 07:43:05 +0200 (MET DST)
Received: from pegase0.si.c-s.fr by pegase0.si.c-s.fr  with ESMTP id HAA28161 for <[e-mail]>; Thu, 4 Apr 2002 07:40:31 +0200 (MET DST)
Received: from hermes3.cstelecom.cie-signaux.fr by pegase0.si.c-s.fr  with ESMTP id HAA28157 for <[e-mail]>; Thu, 4 Apr 2002 07:40:31 +0200 (MET DST)
Received: from saturne ([172.17.92.235]) by hermes3.cstelecom.cie-signaux.fr (Netscape Messaging Server 3.62)  with SMTP id 495 for <[e-mail]>; Thu, 4 Apr 2002 07:37:15 +0200
From: "hermes3.si.c-s.fr" <[e-mail]>
To: [e-mail]
Date: Thu, 04 Apr 2002 07:39:57 +0200
X-Priority: 3 (Normal)
Message-Id: <EBZWTNRLKXVMH3WE9ZUOKEY3143.3cabe72d@saturne>
Subject: Comment on RFC 3161
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
X-Mailer: Opera 6.0 build 1010
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!

I wonder something about the first security considerations of RFC 3161 (§4.1).

It says that if the TSA private key shall not be used any more and
is not compromised ,
the corresponding certificate shall be revoked with a reason code.
Thus any token signed with the corresponding key before the revocation time
will remain valid.

However we could imagine that the key becomes compromised after the
revocation, allowing
the "hacker" to generate time-stamp tokens with a date previous to
the revocation time.
Thus false tokens will be consider as valid...

The point is how to get the crucial "before" in " ... before the
revocation time" .

If someone can help ...

Antoine Bourrouilh





Received: by above.proper.com (8.11.6/8.11.3) id g343Ycm25741 for ietf-pkix-bks; Wed, 3 Apr 2002 19:34:38 -0800 (PST)
Received: from servere.csc.cuhk.edu.hk (servere.itsc.cuhk.edu.hk [137.189.29.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g343Yam25737 for <[e-mail]>; Wed, 3 Apr 2002 19:34:36 -0800 (PST)
Received: by servere.itsc.cuhk.edu.hk with Internet Mail Service (5.5.2653.19) id <2A3S1LMJ>; Thu, 4 Apr 2002 11:34:38 +0800
Message-ID: <[e-mail]>
From: Jason Yeung <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: New testing TSA announcement
Date: Thu, 4 Apr 2002 11:34:27 +0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="big5"
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,

Our testing TSA is available at
ts2.itsc.cuhk.edu.hk, port 3318

The TSA is RFC3161-compliant. It is now based on the socket
protocol and you can find the latest info at 
http://www.e-timestamping.com/status.html

Please kindly provide comments and suggestions. Thanks.


Jason Yeung

---
ITF Project
Information Technology Services Centre
The Chinese University of Hong Kong     

Tel. No: (852) 2609 8874         
Fax  No: (852) 2603 5001
email: [e-mail]
web: http://www.e-timestamping.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g34310o24932 for ietf-pkix-bks; Wed, 3 Apr 2002 19:01:00 -0800 (PST)
Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g3430vm24928 for <[e-mail]>; Wed, 3 Apr 2002 19:00:57 -0800 (PST)
Received: (qmail 5213 invoked from network); 4 Apr 2002 02:57:52 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 4 Apr 2002 02:57:52 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: "'Phil Griffin'" <[e-mail]>
Cc: "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Date: Thu, 4 Apr 2002 12:59:37 +1000
Message-ID: <001301c1db84$c1efaa80$[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 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
In-Reply-To: <[e-mail]>
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>

Phil,

Phil Griffin wrote:
> Sent: Thursday, 4 April 2002 8:56
> To: David Chadwick
> Cc: Housley, Russ; LDAP BIS; PKIX
> Subject: Re: LDAP Certificate transfer syntax
> 
> 
> 
> David,
> 
> Understood and agree. My point though is that if
> the format of the initial encoding is preserved 
> as an open type, it doesn't much matter what it 
> happened to be when it was signed. 
> 
> It is only when someone tries to reconstruct the
> certificate from its values using the strict DER 
> subset of BER that a mismatch with the signature 
> due to BER/DER differences in the encoding can 
> arise.
> 
> And as you've stated, technically when you say BER 
> you've included DER, as DER is a subset. But if 
> you are talking about a protocol requirement you
> may need to be careful with the language and try 
> to be as explicit as possible.
> 
> Surely if ;binary means BER it is not illegal to 
> return DER. But if ;binary means DER, then it would
> seem that returning BER that is not from the DER 
> subset would be illegal.

In LDAPv3, ;binary specifies BER with no requirement to preserve
the exact octets of the encoding. A server is theoretically
allowed to return any valid BER encoding of the abstract value.

However typical client usage of userCertificate;binary depends
on the exact octets being preserved by the server. In the PKIX
LDAP schema we are making the Certificate and related syntaxes
explicit exceptions in that the exact octets of the ;binary
encoding will be preserved. If the client provides DER they will
get back DER. If they provide non-DER BER they will get back the
same non-DER octets.

I've encountered certificates where the signature was calculated
on the provided non-DER BER encoding, so specifying that the
;binary encoding of values of the Certificate syntax is a DER
encoding would break some implementations.

> 
> And if a ;binary object is a BER wrapper around a
> DER encoding, then that's another case.

Preserving the exact BER encoding makes this subtlety unimportant.

Regards,
Steven
 
> 
> Phil
> 
> 
> 
> David Chadwick wrote:
> > 
> > Phil Griffin wrote:
> > 
> > > If this is done, then the concerns Russ raises as to
> > > requiring extra processing disappear, and the issue that
> > > David raised as to whether the protocol can be extended
> > > to other encodings (BER or CER or PER or XER) is also mute.
> > >
> > > The Directory just knows it has a blob. It stores the blob
> > > as given and can return the blob on demand.
> > 
> > Phil
> > 
> > thanks for this. But there is one further point, and that concerns
> > certificate matching which is the other topic of the schema 
> ID. For this
> > to work, the server has to parse the blob and extract the 
> various fields
> > to be used in subsequent searches. Therefore the server 
> needs to be told
> > what transfer syntax the blob is being sent in. The current proposed
> > text only allows the blob to be BER or DER and not PER or 
> XER encoded.
> > To allow the latter we would need to introduce new LDAP transfer
> > encoding keywords such as ;PER and ;XML. The current ;binary keyword
> > specifically means BER encoding. (And because DER is a subset of BER
> > then ;binary is taken to mean DER as well, which maybe it 
> should not if
> > we were to be really strict?).
> > 
> > David
> > 
> > >
> > > Phil
> > >
> > > "Housley, Russ" wrote:
> > > >
> > > > David:
> > > >
> > > > When DAP is used, certificates come back in BER.  This 
> happens because the
> > > > DAP PDU is defined in ASN.1, and the BER encoding of 
> the PDU encodes the
> > > > data too.  An OCTET STRING could have been used, but 
> this was all done
> > > > before there were object that had signatures.  Anyway, 
> I see this as an
> > > > opportunity to do better.
> > > >
> > > > I do not know about your AC development experience, but 
> the specifications
> > > > are quite clear about the need for DER.  It would be 
> nice if the repository
> > > > fetch did not force the client to restore the original 
> DER encoding.
> > > >
> > > > I agree that this is not a schema issue. However, a 
> comment that the DER
> > > > encoding applied by the signer should be preserved is 
> all I really
> > > > want.  You have already fixed the problem where the 
> repository access
> > > > protocol is changing the encoding.
> > > >
> > > > Russ
> > > >
> > > > At 06:39 PM 4/3/2002 +0100, David Chadwick wrote:
> > > > >Russ
> > > > >
> > > > >I dont think the issue below is one for the schema ID. 
> The certificate
> > > > >attributes in the directory should be perfectly happy 
> to receive BER or
> > > > >DER (or PER for that matter I guess). So the schema ID 
> should allow
> > > > >anything to be stored there.
> > > > >
> > > > >Your issue is more one for the LDAP profile ID which 
> was last updated in
> > > > >January. In the profile we can suggest that clients 
> always use DER for
> > > > >encoding certificates.  But what is the common WG 
> concensus on this? FYI
> > > > >in recent work we did with attribute certificates we 
> found we had to use
> > > > >BER because the DER Java objects were too buggy.
> > > > >
> > > > >David
> > > > >
> > > > >
> > > > >"Housley, Russ" wrote:
> > > > > >
> > > > > > David:
> > > > > >
> > > > > > I would like to encourage clients to provide 
> certificates in DER.  We ought
> > > > > > to tell them that there will be less work for 
> everyone if they provide
> > > > > > DER-encoded certificates.  Likewise for CRLs.
> > > > > >
> > > > > > Russ
> > > > > >
> > > > > > At 10:32 PM 4/1/2002 +0100, David Chadwick wrote:
> > > > > >
> > > > > > >"Housley, Russ" wrote:
> > > > > > > >
> > > > > > > > David:
> > > > > > > >
> > > > > > > > Is it possible to preserve the DER encoding.  
> If not, then the DER
> > > > > encoding
> > > > > > > > must be restored in order to validate the 
> signature?  This just
> > > > > seems like
> > > > > > > > wasted processing to me.
> > > > > > > >
> > > > > > >
> > > > > > >Russ
> > > > > > >
> > > > > > >I quite agree. The revised text is meant to ensure 
> that the DER or BER
> > > > > > >encoding created by the client when the 
> certificate was first sent to
> > > > > > >the directory for storage is preserved as is. This 
> is the purpose of the
> > > > > > >sentence below in the revised text, viz:
> > > > > > >
> > > > > > > > >Servers must preserve values in this syntax 
> exactly as given when
> > > > > > > > >storing and retrieving them.
> > > > > > > > >
> > > > > > >
> > > > > > >Perhaps I should say "as given to them by the 
> client, when storing and
> > > > > > >retrieving certificates"
> > > > > > >
> > > > > > >David
> > > > > > >
> > > > >
> > > > >--
> > > > 
> >*****************************************************************
> > > > >
> > > > >David W. Chadwick, BSc PhD
> > > > >Professor of Information Systems Security
> > > > >IS Institute, University of Salford, Salford M5 4WT
> > > > >Tel: [phone]  Fax [phone]
> > > > >Mobile: [phone]
> > > > >Email: [e-mail]
> > > > >Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> > > > >Research Projects: http://sec.isi.salford.ac.uk
> > > > >Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> > > > >X.500/LDAP Seminars: 
http://www.salford.ac.uk/its024/seminars.htm
> > > >Entrust key validation string: MLJ9-DU5T-HV8J
> > > >PGP Key ID is 0xBC238DE5
> > > >
> > > >*****************************************************************
> > > >
> 
> --
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g342qQu24719 for ietf-pkix-bks; Wed, 3 Apr 2002 18:52:26 -0800 (PST)
Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g342qPm24715 for <[e-mail]>; Wed, 3 Apr 2002 18:52:25 -0800 (PST)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id <H5DC14A1>; Thu, 4 Apr 2002 12:50:48 +1000
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: [e-mail], "'David Chadwick'" <[e-mail]>
Cc: "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Date: Thu, 4 Apr 2002 12:51:59 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
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>

Steven,

> I need a standard way to represent attribute values of the
> other two thirds in LDAP and LDIF. The ;binary option serves that
> purpose.

I don't see this as logical. Do you simply mean the use of ;binary means you
don't have to define another encoding? For, surely, defining the behaviour
to be same for ;binary as without it achieves the same end?

Ron.

-----Original Message-----
From: Steven Legg [mailto:[e-mail]]
Sent: Thursday, 4 April 2002 12:22
To: 'David Chadwick'
Cc: 'LDAP BIS'; 'PKIX'
Subject: RE: LDAP Certificate transfer syntax



David,

David Chadwick wrote:
> Sent: Thursday, 4 April 2002 8:45
> To: Kurt D. Zeilenga
> Cc: Sharon Boeyen; 'Mark Wahl'; Mark C Smith; LDAP BIS; PKIX
> Subject: Re: LDAP Certificate transfer syntax

> > In David's table, he shows that existing LDAPv3 implementations
> > are "OK".   That is, LDAPv3 is not broken in this regard.  The
> > specification is clear and there multiple interoperable
> > LDAPv3 implementations.
> > 
> 
> But LDAP (v2 and v3) is deficient in that it has never specified a
> workable "native" transfer encoding for certificates. The 
> LDAPv2 attempt
> was broken as we know, and v3 never replaced it - until my 
> proposed text
> now. Are certificates the only commonly used attributes without a
> "native" encoding? I cant think of any others.

I commonly use entryACI, prescriptiveACI and subentry ACI (ACI Item
syntax) and subtreeSpecification (Subtree Specification syntax).
Neither of the syntaxes for these attributes has a defined
LDAP-specific (i.e. native) encoding in RFC 2252 or RFC 2256.

> So this is a deficiency
> that should be rectified in my opinion.

Recent I-Ds have proposed human readable character string encodings
for both the ACI Item syntax and the Subtree Specification syntax,
by referencing the Generic String Encoding Rules, to correct the
deficiency in these syntaxes. This is in keeping with the statement
in RFC 2252 that "The encoding rules defined for a given attribute
syntax must produce octet strings. To the greatest extent possible,
encoded octet strings should be usable in their native encoded form
for display purposes".

Thus a "right" way to fix the Certificate syntax is to define
the LDAP-specific/native encoding to be the GSER encoding :-).

Had the ACI Item and Subtree Specification syntaxes previously been
defined such that their LDAP-specific encoding was the same as
their ;binary encoding it would not now be possible to define the
default format to be a human readable character string encoding.


> > That is, this suggest change will implementations to updated to
> > support it.  This will include some clients (such as those which
> > as for "*" and expect userCertificate;binary) 
> 
> agreed, if a server is to be consistent it probably would not put
> ;binary on any returned attributes, although I believe that todays
> LDAPv3 servers will put ;binary on certificates because of the MUST
> requirement. If they continued to do this in the future it would not
> cause any problems with the clients, but would be inconsistent
> behaviour.
> 
> >and most (if not
> > all) servers.  That's bad!
> > 
> 
> I think the change would not have been necessary if all existing
> products had implemented the current spec. And thats bad!!

The fault is in the incorrectly implemented products. The obligation
to change is on them, not the correctly implemented products.


> > Hence, for LDAPv3 interoperability sake, the specification needs
> > to continue to MUST the use of ;binary for these attributes except
> > where the client and server have a prior agreement that the
> > OPTIONAL native encoding is to be used.
> > 
> 
> As a general rule I think that continuing to mandate one particular
> tranfer encoding just for certificates is wrong and leaves us 
> in hole in
> the future if new transfer encodings are developed, such as XML (which
> incidentally has now been standardised for certificates). So how would
> you propose to cater for XML encodings in the future?

One way is to provide an update to the Certificate syntax to say that
values in the syntax MUST NOT be requested or returned without an
explicit transfer option. We could also say that now, in the current
draft.


> > Of course, one ought to wonder why any LDAPv3 implementation
> > would support this OPTIONAL native encoding when the REQUIRED
> > encoding is more broadly implemented and provides the same
> > functionality.   It seems redundant to me.
> > 
> 
> Clearly there is redundancy once a native encoding is 
> specified and this
> happens to be the same as the ;binary encoding, that is not in doubt.
> But who is to say which one is the redundant one? It could be 
> the use of
> ;binary. Maybe this transfer encoding is no longer needed by LDAPv3
> (just being devil's advocate here :-)

Only about a third of the syntaxes I support have defined LDAP-specific
encodings. I need a standard way to represent attribute values of the
other two thirds in LDAP and LDIF. The ;binary option serves that
purpose. Now if someone were to mandate that all additional LDAP syntaxes
must use GSER for the LDAP-specific encoding then I wouldn't need ;binary.

Regards,
Steven

> 
> David
> 
> 
> > Kurt
> 
> -- 
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g342NCF24076 for ietf-pkix-bks; Wed, 3 Apr 2002 18:23:12 -0800 (PST)
Received: from nexus.adacel.com (shelob.adacel.com.au [203.36.26.146] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g342N6m24071 for <[e-mail]>; Wed, 3 Apr 2002 18:23:10 -0800 (PST)
Received: (qmail 1491 invoked from network); 4 Apr 2002 02:19:56 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 4 Apr 2002 02:19:56 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: "'David Chadwick'" <[e-mail]>
Cc: "'LDAP BIS'" <[e-mail]>, "'PKIX'" <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Date: Thu, 4 Apr 2002 12:21:40 +1000
Message-ID: <001001c1db7f$751e3cd0$[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 8.5, Build 4.71.2377.0
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0
In-Reply-To: <[e-mail]>
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>

David,

David Chadwick wrote:
> Sent: Thursday, 4 April 2002 8:45
> To: Kurt D. Zeilenga
> Cc: Sharon Boeyen; 'Mark Wahl'; Mark C Smith; LDAP BIS; PKIX
> Subject: Re: LDAP Certificate transfer syntax

> > In David's table, he shows that existing LDAPv3 implementations
> > are "OK".   That is, LDAPv3 is not broken in this regard.  The
> > specification is clear and there multiple interoperable
> > LDAPv3 implementations.
> > 
> 
> But LDAP (v2 and v3) is deficient in that it has never specified a
> workable "native" transfer encoding for certificates. The 
> LDAPv2 attempt
> was broken as we know, and v3 never replaced it - until my 
> proposed text
> now. Are certificates the only commonly used attributes without a
> "native" encoding? I cant think of any others.

I commonly use entryACI, prescriptiveACI and subentry ACI (ACI Item
syntax) and subtreeSpecification (Subtree Specification syntax).
Neither of the syntaxes for these attributes has a defined
LDAP-specific (i.e. native) encoding in RFC 2252 or RFC 2256.

> So this is a deficiency
> that should be rectified in my opinion.

Recent I-Ds have proposed human readable character string encodings
for both the ACI Item syntax and the Subtree Specification syntax,
by referencing the Generic String Encoding Rules, to correct the
deficiency in these syntaxes. This is in keeping with the statement
in RFC 2252 that "The encoding rules defined for a given attribute
syntax must produce octet strings. To the greatest extent possible,
encoded octet strings should be usable in their native encoded form
for display purposes".

Thus a "right" way to fix the Certificate syntax is to define
the LDAP-specific/native encoding to be the GSER encoding :-).

Had the ACI Item and Subtree Specification syntaxes previously been
defined such that their LDAP-specific encoding was the same as
their ;binary encoding it would not now be possible to define the
default format to be a human readable character string encoding.


> > That is, this suggest change will implementations to updated to
> > support it.  This will include some clients (such as those which
> > as for "*" and expect userCertificate;binary) 
> 
> agreed, if a server is to be consistent it probably would not put
> ;binary on any returned attributes, although I believe that todays
> LDAPv3 servers will put ;binary on certificates because of the MUST
> requirement. If they continued to do this in the future it would not
> cause any problems with the clients, but would be inconsistent
> behaviour.
> 
> >and most (if not
> > all) servers.  That's bad!
> > 
> 
> I think the change would not have been necessary if all existing
> products had implemented the current spec. And thats bad!!

The fault is in the incorrectly implemented products. The obligation
to change is on them, not the correctly implemented products.


> > Hence, for LDAPv3 interoperability sake, the specification needs
> > to continue to MUST the use of ;binary for these attributes except
> > where the client and server have a prior agreement that the
> > OPTIONAL native encoding is to be used.
> > 
> 
> As a general rule I think that continuing to mandate one particular
> tranfer encoding just for certificates is wrong and leaves us 
> in hole in
> the future if new transfer encodings are developed, such as XML (which
> incidentally has now been standardised for certificates). So how would
> you propose to cater for XML encodings in the future?

One way is to provide an update to the Certificate syntax to say that
values in the syntax MUST NOT be requested or returned without an
explicit transfer option. We could also say that now, in the current
draft.


> > Of course, one ought to wonder why any LDAPv3 implementation
> > would support this OPTIONAL native encoding when the REQUIRED
> > encoding is more broadly implemented and provides the same
> > functionality.   It seems redundant to me.
> > 
> 
> Clearly there is redundancy once a native encoding is 
> specified and this
> happens to be the same as the ;binary encoding, that is not in doubt.
> But who is to say which one is the redundant one? It could be 
> the use of
> ;binary. Maybe this transfer encoding is no longer needed by LDAPv3
> (just being devil's advocate here :-)

Only about a third of the syntaxes I support have defined LDAP-specific
encodings. I need a standard way to represent attribute values of the
other two thirds in LDAP and LDIF. The ;binary option serves that
purpose. Now if someone were to mandate that all additional LDAP syntaxes
must use GSER for the LDAP-specific encoding then I wouldn't need ;binary.

Regards,
Steven

> 
> David
> 
> 
> > Kurt
> 
> -- 
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g341J0H22580 for ietf-pkix-bks; Wed, 3 Apr 2002 17:19:00 -0800 (PST)
Received: from mtiwmhc23.worldnet.att.net (mtiwmhc23.worldnet.att.net [204.127.131.48]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g341Ixm22576 for <[e-mail]>; Wed, 3 Apr 2002 17:18:59 -0800 (PST)
Received: from Chokhani ([12.91.127.195]) by mtiwmhc23.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020404011856.DQDG8815.mtiwmhc23.worldnet.att.net@Chokhani>; Thu, 4 Apr 2002 01:18:56 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: One last comment on DPD requirements
Date: Wed, 3 Apr 2002 20:20:38 -0500
Message-ID: <003b01c1db76$ee825fb0$a300a8c0@Chokhani>
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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300
Importance: Normal
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>

Russ:

I agree with you, but for a different reason.  I do not think this is
application specific issue.  I think it is the path validation issue.  I
do not think that the DPD server can know which paths are good without
doing a validation also, specially to see if there will be any name
constraints or certificate policy related failures.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Housley, Russ
Sent: Wednesday, April 03, 2002 2:12 PM
To: Ambarish Malpani; Stephen Kent
Cc: [e-mail]
Subject: Re: One last comment on DPD requirements



Steve & Ambarish:

>>Hi Group,
>>     One last (slightly late) comment on the DPD requirements that has

>>been troubling me:
>>
>>In the DPD requirements, there is a reasonable amount of text that 
>>talks about how a server can return multiple paths back to the client 
>>(to allow the client to decide which path is the best).
>>
>>The main goal of DPD is to try and simplify the client. In how many 
>>cases do people really want multiple paths back from the server. While

>>it is the right requirement in principal, do folks really think 
>>clients will want multiple paths back from a DPD server? Are we adding

>>the additional flexiblity/complexity just for technical purity?
>>
>>Comments will be appreciated.
>>
>>Regards,
>>Ambarish
>
>I too would favor simplifying the protocol requirement here. Some folks
>have suggested motivations for multiple paths, but this does seem to 
>conflict with the fundamental goal of creating a protocol to satisfy
the 
>needs of thin clients.
>
>Steve

I agree with your goal.  It is far better for the client to tell the
server 
what it wants, then get back a single path that satisfies all of the 
requirements.  To do this, we need to be able to fully specify the
clients 
criteria and send them to the server.  I think that we know how to do
this 
for many PKI-enabled applications, but I am not sure that we know how to
do 
it for all applications, especially ones that are yet to be developed.

This leaves us with two choices.  Either the protocol returns multiple 
certification paths (the approach in the current document) or the
protocol 
requires the client to adequately specify its criteria.  This could be
done 
with the path discovery policy.  If we adopt this alternative, we should

include additional text so that implements expect application-specific 
(perhaps several application-specific path discovery policy if there are

multiple roles in the application).

Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3415EF22195 for ietf-pkix-bks; Wed, 3 Apr 2002 17:05:14 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3415Dm22191 for <[e-mail]>; Wed, 3 Apr 2002 17:05:13 -0800 (PST)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Wed, 03 Apr 2002 18:04:13 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0.1
Date: Wed, 03 Apr 2002 18:02:25 -0700
From: "Jim Sermersheim" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
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 note that 2252 and 2256 both have problems with the language used to
specify this.

2252 says that values of the Certificate syntax MUST be transferred
using the binary encoding. It then gives two attribute descriptions
"userCertificate;binary" and caCertificate;binary". If I create an
attribute called printerCertificate, what am I supposed to refer to it
as?

It can be argued that the MUST here refers to the encoding, and the
attribute descriptions are merely examples of the day.

2256 says "This attribute is to be stored and requested in the binary
form, as 'userCertificate;binary'". Am I to believe that I must somehow
store the ;binary option in my database? Aside from that sillines, there
is no MUST imperative here.

Jim

>>> "Kurt D. Zeilenga" <[e-mail]> 04/03/02 11:36AM >>>
This text does not clearly "MUST" the use of ;binary as
RFC 2252 and RFC 2256 did.  As previously noted, this
"MUST" should not be dropped as doing so will cause
interoperability problems between implementations of
the current technical specification and the revised
technical specification.

Kurt

At 05:29 AM 2002-04-01, David Chadwick wrote:
>Colleagues
>
>Here is my proposed change to the section describing the LDAP syntax
for
>cerificates in the PKIX id
><draft-pkix-ldap-schema-03.txt> which should be published before the
end
>of April. As this is likely to be the most contentious part of the
new
>ID, I thought it would be useful to distribute this text at the
earlier
>possible moment.
>
>All constructive comments welcomed
>
>David
>
>
>3.3  Certificate Syntax
>
>A value in this transfer syntax is the binary octet string that
results
>from BER or DER-encoding of an X.509 public key certificate.  The
>following string states the OID assigned to this syntax:
>
>      ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
>
>Servers must preserve values in this syntax exactly as given when
>storing and retrieving them. 
>
>Note. Due to the changes from X.509(1988) to X.509(1993) and
subsequent
>changes to the ASN.1 definition to support certificate extensions in
>X.509(1997), no character string transfer syntax is defined for
>certificates. The BNF notation in RFC 1778 [12] for "User
Certificate"
>MUST NOT be used. Values in this syntax MUST be transferred as BER or
>DER encoded octets. The use of the ;binary encoding option, i.e. by
>requesting or returning the attributes with descriptions
>"userCertificate;binary" or "caCertificate;binary" has no effect on
the
>transfer syntax.



Received: by above.proper.com (8.11.6/8.11.3) id g34135D22167 for ietf-pkix-bks; Wed, 3 Apr 2002 17:03:05 -0800 (PST)
Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g34134m22163 for <[e-mail]>; Wed, 3 Apr 2002 17:03:04 -0800 (PST)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id <H5DC1S97>; Thu, 4 Apr 2002 11:01:25 +1000
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: Mark Wahl <[e-mail]>
Cc: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Date: Thu, 4 Apr 2002 11:02:37 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
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 thought certificate syntax was being removed from the LDAP v3 specs and,
therefore, certificate syntax was not an issue for DLAPbis?

Ron.

-----Original Message-----
From: Mark Wahl [mailto:[e-mail]]
Sent: Thursday, 4 April 2002 5:51
To: David Chadwick
Cc: Kurt D. Zeilenga; Mark C Smith; LDAP BIS; PKIX; [e-mail]
Subject: Re: LDAP Certificate transfer syntax


David Chadwick wrote:
> 
> 
> Now to the backwards compatibility issues. In the table below the only
> problem will come with a new LDAPv3 client that does not use ;binary
> with an existing v3 server that demands it. But we already have an
> inconsistency in these current LDAPv3 servers in that they accept LDAPv2
> queries without ;binary but not LDAPv3 queries without ;binary. 

I do not think LDAPv2-LDAPv3 behavior is sufficient justification to cause 
incompatibility between two LDAPv3 implementations.

Maybe an "LDAPv4" should have a different way for clients to send  
certificate, but LDAPv2 compatibility should not be a concern that causes
this significant a change inside of the LDAPv3 specs.  That is out of scope 
for LDAPBIS.

Mark Wahl
Sun Microsystems Inc.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g340TM821105 for ietf-pkix-bks; Wed, 3 Apr 2002 16:29:22 -0800 (PST)
Received: from mail5.microsoft.com (mail5.microsoft.com [131.107.3.121]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g340TLm21101 for <[e-mail]>; Wed, 3 Apr 2002 16:29:21 -0800 (PST)
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.148]) by mail5.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Apr 2002 16:29:17 -0800
Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 03 Apr 2002 16:29:18 -0800
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Apr 2002 16:29:17 -0800
Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.84]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.4905); Wed, 3 Apr 2002 16:29:17 -0800
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3590.0); Wed, 3 Apr 2002 16:25:55 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6157.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: One last comment on DPD requirements
Date: Wed, 3 Apr 2002 16:25:55 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: One last comment on DPD requirements
Thread-Index: AcHbQ+dA1WnXcxeoQW6r8T4tyC3OywAJf1Ug
From: "Trevor Freeman" <[e-mail]>
To: "Housley, Russ" <[e-mail]>, "Ambarish Malpani" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 04 Apr 2002 00:25:55.0503 (UTC) FILETIME=[48F62BF0:01C1DB6F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g340TLm21102
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 state that a client has to be exacting over its specification and
only wants one chain returned is presupposing the application model.
There are applications which are more comfortable with making a vague
request, getting back multiple chains to which they apply their own
policy. One of the specifications to the server can be find me all paths
that meet these criteria. I think the simple case on only wanting a
single chain is the most common so making that the default is fine.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]] 
Sent: Wednesday, April 03, 2002 11:12 AM
To: Ambarish Malpani; Stephen Kent
Cc: [e-mail]
Subject: Re: One last comment on DPD requirements


Steve & Ambarish:

>>Hi Group,
>>     One last (slightly late) comment on the DPD requirements that
>>has been troubling me:
>>
>>In the DPD requirements, there is a reasonable amount of text that
>>talks about how a server can return multiple paths back to the
>>client (to allow the client to decide which path is the best).
>>
>>The main goal of DPD is to try and simplify the client. In how many
>>cases do people really want multiple paths back from the server.
>>While it is the right requirement in principal, do folks really
>>think clients will want multiple paths back from a DPD server? Are
>>we adding the additional flexiblity/complexity just for
>>technical purity?
>>
>>Comments will be appreciated.
>>
>>Regards,
>>Ambarish
>
>I too would favor simplifying the protocol requirement here. Some folks

>have suggested motivations for multiple paths, but this does seem to 
>conflict with the fundamental goal of creating a protocol to satisfy
the 
>needs of thin clients.
>
>Steve

I agree with your goal.  It is far better for the client to tell the
server 
what it wants, then get back a single path that satisfies all of the 
requirements.  To do this, we need to be able to fully specify the
clients 
criteria and send them to the server.  I think that we know how to do
this 
for many PKI-enabled applications, but I am not sure that we know how to
do 
it for all applications, especially ones that are yet to be developed.

This leaves us with two choices.  Either the protocol returns multiple 
certification paths (the approach in the current document) or the
protocol 
requires the client to adequately specify its criteria.  This could be
done 
with the path discovery policy.  If we adopt this alternative, we should

include additional text so that implements expect application-specific 
(perhaps several application-specific path discovery policy if there are

multiple roles in the application).

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33NJb519029 for ietf-pkix-bks; Wed, 3 Apr 2002 15:19:37 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33NJZm19025 for <[e-mail]>; Wed, 3 Apr 2002 15:19:35 -0800 (PST)
Received: from stsIBMT20.addtrust.com ([213.64.0.98]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 4 Apr 2002 01:19:16 +0200
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 04 Apr 2002 01:19:13 +0200
To: Denis Pinkas <[e-mail]>, "Housley, Russ" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
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-OriginalArrivalTime: 03 Apr 2002 23:19:17.0508 (UTC) FILETIME=[F9F88C40:01C1DB65]
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,

Generally I have some problems with your way of arguing. My observation is 
that you ask us to be precise where there is no point in being precise and 
you fail to be precise yourself where your arguments need to be backed by 
facts and examples.

At least I think it would be fair of you to try to understand what the 
draft was written to solve and either argue that we try to find a solution 
to the wrong problem or that we try to solve the right problem the wrong way.

Right now I feel that you claim that we solve the wrong problem the wrong 
way, which is a rather hopeless originating discussion point.

/Stefan

At 17:55 2002-04-03 +0200, Denis Pinkas wrote:

>Russ,
>
>Thank you for this long reply ... that did not convinced me.
>The argumentation you provided is not crystal clear to me.
>
>See my comments below.
>
> > Denis:
> >
> > I fear that you have missed the point of the logotypes draft
> > altogether.  The authors recognize that the introduction needs to be
> > expanded, so we may be to blame for any misunderstanding.  To try and clear
> > up the misunderstanding, I offer some general observations before
> > responding to your specific comments.
> >
> > The logotype extension will aid in two situations:
> >         1.  Certificate-based Identification
> >         2.  Selection of Certificates
> >
> > In the first case, the need for human recognition
>
>1) Recognition of what ? or of which characteristics ?
>    Please be precise.
>
>2) Recognized by which entity ? Please be precise.
>    I would guess a human being acting as a relying party.
>
> > depends on the manner in
> > which certificates are used and whether certificates need to be visible to
> > human users. If certificates are to be used in open environments and in
> > applications that bring the user in conscious contact with the result of a
> > certificate-based identification process, then human recognition is highly
> > relevant, and it may be a necessity.
> >
> > Most applications provide the human user with an opportunity to view the
> > results of a successful certificate-based identification process.  When the
> > user takes the steps necessary to view these results, the user is presented
> > with a view of a certificate. This solution has two major problems.  First,
> > the function to view a certificate is often rather hard to find for a
> > non-technical user. Second, the presentation of the certificate is rather
> > technical; it is not user friendly. It contains no graphic symbols or
> > logotypes to enhance human recognition.
>
> > In the second case, there are software applications that expose human users
> > to certificates for the selection of a single certificate from a portfolio
> > of certificates. In some circumstances, the software application can use
> > information within the certificates to determine suitability; however, the
> > user must be queried if more than one certificate is suitable. The human
> > user must select one of them.
>
>I would guess that is that case it is a recognition by the subscriber.
>Is it what you mean ? Are there other cases you are thinking of ?
>Please be precise.
>
> > This situation is comparable to a person selecting a suitable plastic card
> > from his wallet. In this situation, substantial assistance is provided by
> > card color, location, and branding.
> >
> > In order provide similar support for certificate selection, the users need
> > tools to easily recognize and distinguish certificates. Introduction of
> > logotypes into certificates provides the necessary graphic.
>
> > Now, for your specific comments.
> >
> > COMMENT 1: Subject logotype.
> >
> > Currently a "subject organization logotype" is proposed. It definition is
> > as follows: "a logotype representing the organization identified in the
> > subject name in the certificate".
> >
> >  From this definition only a single logotype would be allowed for a
> > subject. It can make sense to attach more that one logotype to a subject,
> > that does not reflect necessarily the organization a user belongs to (e.g.
> > an individual is a Red Cross member) so the definition should be changed
> > to:
> >
> > "subject logotype" "a logotype representing any characteristic of the
> > entity identified in the subject name in the certificate".
> >
> > RESPONSE 1.
> >
> > We are allowing a graphical identity of the user to facilitate certificate
> > selection or acceptance. We are not trying to graphically represent every
> > attribute of the user.  We certainly do not want to overwhelm the designers
> > of graphic user interfaces.  We need to keep it simple.
>
>I do not buy this argument. The current proposal limits to logo type to the
>logo of the organization, whereas this limitation is not appropriate. A
>subject may even have no O (Organization) component in the DN and there
>could
>be other logos attached to the subject field.
>
> > COMMENT 2: Issuer logotype.
> >
> > Currently an "issuer organization logotype" is proposed. It definition is
> > as follows: "a logotype representing the organization identified as part of
> > the issuer name in the certificate".
> >
> >  From this definition a single logotype would be allowed for an issuer. It
> > can make sense to attach more that one logotype to an issuer, that does not
> > reflect necessarily the organization an issuer belongs to (e.g. an issuer
> > may support a "Privacy Policy" and be a member from two different trade
> > associations), so the definition should be changed to:
> >
> > "issuer logotype: a logotype representing any characteristic of the issuer
> > identified as part of the issuer name in the certificate".
> >
> > RESPONSE 2.
> >
> > Again, we are allowing a graphical identity of the user to facilitate
> > certificate selection or acceptance. We are not trying to graphically
> > represent every attribute of the issuer.
>
>I do not buy this argument. The current proposal limits to logo type to the
>logo of the issuer, whereas this limitation is not appropriate. See my
>examples again.
>
> > COMMENT 3: The "concept logotype", also renamed "community logotype" during
> > the last IETF meeting or " shared community logotype" in the minutes from
> > the same meeting is more hazy.
> >
> > The current text states:" Many issuers may use the concept logotypes to
> > co-brand with a global concept in order to gain global recognition of its
> > local service provision. This type of concept branding is very common in
> > credit card business where local independent card issuers issue cards
> > within a globally branded concept (such as VISA and MasterCard)".
> >
> > The current text also states: " the relationship between the issuer and
> > either the issuer  organization logotype or the concept logotype".
> >
> > A logotype is adding "human processable" information to enhance the
> > properties of an already existing field from a certificate. To this respect
> > it is sensible to add one (or more) logotypes that characterizes the issuer
> > and the subject. The real question is to which field the "concept
> > logotype / community logotype / shared community logotype" relates.
> >
> > It may relate :
> >    - either to the issuer, to state that an issuer belongs to some 
> group, or
> >    - to the certificate policy to state that the policy under which the
> >      certificate is issued obeys to some rules imposed by the organization
> >      whose logo is referenced.
> >
> > This leads to two possible ways:
> >     1) only consider two logotypes: issuer logotype and subject logotypes.
> >     2) consider three logotypes: issuer logotypes, subject logotypes and
> >        policy logotypes.
> >
> > I would favor the former, but would have no major problem to go with the
> > later. In that case the policy logotype would be defined as follows:
> >
> > "Policy logotype: a logotype representing any characteristic of the
> > certificate policy under which the certificate is issued".
> >
> > RESPONSE 3.
> >
> > Policy implies the wrong connotation. We are not trying to graphically
> > represent a certificate policy or anything about how the certificate was
> > issued. The community (or concept) logotype simply allows CA to enter into
> > collective branding relationships.
>
>A branding of what ?  Please be precise.
>
> > I suppose that a large group that share a common security policy could
> > register a logo for that policy and use it as a community logo.  While this
> > was not the model that we considered, it certainly is accommodated.
> >
> > COMMENT 4: Logotypes are not "claimed" by the issuer, but always *verified*
> > to some extend by the issuer. The current text is misleading:
> >
> >     "The relationship between the subject organization and the subject
> >     organization logotype and the relationship between the issuer and
> >     either the issuer organization logotype or the concept logotype, are
> >     relationships *claimed* by the issuer."
> >
> > RESPONSE 4.
> >
> > The issuer is responsible for the verification of anything that is included
> > in the certificate.  After all, the issuer signature covers it.  Thus, the
> > issuer is claiming that the logotypes are appropriate.
>
>Don't twist the wording.  :-)
>
>We agree on the concept, but we should try to use another wording and avoid
>to use the word "claim".
>
> > COMMENT 5: During the meeting, it has been proposed to add a small image of
> > the logotype in the certificate itself. In this WG we always have had a
> > concern about the size of the certificate, so that it can be lodged in some
> > small devices. So I would not favor to allow such provision in a
> > extension standardized by this WG.
> >
> > RESPONSE 5.
> >
> > There are environments where the client cannot access the Internet until
> > after the certificate is used.  Consider certificate-based authentication
> > to an ISP.  A small logotype in the certificate could be useful to aid
> > certificate selection in this situation.  The inclusion of a small logotype
> > is, of course, optional.
>
>...and instead of certificates between 1 K and 2 K bytes, have certificates
>with at least one more K !
>
>Denis
>
>
> > COMMENT 6: It should be made clear that this extension in non-critical.
> >
> > RESPONSE 6.
> >
> > Agree.  The logotype extension was never intended to be critical.
> >
> > COMMENT 7: The document includes many typos to be corrected.
> >
> > RESPONSE 7.
> >
> > We will make every effort to correct them before the next draft is 
> published.
> >
> > Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33N4eb18802 for ietf-pkix-bks; Wed, 3 Apr 2002 15:04:40 -0800 (PST)
Received: from tisch.mail.mindspring.net (tisch.mail.mindspring.net [207.69.200.157]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33N4cm18798 for <[e-mail]>; Wed, 3 Apr 2002 15:04:38 -0800 (PST)
Received: from user-2ivf760.dialup.mindspring.com ([165.247.156.192] helo=asn-1.com) by tisch.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16stnk-0001xj-00; Wed, 03 Apr 2002 18:04:25 -0500
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 17:56:03 -0500
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
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>

David,

Understood and agree. My point though is that if
the format of the initial encoding is preserved 
as an open type, it doesn't much matter what it 
happened to be when it was signed. 

It is only when someone tries to reconstruct the
certificate from its values using the strict DER 
subset of BER that a mismatch with the signature 
due to BER/DER differences in the encoding can 
arise.

And as you've stated, technically when you say BER 
you've included DER, as DER is a subset. But if 
you are talking about a protocol requirement you
may need to be careful with the language and try 
to be as explicit as possible.

Surely if ;binary means BER it is not illegal to 
return DER. But if ;binary means DER, then it would
seem that returning BER that is not from the DER 
subset would be illegal. 

And if a ;binary object is a BER wrapper around a
DER encoding, then that's another case. 

Phil



David Chadwick wrote:
> 
> Phil Griffin wrote:
> 
> > If this is done, then the concerns Russ raises as to
> > requiring extra processing disappear, and the issue that
> > David raised as to whether the protocol can be extended
> > to other encodings (BER or CER or PER or XER) is also mute.
> >
> > The Directory just knows it has a blob. It stores the blob
> > as given and can return the blob on demand.
> 
> Phil
> 
> thanks for this. But there is one further point, and that concerns
> certificate matching which is the other topic of the schema ID. For this
> to work, the server has to parse the blob and extract the various fields
> to be used in subsequent searches. Therefore the server needs to be told
> what transfer syntax the blob is being sent in. The current proposed
> text only allows the blob to be BER or DER and not PER or XER encoded.
> To allow the latter we would need to introduce new LDAP transfer
> encoding keywords such as ;PER and ;XML. The current ;binary keyword
> specifically means BER encoding. (And because DER is a subset of BER
> then ;binary is taken to mean DER as well, which maybe it should not if
> we were to be really strict?).
> 
> David
> 
> >
> > Phil
> >
> > "Housley, Russ" wrote:
> > >
> > > David:
> > >
> > > When DAP is used, certificates come back in BER.  This happens because the
> > > DAP PDU is defined in ASN.1, and the BER encoding of the PDU encodes the
> > > data too.  An OCTET STRING could have been used, but this was all done
> > > before there were object that had signatures.  Anyway, I see this as an
> > > opportunity to do better.
> > >
> > > I do not know about your AC development experience, but the specifications
> > > are quite clear about the need for DER.  It would be nice if the repository
> > > fetch did not force the client to restore the original DER encoding.
> > >
> > > I agree that this is not a schema issue. However, a comment that the DER
> > > encoding applied by the signer should be preserved is all I really
> > > want.  You have already fixed the problem where the repository access
> > > protocol is changing the encoding.
> > >
> > > Russ
> > >
> > > At 06:39 PM 4/3/2002 +0100, David Chadwick wrote:
> > > >Russ
> > > >
> > > >I dont think the issue below is one for the schema ID. The certificate
> > > >attributes in the directory should be perfectly happy to receive BER or
> > > >DER (or PER for that matter I guess). So the schema ID should allow
> > > >anything to be stored there.
> > > >
> > > >Your issue is more one for the LDAP profile ID which was last updated in
> > > >January. In the profile we can suggest that clients always use DER for
> > > >encoding certificates.  But what is the common WG concensus on this? FYI
> > > >in recent work we did with attribute certificates we found we had to use
> > > >BER because the DER Java objects were too buggy.
> > > >
> > > >David
> > > >
> > > >
> > > >"Housley, Russ" wrote:
> > > > >
> > > > > David:
> > > > >
> > > > > I would like to encourage clients to provide certificates in DER.  We ought
> > > > > to tell them that there will be less work for everyone if they provide
> > > > > DER-encoded certificates.  Likewise for CRLs.
> > > > >
> > > > > Russ
> > > > >
> > > > > At 10:32 PM 4/1/2002 +0100, David Chadwick wrote:
> > > > >
> > > > > >"Housley, Russ" wrote:
> > > > > > >
> > > > > > > David:
> > > > > > >
> > > > > > > Is it possible to preserve the DER encoding.  If not, then the DER
> > > > encoding
> > > > > > > must be restored in order to validate the signature?  This just
> > > > seems like
> > > > > > > wasted processing to me.
> > > > > > >
> > > > > >
> > > > > >Russ
> > > > > >
> > > > > >I quite agree. The revised text is meant to ensure that the DER or BER
> > > > > >encoding created by the client when the certificate was first sent to
> > > > > >the directory for storage is preserved as is. This is the purpose of the
> > > > > >sentence below in the revised text, viz:
> > > > > >
> > > > > > > >Servers must preserve values in this syntax exactly as given when
> > > > > > > >storing and retrieving them.
> > > > > > > >
> > > > > >
> > > > > >Perhaps I should say "as given to them by the client, when storing and
> > > > > >retrieving certificates"
> > > > > >
> > > > > >David
> > > > > >
> > > >
> > > >--
> > > >*****************************************************************
> > > >
> > > >David W. Chadwick, BSc PhD
> > > >Professor of Information Systems Security
> > > >IS Institute, University of Salford, Salford M5 4WT
> > > >Tel: [phone]  Fax [phone]
> > > >Mobile: [phone]
> > > >Email: [e-mail]
> > > >Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> > > >Research Projects: http://sec.isi.salford.ac.uk
> > > >Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> > > >X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> > > >Entrust key validation string: MLJ9-DU5T-HV8J
> > > >PGP Key ID is 0xBC238DE5
> > > >
> > > >*****************************************************************
> > > >
> 
> --
> *****************************************************************
> 
> David W. Chadwick, BSc PhD
> Professor of Information Systems Security
> IS Institute, University of Salford, Salford M5 4WT
> Tel: [phone]  Fax [phone]
> Mobile: [phone]
> Email: [e-mail]
> Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> Research Projects: http://sec.isi.salford.ac.uk
> Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> Entrust key validation string: MLJ9-DU5T-HV8J
> PGP Key ID is 0xBC238DE5
> 
> *****************************************************************


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33Mets18095 for ietf-pkix-bks; Wed, 3 Apr 2002 14:40:55 -0800 (PST)
Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33Mesm18091 for <[e-mail]>; Wed, 3 Apr 2002 14:40:54 -0800 (PST)
Received: from salford.ac.uk ([213.107.136.218]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Wed, 3 Apr 2002 23:40:46 +0100
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 23:44:45 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: Sharon Boeyen <[e-mail]>, "'Mark Wahl'" <[e-mail]>, Mark C Smith <[e-mail]>, LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <5.1.0.14.0.20020403133750.0252a4f0@127.0.0.1>
Content-Type: multipart/mixed; boundary="------------2760BDF270BAB33094D4E39F"
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.
--------------2760BDF270BAB33094D4E39F
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Kurt D. Zeilenga" wrote:

> These changes have ZERO impact on LDAPv2 implementations.
> 

Agreed


> In David's table, he shows that existing LDAPv3 implementations
> are "OK".   That is, LDAPv3 is not broken in this regard.  The
> specification is clear and there multiple interoperable
> LDAPv3 implementations.
> 

But LDAP (v2 and v3) is deficient in that it has never specified a
workable "native" transfer encoding for certificates. The LDAPv2 attempt
was broken as we know, and v3 never replaced it - until my proposed text
now. Are certificates the only commonly used attributes without a
"native" encoding? I cant think of any others. So this is a deficiency
that should be rectified in my opinion.


> Removing the "MUST" request 

This is a natural consequence of defining a native encoding.
Clients now have a choice of transfer encoding to ask for. It just so
happens that in the case of certificates both native and ;binary
encodings happen to be the same (fortunately for signature checking :-)

>and use certificate attributes using
> ;binary will cause interoperability problems and will force
> unnecessary changes to BOTH LDAPv3 clients and LDAPv3 servers.

No, it wont necessitate any changes to clients. Once the LDAPv3 servers
make the change, this is backwards compatible and will work with any v3
client. The servers can accept any request, with or without ;binary, and
if they want can always return ;binary in their responses to cater for
both types of client.

> This is because LDAPv3 does not provide any mechanism for
> an LDAP peer (client or server) to discover which options its peer
> (server or client) to discover which attribute descriptions
> it supports.
> 

This is not a certificate problem per se, this is a generic LDAP problem
isnt it?

> That is, this suggest change will implementations to updated to
> support it.  This will include some clients (such as those which
> as for "*" and expect userCertificate;binary) 

agreed, if a server is to be consistent it probably would not put
;binary on any returned attributes, although I believe that todays
LDAPv3 servers will put ;binary on certificates because of the MUST
requirement. If they continued to do this in the future it would not
cause any problems with the clients, but would be inconsistent
behaviour.

>and most (if not
> all) servers.  That's bad!
> 

I think the change would not have been necessary if all existing
products had implemented the current spec. And thats bad!!

> Hence, for LDAPv3 interoperability sake, the specification needs
> to continue to MUST the use of ;binary for these attributes except
> where the client and server have a prior agreement that the
> OPTIONAL native encoding is to be used.
> 

As a general rule I think that continuing to mandate one particular
tranfer encoding just for certificates is wrong and leaves us in hole in
the future if new transfer encodings are developed, such as XML (which
incidentally has now been standardised for certificates). So how would
you propose to cater for XML encodings in the future?


> Of course, one ought to wonder why any LDAPv3 implementation
> would support this OPTIONAL native encoding when the REQUIRED
> encoding is more broadly implemented and provides the same
> functionality.   It seems redundant to me.
> 

Clearly there is redundancy once a native encoding is specified and this
happens to be the same as the ;binary encoding, that is not in doubt.
But who is to say which one is the redundant one? It could be the use of
;binary. Maybe this transfer encoding is no longer needed by LDAPv3
(just being devil's advocate here :-)

David


> Kurt

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------2760BDF270BAB33094D4E39F
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------2760BDF270BAB33094D4E39F--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33Ltaj15726 for ietf-pkix-bks; Wed, 3 Apr 2002 13:55:36 -0800 (PST)
Received: from mta01-svc.ntlworld.com (mta01-svc.ntlworld.com [62.253.162.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33LtYm15722 for <[e-mail]>; Wed, 3 Apr 2002 13:55:34 -0800 (PST)
Received: from salford.ac.uk ([213.107.136.218]) by mta01-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Wed, 3 Apr 2002 22:55:36 +0100
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 22:59:35 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Phil Griffin <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------6D0B5EBF29B744646766569C"
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.
--------------6D0B5EBF29B744646766569C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Phil Griffin wrote:

> If this is done, then the concerns Russ raises as to
> requiring extra processing disappear, and the issue that
> David raised as to whether the protocol can be extended
> to other encodings (BER or CER or PER or XER) is also mute.
> 
> The Directory just knows it has a blob. It stores the blob
> as given and can return the blob on demand.

Phil

thanks for this. But there is one further point, and that concerns
certificate matching which is the other topic of the schema ID. For this
to work, the server has to parse the blob and extract the various fields
to be used in subsequent searches. Therefore the server needs to be told
what transfer syntax the blob is being sent in. The current proposed
text only allows the blob to be BER or DER and not PER or XER encoded.
To allow the latter we would need to introduce new LDAP transfer
encoding keywords such as ;PER and ;XML. The current ;binary keyword
specifically means BER encoding. (And because DER is a subset of BER
then ;binary is taken to mean DER as well, which maybe it should not if
we were to be really strict?).

David

> 
> Phil
> 
> "Housley, Russ" wrote:
> >
> > David:
> >
> > When DAP is used, certificates come back in BER.  This happens because the
> > DAP PDU is defined in ASN.1, and the BER encoding of the PDU encodes the
> > data too.  An OCTET STRING could have been used, but this was all done
> > before there were object that had signatures.  Anyway, I see this as an
> > opportunity to do better.
> >
> > I do not know about your AC development experience, but the specifications
> > are quite clear about the need for DER.  It would be nice if the repository
> > fetch did not force the client to restore the original DER encoding.
> >
> > I agree that this is not a schema issue. However, a comment that the DER
> > encoding applied by the signer should be preserved is all I really
> > want.  You have already fixed the problem where the repository access
> > protocol is changing the encoding.
> >
> > Russ
> >
> > At 06:39 PM 4/3/2002 +0100, David Chadwick wrote:
> > >Russ
> > >
> > >I dont think the issue below is one for the schema ID. The certificate
> > >attributes in the directory should be perfectly happy to receive BER or
> > >DER (or PER for that matter I guess). So the schema ID should allow
> > >anything to be stored there.
> > >
> > >Your issue is more one for the LDAP profile ID which was last updated in
> > >January. In the profile we can suggest that clients always use DER for
> > >encoding certificates.  But what is the common WG concensus on this? FYI
> > >in recent work we did with attribute certificates we found we had to use
> > >BER because the DER Java objects were too buggy.
> > >
> > >David
> > >
> > >
> > >"Housley, Russ" wrote:
> > > >
> > > > David:
> > > >
> > > > I would like to encourage clients to provide certificates in DER.  We ought
> > > > to tell them that there will be less work for everyone if they provide
> > > > DER-encoded certificates.  Likewise for CRLs.
> > > >
> > > > Russ
> > > >
> > > > At 10:32 PM 4/1/2002 +0100, David Chadwick wrote:
> > > >
> > > > >"Housley, Russ" wrote:
> > > > > >
> > > > > > David:
> > > > > >
> > > > > > Is it possible to preserve the DER encoding.  If not, then the DER
> > > encoding
> > > > > > must be restored in order to validate the signature?  This just
> > > seems like
> > > > > > wasted processing to me.
> > > > > >
> > > > >
> > > > >Russ
> > > > >
> > > > >I quite agree. The revised text is meant to ensure that the DER or BER
> > > > >encoding created by the client when the certificate was first sent to
> > > > >the directory for storage is preserved as is. This is the purpose of the
> > > > >sentence below in the revised text, viz:
> > > > >
> > > > > > >Servers must preserve values in this syntax exactly as given when
> > > > > > >storing and retrieving them.
> > > > > > >
> > > > >
> > > > >Perhaps I should say "as given to them by the client, when storing and
> > > > >retrieving certificates"
> > > > >
> > > > >David
> > > > >
> > >
> > >--
> > >*****************************************************************
> > >
> > >David W. Chadwick, BSc PhD
> > >Professor of Information Systems Security
> > >IS Institute, University of Salford, Salford M5 4WT
> > >Tel: [phone]  Fax [phone]
> > >Mobile: [phone]
> > >Email: [e-mail]
> > >Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> > >Research Projects: http://sec.isi.salford.ac.uk
> > >Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> > >X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> > >Entrust key validation string: MLJ9-DU5T-HV8J
> > >PGP Key ID is 0xBC238DE5
> > >
> > >*****************************************************************
> > >

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------6D0B5EBF29B744646766569C
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------6D0B5EBF29B744646766569C--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33Lebs15105 for ietf-pkix-bks; Wed, 3 Apr 2002 13:40:37 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33LeZm15096 for <[e-mail]>; Wed, 3 Apr 2002 13:40:35 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g33LeFC12416; Wed, 3 Apr 2002 21:40:15 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020403133750.0252a4f0@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 03 Apr 2002 13:40:27 -0800
To: Sharon Boeyen <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Cc: "'Mark Wahl'" <[e-mail]>, David Chadwick <[e-mail]>, Mark C Smith <[e-mail]>, LDAP BIS <[e-mail]>, PKIX <[e-mail]>
In-Reply-To: <[e-mail] .com>
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>

At 12:32 PM 2002-04-03, Sharon Boeyen wrote:
>>From the PKIX perspective, I firmly believe that backward compatibility 
>with the PKIX LDAP specs is a very important issue.

I think there is some confusion here as to regards to
"compatibility".  This is an update/revision of an LDAPv3
technical specification.  We are implicitly talking about
compatibility of (conformant) implementations of the
existing LDAPv3 technical specification and future
(conformant) implementations of a future LDAPv3 technical
specification.

LDAPv2 and LDAPv3 are distinct on-the-wire protocols.
Directory add, delete, modify, rename, or search operations
either has LDAPv2 syntax and semantics or has LDAPv3 syntax
and semantics.

Here we are talking about changes to LDAPv3 technical
specification and how they would or wouldn't affect LDAPv3
implementations.

These changes have ZERO impact on LDAPv2 implementations.


>I believe that what 
>David is proposing satisfies that important criteria and support the 
>proposal.
In David's table, he shows that existing LDAPv3 implementations
are "OK".   That is, LDAPv3 is not broken in this regard.  The
specification is clear and there multiple interoperable
LDAPv3 implementations.

Removing the "MUST" request and use certificate attributes using
;binary will cause interoperability problems and will force
unnecessary changes to BOTH LDAPv3 clients and LDAPv3 servers.
This is because LDAPv3 does not provide any mechanism for
an LDAP peer (client or server) to discover which options its peer
(server or client) to discover which attribute descriptions
it supports.

That is, this suggest change will implementations to updated to
support it.  This will include some clients (such as those which
as for "*" and expect userCertificate;binary) and most (if not
all) servers.  That's bad!

Hence, for LDAPv3 interoperability sake, the specification needs
to continue to MUST the use of ;binary for these attributes except
where the client and server have a prior agreement that the
OPTIONAL native encoding is to be used.

Of course, one ought to wonder why any LDAPv3 implementation
would support this OPTIONAL native encoding when the REQUIRED
encoding is more broadly implemented and provides the same
functionality.   It seems redundant to me.

Kurt



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33KWHE12689 for ietf-pkix-bks; Wed, 3 Apr 2002 12:32:17 -0800 (PST)
Received: from SOTTMXS01.entrust.com (mail.entrust.com [216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33KWEm12679 for <[e-mail]>; Wed, 3 Apr 2002 12:32:14 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <2GYX4KF4>; Wed, 3 Apr 2002 15:32:12 -0500
Message-ID: <[e-mail]>
From: Sharon Boeyen <[e-mail]>
To: "'Mark Wahl'" <[e-mail]>, David Chadwick <[e-mail]>
Cc: "Kurt D. Zeilenga" <[e-mail]>, Mark C Smith <[e-mail]>, LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax
Date: Wed, 3 Apr 2002 15:32:11 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1DB4E.A1DBE780"
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_01C1DB4E.A1DBE780
Content-Type: text/plain

>From the PKIX perspective, I firmly believe that backward compatibility 
with the PKIX LDAP specs is a very important issue. I believe that what 
David is proposing satisfies that important criteria and support the 
proposal.

Sharon 


-----Original Message-----
From: Mark Wahl [mailto:[e-mail]]
Sent: Wednesday, April 03, 2002 2:51 PM
To: David Chadwick
Cc: Kurt D. Zeilenga; Mark C Smith; LDAP BIS; PKIX; [e-mail]
Subject: Re: LDAP Certificate transfer syntax



David Chadwick wrote:
> 
> 
> Now to the backwards compatibility issues. In the table below the only
> problem will come with a new LDAPv3 client that does not use ;binary
> with an existing v3 server that demands it. But we already have an
> inconsistency in these current LDAPv3 servers in that they accept LDAPv2
> queries without ;binary but not LDAPv3 queries without ;binary. 

I do not think LDAPv2-LDAPv3 behavior is sufficient justification to cause 
incompatibility between two LDAPv3 implementations.

Maybe an "LDAPv4" should have a different way for clients to send  
certificate, but LDAPv2 compatibility should not be a concern that causes
this significant a change inside of the LDAPv3 specs.  That is out of scope 
for LDAPBIS.

Mark Wahl
Sun Microsystems Inc.

------_=_NextPart_001_01C1DB4E.A1DBE780
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: LDAP Certificate transfer syntax</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>From the PKIX perspective, I firmly believe that backward compatibility </FONT>
<BR><FONT SIZE=2>with the PKIX LDAP specs is a very important issue. I believe that what </FONT>
<BR><FONT SIZE=2>David is proposing satisfies that important criteria and support the </FONT>
<BR><FONT SIZE=2>proposal.</FONT>
</P>

<P><FONT SIZE=2>Sharon </FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Mark Wahl [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, April 03, 2002 2:51 PM</FONT>
<BR><FONT SIZE=2>To: David Chadwick</FONT>
<BR><FONT SIZE=2>Cc: Kurt D. Zeilenga; Mark C Smith; LDAP BIS; PKIX; [e-mail]</FONT>
<BR><FONT SIZE=2>Subject: Re: LDAP Certificate transfer syntax</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=2>David Chadwick wrote:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Now to the backwards compatibility issues. In the table below the only</FONT>
<BR><FONT SIZE=2>&gt; problem will come with a new LDAPv3 client that does not use ;binary</FONT>
<BR><FONT SIZE=2>&gt; with an existing v3 server that demands it. But we already have an</FONT>
<BR><FONT SIZE=2>&gt; inconsistency in these current LDAPv3 servers in that they accept LDAPv2</FONT>
<BR><FONT SIZE=2>&gt; queries without ;binary but not LDAPv3 queries without ;binary. </FONT>
</P>

<P><FONT SIZE=2>I do not think LDAPv2-LDAPv3 behavior is sufficient justification to cause </FONT>
<BR><FONT SIZE=2>incompatibility between two LDAPv3 implementations.</FONT>
</P>

<P><FONT SIZE=2>Maybe an &quot;LDAPv4&quot; should have a different way for clients to send&nbsp; </FONT>
<BR><FONT SIZE=2>certificate, but LDAPv2 compatibility should not be a concern that causes</FONT>
<BR><FONT SIZE=2>this significant a change inside of the LDAPv3 specs.&nbsp; That is out of scope </FONT>
<BR><FONT SIZE=2>for LDAPBIS.</FONT>
</P>

<P><FONT SIZE=2>Mark Wahl</FONT>
<BR><FONT SIZE=2>Sun Microsystems Inc.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1DB4E.A1DBE780--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33Jog810542 for ietf-pkix-bks; Wed, 3 Apr 2002 11:50:42 -0800 (PST)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33Jofm10532 for <[e-mail]>; Wed, 3 Apr 2002 11:50:41 -0800 (PST)
Received: from rowlf.Central.Sun.COM ([129.153.131.70]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA15108; Wed, 3 Apr 2002 11:50:08 -0800 (PST)
Received: from sun.com (dhcp-aus09-222 [129.153.130.222]) by rowlf.Central.Sun.COM (8.11.6+Sun/8.11.6/ENSMAIL,v2.2) with ESMTP id g33Jo5e15260; Wed, 3 Apr 2002 13:50:06 -0600 (CST)
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 13:50:57 -0600
From: Mark Wahl <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
CC: "Kurt D. Zeilenga" <[e-mail]>, Mark C Smith <[e-mail]>, LDAP BIS <[e-mail]>, PKIX <[e-mail]>, [e-mail]
Subject: Re: LDAP Certificate transfer syntax
References: <[e-mail]> <5.1.0.14.0.20020403094751.01744a18@127.0.0.1> <[e-mail]>
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>

David Chadwick wrote:
> 
> 
> Now to the backwards compatibility issues. In the table below the only
> problem will come with a new LDAPv3 client that does not use ;binary
> with an existing v3 server that demands it. But we already have an
> inconsistency in these current LDAPv3 servers in that they accept LDAPv2
> queries without ;binary but not LDAPv3 queries without ;binary. 

I do not think LDAPv2-LDAPv3 behavior is sufficient justification to cause 
incompatibility between two LDAPv3 implementations.

Maybe an "LDAPv4" should have a different way for clients to send  
certificate, but LDAPv2 compatibility should not be a concern that causes
this significant a change inside of the LDAPv3 specs.  That is out of scope 
for LDAPBIS.

Mark Wahl
Sun Microsystems Inc.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33JW7109686 for ietf-pkix-bks; Wed, 3 Apr 2002 11:32:07 -0800 (PST)
Received: from mclean.mail.mindspring.net (mclean.mail.mindspring.net [207.69.200.57]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33JW5m09682 for <[e-mail]>; Wed, 3 Apr 2002 11:32:05 -0800 (PST)
Received: from user-2ivf7qu.dialup.mindspring.com ([165.247.159.94] helo=asn-1.com) by mclean.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16sqTF-0003Hb-00; Wed, 03 Apr 2002 14:31:02 -0500
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 14:23:25 -0500
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: David Chadwick <[e-mail]>, LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <[e-mail]> <[e-mail]> <[e-mail]>
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>

Forgive me if I'm wrong here, but I had the understanding 
that the outermost sequence wrapper of a certificate was
a BER encoding, and the the inner content "ToBeSigned"
is required to be encoded using DER.

I think the point here should be, regardless of how the
certificate was initially encoded, it should be treated
as an open type, a value of type Certificate in its 
encoded form, and that the encoding received by the 
Directory should be preserved, and that preserved form
of the data should be returned to a requester.

If this is done, then the concerns Russ raises as to
requiring extra processing disappear, and the issue that
David raised as to whether the protocol can be extended 
to other encodings (BER or CER or PER or XER) is also mute.

The Directory just knows it has a blob. It stores the blob
as given and can return the blob on demand. 

Phil

"Housley, Russ" wrote:
> 
> David:
> 
> When DAP is used, certificates come back in BER.  This happens because the
> DAP PDU is defined in ASN.1, and the BER encoding of the PDU encodes the
> data too.  An OCTET STRING could have been used, but this was all done
> before there were object that had signatures.  Anyway, I see this as an
> opportunity to do better.
> 
> I do not know about your AC development experience, but the specifications
> are quite clear about the need for DER.  It would be nice if the repository
> fetch did not force the client to restore the original DER encoding.
> 
> I agree that this is not a schema issue. However, a comment that the DER
> encoding applied by the signer should be preserved is all I really
> want.  You have already fixed the problem where the repository access
> protocol is changing the encoding.
> 
> Russ
> 
> At 06:39 PM 4/3/2002 +0100, David Chadwick wrote:
> >Russ
> >
> >I dont think the issue below is one for the schema ID. The certificate
> >attributes in the directory should be perfectly happy to receive BER or
> >DER (or PER for that matter I guess). So the schema ID should allow
> >anything to be stored there.
> >
> >Your issue is more one for the LDAP profile ID which was last updated in
> >January. In the profile we can suggest that clients always use DER for
> >encoding certificates.  But what is the common WG concensus on this? FYI
> >in recent work we did with attribute certificates we found we had to use
> >BER because the DER Java objects were too buggy.
> >
> >David
> >
> >
> >"Housley, Russ" wrote:
> > >
> > > David:
> > >
> > > I would like to encourage clients to provide certificates in DER.  We ought
> > > to tell them that there will be less work for everyone if they provide
> > > DER-encoded certificates.  Likewise for CRLs.
> > >
> > > Russ
> > >
> > > At 10:32 PM 4/1/2002 +0100, David Chadwick wrote:
> > >
> > > >"Housley, Russ" wrote:
> > > > >
> > > > > David:
> > > > >
> > > > > Is it possible to preserve the DER encoding.  If not, then the DER
> > encoding
> > > > > must be restored in order to validate the signature?  This just
> > seems like
> > > > > wasted processing to me.
> > > > >
> > > >
> > > >Russ
> > > >
> > > >I quite agree. The revised text is meant to ensure that the DER or BER
> > > >encoding created by the client when the certificate was first sent to
> > > >the directory for storage is preserved as is. This is the purpose of the
> > > >sentence below in the revised text, viz:
> > > >
> > > > > >Servers must preserve values in this syntax exactly as given when
> > > > > >storing and retrieving them.
> > > > > >
> > > >
> > > >Perhaps I should say "as given to them by the client, when storing and
> > > >retrieving certificates"
> > > >
> > > >David
> > > >
> >
> >--
> >*****************************************************************
> >
> >David W. Chadwick, BSc PhD
> >Professor of Information Systems Security
> >IS Institute, University of Salford, Salford M5 4WT
> >Tel: [phone]  Fax [phone]
> >Mobile: [phone]
> >Email: [e-mail]
> >Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
> >Research Projects: http://sec.isi.salford.ac.uk
> >Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
> >X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
> >Entrust key validation string: MLJ9-DU5T-HV8J
> >PGP Key ID is 0xBC238DE5
> >
> >*****************************************************************
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33JBmD07208 for ietf-pkix-bks; Wed, 3 Apr 2002 11:11:48 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g33JBfm07192 for <[e-mail]>; Wed, 3 Apr 2002 11:11:41 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Apr 2002 19:10:47 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA10668; Wed, 3 Apr 2002 14:10:42 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g33JBiu11159; Wed, 3 Apr 2002 14:11:44 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX13CV2>; Wed, 3 Apr 2002 14:09:20 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.152]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX13CVH; Wed, 3 Apr 2002 14:09:18 -0500
From: "Housley, Russ" <[e-mail]>
To: Ambarish Malpani <[e-mail]>, Stephen Kent <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 03 Apr 2002 14:11:37 -0500
Subject: Re: One last comment on DPD requirements
In-Reply-To: <p05100309b8d0e4264f87@[128.89.88.34]>
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>

Steve & Ambarish:

>>Hi Group,
>>     One last (slightly late) comment on the DPD requirements that
>>has been troubling me:
>>
>>In the DPD requirements, there is a reasonable amount of text that
>>talks about how a server can return multiple paths back to the
>>client (to allow the client to decide which path is the best).
>>
>>The main goal of DPD is to try and simplify the client. In how many
>>cases do people really want multiple paths back from the server.
>>While it is the right requirement in principal, do folks really
>>think clients will want multiple paths back from a DPD server? Are
>>we adding the additional flexiblity/complexity just for
>>technical purity?
>>
>>Comments will be appreciated.
>>
>>Regards,
>>Ambarish
>
>I too would favor simplifying the protocol requirement here. Some folks 
>have suggested motivations for multiple paths, but this does seem to 
>conflict with the fundamental goal of creating a protocol to satisfy the 
>needs of thin clients.
>
>Steve

I agree with your goal.  It is far better for the client to tell the server 
what it wants, then get back a single path that satisfies all of the 
requirements.  To do this, we need to be able to fully specify the clients 
criteria and send them to the server.  I think that we know how to do this 
for many PKI-enabled applications, but I am not sure that we know how to do 
it for all applications, especially ones that are yet to be developed.

This leaves us with two choices.  Either the protocol returns multiple 
certification paths (the approach in the current document) or the protocol 
requires the client to adequately specify its criteria.  This could be done 
with the path discovery policy.  If we adopt this alternative, we should 
include additional text so that implements expect application-specific 
(perhaps several application-specific path discovery policy if there are 
multiple roles in the application).

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33Iq9v05500 for ietf-pkix-bks; Wed, 3 Apr 2002 10:52:09 -0800 (PST)
Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by above.proper.com (8.11.6/8.11.3) with SMTP id g33Iq8m05496 for <[e-mail]>; Wed, 3 Apr 2002 10:52:08 -0800 (PST)
Received: (qmail 60789 invoked by alias); 3 Apr 2002 18:52:10 -0000
Received: (qmail 60765 invoked from network); 3 Apr 2002 18:52:09 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by rhea.salford.ac.uk with SMTP; 3 Apr 2002 18:52:09 -0000
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 19:56:07 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kurt D. Zeilenga" <[e-mail]>
CC: Mark C Smith <[e-mail]>, LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <[e-mail]> <5.1.0.14.0.20020403094751.01744a18@127.0.0.1>
Content-Type: multipart/mixed; boundary="------------2E38E2F8CB70E2AA402FD5FD"
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.
--------------2E38E2F8CB70E2AA402FD5FD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Kurt D. Zeilenga" wrote:
>
> I fully concur.  The PKI schema specification needs to be
> revised in a manner which doesn't introduce significant
> backwards compatibility problems with implementations of
> the current LDAPv3 technical specification.
> 
> Kurt

Kurt

I dont believe we are introducing significant backwards compatibility
problems (though there are some, see below) and we are removing forwards
compatibility problems which is a big plus. Given that there are many
fewer server implementations than clients, it will be easier to migrate
these to be ;binary lenient than to migrate lots of clients.

What the PKIX spec is in fact doing, which has never been done before
but should have been, is to specify a "native" encoding for certificates
that says they are BER or DER encoded byte strings. Thus the ;binary
option can be used, but it is a null function. It is also saying, which
again should have been said a long time ago but never was, is that
servers MUST NOT change the encoding of certificates when they recieve
them, but MUST leave them exactly as received and return them exactly as
received.

Now to the backwards compatibility issues. In the table below the only
problem will come with a new LDAPv3 client that does not use ;binary
with an existing v3 server that demands it. But we already have an
inconsistency in these current LDAPv3 servers in that they accept LDAPv2
queries without ;binary but not LDAPv3 queries without ;binary. But they
sometimes screw things up because a certificate stored by an LDAPv2
client cannot always be retrieved by an LDAPv3 client (which you have to
admit is pretty crazy). The new schema spec will remove all of these
problems once the servers become less religious about the presence of
;binary, and are configured to know that a certificate's native encoding
is already BER/DER.



                    Current LDAPv3 Server       NewLDAPv3Server
                    mandates ;binary            does not care

LDAPv2 client
does not use             seems to work                 OK  
;binary

Current LDAPv3 client       OK                        OK
does use ;binary


New LDAPv3 client         probably
does not use              wont work                   OK
;binary


I honestly believe that what is being proposed is the best solution to
what at present is a very messy LDAP world, as far as PKI is concerned

David


-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------2E38E2F8CB70E2AA402FD5FD
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------2E38E2F8CB70E2AA402FD5FD--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33IaFB04969 for ietf-pkix-bks; Wed, 3 Apr 2002 10:36:15 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33IaDm04965 for <[e-mail]>; Wed, 3 Apr 2002 10:36:13 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g33IaCC11398; Wed, 3 Apr 2002 18:36:12 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020403103001.01744250@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 03 Apr 2002 10:36:25 -0800
To: David Chadwick <[e-mail]>
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
Cc: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
In-Reply-To: <[e-mail]>
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>

This text does not clearly "MUST" the use of ;binary as
RFC 2252 and RFC 2256 did.  As previously noted, this
"MUST" should not be dropped as doing so will cause
interoperability problems between implementations of
the current technical specification and the revised
technical specification.

Kurt

At 05:29 AM 2002-04-01, David Chadwick wrote:
>Colleagues
>
>Here is my proposed change to the section describing the LDAP syntax for
>cerificates in the PKIX id
><draft-pkix-ldap-schema-03.txt> which should be published before the end
>of April. As this is likely to be the most contentious part of the new
>ID, I thought it would be useful to distribute this text at the earlier
>possible moment.
>
>All constructive comments welcomed
>
>David
>
>
>3.3  Certificate Syntax
>
>A value in this transfer syntax is the binary octet string that results
>from BER or DER-encoding of an X.509 public key certificate.  The
>following string states the OID assigned to this syntax:
>
>      ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
>
>Servers must preserve values in this syntax exactly as given when
>storing and retrieving them. 
>
>Note. Due to the changes from X.509(1988) to X.509(1993) and subsequent
>changes to the ASN.1 definition to support certificate extensions in
>X.509(1997), no character string transfer syntax is defined for
>certificates. The BNF notation in RFC 1778 [12] for "User Certificate"
>MUST NOT be used. Values in this syntax MUST be transferred as BER or
>DER encoded octets. The use of the ;binary encoding option, i.e. by
>requesting or returning the attributes with descriptions
>"userCertificate;binary" or "caCertificate;binary" has no effect on the
>transfer syntax.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33I7TK03102 for ietf-pkix-bks; Wed, 3 Apr 2002 10:07:29 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g33I7Rm03095 for <[e-mail]>; Wed, 3 Apr 2002 10:07:27 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Apr 2002 18:06:34 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id NAA04639; Wed, 3 Apr 2002 13:06:28 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g33I7Sb03900; Wed, 3 Apr 2002 13:07:28 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX13BQ1>; Wed, 3 Apr 2002 13:05:02 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.152]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX13BP0; Wed, 3 Apr 2002 13:04:54 -0500
From: "Housley, Russ" <[e-mail]>
To: David Chadwick <[e-mail]>
Cc: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 03 Apr 2002 13:05:59 -0500
Subject: Re: LDAP Certificate transfer syntax
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>

David:

When DAP is used, certificates come back in BER.  This happens because the 
DAP PDU is defined in ASN.1, and the BER encoding of the PDU encodes the 
data too.  An OCTET STRING could have been used, but this was all done 
before there were object that had signatures.  Anyway, I see this as an 
opportunity to do better.

I do not know about your AC development experience, but the specifications 
are quite clear about the need for DER.  It would be nice if the repository 
fetch did not force the client to restore the original DER encoding.

I agree that this is not a schema issue. However, a comment that the DER 
encoding applied by the signer should be preserved is all I really 
want.  You have already fixed the problem where the repository access 
protocol is changing the encoding.

Russ


At 06:39 PM 4/3/2002 +0100, David Chadwick wrote:
>Russ
>
>I dont think the issue below is one for the schema ID. The certificate
>attributes in the directory should be perfectly happy to receive BER or
>DER (or PER for that matter I guess). So the schema ID should allow
>anything to be stored there.
>
>Your issue is more one for the LDAP profile ID which was last updated in
>January. In the profile we can suggest that clients always use DER for
>encoding certificates.  But what is the common WG concensus on this? FYI
>in recent work we did with attribute certificates we found we had to use
>BER because the DER Java objects were too buggy.
>
>David
>
>
>"Housley, Russ" wrote:
> >
> > David:
> >
> > I would like to encourage clients to provide certificates in DER.  We ought
> > to tell them that there will be less work for everyone if they provide
> > DER-encoded certificates.  Likewise for CRLs.
> >
> > Russ
> >
> > At 10:32 PM 4/1/2002 +0100, David Chadwick wrote:
> >
> > >"Housley, Russ" wrote:
> > > >
> > > > David:
> > > >
> > > > Is it possible to preserve the DER encoding.  If not, then the DER 
> encoding
> > > > must be restored in order to validate the signature?  This just 
> seems like
> > > > wasted processing to me.
> > > >
> > >
> > >Russ
> > >
> > >I quite agree. The revised text is meant to ensure that the DER or BER
> > >encoding created by the client when the certificate was first sent to
> > >the directory for storage is preserved as is. This is the purpose of the
> > >sentence below in the revised text, viz:
> > >
> > > > >Servers must preserve values in this syntax exactly as given when
> > > > >storing and retrieving them.
> > > > >
> > >
> > >Perhaps I should say "as given to them by the client, when storing and
> > >retrieving certificates"
> > >
> > >David
> > >
>
>--
>*****************************************************************
>
>David W. Chadwick, BSc PhD
>Professor of Information Systems Security
>IS Institute, University of Salford, Salford M5 4WT
>Tel: [phone]  Fax [phone]
>Mobile: [phone]
>Email: [e-mail]
>Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
>Research Projects: http://sec.isi.salford.ac.uk
>Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
>X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
>Entrust key validation string: MLJ9-DU5T-HV8J
>PGP Key ID is 0xBC238DE5
>
>*****************************************************************
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33I2Qr02741 for ietf-pkix-bks; Wed, 3 Apr 2002 10:02:26 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33I2Om02736 for <[e-mail]>; Wed, 3 Apr 2002 10:02:24 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA04282; Wed, 3 Apr 2002 20:02:25 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 3 Apr 2002 20:02:25 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA10615; Wed, 3 Apr 2002 20:02:24 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA04158; Wed, 3 Apr 2002 20:02:24 +0200 (MET DST)
Date: Wed, 3 Apr 2002 20:02:24 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
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>

> 
> If the protocol does choose to return the requestHash in the response, do
> you see any benefit to adding a requestNonce in the response? If not, the
> requirement should go. I think it would be better for the requirements doc
> to say what is desired: "Prevent replay attacks on responses" and let the
> protocol decide how to do it.
> 
I seem to agree with Ambarish that the current texts is an overspecification.

Thus, a simple text like: "The protocol MUST provide a means to
protect itself against replay attacks." seems sufficient for this
document. 

Peter 


Received: by above.proper.com (8.11.6/8.11.3) id g33I0KK02653 for ietf-pkix-bks; Wed, 3 Apr 2002 10:00:20 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33I0Km02649 for <[e-mail]>; Wed, 3 Apr 2002 10:00:20 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 3 Apr 2002 09:58:16 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Wed, 03 Apr 2002 09:58:16 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <H570PHRA>; Wed, 03 Apr 2002 09:59:52 -0800
Content-return: allowed
Date: Wed, 03 Apr 2002 09:59:50 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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>

Agreed!

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Wednesday, April 03, 2002 9:19 AM
> To: Denis Pinkas; Ambarish Malpani
> Cc: [e-mail]
> Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
> 
> 
> Denis and Ambarish:
> 
> > > 3. Section 4 Para  12
> > >     In order to prevent replay attacks, you require the 
> nonce to be
> > > present in the response. As mentioned by Petra, if the response
> > > contained the request hash, it doesn't need to contain 
> the nonce. It
> > > is still bound to the request. Present of the request nonce in the
> > > reply shouldn't be a requirement in this case.
> >
> >Verification of equality of the nonce is simple and 
> straigthforward to
> >discard replay attacks. Since we do not require to use the 
> hash of the
> >request in the response, we have purposely maintained this 
> requirement.
> 
> Perhaps we have boxed ourselves into a corner.  Maybe there 
> is a simple way 
> forward.
> 
> Two requirements are getting muddled here.  One requirement 
> is to bind the 
> request to the response.  The second requirement is to 
> include a replay 
> detection mechanism.
> 
> Nonces and hashes are mechanisms that are used to implement 
> one of these 
> requirements.  Perhaps this document should simply state the 
> requirement, 
> and not impose a mechanism.
> 
> Russ
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33HwIq02596 for ietf-pkix-bks; Wed, 3 Apr 2002 09:58:18 -0800 (PST)
Received: from pretender.boolean.net ([e-mail] [198.144.206.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33HwGm02592 for <[e-mail]>; Wed, 3 Apr 2002 09:58:16 -0800 (PST)
Received: from nomad.OpenLDAP.org (root@localhost [127.0.0.1]) by pretender.boolean.net (8.11.3/8.11.1/Boolean/Hub) with ESMTP id g33HwAC11133; Wed, 3 Apr 2002 17:58:10 GMT (envelope-from [e-mail])
Message-Id: <5.1.0.14.0.20020403094751.01744a18@127.0.0.1>
X-Sender: kurt@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 03 Apr 2002 09:58:22 -0800
To: [e-mail] (Mark C Smith)
From: "Kurt D. Zeilenga" <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
Cc: David Chadwick <[e-mail]>, LDAP BIS <[e-mail]>, PKIX <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
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>

At 08:16 AM 2002-04-03, Mark C Smith wrote:
>I am still concerned about how dropping the ;binary transfer option that was mandated by RFC 2252 will affect the large installed base of LDAPv3 and PKI implementations (of course some PKI clients are already trying to use userCertificate without ;binary with LDAPv3 implementations, and not surprisingly there are having a difficult time).

I fully concur.  The PKI schema specification needs to be
revised in a manner which doesn't introduce significant
backwards compatibility problems with implementations of
the current LDAPv3 technical specification.

Kurt



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33HfCx01038 for ietf-pkix-bks; Wed, 3 Apr 2002 09:41:12 -0800 (PST)
Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by above.proper.com (8.11.6/8.11.3) with SMTP id g33HfBm01034 for <[e-mail]>; Wed, 3 Apr 2002 09:41:11 -0800 (PST)
Received: (qmail 48646 invoked by alias); 3 Apr 2002 17:41:12 -0000
Received: (qmail 48628 invoked from network); 3 Apr 2002 17:41:12 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by rhea.salford.ac.uk with SMTP; 3 Apr 2002 17:41:12 -0000
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 18:45:10 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Mark C Smith <[e-mail]>
CC: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------FD959FE37FB6DF8FBBDCD039"
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.
--------------FD959FE37FB6DF8FBBDCD039
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Mark

We are not dropping the ;binary option, you can still use it, but its
functionality is redundant as the "native" LDAP encoding is BER.

To put the other view, I have heard that some other LDAPv3 directories
are unable to accept the ;binary option anyway. So what I am now arguing
for is leniency on the part of servers, that they neither demand nor
reject the use of ;binary, but just ignore it if it is there.

David


Mark C Smith wrote:
> 
> I am still concerned about how dropping the ;binary transfer option that
> was mandated by RFC 2252 will affect the large installed base of LDAPv3
> and PKI implementations (of course some PKI clients are already trying
> to use userCertificate without ;binary with LDAPv3 implementations, and
> not surprisingly there are having a difficult time).
> 
> But if consensus is to proceed with this proposal, then I think the
> conflict with RFC 2252 should be noted in the PKIX document (there is a
> lot of history behind all of this, and implementors and users who do not
> know all of it will undoubtedly be confused).
> 
> -Mark Smith
>   Netscape
> 
> David Chadwick wrote:
> > Colleagues
> >
> > Here is my proposed change to the section describing the LDAP syntax for
> > cerificates in the PKIX id
> > <draft-pkix-ldap-schema-03.txt> which should be published before the end
> > of April. As this is likely to be the most contentious part of the new
> > ID, I thought it would be useful to distribute this text at the earlier
> > possible moment.
> >
> > All constructive comments welcomed
> >
> > David
> >
> >
> > 3.3  Certificate Syntax
> >
> > A value in this transfer syntax is the binary octet string that results
> > from BER or DER-encoding of an X.509 public key certificate.  The
> > following string states the OID assigned to this syntax:
> >
> >       ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
> >
> > Servers must preserve values in this syntax exactly as given when
> > storing and retrieving them.
> >
> > Note. Due to the changes from X.509(1988) to X.509(1993) and subsequent
> > changes to the ASN.1 definition to support certificate extensions in
> > X.509(1997), no character string transfer syntax is defined for
> > certificates. The BNF notation in RFC 1778 [12] for "User Certificate"
> > MUST NOT be used. Values in this syntax MUST be transferred as BER or
> > DER encoded octets. The use of the ;binary encoding option, i.e. by
> > requesting or returning the attributes with descriptions
> > "userCertificate;binary" or "caCertificate;binary" has no effect on the
> > transfer syntax.

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------FD959FE37FB6DF8FBBDCD039
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------FD959FE37FB6DF8FBBDCD039--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33HZS500453 for ietf-pkix-bks; Wed, 3 Apr 2002 09:35:28 -0800 (PST)
Received: from rhea.salford.ac.uk (rhea.salford.ac.uk [146.87.255.99]) by above.proper.com (8.11.6/8.11.3) with SMTP id g33HZRm00449 for <[e-mail]>; Wed, 3 Apr 2002 09:35:27 -0800 (PST)
Received: (qmail 47790 invoked by alias); 3 Apr 2002 17:35:28 -0000
Received: (qmail 47772 invoked from network); 3 Apr 2002 17:35:28 -0000
Received: from unknown (HELO salford.ac.uk) (146.87.80.124) by rhea.salford.ac.uk with SMTP; 3 Apr 2002 17:35:28 -0000
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 18:39:26 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/mixed; boundary="------------727D949320E69CF4C0772B49"
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.
--------------727D949320E69CF4C0772B49
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Russ

I dont think the issue below is one for the schema ID. The certificate
attributes in the directory should be perfectly happy to receive BER or
DER (or PER for that matter I guess). So the schema ID should allow
anything to be stored there.

Your issue is more one for the LDAP profile ID which was last updated in
January. In the profile we can suggest that clients always use DER for
encoding certificates.  But what is the common WG concensus on this? FYI
in recent work we did with attribute certificates we found we had to use
BER because the DER Java objects were too buggy.

David


"Housley, Russ" wrote:
> 
> David:
> 
> I would like to encourage clients to provide certificates in DER.  We ought
> to tell them that there will be less work for everyone if they provide
> DER-encoded certificates.  Likewise for CRLs.
> 
> Russ
> 
> At 10:32 PM 4/1/2002 +0100, David Chadwick wrote:
> 
> >"Housley, Russ" wrote:
> > >
> > > David:
> > >
> > > Is it possible to preserve the DER encoding.  If not, then the DER encoding
> > > must be restored in order to validate the signature?  This just seems like
> > > wasted processing to me.
> > >
> >
> >Russ
> >
> >I quite agree. The revised text is meant to ensure that the DER or BER
> >encoding created by the client when the certificate was first sent to
> >the directory for storage is preserved as is. This is the purpose of the
> >sentence below in the revised text, viz:
> >
> > > >Servers must preserve values in this syntax exactly as given when
> > > >storing and retrieving them.
> > > >
> >
> >Perhaps I should say "as given to them by the client, when storing and
> >retrieving certificates"
> >
> >David
> >

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------727D949320E69CF4C0772B49
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------727D949320E69CF4C0772B49--



Received: by above.proper.com (8.11.6/8.11.3) id g33HJR429791 for ietf-pkix-bks; Wed, 3 Apr 2002 09:19:27 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g33HJPm29787 for <[e-mail]>; Wed, 3 Apr 2002 09:19:25 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Apr 2002 17:18:31 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id MAA00616; Wed, 3 Apr 2002 12:18:26 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g33HJSS28983; Wed, 3 Apr 2002 12:19:28 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX13AW9>; Wed, 3 Apr 2002 12:17:04 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.152]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX13AW6; Wed, 3 Apr 2002 12:16:58 -0500
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>, Ambarish Malpani <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 03 Apr 2002 12:18:44 -0500
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
In-Reply-To: <[e-mail]>
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>

Denis and Ambarish:

> > 3. Section 4 Para  12
> >     In order to prevent replay attacks, you require the nonce to be
> > present in the response. As mentioned by Petra, if the response
> > contained the request hash, it doesn't need to contain the nonce. It
> > is still bound to the request. Present of the request nonce in the
> > reply shouldn't be a requirement in this case.
>
>Verification of equality of the nonce is simple and straigthforward to
>discard replay attacks. Since we do not require to use the hash of the
>request in the response, we have purposely maintained this requirement.

Perhaps we have boxed ourselves into a corner.  Maybe there is a simple way 
forward.

Two requirements are getting muddled here.  One requirement is to bind the 
request to the response.  The second requirement is to include a replay 
detection mechanism.

Nonces and hashes are mechanisms that are used to implement one of these 
requirements.  Perhaps this document should simply state the requirement, 
and not impose a mechanism.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id g33HIx829782 for ietf-pkix-bks; Wed, 3 Apr 2002 09:18:59 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33HIvm29778 for <[e-mail]>; Wed, 3 Apr 2002 09:18:57 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA04043; Wed, 3 Apr 2002 19:18:57 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 3 Apr 2002 19:18:57 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA10422; Wed, 3 Apr 2002 19:18:56 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA04146; Wed, 3 Apr 2002 19:18:56 +0200 (MET DST)
Date: Wed, 3 Apr 2002 19:18:56 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
Cc: [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>

> 
> It is proposed to add after the current last paragraph from section 4: 
> 
> "When the request is authenticated, the requestor shall have the possibility
> to have its identifier included or not in the response."

Identification and Authentication are different things. 

I have proposed in a different mail to Russ: 

  The protocol MUST provide a means to allow a client and a server
  to indicate the participating entities. 

I correct '... to indicate the identities of the entities participating in
the transction'. 

and one may add "(depending on policy or application context)". 

> Since relaying is not supported (see the response to your other e-mail),
> there is no difference between "for whom the response has been made" and
> "who has made the response".

'For whom' indicated the requester(s). I agree that there may
be a language problem. I did not mention 'for whom' as a synomym
of 'on behalf of'. 


Peter



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33HEoP29707 for ietf-pkix-bks; Wed, 3 Apr 2002 09:14:50 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33HEmm29703 for <[e-mail]>; Wed, 3 Apr 2002 09:14:48 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA04007; Wed, 3 Apr 2002 19:14:47 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 3 Apr 2002 19:14:47 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA10398; Wed, 3 Apr 2002 19:14:46 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA04143; Wed, 3 Apr 2002 19:14:46 +0200 (MET DST)
Date: Wed, 3 Apr 2002 19:14:46 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
Cc: [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>

About 'invisible realying':

> > Why do you think that a DPV response from a server MUST NOT
> > contain a DPV response from another server, while on the other
> > hand it is provided that the server returns all information
> > concerning the certification path, an revocation information.
> > What does make DPV responses so different from OCSP reponses
> > that they would create either additional complexity or harm.
> > 
> > An end user only communicates with his local company
> > service. The company knows which external CAs can be
> > trusted, and which service can be contacted.
> > You already allow to contact OCSP services in this
> > way. Where is the difference between DPV and OCSP?
> > 
> > It may be desirable that an end user may not
> > directly interface with a remote DPV and needs an
> > intermediate 'anonymizer' or 'authorized relay'.
> > 
> > In all such cases there is a danger (like in OCSP)
> > for endless loops.
> 
> There is no such a danger: the request is sent to one server and must come
> back from that same server. If the server uses relaying in the back ground
> to fulfill the service, then this is not visible from the requester. The
> final response from a DPV server is signed by the server that received the
> original request. Relaying is not supported by the protocol.

- You accept now that there is relaying of dpv requests is possible.  

  Assume that two companies operate a DPV service, and in 
  order to validate a certificat of the other company, a request is relayed
  (as you suggest) in a back ground way. A simple configuration
  error in one of the servers and the request gets relayed back etc.

- Russ answered my request for an optional inclusion of the identities
participating in the transaction. having this I think this is sufficient
to address the loop problem. 

But: You have not answered my question why you believe that a inclusion
of another dpv response in a response is a harmful thing. 
I believe that there are scenarios where it is useful that relaying be
made visible. 





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33H1Ct29349 for ietf-pkix-bks; Wed, 3 Apr 2002 09:01:12 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33H1Am29345 for <[e-mail]>; Wed, 3 Apr 2002 09:01:10 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA17744; Wed, 3 Apr 2002 19:03:36 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040319003695:387 ; Wed, 3 Apr 2002 19:00:36 +0200 
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 19:00:10 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>, Russ Housley <[e-mail]>
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 19:00:37, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 19:01:08, Serialize complete at 03/04/2002 19:01:08
Content-Transfer-Encoding: 7bit
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>

Ambarish,
 
> Hi Denis,
>     Thank you, the resolution to all these questions is
> excellent (other than #3).
> 
> In case of the 3rd comment:
> 
> > > 3. Section 4 Para  12
> > >     In order to prevent replay attacks, you require the nonce to be
> > > present in the response. As mentioned by Petra, if the response
> > > contained the request hash, it doesn't need to contain the nonce. It
> > > is still bound to the request. Present of the request nonce in the
> > > reply shouldn't be a requirement in this case.
> >
> > Verification of equality of the nonce is simple and straigthforward to
> > discard replay attacks. Since we do not require to use the hash of the
> > request in the response, we have purposely maintained this
> > requirement.
> 
> If the protocol does choose to return the requestHash in the response, do
> you see any benefit to adding a requestNonce in the response? 

The benefit is that replay attacks can be detected very easily, 
in particular when using a traffic analyzer. Otherwise this is not
straightforward. A copy of this field in the response is worth the money.
:-)

> If not, the
> requirement should go. I think it would be better for the requirements doc
> to say what is desired: "Prevent replay attacks on responses" and let the
> protocol decide how to do it.

This resolution has been taken at the Minneapolis meeting after a discussion
with Russ. 

Denis

> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Chief Architect                                          650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Wednesday, April 03, 2002 7:00 AM
> > To: Ambarish Malpani; [e-mail]
> > Cc: [e-mail]
> > Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
> >
> >
> >
> > > Hi Denis, Russ,
> > >      Great work on the new draft!
> >
> > Thank you. It was quite harder than expected.
> >
> > > A few comments:
> > >
> > > 1. In 2 places you equate the "root" with a self-signed cert. I
> > > hope you intend to allow the trust anchor to be a non-self-signed
> > > cert. The 2 places are Para 4 of Section 4 and Para 4 of Section 5.
> >
> > In Para 4 of Section 4, the text says "e.g. root self-signed
> > certificates".
> > So there is nothing wrong, since this is only an example. No
> > change needed.
> >
> > In Para 4 of Section 5, the text says: "The trust anchor self-signed
> > certificate, if issued, is not included." Since Brian had
> > problems with
> > that sentence too, it is proposed to change it into:
> >
> > "Each path consists of a sequence of certificates, starting with
> > the certificate to be validated and ending with a trust anchor.
> > If the trust anchor is a self-signed certificate, that self-signed
> > certificate is not included."
> >
> > > 2. Section 4 Para 9
> > >     You require the DPV server to "obtain" the certificate from the
> > > reference provided by the client. This is *not* a requirement. If
> > > the server obtains the certificate by some other means,
> > that is okay,
> > > as long as it verifies that the certificate is indeed the one
> > > being referred to by the client.
> >
> > The current sentence is:
> >
> > "If not provided in the request, the server MUST use the unambiguous
> > reference provided in the request to obtain it."
> >
> > It is proposed to change the sentence into:
> >
> > "If not provided in the request, the server MUST verify that
> > the certificate
> > is indeed the one being unambiguous referenced by the client".
> >
> > > 3. Section 4 Para  12
> > >     In order to prevent replay attacks, you require the nonce to be
> > > present in the response. As mentioned by Petra, if the response
> > > contained the request hash, it doesn't need to contain the nonce. It
> > > is still bound to the request. Present of the request nonce in the
> > > reply shouldn't be a requirement in this case.
> >
> > Verification of equality of the nonce is simple and straigthforward to
> > discard replay attacks. Since we do not require to use the hash of the
> > request in the response, we have purposely maintained this
> > requirement.
> >
> > > 4. Section 4 Para 16
> > >     You require a DPV response to be signed - error response
> > > might not be signed (e.g. badly formatted request, etc.) Please
> > > allow for that case.
> >
> > Certainly. The current text is:
> >
> > "For the client to be confident that the certificate validation was
> > handled by the expected DPV server, the DPV response MUST be
> > authenticated.
> >
> > 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."
> >
> > It is proposed to add at the end of each paragraph:
> >
> > "unless an error is reported (e.g. badly formatted request, etc.)."
> >
> > > That's it!
> >
> > Thank you !
> >
> > Denis
> >
> >
> > > Regards,
> > > Ambarish
> > >
> > >
> > ---------------------------------------------------------------------
> > > Ambarish Malpani
> > > Chief Architect
> > 650.567.5457
> > > ValiCert, Inc.
> > [e-mail]
> > > 1215 Terra Bella Ave.
> > http://www.valicert.com
> > > Mountain View, CA 94043
> > >
> > > > -----Original Message-----
> > > > From: Tim Polk [mailto:[e-mail]]
> > > > Sent: Friday, March 29, 2002 2:55 PM
> > > > To: [e-mail]
> > > > Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
> > > >
> > > >
> > > >
> > > > Folks,
> > > >
> > > > The editors have informed me that they believe the -03 draft
> > > > satisfies all
> > > > WG Last Call comments and meets the criteria of rough
> > > > consesnsus. My review
> > > > agrees with their position, and I would like to ship the
> > > > document to the
> > > > ADs as soon as possible.
> > > >
> > > > If you have a dog in this fight, *please review the
> > specification by
> > > > Tuesday COB.*  If I do not see any traffic on the list
> > stating that
> > > > unresolved comments remain, I will forward the document to the ADs
> > > > Wednesday morning.
> > > >
> > > > Thanks,
> > > >
> > > > Tim Polk
> > > >
> > > > At 07:03 AM 3/29/02 -0500, you 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           : Delegated Path Validation and
> > > > Delegated Path
> > > > > Discovery
> > > > >                           Protocol Requirements (DPV&DPD-REQ)
> > > > >         Author(s)       : D. Pinkas, R. Housley
> > > > >         Filename        : draft-ietf-pkix-dpv-dpd-req-03.txt
> > > > >         Pages           : 11
> > > > >         Date            : 28-Mar-02
> > > > >
> > > > >This document specifies the requirements for Delegated Path
> > > > Validation
> > > > >(DPV) and Delegated Path Discovery (DPD) for Public Key
> > Certificates.
> > > > >It also specifies the requirements for DPV and DPD
> > policy management.
> > > > >
> > > > >A URL for this Internet-Draft is:
> > > > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> > > > eq-03.txt
> > > > >
> > > > >To remove yourself from the IETF Announcement list, send
> > a message to
> > > > >ietf-announce-request with the word unsubscribe in the body
> > > > of the message.
> > > > >
> > > > >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-dpv-dpd-req-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-dpv-dpd-req-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.
> > > > >Content-Type: text/plain
> > > > >Content-ID:     <[e-mail]>
> > > > >
> > > > >ENCODING mime
> > > > >FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
> > > > >
> > > > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> > > > eq-03.txt>
> > > >
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33GxJf29271 for ietf-pkix-bks; Wed, 3 Apr 2002 08:59:19 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.com [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33GxIm29267 for <[e-mail]>; Wed, 3 Apr 2002 08:59:18 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id LAA29810; Wed, 3 Apr 2002 11:59:09 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100309b8d0e4264f87@[128.89.88.34]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Wed, 3 Apr 2002 11:55:32 -0500
To: Ambarish Malpani <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: One last comment on DPD requirements
Cc: "'[e-mail]'" <[e-mail]>
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>

At 8:36 AM -0800 4/3/02, Ambarish Malpani wrote:
>Hi Group,
>     One last (slightly late) comment on the DPD requirements that
>has been troubling me:
>
>In the DPD requirements, there is a reasonable amount of text that
>talks about how a server can return multiple paths back to the
>client (to allow the client to decide which path is the best).
>
>The main goal of DPD is to try and simplify the client. In how many
>cases do people really want multiple paths back from the server.
>While it is the right requirement in principal, do folks really
>think clients will want multiple paths back from a DPD server? Are
>we adding the additional flexiblity/complexity just for
>technical purity?
>
>Comments will be appreciated.
>
>Regards,
>Ambarish

I too would favor simplifying the protocol requirement here. Some 
folks have suggested motivations for multiple paths, but this does 
seem to conflict with the fundamental goal of creating a protocol to 
satisfy the needs of thin clients.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33GvJ029226 for ietf-pkix-bks; Wed, 3 Apr 2002 08:57:19 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g33GvIm29222 for <[e-mail]>; Wed, 3 Apr 2002 08:57:18 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Apr 2002 16:56:24 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA28253; Wed, 3 Apr 2002 11:56:18 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g33GvL826166; Wed, 3 Apr 2002 11:57:21 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX13AH8>; Wed, 3 Apr 2002 11:54:57 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.129]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX13AH5; Wed, 3 Apr 2002 11:54:52 -0500
From: "Housley, Russ" <[e-mail]>
To: Brian Hunter <[e-mail]>
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 03 Apr 2002 11:53:06 -0500
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
In-Reply-To: <[e-mail]>
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>

Brian:

>5. Section 5 Para 4
>     This comment goes along with Ambarish's comment 1.  I do not
>understand what is meant by "if issued" in the following sentence:
>   "The trust anchor self-signed certificate, if issued, is not
>included."
>
>Without understanding the "issued" point and assuming that all trust
>anchor certificates, self-signed or not, are issued, then I would have
>the sentence read:
>   "The trust anchor is not included."
>Note that I am agreeing with Ambarish that the self-signed requirement
>for a root should be dropped.

Trust anchors can be established using self-signed certificates or by other 
means, either way, the  trust anchor is not included.  Perhaps this point 
is only adding confusion.

>9. Section 9 Last paragraph point (3)
>     Is it intended that the validation time should be adjusted for only
>one of the four points, hence the use of "or" after point three? I would
>suggest the use of "and".

I disagree.  The time could be adjusted for one or more of these 
reasons.  It is an inclusive or.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33GsHM29173 for ietf-pkix-bks; Wed, 3 Apr 2002 08:54:17 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33GsGm29168 for <[e-mail]>; Wed, 3 Apr 2002 08:54:16 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA20748; Wed, 3 Apr 2002 18:56:44 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040318534514:385 ; Wed, 3 Apr 2002 18:53:45 +0200 
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 18:53:19 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'[e-mail]'" <[e-mail]>
Subject: Re: One last comment on DPD requirements
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 18:53:45, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 18:54:16, Serialize complete at 03/04/2002 18:54:16
Content-Transfer-Encoding: 7bit
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>

Ambarish,

This is indeed a very late comment. 

> Hi Group,
>     One last (slightly late) comment on the DPD requirements that
> has been troubling me:
> 
> In the DPD requirements, there is a reasonable amount of text that
> talks about how a server can return multiple paths back to the
> client (to allow the client to decide which path is the best).
> 
> The main goal of DPD is to try and simplify the client. In how many
> cases do people really want multiple paths back from the server.
> While it is the right requirement in principal, do folks really
> think clients will want multiple paths back from a DPD server? Are
> we adding the additional flexiblity/complexity just for
> technical purity?

If there exists more than one path, and if the server only returns one path
and that path does not comply with the conditions set by the client, no
other path would never be sent back and there might well be another one that
would
satisfy the conditions set by the client. DPD clients are not clients as
simple as DPV clients, they are able to perform path validation themselves.

It would not make sense to only return one path.

Denis 

 
> Comments will be appreciated.
> 
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Chief Architect                                          650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33Gehc28772 for ietf-pkix-bks; Wed, 3 Apr 2002 08:40:43 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33Gebm28768 for <[e-mail]>; Wed, 3 Apr 2002 08:40:37 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 3 Apr 2002 08:38:34 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Wed, 03 Apr 2002 08:38:33 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <H570PHC6>; Wed, 03 Apr 2002 08:40:09 -0800
Content-return: allowed
Date: Wed, 03 Apr 2002 08:40:00 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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 Denis,
    Thank you, the resolution to all these questions is
excellent (other than #3).

In case of the 3rd comment:

> > 3. Section 4 Para  12
> >     In order to prevent replay attacks, you require the nonce to be
> > present in the response. As mentioned by Petra, if the response
> > contained the request hash, it doesn't need to contain the nonce. It
> > is still bound to the request. Present of the request nonce in the
> > reply shouldn't be a requirement in this case.
> 
> Verification of equality of the nonce is simple and straigthforward to
> discard replay attacks. Since we do not require to use the hash of the
> request in the response, we have purposely maintained this 
> requirement.

If the protocol does choose to return the requestHash in the response, do
you see any benefit to adding a requestNonce in the response? If not, the
requirement should go. I think it would be better for the requirements doc
to say what is desired: "Prevent replay attacks on responses" and let the
protocol decide how to do it.

Regards,
Ambarish



---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Wednesday, April 03, 2002 7:00 AM
> To: Ambarish Malpani; [e-mail]
> Cc: [e-mail]
> Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
> 
> 
>  
> > Hi Denis, Russ,
> >      Great work on the new draft!
> 
> Thank you. It was quite harder than expected.
> 
> > A few comments:
> > 
> > 1. In 2 places you equate the "root" with a self-signed cert. I
> > hope you intend to allow the trust anchor to be a non-self-signed
> > cert. The 2 places are Para 4 of Section 4 and Para 4 of Section 5.
> 
> In Para 4 of Section 4, the text says "e.g. root self-signed 
> certificates".
> So there is nothing wrong, since this is only an example. No 
> change needed.
> 
> In Para 4 of Section 5, the text says: "The trust anchor self-signed
> certificate, if issued, is not included." Since Brian had 
> problems with 
> that sentence too, it is proposed to change it into:
> 
> "Each path consists of a sequence of certificates, starting with 
> the certificate to be validated and ending with a trust anchor. 
> If the trust anchor is a self-signed certificate, that self-signed 
> certificate is not included."
> 
> > 2. Section 4 Para 9
> >     You require the DPV server to "obtain" the certificate from the
> > reference provided by the client. This is *not* a requirement. If
> > the server obtains the certificate by some other means, 
> that is okay,
> > as long as it verifies that the certificate is indeed the one
> > being referred to by the client.
> 
> The current sentence is:
> 
> "If not provided in the request, the server MUST use the unambiguous 
> reference provided in the request to obtain it."
> 
> It is proposed to change the sentence into:
> 
> "If not provided in the request, the server MUST verify that 
> the certificate
> is indeed the one being unambiguous referenced by the client".
> 
> > 3. Section 4 Para  12
> >     In order to prevent replay attacks, you require the nonce to be
> > present in the response. As mentioned by Petra, if the response
> > contained the request hash, it doesn't need to contain the nonce. It
> > is still bound to the request. Present of the request nonce in the
> > reply shouldn't be a requirement in this case.
> 
> Verification of equality of the nonce is simple and straigthforward to
> discard replay attacks. Since we do not require to use the hash of the
> request in the response, we have purposely maintained this 
> requirement.
>  
> > 4. Section 4 Para 16
> >     You require a DPV response to be signed - error response
> > might not be signed (e.g. badly formatted request, etc.) Please
> > allow for that case.
> 
> Certainly. The current text is:
> 
> "For the client to be confident that the certificate validation was 
> handled by the expected DPV server, the DPV response MUST be 
> authenticated.
> 
> 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."
> 
> It is proposed to add at the end of each paragraph:
> 
> "unless an error is reported (e.g. badly formatted request, etc.)."
>  
> > That's it!
> 
> Thank you !
> 
> Denis
> 
> 
> > Regards,
> > Ambarish
> > 
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Chief Architect                                          
> 650.567.5457
> > ValiCert, Inc.                                  
> [e-mail]
> > 1215 Terra Bella Ave.                         
> http://www.valicert.com
> > Mountain View, CA 94043
> > 
> > > -----Original Message-----
> > > From: Tim Polk [mailto:[e-mail]]
> > > Sent: Friday, March 29, 2002 2:55 PM
> > > To: [e-mail]
> > > Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
> > >
> > >
> > >
> > > Folks,
> > >
> > > The editors have informed me that they believe the -03 draft
> > > satisfies all
> > > WG Last Call comments and meets the criteria of rough
> > > consesnsus. My review
> > > agrees with their position, and I would like to ship the
> > > document to the
> > > ADs as soon as possible.
> > >
> > > If you have a dog in this fight, *please review the 
> specification by
> > > Tuesday COB.*  If I do not see any traffic on the list 
> stating that
> > > unresolved comments remain, I will forward the document to the ADs
> > > Wednesday morning.
> > >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > > At 07:03 AM 3/29/02 -0500, you 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           : Delegated Path Validation and
> > > Delegated Path
> > > > Discovery
> > > >                           Protocol Requirements (DPV&DPD-REQ)
> > > >         Author(s)       : D. Pinkas, R. Housley
> > > >         Filename        : draft-ietf-pkix-dpv-dpd-req-03.txt
> > > >         Pages           : 11
> > > >         Date            : 28-Mar-02
> > > >
> > > >This document specifies the requirements for Delegated Path
> > > Validation
> > > >(DPV) and Delegated Path Discovery (DPD) for Public Key 
> Certificates.
> > > >It also specifies the requirements for DPV and DPD 
> policy management.
> > > >
> > > >A URL for this Internet-Draft is:
> > > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> > > eq-03.txt
> > > >
> > > >To remove yourself from the IETF Announcement list, send 
> a message to
> > > >ietf-announce-request with the word unsubscribe in the body
> > > of the message.
> > > >
> > > >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-dpv-dpd-req-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-dpv-dpd-req-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.
> > > >Content-Type: text/plain
> > > >Content-ID:     <[e-mail]>
> > > >
> > > >ENCODING mime
> > > >FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
> > > >
> > > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> > > eq-03.txt>
> > >
> 


Received: by above.proper.com (8.11.6/8.11.3) id g33GbKo28675 for ietf-pkix-bks; Wed, 3 Apr 2002 08:37:20 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33GbJm28671 for <[e-mail]>; Wed, 3 Apr 2002 08:37:19 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 3 Apr 2002 08:35:14 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Wed, 03 Apr 2002 08:35:13 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <H570PHCN>; Wed, 03 Apr 2002 08:36:49 -0800
Content-return: allowed
Date: Wed, 03 Apr 2002 08:36:47 -0800
From: Ambarish Malpani <[e-mail]>
Subject: One last comment on DPD requirements
To: "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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 Group,
    One last (slightly late) comment on the DPD requirements that
has been troubling me:

In the DPD requirements, there is a reasonable amount of text that
talks about how a server can return multiple paths back to the
client (to allow the client to decide which path is the best).

The main goal of DPD is to try and simplify the client. In how many
cases do people really want multiple paths back from the server.
While it is the right requirement in principal, do folks really
think clients will want multiple paths back from a DPD server? Are
we adding the additional flexiblity/complexity just for
technical purity?

Comments will be appreciated.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043



Received: by above.proper.com (8.11.6/8.11.3) id g33GH0s28134 for ietf-pkix-bks; Wed, 3 Apr 2002 08:17:00 -0800 (PST)
Received: from netscape.com (r2d2.netscape.com [205.217.237.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33GGxm28130 for <[e-mail]>; Wed, 3 Apr 2002 08:16:59 -0800 (PST)
Received: from judge.mcom.com (judge.mcom.com [205.217.237.53]) by netscape.com (8.10.0/8.10.0) with ESMTP id g33GGs706906 for <[e-mail]>; Wed, 3 Apr 2002 08:16:55 -0800 (PST)
Received: from netscape.com ([10.169.184.32]) by judge.mcom.com (Netscape Messaging Server 4.15) with ESMTP id GU02K600.CNJ; Wed, 3 Apr 2002 08:16:54 -0800 
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 11:16:49 -0500
From: [e-mail] (Mark C Smith)
Organization: Netscape Communications Corp.
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.9) Gecko/20020311
X-Accept-Language: English/United States [en-US],En
MIME-Version: 1.0
To: David Chadwick <[e-mail]>
CC: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <[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>

I am still concerned about how dropping the ;binary transfer option that 
was mandated by RFC 2252 will affect the large installed base of LDAPv3 
and PKI implementations (of course some PKI clients are already trying 
to use userCertificate without ;binary with LDAPv3 implementations, and 
not surprisingly there are having a difficult time).

But if consensus is to proceed with this proposal, then I think the 
conflict with RFC 2252 should be noted in the PKIX document (there is a 
lot of history behind all of this, and implementors and users who do not 
know all of it will undoubtedly be confused).

-Mark Smith
  Netscape


David Chadwick wrote:
> Colleagues
> 
> Here is my proposed change to the section describing the LDAP syntax for
> cerificates in the PKIX id
> <draft-pkix-ldap-schema-03.txt> which should be published before the end
> of April. As this is likely to be the most contentious part of the new
> ID, I thought it would be useful to distribute this text at the earlier
> possible moment.
> 
> All constructive comments welcomed
> 
> David
> 
> 
> 3.3  Certificate Syntax
> 
> A value in this transfer syntax is the binary octet string that results
> from BER or DER-encoding of an X.509 public key certificate.  The
> following string states the OID assigned to this syntax:
> 
>       ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
> 
> Servers must preserve values in this syntax exactly as given when
> storing and retrieving them. 
> 
> Note. Due to the changes from X.509(1988) to X.509(1993) and subsequent
> changes to the ASN.1 definition to support certificate extensions in
> X.509(1997), no character string transfer syntax is defined for
> certificates. The BNF notation in RFC 1778 [12] for "User Certificate"
> MUST NOT be used. Values in this syntax MUST be transferred as BER or
> DER encoded octets. The use of the ;binary encoding option, i.e. by
> requesting or returning the attributes with descriptions
> "userCertificate;binary" or "caCertificate;binary" has no effect on the
> transfer syntax.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33GGli28125 for ietf-pkix-bks; Wed, 3 Apr 2002 08:16:47 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33GGjm28121 for <[e-mail]>; Wed, 3 Apr 2002 08:16:45 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA10830; Wed, 3 Apr 2002 18:19:14 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040318161624:380 ; Wed, 3 Apr 2002 18:16:16 +0200 
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 18:15:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: [e-mail]
Subject: Re: WG Last Call: Roadmap
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 18:16:16, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 18:16:46, Serialize complete at 03/04/2002 18:16:46
Content-Transfer-Encoding: 7bit
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>

Tom,

>       I have a few issues with this, and some corrections as well.

>       In comment 12, I have two issues.  The first one, which is minor, is
> that  "one or more Top CA's may be trusted" should refer to root CA's
> instead - the two terms mean the same thing more often than not, but when
> they differ the trust point is the root rather than the top.

PKIX-1 states:

   " - Top CA - A CA that is at the top of a PKI hierarchy. 
    
   Note: This is often also called a "Root CA," since in data structures 
   terms and in graph theory, the node at the top of a tree is the 
   "root." However, to minimize confusion in this document, we elect to 
   call this node a "Top CA," and reserve "Root CA" for the CA directly 
   trusted by the EE."

The problem lies with the last sentence, i.e. "*the* CA directly trusted by
the EE.". The singular is being used which means that there is a single
one, multiple roots are not permitted, while multiple Top-CAs are permitted.

>       The second is less minor.  Is it truly intended that a signing EE 
> be permitted to specify the set of trusted CA's for an RP to use in 
> verifying a signature?  At a minimum, an RP in this model is responsible 
> for validating the the set of rules is identical to one it has already 
> decided to trust, but there is no reference in the model description to 
> any active role for the RP.

A verifier (not a signing EE as you mentioned) does not know what an anchor
is, but may know what a policy is. So by selecting the policy that applies
to the application, indirectly trust anchors (and much more) are selected.
Remember that the same verifier may verify digital signatures in various
contexts, e.g. for a Bank transaction or for a green reservation in a Golf
Club. The trust conditions are not necessarilly identical. Note also that a
verifier does not need to be a signer and may not have any certificate of
its own.

The case of a single (root) CA trusted for any kind of application is a very
specific case and cannot be considered as the general case.

>       In your comment 5 (on page 15), replace "date of issue" by "date and
> time of issue".

This is fine.

>       At a slightly more substantive level, shouldn't the clarification of
> the definition of Top CA on page 4 end "and reserve 'root CA' for a CA
> directly trusted by the EE."?  This wording permits multiple trusted roots.

I do not think that PKIX-1 allows for this. See the quote above.

>       In your comment 4, shouldn't "CA certificate" be "hierarchical CA
> certificate"?  Surely a Top CA's self-signed certificate is also a "CA
> certificate", and your definition excludes it.  Then the sentence "Some
> people in the WG believe that a cross certificate is a special kind of CA
> certificate." is reversed to "... believe that a hierarchical CA
> certificate is a special kind of cross certificate".

You say that the definition excludes the fact that a Top CA's self-signed
certificate is also a CA-certificate. This is correct, ... but was not
intended.

So what about this full correction ?

[2459bis] defines a cross-certificate as "a certificate issued by one CA to
another CA". [2459bis] does not provide a formal definition of a CA
certificate but implictly means a certificate where the subject of the
certificate is a CA. This means that self-signed certificates are CA
certificats but are not cross-certificates. Some people in the WG believe
that a cross certificate is a special kind of CA certificate issued by a CA
under one Top CA for another CA under a different Top CA. CAs in the same
hierarchy usually have part of their names imposed by the Top CA or by the
CAs under that Top CAs. When a cross certificate is issued, there is no
relationship between the names of the CAs.

>       In comment 11, the i.e. should remain "what are the root CA's" rather
> than "what are the Top CA's", for the same reason as in comment 12.

I do not think so. See my first comment.

Regards,

Denis

 
>             Tom Gindin
> 
> Denis Pinkas <[e-mail]>@mail.imc.org on 03/26/2002 12:11:50 PM
> 
> Sent by:    [e-mail]
> 
> To:    [e-mail]
> cc:    Carlisle Adams <[e-mail]>
> Subject:    Re: WG Last Call: Roadmap
> 
> Comments on the roadmap document draft-ietf-pkix-roadmap-07.txt
> 
> (snip)
> COMMENT 3. A sentence states: "However, to minimize confusion in this
> document, we elect to call this node a "Top CA," and reserve "Root CA" for
> the CA directly trusted by the EE". Since an EE may trust more than one Top
> CA, shouldn't we say:
> 
> "However, to minimize confusion in this document, we elect to call this
> node
> a "Top CA," and reserve "Root CA" when there is a single CA directly
> trusted
> by the EE."
> 
> COMMENT 4. On page 14. A clarification needs to be done between
> cross-certificates and CA certificates. The text currently states:
> 
>    A cross-certificate is a PKC issued by one CA to another CA which
>    contains a public CA key associated with the private CA signature key
>    used for issuing PKCs. Typically, a cross-certificate is used to
>    allow client systems or end entities in one administrative domain to
>    communicate securely with client systems or end users in another
>    administrative domain. Use of a cross-certificate issued from CA_1 to
>    CA_2 allows user Alice, who trusts CA_1, to accept a PKC used by Bob,
>    which was issued by CA_2. Cross-certificates can also be issued from
>    one CA to another CA in the same administrative domain, if required.
> 
> I would propose instead the following:
> 
> " A CA certificate is a certificate in a hierarchy that is neither a
> self-signed certificate, nor an end-entity certificate. [2459bis] does not
> make a difference between a CA certificate and a cross certificate since it
> defines a cross-certificate as "a certificate issued by one CA to another
> CA". Some people in the WG believe that a cross certificate is a special
> kind of CA certificate. A cross certificate is issued by a CA under one
> Top CA for another CA under a different Top CA. CAs in the same hierarchy
> have part of their names imposed by the Top CA or by the CAs under that
> Top CAS. When a cross certificate is issued, there is no relationship
> between the names of the CAS.
> 
> Typically, a cross-certificate is used to allow client systems or end
> entities in one administrative domain to communicate securely with client
> systems or end users in another administrative domain. Use of a
> cross-certificate issued from CA_1 to CA_2 allows user Alice, who trusts
> CA_1, to accept a PKC used by Bob, which was issued by CA_2.
> Cross-certificates can also be issued from one CA to another CA in the same
> administrative domain, if required."
> 
> COMMENT 5. On page 15, the text states: "A CRL is a time stamped list
> identifying revoked PKCs that is signed by a CA and made freely available
> in a public repository."
> 
> I would prefer to avoid to use "time-stamped" in that context and thus I
> would propose the following wording:
> 
> "A CRL is a list that identifies the references of revoked PKCs. This list
> contains a date of issue and is signed by a CA and made freely available in
> a public repository."
> 
> (snip)
> 
> COMMENT 11. On page 47. Section 5.5 talks about trust model, but only
> consider a single trust point:
> 
> "  An important design decision is where a particular EE's trust point
>    is located (i.e., where is the EE's Root CA). There are a number of
>    models that have been developed and depending on the environment some
>    models may be more suited than others. The following provides some
>    background on the models."
> 
> I would rather propose to change it into:
> 
> " An important design decision is, for a given application, where the
> particular EE's trust points are located (i.e. what are the Top CAs).
> There are a number of models that have been developed and depending on
> the environment some models may be more suited than others. The following
> provides some background on the models."
> 
> COMMENT 12. On page 49. Section 5.5 I would propose to add another model.
> 
> 5.5.5 Validation policies
> 
> Another model considers a set of rules that apply to an application
> context.
> Every application context may have a different set of rules. When choosing
> to use certificates in the context of that application, the EE selects the
> set of rules for that context. In a set of rules, one or more Top CAs may
> be
> trusted, each one may be associated with different constraints, like the
> certificate policies that are trusted or the naming constraints that apply.
> These constrains may be specified either in self-signed certificates or in
> addition to self-signed certificates when they do not incorporate these
> constraints. This set of rules is called a validation policy (when
> validating a certificate) or a signature policy (when validating a digital
> signature).
> 
> Regards,
> 
> Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33Fui325773 for ietf-pkix-bks; Wed, 3 Apr 2002 07:56:44 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33Fugm25760 for <[e-mail]>; Wed, 3 Apr 2002 07:56:42 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA12526; Wed, 3 Apr 2002 17:59:09 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040317561116:377 ; Wed, 3 Apr 2002 17:56:11 +0200 
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 17:55:50 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-logotypes-01.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 17:56:11, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 17:56:41, Serialize complete at 03/04/2002 17:56:41
Content-Transfer-Encoding: 7bit
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>

Russ,

Thank you for this long reply ... that did not convinced me.
The argumentation you provided is not crystal clear to me.

See my comments below.

> Denis:
> 
> I fear that you have missed the point of the logotypes draft
> altogether.  The authors recognize that the introduction needs to be
> expanded, so we may be to blame for any misunderstanding.  To try and clear
> up the misunderstanding, I offer some general observations before
> responding to your specific comments.
> 
> The logotype extension will aid in two situations:
>         1.  Certificate-based Identification
>         2.  Selection of Certificates
> 
> In the first case, the need for human recognition 

1) Recognition of what ? or of which characteristics ? 
   Please be precise.

2) Recognized by which entity ? Please be precise. 
   I would guess a human being acting as a relying party.

> depends on the manner in
> which certificates are used and whether certificates need to be visible to
> human users. If certificates are to be used in open environments and in
> applications that bring the user in conscious contact with the result of a
> certificate-based identification process, then human recognition is highly
> relevant, and it may be a necessity.
> 
> Most applications provide the human user with an opportunity to view the
> results of a successful certificate-based identification process.  When the
> user takes the steps necessary to view these results, the user is presented
> with a view of a certificate. This solution has two major problems.  First,
> the function to view a certificate is often rather hard to find for a
> non-technical user. Second, the presentation of the certificate is rather
> technical; it is not user friendly. It contains no graphic symbols or
> logotypes to enhance human recognition.
 
> In the second case, there are software applications that expose human users
> to certificates for the selection of a single certificate from a portfolio
> of certificates. In some circumstances, the software application can use
> information within the certificates to determine suitability; however, the
> user must be queried if more than one certificate is suitable. The human
> user must select one of them.

I would guess that is that case it is a recognition by the subscriber. 
Is it what you mean ? Are there other cases you are thinking of ? 
Please be precise.

> This situation is comparable to a person selecting a suitable plastic card
> from his wallet. In this situation, substantial assistance is provided by
> card color, location, and branding.
> 
> In order provide similar support for certificate selection, the users need
> tools to easily recognize and distinguish certificates. Introduction of
> logotypes into certificates provides the necessary graphic.

> Now, for your specific comments.
> 
> COMMENT 1: Subject logotype.
> 
> Currently a "subject organization logotype" is proposed. It definition is
> as follows: "a logotype representing the organization identified in the
> subject name in the certificate".
> 
>  From this definition only a single logotype would be allowed for a
> subject. It can make sense to attach more that one logotype to a subject,
> that does not reflect necessarily the organization a user belongs to (e.g.
> an individual is a Red Cross member) so the definition should be changed
> to:
> 
> "subject logotype" "a logotype representing any characteristic of the
> entity identified in the subject name in the certificate".
> 
> RESPONSE 1.
> 
> We are allowing a graphical identity of the user to facilitate certificate
> selection or acceptance. We are not trying to graphically represent every
> attribute of the user.  We certainly do not want to overwhelm the designers
> of graphic user interfaces.  We need to keep it simple.

I do not buy this argument. The current proposal limits to logo type to the
logo of the organization, whereas this limitation is not appropriate. A
subject may even have no O (Organization) component in the DN and there
could
be other logos attached to the subject field.

> COMMENT 2: Issuer logotype.
> 
> Currently an "issuer organization logotype" is proposed. It definition is
> as follows: "a logotype representing the organization identified as part of
> the issuer name in the certificate".
> 
>  From this definition a single logotype would be allowed for an issuer. It
> can make sense to attach more that one logotype to an issuer, that does not
> reflect necessarily the organization an issuer belongs to (e.g. an issuer
> may support a "Privacy Policy" and be a member from two different trade
> associations), so the definition should be changed to:
> 
> "issuer logotype: a logotype representing any characteristic of the issuer
> identified as part of the issuer name in the certificate".
>
> RESPONSE 2.
> 
> Again, we are allowing a graphical identity of the user to facilitate
> certificate selection or acceptance. We are not trying to graphically
> represent every attribute of the issuer.

I do not buy this argument. The current proposal limits to logo type to the
logo of the issuer, whereas this limitation is not appropriate. See my 
examples again.
 
> COMMENT 3: The "concept logotype", also renamed "community logotype" during
> the last IETF meeting or " shared community logotype" in the minutes from
> the same meeting is more hazy.
> 
> The current text states:" Many issuers may use the concept logotypes to
> co-brand with a global concept in order to gain global recognition of its
> local service provision. This type of concept branding is very common in
> credit card business where local independent card issuers issue cards
> within a globally branded concept (such as VISA and MasterCard)".
> 
> The current text also states: " the relationship between the issuer and
> either the issuer  organization logotype or the concept logotype".
> 
> A logotype is adding "human processable" information to enhance the
> properties of an already existing field from a certificate. To this respect
> it is sensible to add one (or more) logotypes that characterizes the issuer
> and the subject. The real question is to which field the "concept
> logotype / community logotype / shared community logotype" relates.
> 
> It may relate :
>    - either to the issuer, to state that an issuer belongs to some group, or
>    - to the certificate policy to state that the policy under which the
>      certificate is issued obeys to some rules imposed by the organization
>      whose logo is referenced.
> 
> This leads to two possible ways:
>     1) only consider two logotypes: issuer logotype and subject logotypes.
>     2) consider three logotypes: issuer logotypes, subject logotypes and
>        policy logotypes.
> 
> I would favor the former, but would have no major problem to go with the
> later. In that case the policy logotype would be defined as follows:
> 
> "Policy logotype: a logotype representing any characteristic of the
> certificate policy under which the certificate is issued".
> 
> RESPONSE 3.
> 
> Policy implies the wrong connotation. We are not trying to graphically
> represent a certificate policy or anything about how the certificate was
> issued. The community (or concept) logotype simply allows CA to enter into
> collective branding relationships.

A branding of what ?  Please be precise.
 
> I suppose that a large group that share a common security policy could
> register a logo for that policy and use it as a community logo.  While this
> was not the model that we considered, it certainly is accommodated.
> 
> COMMENT 4: Logotypes are not "claimed" by the issuer, but always *verified*
> to some extend by the issuer. The current text is misleading:
> 
>     "The relationship between the subject organization and the subject
>     organization logotype and the relationship between the issuer and
>     either the issuer organization logotype or the concept logotype, are
>     relationships *claimed* by the issuer."
> 
> RESPONSE 4.
> 
> The issuer is responsible for the verification of anything that is included
> in the certificate.  After all, the issuer signature covers it.  Thus, the
> issuer is claiming that the logotypes are appropriate.

Don't twist the wording.  :-)

We agree on the concept, but we should try to use another wording and avoid
to use the word "claim".
 
> COMMENT 5: During the meeting, it has been proposed to add a small image of
> the logotype in the certificate itself. In this WG we always have had a
> concern about the size of the certificate, so that it can be lodged in some
> small devices. So I would not favor to allow such provision in a
> extension standardized by this WG.
> 
> RESPONSE 5.
> 
> There are environments where the client cannot access the Internet until
> after the certificate is used.  Consider certificate-based authentication
> to an ISP.  A small logotype in the certificate could be useful to aid
> certificate selection in this situation.  The inclusion of a small logotype
> is, of course, optional.

...and instead of certificates between 1 K and 2 K bytes, have certificates 
with at least one more K !

Denis

 
> COMMENT 6: It should be made clear that this extension in non-critical.
> 
> RESPONSE 6.
> 
> Agree.  The logotype extension was never intended to be critical.
> 
> COMMENT 7: The document includes many typos to be corrected.
> 
> RESPONSE 7.
> 
> We will make every effort to correct them before the next draft is published.
> 
> Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33Fbwv23262 for ietf-pkix-bks; Wed, 3 Apr 2002 07:37:58 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33Fbum23258 for <[e-mail]>; Wed, 3 Apr 2002 07:37:56 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA03534; Wed, 3 Apr 2002 17:37:55 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 3 Apr 2002 17:37:55 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA09673; Wed, 3 Apr 2002 17:37:54 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA04100; Wed, 3 Apr 2002 17:37:53 +0200 (MET DST)
Date: Wed, 3 Apr 2002 17:37:53 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
Cc: [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>

Thnaks for adding the following: I suggest some small wording change:

> 
> "There are no specific requirements for confidentiality at the protocol 
> level. Confidentiality may be achieved at the transport level."
I suggest: 

  "There are no specific requirements for support of confidentiality at the protocol 
  level. Confidentiality may be achieved at the transport level."
 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33FUZX23031 for ietf-pkix-bks; Wed, 3 Apr 2002 07:30:35 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g33FUXm23025 for <[e-mail]>; Wed, 3 Apr 2002 07:30:33 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Apr 2002 15:29:39 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA19357; Wed, 3 Apr 2002 10:29:34 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g33FUaO15504; Wed, 3 Apr 2002 10:30:36 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1N9S9>; Wed, 3 Apr 2002 10:28:13 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.113]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1N9S5; Wed, 3 Apr 2002 10:28:06 -0500
From: "Housley, Russ" <[e-mail]>
To: David Chadwick <[e-mail]>
Cc: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 03 Apr 2002 10:21:39 -0500
Subject: Re: LDAP Certificate transfer syntax
In-Reply-To: <[e-mail]>
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>

David:

I would like to encourage clients to provide certificates in DER.  We ought 
to tell them that there will be less work for everyone if they provide 
DER-encoded certificates.  Likewise for CRLs.

Russ

At 10:32 PM 4/1/2002 +0100, David Chadwick wrote:


>"Housley, Russ" wrote:
> >
> > David:
> >
> > Is it possible to preserve the DER encoding.  If not, then the DER encoding
> > must be restored in order to validate the signature?  This just seems like
> > wasted processing to me.
> >
>
>Russ
>
>I quite agree. The revised text is meant to ensure that the DER or BER
>encoding created by the client when the certificate was first sent to
>the directory for storage is preserved as is. This is the purpose of the
>sentence below in the revised text, viz:
>
> > >Servers must preserve values in this syntax exactly as given when
> > >storing and retrieving them.
> > >
>
>Perhaps I should say "as given to them by the client, when storing and
>retrieving certificates"
>
>David
>


Received: by above.proper.com (8.11.6/8.11.3) id g33FMf122330 for ietf-pkix-bks; Wed, 3 Apr 2002 07:22:41 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33FMdm22326 for <[e-mail]>; Wed, 3 Apr 2002 07:22:39 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA03471; Wed, 3 Apr 2002 17:22:34 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 3 Apr 2002 17:22:34 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA09603; Wed, 3 Apr 2002 17:22:33 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA04090; Wed, 3 Apr 2002 17:22:33 +0200 (MET DST)
Date: Wed, 3 Apr 2002 17:22:33 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
Cc: [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>

> 
> Peter:
> 
> Would you be happy if the client and server identities were optional?

I never had anything else in mind: What about:

The protocol MUST provide a means to allow a client and a server
to indicate the participating entities (depending on policy
or application context). 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33FEpV21961 for ietf-pkix-bks; Wed, 3 Apr 2002 07:14:51 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33FEom21957 for <[e-mail]>; Wed, 3 Apr 2002 07:14:50 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA17590; Wed, 3 Apr 2002 17:17:18 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040317143140:368 ; Wed, 3 Apr 2002 17:14:31 +0200 
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 17:14:16 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 17:14:31, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 17:14:50, Serialize complete at 03/04/2002 17:14:50
Content-Transfer-Encoding: 7bit
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>

Peter,

> > COMMENT 7: Requests shall be able to be authenticated.
> 
> At the end of the following exchange you mention that it
> is unclear what requirement is being addressed and
> what ind of treatment would be done with such an identity
> field. The comment is not necessarily related to
> authentication.
> 
> - The requirement is to include the identities of
>   participating parties in the request and in the
>   response, in order to indicate who has participated.

It is proposed to add after the current last paragraph from section 4: 

"When the request is authenticated, the requestor shall have the possibility
to have its identifier included or not in the response."

>   This is independant of whether this matches with
>   some authentication.
> 
> - The treatment is essentially for display purposes
>   to be able to describe show the transaction result
>   together with the identities with the need to
>   understand a particular way how these information
>   can be found in some authnetication envelope.
> 
> - Anyway, the response should provide for a means
>   to indicate for whom the response has been made,
>   not only who has made the response.

Since relaying is not supported (see the response to your other e-mail),
there is no difference between "for whom the response has been made" and
"who has made the response".

Denis
 
> Peter
> 
> ----------------------
> 
> [About COMMENT 7]
> 
> > - a method that client and server provide their identity
> >    in the requests and responses: 'You, the client X, has
> >    asked me, the server Y, the following question, and
> >    I, the server Y, with the help of server Z respond.'
> 
> > This allows to be able to determine the participating entities
> > without having access to whatever particular authentication
> > method information.
> 
> > [Answer 7] Actually, we already include the identity of the server in the
> > response. The request could also be optionally signed. This allows
> > the server to authenticate the client, and this authentication allows the
> > server to only support a selective community if desired. An option to be
> > able to sign the request may be added.
> 
> > The following requirements may be used for example in case of
> > validation of an encryption certificate before usage.
> 
> There is a difference between authentication and identification.
> The request is that the identification is independant from the
> authentication methods and the transports.
> 
> A signing entity (the one identified in a signer info or a certificate)
> may or may not be the same as the one declared in the request/response.
> you may have separation of roles or other situations.
> 
> "The President of the United States declares, ... signed by JWB".
> 
> Another example is in relaying as follows:
> 
> Your company service declares that I can use Your encryption cert,
> and the response is signed by my local service.
> 
> [Additional Answer 7]
> 
> It is unclear what requirement is being addressed and what kind of treatment
> would be done with such an identity field.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33FE8e21943 for ietf-pkix-bks; Wed, 3 Apr 2002 07:14:08 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130] (may be forged)) by above.proper.com (8.11.6/8.11.3) with SMTP id g33FE6m21939 for <[e-mail]>; Wed, 3 Apr 2002 07:14:06 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 3 Apr 2002 15:13:12 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA17658; Wed, 3 Apr 2002 10:13:06 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g33FE8113442; Wed, 3 Apr 2002 10:14:08 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1N92K>; Wed, 3 Apr 2002 10:11:44 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (10.3.16.113 [10.3.16.113]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1N92B; Wed, 3 Apr 2002 10:11:40 -0500
From: "Housley, Russ" <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail], [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 03 Apr 2002 09:32:19 -0500
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
In-Reply-To: <[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>

Peter:

Would you be happy if the client and server identities were optional?

Russ

At 08:00 PM 4/2/2002 +0200, Peter Sylvester wrote:

> >
> > COMMENT 7: Requests shall be able to be authenticated.
>
>At the end of the following exchange you mention that it
>is unclear what requirement is being addressed and
>what ind of treatment would be done with such an identity
>field. The comment is not necessarily related to
>authentication.
>
>- The requirement is to include the identities of
>   participating parties in the request and in the
>   response, in order to indicate who has participated.
>
>   This is independant of whether this matches with
>   some authentication.
>
>- The treatment is essentially for display purposes
>   to be able to describe show the transaction result
>   together with the identities with the need to
>   understand a particular way how these information
>   can be found in some authnetication envelope.
>
>- Anyway, the response should provide for a means
>   to indicate for whom the response has been made,
>   not only who has made the response.
>
>Peter
>
>----------------------
>
>
>[About COMMENT 7]
>
> > - a method that client and server provide their identity
> >    in the requests and responses: 'You, the client X, has
> >    asked me, the server Y, the following question, and
> >    I, the server Y, with the help of server Z respond.'
>
> > This allows to be able to determine the participating entities
> > without having access to whatever particular authentication
> > method information.
>
> > [Answer 7] Actually, we already include the identity of the server in the
> > response. The request could also be optionally signed. This allows
> > the server to authenticate the client, and this authentication allows the
> > server to only support a selective community if desired. An option to be
> > able to sign the request may be added.
>
> > The following requirements may be used for example in case of
> > validation of an encryption certificate before usage.
>
>There is a difference between authentication and identification.
>The request is that the identification is independant from the
>authentication methods and the transports.
>
>A signing entity (the one identified in a signer info or a certificate)
>may or may not be the same as the one declared in the request/response.
>you may have separation of roles or other situations.
>
>"The President of the United States declares, ... signed by JWB".
>
>Another example is in relaying as follows:
>
>Your company service declares that I can use Your encryption cert,
>and the response is signed by my local service.
>
>[Additional Answer 7]
>
>It is unclear what requirement is being addressed and what kind of treatment
>would be done with such an identity field.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33F8Eg21173 for ietf-pkix-bks; Wed, 3 Apr 2002 07:08:14 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33F8Cm21165 for <[e-mail]>; Wed, 3 Apr 2002 07:08:12 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA27850; Wed, 3 Apr 2002 17:10:39 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040317074055:364 ; Wed, 3 Apr 2002 17:07:40 +0200 
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 17:07:25 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 17:07:40, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 17:08:11, Serialize complete at 03/04/2002 17:08:11
Content-Transfer-Encoding: 7bit
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>

Peter,


> > COMMENT 5: No authentication of the server prior to the sending of the
> > request (not done with similar protocols).

> Denis, I think that I may have badly stated the requirement. I
> assume an online connection *and* confidentiality via TLS
> done at the transport layer. In this case, confidentiality
> would be somewhat meaningless if you don't authenticate the
> server.  Your remark is correct if you think about encryption
> with email, but then you assume that only the server can decrypt,
> thus you still have server authentication.

If a server can decrypt, this does not authenticate the server to the
requester.
 
> What similar protocol do you have in mind? (OCSP)?

For example.
 
> > COMMENT 6: Confidentiality done at transport level.
 
> Ok, but it is not mentioned in the text. If
> properly stated, it resolves COMMENT 5.

Confidentiality is not a requirement for this protocol. 
Since this document lists requirements, non-requirements are not listed.
Nevertheless, in order to be very explicit on that point (and because a new
draft will need to be edited for some other comments anyway), it is proposed
to add the following sentence at the end of sections 4 and 5:

"There are no specific requirements for confidentiality at the protocol 
level. Confidentiality may be achieved at the transport level."

> > COMMENT 8: Relaying not supported by the protocol.
> >
> This is a pity: This was omitted in OCSP, and the risk
> of endless loops of two OCSP servers talking to each other
> are definitely there.
> Relaying a request to another service is a requirement,
> at least in the same way as it is for OCSP.

These two sentences are self-contradictory: 

 - "omitted in OCSP" and 
 - "in the same way as it is for OCSP". 

There is no relaying in OCSP.

> But there are two issues:
> 
> Why do you think that a DPV response from a server MUST NOT
> contain a DPV response from another server, while on the other
> hand it is provided that the server returns all information
> concerning the certification path, an revocation information.
> What does make DPV responses so different from OCSP reponses
> that they would create either additional complexity or harm.
> 
> An end user only communicates with his local company
> service. The company knows which external CAs can be
> trusted, and which service can be contacted.
> You already allow to contact OCSP services in this
> way. Where is the difference between DPV and OCSP?
> 
> It may be desirable that an end user may not
> directly interface with a remote DPV and needs an
> intermediate 'anonymizer' or 'authorized relay'.
> 
> In all such cases there is a danger (like in OCSP)
> for endless loops.

There is no such a danger: the request is sent to one server and must come
back from that same server. If the server uses relaying in the back ground
to fulfill the service, then this is not visible from the requester. The
final response from a DPV server is signed by the server that received the
original request. Relaying is not supported by the protocol.

Denis

> peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33F5vj20789 for ietf-pkix-bks; Wed, 3 Apr 2002 07:05:57 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33F5tm20770 for <[e-mail]>; Wed, 3 Apr 2002 07:05:55 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA25334; Wed, 3 Apr 2002 17:08:18 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040317052000:362 ; Wed, 3 Apr 2002 17:05:20 +0200 
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 17:05:05 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Brian Hunter <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]> <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 17:05:20, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 17:05:50, Serialize complete at 03/04/2002 17:05:50
Content-Transfer-Encoding: 7bit
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>

Brian,

> Hello Denis and Russ,
> 
> >      Great work on the new draft!

> I concur.
 
> I have one question and a couple of small typographical comments to add.
> 
> 5. Section 5 Para 4
>     This comment goes along with Ambarish's comment 1.  I do not
> understand what is meant by "if issued" in the following sentence:
>   "The trust anchor self-signed certificate, if issued, is not
> included."
> 
> Without understanding the "issued" point and assuming that all trust
> anchor certificates, self-signed or not, are issued, then I would have
> the sentence read:
>   "The trust anchor is not included."
> Note that I am agreeing with Ambarish that the self-signed requirement
> for a root should be dropped.

For this point, see the response to Ambarish. It is proposed to have the
following text:

"Each path consists of a sequence of certificates, starting with 
the certificate to be validated and ending with a trust anchor. 
If the trust anchor is a self-signed certificate, that self-signed 
certificate is not included."

All the following change requests have been granted.

Denis

 
> 6. Section 4 Para 11 c)
>     "If another request could made later..."
>     Suggest to change to: "...could be made..."
> 
> 7. Section 7 Para 3
>     "constrains" -> "constraints"
> 
> 8. Section 7.1 Para 1
>     "build" -> "built"
> 
> 9. Section 9 Last paragraph point (3)
>     Is it intended that the validation time should be adjusted for only
> one of the four points, hence the use of "or" after point three? I would
> suggest the use of "and".
> 
> Regards,
> Brian
> 
> >
> > A few comments:
> >
> > 1. In 2 places you equate the "root" with a self-signed cert. I
> > hope you intend to allow the trust anchor to be a non-self-signed
> > cert. The 2 places are Para 4 of Section 4 and Para 4 of Section 5.
> >
> > 2. Section 4 Para 9
> >     You require the DPV server to "obtain" the certificate from the
> > reference provided by the client. This is *not* a requirement. If
> > the server obtains the certificate by some other means, that is okay,
> > as long as it verifies that the certificate is indeed the one
> > being referred to by the client.
> >
> > 3. Section 4 Para  12
> >     In order to prevent replay attacks, you require the nonce to be
> > present in the response. As mentioned by Petra, if the response
> > contained the request hash, it doesn't need to contain the nonce. It
> > is still bound to the request. Present of the request nonce in the
> > reply shouldn't be a requirement in this case.
> >
> > 4. Section 4 Para 16
> >     You require a DPV response to be signed - error response
> > might not be signed (e.g. badly formatted request, etc.) Please
> > allow for that case.
> >
> > That's it!
> >
> > Regards,
> > Ambarish
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Chief Architect                                          650.567.5457
> > ValiCert, Inc.                                  [e-mail]
> > 1215 Terra Bella Ave.                         http://www.valicert.com
> > Mountain View, CA 94043
> >
> > > -----Original Message-----
> > > From: Tim Polk [mailto:[e-mail]]
> > > Sent: Friday, March 29, 2002 2:55 PM
> > > To: [e-mail]
> > > Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
> > >
> > >
> > >
> > > Folks,
> > >
> > > The editors have informed me that they believe the -03 draft
> > > satisfies all
> > > WG Last Call comments and meets the criteria of rough
> > > consesnsus. My review
> > > agrees with their position, and I would like to ship the
> > > document to the
> > > ADs as soon as possible.
> > >
> > > If you have a dog in this fight, *please review the specification by
> > > Tuesday COB.*  If I do not see any traffic on the list stating that
> > > unresolved comments remain, I will forward the document to the ADs
> > > Wednesday morning.
> > >
> > > Thanks,
> > >
> > > Tim Polk
> > >
> > > At 07:03 AM 3/29/02 -0500, you 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           : Delegated Path Validation and
> > > Delegated Path
> > > > Discovery
> > > >                           Protocol Requirements (DPV&DPD-REQ)
> > > >         Author(s)       : D. Pinkas, R. Housley
> > > >         Filename        : draft-ietf-pkix-dpv-dpd-req-03.txt
> > > >         Pages           : 11
> > > >         Date            : 28-Mar-02
> > > >
> > > >This document specifies the requirements for Delegated Path
> > > Validation
> > > >(DPV) and Delegated Path Discovery (DPD) for Public Key Certificates.
> > > >It also specifies the requirements for DPV and DPD policy management.
> > > >
> > > >A URL for this Internet-Draft is:
> > > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> > > eq-03.txt
> > > >
> > > >To remove yourself from the IETF Announcement list, send a message to
> > > >ietf-announce-request with the word unsubscribe in the body
> > > of the message.
> > > >
> > > >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-dpv-dpd-req-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-dpv-dpd-req-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.
> > > >Content-Type: text/plain
> > > >Content-ID:     <[e-mail]>
> > > >
> > > >ENCODING mime
> > > >FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
> > > >
> > > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> > > eq-03.txt>
> > >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g33F16220276 for ietf-pkix-bks; Wed, 3 Apr 2002 07:01:06 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33F15m20272 for <[e-mail]>; Wed, 3 Apr 2002 07:01:05 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA28180; Wed, 3 Apr 2002 17:03:15 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040317003987:361 ; Wed, 3 Apr 2002 17:00:39 +0200 
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 17:00:25 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>, [e-mail]
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 17:00:39, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 03/04/2002 17:00:52, Serialize complete at 03/04/2002 17:00:52
Content-Transfer-Encoding: 7bit
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>

 
> Hi Denis, Russ,
>      Great work on the new draft!

Thank you. It was quite harder than expected.

> A few comments:
> 
> 1. In 2 places you equate the "root" with a self-signed cert. I
> hope you intend to allow the trust anchor to be a non-self-signed
> cert. The 2 places are Para 4 of Section 4 and Para 4 of Section 5.

In Para 4 of Section 4, the text says "e.g. root self-signed certificates".
So there is nothing wrong, since this is only an example. No change needed.

In Para 4 of Section 5, the text says: "The trust anchor self-signed
certificate, if issued, is not included." Since Brian had problems with 
that sentence too, it is proposed to change it into:

"Each path consists of a sequence of certificates, starting with 
the certificate to be validated and ending with a trust anchor. 
If the trust anchor is a self-signed certificate, that self-signed 
certificate is not included."

> 2. Section 4 Para 9
>     You require the DPV server to "obtain" the certificate from the
> reference provided by the client. This is *not* a requirement. If
> the server obtains the certificate by some other means, that is okay,
> as long as it verifies that the certificate is indeed the one
> being referred to by the client.

The current sentence is:

"If not provided in the request, the server MUST use the unambiguous 
reference provided in the request to obtain it."

It is proposed to change the sentence into:

"If not provided in the request, the server MUST verify that the certificate
is indeed the one being unambiguous referenced by the client".

> 3. Section 4 Para  12
>     In order to prevent replay attacks, you require the nonce to be
> present in the response. As mentioned by Petra, if the response
> contained the request hash, it doesn't need to contain the nonce. It
> is still bound to the request. Present of the request nonce in the
> reply shouldn't be a requirement in this case.

Verification of equality of the nonce is simple and straigthforward to
discard replay attacks. Since we do not require to use the hash of the
request in the response, we have purposely maintained this requirement.
 
> 4. Section 4 Para 16
>     You require a DPV response to be signed - error response
> might not be signed (e.g. badly formatted request, etc.) Please
> allow for that case.

Certainly. The current text is:

"For the client to be confident that the certificate validation was 
handled by the expected DPV server, the DPV response MUST be 
authenticated.

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

It is proposed to add at the end of each paragraph:

"unless an error is reported (e.g. badly formatted request, etc.)."
 
> That's it!

Thank you !

Denis


> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Chief Architect                                          650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043
> 
> > -----Original Message-----
> > From: Tim Polk [mailto:[e-mail]]
> > Sent: Friday, March 29, 2002 2:55 PM
> > To: [e-mail]
> > Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
> >
> >
> >
> > Folks,
> >
> > The editors have informed me that they believe the -03 draft
> > satisfies all
> > WG Last Call comments and meets the criteria of rough
> > consesnsus. My review
> > agrees with their position, and I would like to ship the
> > document to the
> > ADs as soon as possible.
> >
> > If you have a dog in this fight, *please review the specification by
> > Tuesday COB.*  If I do not see any traffic on the list stating that
> > unresolved comments remain, I will forward the document to the ADs
> > Wednesday morning.
> >
> > Thanks,
> >
> > Tim Polk
> >
> > At 07:03 AM 3/29/02 -0500, you 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           : Delegated Path Validation and
> > Delegated Path
> > > Discovery
> > >                           Protocol Requirements (DPV&DPD-REQ)
> > >         Author(s)       : D. Pinkas, R. Housley
> > >         Filename        : draft-ietf-pkix-dpv-dpd-req-03.txt
> > >         Pages           : 11
> > >         Date            : 28-Mar-02
> > >
> > >This document specifies the requirements for Delegated Path
> > Validation
> > >(DPV) and Delegated Path Discovery (DPD) for Public Key Certificates.
> > >It also specifies the requirements for DPV and DPD policy management.
> > >
> > >A URL for this Internet-Draft is:
> > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> > eq-03.txt
> > >
> > >To remove yourself from the IETF Announcement list, send a message to
> > >ietf-announce-request with the word unsubscribe in the body
> > of the message.
> > >
> > >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-dpv-dpd-req-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-dpv-dpd-req-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.
> > >Content-Type: text/plain
> > >Content-ID:     <[e-mail]>
> > >
> > >ENCODING mime
> > >FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
> > >
> > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> > eq-03.txt>
> >


Received: by above.proper.com (8.11.6/8.11.3) id g33Ex4C20198 for ietf-pkix-bks; Wed, 3 Apr 2002 06:59:04 -0800 (PST)
Received: from mtk-mail1.mitretek.org (mtk-mail1.mitretek.org [141.156.156.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33Ex2m20194 for <[e-mail]>; Wed, 3 Apr 2002 06:59:02 -0800 (PST)
Received: from tsf-gw.tsf.mitretek.org ([e-mail] [172.16.17.253]) by mtk-mail1.mitretek.org (8.12.1/8.12.1) with ESMTP id g33EvpGk022547; Wed, 3 Apr 2002 09:57:52 -0500 (EST)
Received: from localhost (stillson@localhost [127.0.0.1]) by tsf-gw.tsf.mitretek.org (8.12.1/8.12.1/Debian -5) with ESMTP id g33F0k9w013618; Wed, 3 Apr 2002 10:00:47 -0500
Date: Wed, 3 Apr 2002 10:00:46 -0500 (EST)
From: Ken Stillson <[e-mail]>
To: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
cc: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax (draft-ietf-pkix-ldap-v3-05.txt)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by above.proper.com id g33Ex3m20195
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 Wed, 3 Apr 2002, Michael Ströder wrote:
> Ken, for various reasons this old style 1:1 DIT mapping and obtaining the
> certificate chain from a directory never really worked in practice. Maybe in
> some small environments or very specific environments.

  As I understand it, this is the approach being taken in the rather large
  effort of the Federal Bridge CA (FBCA).  Perhaps it's not an ideal
  solution, but at the moment, it appears to be the only available solution.

  The problem is that when finding the next certificate in a hierarchical or
  cross-cert chain, validation software might (when AIA and similar
  extensions are not populated) only have the issuer field of the current
  cert in order to find the next certificate.

  (David W. informs me that an outcome of the LDAP PKIX ID will be the
   ability to search for an entry based on its internal cert DN rather than
   ldap-read it from a directory location.  I hadn't caught that; perhaps
   that's the permanent solution.  I'm coming from the point of view of the
   FBCA project which is already well underway and didn't have that
   capability available to rely upon.)


> BTW: Which implementation do exist outside the X.500 world which try to
> obtain the whole certificate chain from a LDAP directory? I do not know a
> single one.

  FBCA is using a combination of chained X.500 directories (with LDAP
  front-ends), and LDAP "meta-directories," essentially a mesh of referral
  systems.


> Also think of dc-style naming vs. traditional X521 naming. If you'd like to
> use dc-style naming in your LDAP directory and have that DIT 1:1 in your
> certificate's subject name you will run into many serious interoperability
> problems with PKI enabled software.

  Well, I guess I would say that if one "would like" dc-style naming, then
  that directory is designed for human interaction (humans "like" things).

  A PKI repository being stood-up for automated certificate retrieval should
  be structured for the ease of retrieval; if one really needs both, and
  they conflict, it wouldn't be too surprising to need two structures;  at
  least two indexing structures (I believe most directory software would
  allow referrals or aliases to provide two DN views to the same objects).

    - Ken


-- 
      |   Ken Stillson             |    [e-mail]    |
      |   Sr. Principal Engineer   |    voice: [phone]    |
      |   Mitretek Systems         |      fax: [phone]    |







Received: by above.proper.com (8.11.6/8.11.3) id g33Es5m19790 for ietf-pkix-bks; Wed, 3 Apr 2002 06:54:05 -0800 (PST)
Received: from e1.esmtp.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33Es3m19786 for <[e-mail]>; Wed, 3 Apr 2002 06:54:03 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.us.ibm.com [9.117.200.22]) by e1.esmtp.ibm.com (8.12.2/8.12.2) with ESMTP id g33EoVMr363910; Wed, 3 Apr 2002 09:50:31 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO/VER6.00) with ESMTP id g33Erto15380; Wed, 3 Apr 2002 09:53:55 -0500
Importance: Normal
Sensitivity: 
Subject: Re: LDAP Certificate transfer syntax (draft-ietf-pkix-ldap-v3-05.txt)
To: Harald Koch <[e-mail]>
Cc: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 3 Apr 2002 09:49:06 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9a |January 28, 2002) at 04/03/2002 09:53:56 AM
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>

      Harald:

      While there is obviously nothing wrong with putting certificates in a
directory entry other than that of the subject (cross-certificates are
recommended to go into the issuer's directory entry as well as the
subject's for example), should certificates be stored in the
userCertificate attribute of any entry other than the subject's?  That's a
much more dubious thing to do.  Shouldn't a different attribute be defined
for such a purpose?

            Tom Gindin


Harald Koch <[e-mail]>@mail.imc.org on 04/03/2002 12:08:14 AM

Sent by:    [e-mail]


To:    LDAP BIS <[e-mail]>, PKIX <[e-mail]>
cc:
Subject:    Re: LDAP Certificate transfer syntax
       (draft-ietf-pkix-ldap-v3-05.txt)



Of all the gin joints in all the towns in all the world, Ken Stillson
had to walk into mine and say:
>
>   "A PKI object should be placed into a LDAP directory such that the LDAP
>    object DN matches the subject DN of the object."

It's supposed to be the other way around, isn't it? One should issue
certificates with a subject DN that matches the LDAP object DN.

Anyway, there are many environments where a certificate issued by one
organisation must be stored in a directory belonging to another. I don't
believe that an arbitrary restriction like this won't fly.

--
Harald Koch     <[e-mail]>






Received: by above.proper.com (8.11.6/8.11.3) id g33AIJx02531 for ietf-pkix-bks; Wed, 3 Apr 2002 02:18:19 -0800 (PST)
Received: from ntsiaexch.office ([193.203.230.22]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g33AHsm02493 for <[e-mail]>; Wed, 3 Apr 2002 02:17:55 -0800 (PST)
Received: by ntsiaexch.office with Internet Mail Service (5.5.2653.19) id <2F65LS19>; Wed, 3 Apr 2002 12:17:45 +0200
Message-ID: <[e-mail]>
From: Santoni Adriano <[e-mail]>
To: PKIX <[e-mail]>
Subject: ISO 9796-2 and PKCS#7
Date: Wed, 3 Apr 2002 12:17:44 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
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>

A little bizarre question to all volunteers: does somebody think that ISO
9796-2 could be used within PKCS#7 SignedData envelopes?

Adriano


___________________________________________________________________

SIA S.p.A. SI TRASFERISCE

NUOVA SEDE ---> http://www.sia.it/taramelli <--- NUOVA SEDE
___________________________________________________________________

*******************Internet Email Confidentiality Footer******************* 
Qualsiasi utilizzo non autorizzato del presente messaggio nonche' dei suoi
allegati e' vietato e potrebbe costituire reato. Se lei ha ricevuto
erroneamente il presente messaggio, Le saremmo grati se, via e-mail, ce ne
comunicasse la ricezione e provvedesse alla distruzione del messaggio stesso
e dei suoi eventuali allegati. Le dichiarazioni contenute nel presente
messaggio nonche' nei suoi eventuali allegati devono essere attribuite
esclusivamente al mittente e non possono essere considerate come trasmesse o
autorizzate da SIA S.p.A.; le medesime dichiarazioni non impegnano SIA
S.p.A. nei confronti del destinatario o di terzi. 
SIA S.p.A. non si assume alcuna responsabilita' per eventuali
intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail. 

Any unauthorized use of this e-mail or any of its attachments is prohibited
and could constitute an offence. If you are not the intended addressee
please advise immediately the sender by using the reply facility in your
e-mail software and destroy the message and its attachments. The statements
and opinions expressed in this e-mail message are those of the author of the
message and do not necessarily represent those of SIA. Besides, The contents
of this message shall be understood as neither given nor endorsed by SIA
S.p.A.. 
SIA S.p.A. does not accept liability for corruption, interception or
amendment, if any, or the consequences thereof. 




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g338MEt16229 for ietf-pkix-bks; Wed, 3 Apr 2002 00:22:14 -0800 (PST)
Received: from brot.celocom.de (brot.celocom.de [212.78.104.200]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g338MCm16223 for <[e-mail]>; Wed, 3 Apr 2002 00:22:12 -0800 (PST)
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 10:21:44 +0200
From: Bernd Matthes <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (WinNT; U)
X-Accept-Language: de,en
MIME-Version: 1.0
To: ietf pkix <[e-mail]>
Subject: Q: TSA policy
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msECB7DC067B9673DB81FBEC11"
X-Virus-Scanned: by AMaViS perl-11
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 cryptographically signed message in MIME format.

--------------msECB7DC067B9673DB81FBEC11
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi!

I need some clarification about TSA policy ID.
RFC3161 says:
   "The policy field MUST indicate the TSA's policy under which the
   response was produced.  If a similar field was present in the
   TimeStampReq, then it MUST have the same value, otherwise an error
   (unacceptedPolicy) MUST be returned."

The first question is whether a TSA can be have a "list" of policy ID's
to check
the requested policy against this list and generate a timestamp if one
is 
matching or use the "first" entry if no policy is requested.
I think that's not allowed, but for each policy MUST run a separate TSA
server,
i'm right?

RFC3161 says (chapter 2.1.):
"   5.    to include within each time-stamp token an identifier to
         uniquely indicate the security policy under which the token was
         created."

The policy belongs to the TSA, i.e. it says about secure environment,
time source availability/precision, hardware/software key, private key
storage and so on, i'm right?
So a client cannot say in in the requested policy what the source of the
messageImprint is. For example a request for a word document comes with
"1.2.3.4" and a request for a excel table comes with "1.2.3.5"?
Or is the extension the better place to specify what was the origin 
for the messageImprint?

The third question is about the possibility to "forward" a time-stamp
request
to another TSA if the requested policy did not match? So proxy likely?

Thanks in advance.

with kind regards
-- 
Bernd Matthes                   Gemplus mids GmbH --
Senior Software Engineer    	   formerly Celo Communications GmbH
Dipl.-Ing.(FH)                  R&D Center Germany
--------------------------------------------------------------------
"Complexity breeds bugs. Bugs prevent adoption, lack of" \
"adoption results in death. Death not good." "Life sucks."
--------------msECB7DC067B9673DB81FBEC11
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIH6gYJKoZIhvcNAQcCoIIH2zCCB9cCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
Bb0wggKMMIIB9aADAgECAgMHA+kwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMjAzMTgxNzIxMzRaFw0wMzAzMTgxNzIxMzRa
MEsxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxKDAmBgkqhkiG9w0BCQEWGWJl
cm5kLm1hdHRoZXNAZ2VtcGx1cy5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANLH
Ug0UXihUAGRuILAJAZhyok9Oj2UG5HcQXVgAK8Q1MJOTs3XKzdimgxdKdl1C6GBj+XUDhyin
6EM0/nrgpIg+abWtjmz1U4XXOhmqDz7qLRP/wu/FZefkM/QRbgrBXZh/NTOr1m0sMThKGTgs
ZCiwc6HebSh43HNgwE74QTHhAgMBAAGjNjA0MCQGA1UdEQQdMBuBGWJlcm5kLm1hdHRoZXNA
Z2VtcGx1cy5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQQFAAOBgQDK4ZRCCCV5wytZ
NmCxQfoGRljKsUxU4L5gztN0ni6ibvlDeDfg6A2+Hsv5JqhNq1EoujkRAKAry4jcSDY/pI+7
D4zhyMxx4eH+vEIGq3z1Jvukx9Tm/wKGyW504SKWCBo5LI0jMnfydBY7gQd1wyGlRuYDm77f
mzOXD2VfcMy87jCCAykwggKSoAMCAQICAQwwDQYJKoZIhvcNAQEEBQAwgdExCzAJBgNVBAYT
AlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UE
ChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMg
RGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqG
SIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMDA4MzAwMDAwMDBa
Fw0wMjA4MjkyMzU5NTlaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMMV2VzdGVybiBDYXBl
MRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsGA1UECxMUQ2VydGlm
aWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWlsIFJTQSAyMDAwLjgu
MzAwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAN4zMqZjxwklRT7SbngnZ4HF2ogZgpcO
40QpimM1Km1wPPrcrvfudG8wvDOQf/k0caCjbZjxw0+iZdsN+kvx1t1hpfmFzVWaNRqdknWo
J67Ycvm6AvbXsJHeHOmr4BgDqHxDQlBRh4M88Dm0m1SKE4f/s5udSWYALQmJ7JRr6aFpAgMB
AAGjTjBMMCkGA1UdEQQiMCCkHjAcMRowGAYDVQQDExFQcml2YXRlTGFiZWwxLTI5NzASBgNV
HRMBAf8ECDAGAQH/AgEAMAsGA1UdDwQEAwIBBjANBgkqhkiG9w0BAQQFAAOBgQBzG28mZYv/
FTRLWWKK7US+ScfoDbuPuQ1qJipihB+4h2N0HG23zxpTkUvhzeY42e1Q9DpsNJKs5pKcbsEj
AcIJp+9LrnLdBmf1UG8uWLi2C8FQV7XsHNfvF7bViJu3ooga7TlbOX00/LaWGCVNavSdxcOR
L6mWuAU8Uvzd6WIDSDGCAfUwggHxAgEBMIGaMIGSMQswCQYDVQQGEwJaQTEVMBMGA1UECBMM
V2VzdGVybiBDYXBlMRIwEAYDVQQHEwlDYXBlIFRvd24xDzANBgNVBAoTBlRoYXd0ZTEdMBsG
A1UECxMUQ2VydGlmaWNhdGUgU2VydmljZXMxKDAmBgNVBAMTH1BlcnNvbmFsIEZyZWVtYWls
IFJTQSAyMDAwLjguMzACAwcD6TAJBgUrDgMCGgUAoIGxMBgGCSqGSIb3DQEJAzELBgkqhkiG
9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDQwMzA4MjE0OFowIwYJKoZIhvcNAQkEMRYEFPLR
MKHqXvRRZNShFqTvhnfmUA+/MFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZI
hvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEoMA0GCSqG
SIb3DQEBAQUABIGAtgvHQZE1p4e1VziVSnSky9GAjAPboepE+A0QzTWJDWecd1j1Jx6i1bfK
G1l4LXuRdneKeXpIyb7MEbSQAtvLY8q3A56l32wcGma0whOVjelGIB+VmVtBle/6nDb9vnsy
2cPSyXWNpzUatJe2oj+NGaqvLc2BvgCCApJEZEZGsNw=
--------------msECB7DC067B9673DB81FBEC11--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g337Y3Y09116 for ietf-pkix-bks; Tue, 2 Apr 2002 23:34:03 -0800 (PST)
Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g337Y2m09111 for <[e-mail]>; Tue, 2 Apr 2002 23:34:02 -0800 (PST)
Received: from fwd08.sul.t-online.de  by mailout09.sul.t-online.com with smtp  id 16sfHC-0000uB-05; Wed, 03 Apr 2002 09:33:50 +0200
Received: from junker.stroeder.com (520010731148-0001@[62.224.169.33]) by fmrl08.sul.t-online.com with esmtp id 16sfH2-0xdPbkC; Wed, 3 Apr 2002 09:33:40 +0200
Received: from stroeder.com (junker [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 65377157287; Wed,  3 Apr 2002 09:33:30 +0200 (CEST)
Message-ID: <[e-mail]>
Date: Wed, 03 Apr 2002 09:33:30 +0200
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020310
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Ken Stillson <[e-mail]>
Cc: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax (draft-ietf-pkix-ldap-v3-05.txt)
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Sender: [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>

Ken Stillson wrote:
>   On Mon, 1 Apr 2002, David Chadwick wrote:
> 
>>All constructive comments welcomed
> 
> 
>   Although implied by section 3, perhaps it should be stated expectedly:
> 
>   "A PKI object should be placed into a LDAP directory such that the LDAP
>    object DN matches the subject DN of the object."
> 
>   Although this seems obvious to some, I've run into a surprising number of
>   clients setting up directories using some alternate structure, who are
>   then surprised when validation software can't find certificates given
>   subject DN's.

Ken, for various reasons this old style 1:1 DIT mapping and obtaining the 
certificate chain from a directory never really worked in practice. Maybe in 
some small environments or very specific environments. It also assumes that 
the CA and the LDAP directory are structured and maintained by the same 
authority which is most times not true in e.g. bigger companies.
BTW: Which implementation do exist outside the X.500 world which try to 
obtain the whole certificate chain from a LDAP directory? I do not know a 
single one.

Also think of dc-style naming vs. traditional X521 naming. If you'd like to 
use dc-style naming in your LDAP directory and have that DIT 1:1 in your 
certificate's subject name you will run into many serious interoperability 
problems with PKI enabled software.

Ciao, Michael. (somewhat sick of DIT discussions)



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g3358XH28856 for ietf-pkix-bks; Tue, 2 Apr 2002 21:08:33 -0800 (PST)
Received: from persephone.cfrq.net (persephone.cfrq.net [207.245.2.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g3358Wm28852 for <[e-mail]>; Tue, 2 Apr 2002 21:08:32 -0800 (PST)
Received: from elisabeth.cfrq.net (CPE0020afa1901b.cpe.net.cable.rogers.com [24.43.24.209]) by persephone.cfrq.net (8.11.6/8.11.6) with ESMTP id g3358Jh06633 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 3 Apr 2002 00:08:24 -0500
Received: from elisabeth.cfrq.net (chk@localhost) by elisabeth.cfrq.net (8.11.6/8.11.6) with ESMTP id g3358F113512; Wed, 3 Apr 2002 00:08:16 -0500
To: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax (draft-ietf-pkix-ldap-v3-05.txt) 
References: <[e-mail]>
In-reply-to: stillson's message of "Tue, 02 Apr 2002 15:52:48 -0500". <[e-mail]> 
From: Harald Koch <[e-mail]>
Date: Wed, 03 Apr 2002 00:08:14 -0500
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>

Of all the gin joints in all the towns in all the world, Ken Stillson
had to walk into mine and say:
> 
>   "A PKI object should be placed into a LDAP directory such that the LDAP
>    object DN matches the subject DN of the object."

It's supposed to be the other way around, isn't it? One should issue
certificates with a subject DN that matches the LDAP object DN.

Anyway, there are many environments where a certificate issued by one
organisation must be stored in a directory belonging to another. I don't
believe that an arbitrary restriction like this won't fly.

-- 
Harald Koch     <[e-mail]>


Received: by above.proper.com (8.11.6/8.11.3) id g330DYu23541 for ietf-pkix-bks; Tue, 2 Apr 2002 16:13:34 -0800 (PST)
Received: from aspams52.ca.com (aspams52.cai.com [155.35.248.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g330DXm23536 for <[e-mail]>; Tue, 2 Apr 2002 16:13:33 -0800 (PST)
Received: by aspams52.ca.com with Internet Mail Service (5.5.2655.55) id <H5DC1LXH>; Wed, 3 Apr 2002 10:11:58 +1000
Message-ID: <[e-mail]>
From: "Ramsay, Ron" <[e-mail]>
To: Ken Stillson <[e-mail]>, David Chadwick <[e-mail]>
Cc: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: RE: LDAP Certificate transfer syntax (draft-ietf-pkix-ldap-v3-05. txt)
Date: Wed, 3 Apr 2002 10:13:03 +1000 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2655.55)
Content-Type: text/plain; charset="iso-8859-1"
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>

Ken,

I don't find this at all obvious. Apparently, some company creates
certificates with an email address in the subject DN. This would be horrible
to have to implement in a DIT. (I think the approved method of finding the
principal in this case is to search for an entry where the mail attribute
has this address as a value.)

There is also the case where the same identity has multiple cdrtificates.

Ron.

-----Original Message-----
From: Ken Stillson [mailto:[e-mail]]
Sent: Wednesday, 3 April 2002 6:53
To: David Chadwick
Cc: LDAP BIS; PKIX
Subject: Re: LDAP Certificate transfer syntax
(draft-ietf-pkix-ldap-v3-05.txt)



  On Mon, 1 Apr 2002, David Chadwick wrote:
> All constructive comments welcomed

  Hi David-
  A thought for the you...

  Although implied by section 3, perhaps it should be stated expectedly:

  "A PKI object should be placed into a LDAP directory such that the LDAP
   object DN matches the subject DN of the object."

  Although this seems obvious to some, I've run into a surprising number of
  clients setting up directories using some alternate structure, who are
  then surprised when validation software can't find certificates given
  subject DN's.

    - Ken Stillson


-- 
      |   Ken Stillson             |    [e-mail]    |
      |   Sr. Principal Engineer   |    voice: [phone]    |
      |   Mitretek Systems         |      fax: [phone]    |


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g32MZ8w20808 for ietf-pkix-bks; Tue, 2 Apr 2002 14:35:08 -0800 (PST)
Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g32MZ7m20801 for <[e-mail]>; Tue, 2 Apr 2002 14:35:07 -0800 (PST)
Received: from salford.ac.uk ([213.107.136.218]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Tue, 2 Apr 2002 23:35:09 +0100
Message-ID: <[e-mail]>
Date: Tue, 02 Apr 2002 23:39:05 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Ken Stillson <[e-mail]>
CC: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax (draft-ietf-pkix-ldap-v3-05.txt)
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------F320DF69068B4CA55CA30269"
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.
--------------F320DF69068B4CA55CA30269
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Ken Stillson wrote:
> 
>   On Mon, 1 Apr 2002, David Chadwick wrote:
> > All constructive comments welcomed
> 
>   Hi David-
>   A thought for the you...
> 
>   Although implied by section 3, perhaps it should be stated expectedly:
> 
>   "A PKI object should be placed into a LDAP directory such that the LDAP
>    object DN matches the subject DN of the object."
> 

Ken

whilst I agree with you that this is an obvious thing to do, I dont
believe the ID should say how people should structure their DITs. As
this is a general standard, people are free to structure their DITs in
any way they wish to, and should still be able to use the subschema in
this ID. I think it should rather be a BCP that tells people the best
way to build their directories so that they have the minimum of hassles
operationally. (But I bet it will be difficult to get people to agree on
the contents of the BCP)

David



>   Although this seems obvious to some, I've run into a surprising number of
>   clients setting up directories using some alternate structure, who are
>   then surprised when validation software can't find certificates given
>   subject DN's.
> 
>     - Ken Stillson
> 
> --
>       |   Ken Stillson             |    [e-mail]    |
>       |   Sr. Principal Engineer   |    voice: [phone]    |
>       |   Mitretek Systems         |      fax: [phone]    |

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------F320DF69068B4CA55CA30269
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------F320DF69068B4CA55CA30269--



Received: by above.proper.com (8.11.6/8.11.3) id g32KpAC16818 for ietf-pkix-bks; Tue, 2 Apr 2002 12:51:10 -0800 (PST)
Received: from mtk-mail1.mitretek.org (mtk-mail1.mitretek.org [141.156.156.58]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g32Kp8m16814 for <[e-mail]>; Tue, 2 Apr 2002 12:51:08 -0800 (PST)
Received: from tsf-gw.tsf.mitretek.org ([e-mail] [172.16.17.253]) by mtk-mail1.mitretek.org (8.12.1/8.12.1) with ESMTP id g32KnsGk008678; Tue, 2 Apr 2002 15:49:55 -0500 (EST)
Received: from localhost (stillson@localhost [127.0.0.1]) by tsf-gw.tsf.mitretek.org (8.12.1/8.12.1/Debian -5) with ESMTP id g32Kqm9w011874; Tue, 2 Apr 2002 15:52:51 -0500
Date: Tue, 2 Apr 2002 15:52:48 -0500 (EST)
From: Ken Stillson <[e-mail]>
To: David Chadwick <[e-mail]>
cc: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax (draft-ietf-pkix-ldap-v3-05.txt)
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
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>

  On Mon, 1 Apr 2002, David Chadwick wrote:
> All constructive comments welcomed

  Hi David-
  A thought for the you...

  Although implied by section 3, perhaps it should be stated expectedly:

  "A PKI object should be placed into a LDAP directory such that the LDAP
   object DN matches the subject DN of the object."

  Although this seems obvious to some, I've run into a surprising number of
  clients setting up directories using some alternate structure, who are
  then surprised when validation software can't find certificates given
  subject DN's.

    - Ken Stillson


-- 
      |   Ken Stillson             |    [e-mail]    |
      |   Sr. Principal Engineer   |    voice: [phone]    |
      |   Mitretek Systems         |      fax: [phone]    |



Received: by above.proper.com (8.11.6/8.11.3) id g32Kc0D16415 for ietf-pkix-bks; Tue, 2 Apr 2002 12:38:00 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g32KbXm16410 for <[e-mail]>; Tue, 2 Apr 2002 12:37:38 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA28879; Tue, 2 Apr 2002 20:00:04 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 2 Apr 2002 20:00:04 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA05471; Tue, 2 Apr 2002 20:00:03 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA03750; Tue, 2 Apr 2002 20:00:03 +0200 (MET DST)
Date: Tue, 2 Apr 2002 20:00:03 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
Cc: [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>

> 
> COMMENT 7: Requests shall be able to be authenticated.

At the end of the following exchange you mention that it
is unclear what requirement is being addressed and
what ind of treatment would be done with such an identity
field. The comment is not necessarily related to 
authentication. 

- The requirement is to include the identities of 
  participating parties in the request and in the 
  response, in order to indicate who has participated.

  This is independant of whether this matches with
  some authentication. 

- The treatment is essentially for display purposes
  to be able to describe show the transaction result
  together with the identities with the need to 
  understand a particular way how these information
  can be found in some authnetication envelope.

- Anyway, the response should provide for a means
  to indicate for whom the response has been made,
  not only who has made the response.  
   
Peter

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


[About COMMENT 7]

> - a method that client and server provide their identity
>    in the requests and responses: 'You, the client X, has
>    asked me, the server Y, the following question, and
>    I, the server Y, with the help of server Z respond.'

> This allows to be able to determine the participating entities
> without having access to whatever particular authentication
> method information.

> [Answer 7] Actually, we already include the identity of the server in the
> response. The request could also be optionally signed. This allows 
> the server to authenticate the client, and this authentication allows the 
> server to only support a selective community if desired. An option to be
> able to sign the request may be added.

> The following requirements may be used for example in case of
> validation of an encryption certificate before usage.

There is a difference between authentication and identification.
The request is that the identification is independant from the
authentication methods and the transports. 

A signing entity (the one identified in a signer info or a certificate)
may or may not be the same as the one declared in the request/response.
you may have separation of roles or other situations. 

"The President of the United States declares, ... signed by JWB".

Another example is in relaying as follows: 

Your company service declares that I can use Your encryption cert,
and the response is signed by my local service. 

[Additional Answer 7]

It is unclear what requirement is being addressed and what kind of treatment
would be done with such an identity field.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g32DPjn17837 for ietf-pkix-bks; Tue, 2 Apr 2002 05:25:45 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g32DPgm17830 for <[e-mail]>; Tue, 2 Apr 2002 05:25:43 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA27365; Tue, 2 Apr 2002 15:25:40 +0200 (MET DST)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Tue, 2 Apr 2002 15:25:40 +0200 (MET DST)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA04170; Tue, 2 Apr 2002 15:25:39 +0200 (MET DST)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA03676; Tue, 2 Apr 2002 15:25:39 +0200 (MET DST)
Date: Tue, 2 Apr 2002 15:25:39 +0200 (MET DST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
Cc: [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>

> 
> COMMENT 5: No authentication of the server prior to the sending of the
> request (not done with similar protocols). 
> 
Denis, I think that I may have badly stated the requirement. I 
assume an online connection *and* confidentiality via TLS
done at the transport layer. In this case, confidentiality
would be somewhat meaningless if you don't authenticate the 
server.  Your remark is correct if you think about encryption 
with email, but then you assume that only the server can decrypt,
thus you still have server authentication. 

What similar protocol do you have in mind? (OCSP)?

> COMMENT 6: Confidentiality done at transport level.

Ok, but it is not mentioned in the text. If
properly stated, it resolves COMMENT 5. 

>  
> COMMENT 8: Relaying not supported by the protocol.
>
This is a pity: This was omitted in OCSP, and the risk
of endless loops of two OCSP servers talking to each other
are definitely there. 
Relaying a request to another service is a requirement,
at least in the same way as it is for OCSP. 

But there are two issues:

Why do you think that a DPV response from a server MUST NOT 
contain a DPV response from another server, while on the other
hand it is provided that the server returns all information
concerning the certification path, an revocation information.
What does make DPV responses so different from OCSP reponses
that they would create either additional complexity or harm.

An end user only communicates with his local company
service. The company knows which external CAs can be
trusted, and which service can be contacted.
You already allow to contact OCSP services in this 
way. Where is the difference between DPV and OCSP?  

It may be desirable that an end user may not
directly interface with a remote DPV and needs an
intermediate 'anonymizer' or 'authorized relay'. 

In all such cases there is a danger (like in OCSP)
for endless loops.  

peter

  




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g32DNku17586 for ietf-pkix-bks; Tue, 2 Apr 2002 05:23:46 -0800 (PST)
Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g32DNjm17580 for <[e-mail]>; Tue, 2 Apr 2002 05:23:45 -0800 (PST)
Received: from sit.fraunhofer.de (pc-pisa [141.12.37.18]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with ESMTP id PAA24830; Tue, 2 Apr 2002 15:23:04 +0200 (MET DST)
Message-ID: <[e-mail]>
Date: Tue, 02 Apr 2002 15:24:01 +0200
From: Brian Hunter <[e-mail]>
X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail], [e-mail]
CC: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]>
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>

Hello Denis and Russ,

>      Great work on the new draft!
I concur.

I have one question and a couple of small typographical comments to add.

5. Section 5 Para 4
    This comment goes along with Ambarish's comment 1.  I do not
understand what is meant by "if issued" in the following sentence:
  "The trust anchor self-signed certificate, if issued, is not
included."

Without understanding the "issued" point and assuming that all trust
anchor certificates, self-signed or not, are issued, then I would have
the sentence read:
  "The trust anchor is not included."
Note that I am agreeing with Ambarish that the self-signed requirement
for a root should be dropped.

6. Section 4 Para 11 c)
    "If another request could made later..."
    Suggest to change to: "...could be made..."

7. Section 7 Para 3
    "constrains" -> "constraints"

8. Section 7.1 Para 1
    "build" -> "built"

9. Section 9 Last paragraph point (3)
    Is it intended that the validation time should be adjusted for only
one of the four points, hence the use of "or" after point three? I would
suggest the use of "and".

Regards,
Brian


> 
> A few comments:
> 
> 1. In 2 places you equate the "root" with a self-signed cert. I
> hope you intend to allow the trust anchor to be a non-self-signed
> cert. The 2 places are Para 4 of Section 4 and Para 4 of Section 5.
> 
> 2. Section 4 Para 9
>     You require the DPV server to "obtain" the certificate from the
> reference provided by the client. This is *not* a requirement. If
> the server obtains the certificate by some other means, that is okay,
> as long as it verifies that the certificate is indeed the one
> being referred to by the client.
> 
> 3. Section 4 Para  12
>     In order to prevent replay attacks, you require the nonce to be
> present in the response. As mentioned by Petra, if the response
> contained the request hash, it doesn't need to contain the nonce. It
> is still bound to the request. Present of the request nonce in the
> reply shouldn't be a requirement in this case.
> 
> 4. Section 4 Para 16
>     You require a DPV response to be signed - error response
> might not be signed (e.g. badly formatted request, etc.) Please
> allow for that case.
> 
> That's it!
> 
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Chief Architect                                          650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 1215 Terra Bella Ave.                         http://www.valicert.com
> Mountain View, CA 94043
> 
> > -----Original Message-----
> > From: Tim Polk [mailto:[e-mail]]
> > Sent: Friday, March 29, 2002 2:55 PM
> > To: [e-mail]
> > Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
> >
> >
> >
> > Folks,
> >
> > The editors have informed me that they believe the -03 draft
> > satisfies all
> > WG Last Call comments and meets the criteria of rough
> > consesnsus. My review
> > agrees with their position, and I would like to ship the
> > document to the
> > ADs as soon as possible.
> >
> > If you have a dog in this fight, *please review the specification by
> > Tuesday COB.*  If I do not see any traffic on the list stating that
> > unresolved comments remain, I will forward the document to the ADs
> > Wednesday morning.
> >
> > Thanks,
> >
> > Tim Polk
> >
> > At 07:03 AM 3/29/02 -0500, you 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           : Delegated Path Validation and
> > Delegated Path
> > > Discovery
> > >                           Protocol Requirements (DPV&DPD-REQ)
> > >         Author(s)       : D. Pinkas, R. Housley
> > >         Filename        : draft-ietf-pkix-dpv-dpd-req-03.txt
> > >         Pages           : 11
> > >         Date            : 28-Mar-02
> > >
> > >This document specifies the requirements for Delegated Path
> > Validation
> > >(DPV) and Delegated Path Discovery (DPD) for Public Key Certificates.
> > >It also specifies the requirements for DPV and DPD policy management.
> > >
> > >A URL for this Internet-Draft is:
> > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> > eq-03.txt
> > >
> > >To remove yourself from the IETF Announcement list, send a message to
> > >ietf-announce-request with the word unsubscribe in the body
> > of the message.
> > >
> > >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-dpv-dpd-req-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-dpv-dpd-req-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.
> > >Content-Type: text/plain
> > >Content-ID:     <[e-mail]>
> > >
> > >ENCODING mime
> > >FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
> > >
> > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> > eq-03.txt>
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g329OYn27632 for ietf-pkix-bks; Tue, 2 Apr 2002 01:24:34 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g329OPm27588 for <[e-mail]>; Tue, 2 Apr 2002 01:24:25 -0800 (PST)
Received: from lvn-m002.frlv.bull.fr (lvn-m002.frlv.bull.fr [129.184.62.72]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA18628; Tue, 2 Apr 2002 11:26:44 +0200
Received: from bull.net ([129.184.37.97]) by lvn-m002.frlv.bull.fr (Lotus Domino Release 5.0.8) with ESMTP id 2002040211234561:220 ; Tue, 2 Apr 2002 11:23:45 +0200 
Message-ID: <[e-mail]>
Date: Tue, 02 Apr 2002 11:23:53 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
References: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 02/04/2002 11:23:45, Serialize by Router on LVN-M002/FR/BULL(Release 5.0.8 |June 18, 2001) at 02/04/2002 11:24:17, Serialize complete at 02/04/2002 11:24:17
Content-Transfer-Encoding: 7bit
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>

Mike,

> Tim,
> 
> Two working days seems a bit tight given the breadth of
> comments.  Given that constraint, silence may not necessarily
> concurrence.  It could very well be the effects of our day jobs.
> But that said, I'll see what I can do regarding those comments I
> made.

Since you did not attended the Minneapolis meeting, in order to help you,
here is the disposition of comments that has been presented, with comments
19, 23 and 25 updated.

Denis

Disposition of comments

COMMENT 1: Hash of the request in signed response or important elements of
the request: responses need to include binding to the certificate from the
request.

COMMENT 2: random number repeated in the response.

COMMENT 3: no algorithm requirements.

COMMENT 4: PDP (Policy Definition Requ.) will be in a different document.

COMMENT 5: No authentication of the server prior to the sending of the
request (not done with similar protocols). 

COMMENT 6: Confidentiality done at transport level.

COMMENT 7: Requests shall be able to be authenticated.

COMMENT 8: Relaying not supported by the protocol.

COMMENT 9: Responses are definitive. No later update. 

COMMENT 10: Meaning of time T. It is the time for which the revocation
status is requested by the client. 

COMMENT 11:  For DPV, a reference to a validation policy is mandatory. 
Somevalidation policies may allow for a few user-defined parameters.

COMMENT 12: the server must have the full certificate. In the response
either the full certificate or an unambiguous reference of the certificate
is needed (in case of a CA key compromise). 

COMMENT 13: The client should must verify that the policy used by the server
is appropriate (moved in the security consideration section)

COMMENT 14: Number of states to be returned: two (Yes/No). A reason for the
No has to be returned.  

COMMENT 15: See comment 1.

COMMENT 16: Relates to comment 10. Cautionary period moved in security
consideration section.

COMMENT 17: Idem 16.

COMMENT 18: DSV mention deleted. A DSV Requ. draft will be progressed a soon
as this document is sent to the IESG.

COMMENT 19: Accepted. The paragraph has been deleted.

COMMENTS 20, 21, 22: Editorial. OK.

COMMENT 23 : Accepted. I have added an example for the policy specific
parameters: "e.g. root self-signed certificates".

COMMENT 24 : Editorial. OK.

COMMENT 25 : Since the text will move in a new document about PDP, the
comment is no more relevant to this document.

COMMENT 26 : "The protocol SHALL allow clients to obtain the references for
the default or for all of the policies supported by the server by using an
additional request/response pair".

COMMENT 27 : Addition of Policy Retrieval Protocol (PRP) requirements in the
PDP document (no more relevant for this document).

Note: The requirements only address Public Key Certificates (PKCs).
Attribute Certificates are outside the scope. 
 
> Mike
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]]On Behalf Of Tim Polk
> > Sent: Friday, March 29, 2002 2:55 PM
> > To: [e-mail]
> > Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
> >
> >
> >
> > Folks,
> >
> > The editors have informed me that they believe the
> > -03 draft satisfies all
> > WG Last Call comments and meets the criteria of rough
> > consesnsus. My review
> > agrees with their position, and I would like to ship
> > the document to the
> > ADs as soon as possible.
> >
> > If you have a dog in this fight, *please review the
> > specification by
> > Tuesday COB.*  If I do not see any traffic on the
> > list stating that
> > unresolved comments remain, I will forward the
> > document to the ADs
> > Wednesday morning.
> >
> > Thanks,
> >
> > Tim Polk
> >
> > At 07:03 AM 3/29/02 -0500, you 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           : Delegated Path Validation
> > and Delegated Path
> > > Discovery
> > >                           Protocol Requirements
> > (DPV&DPD-REQ)
> > >         Author(s)       : D. Pinkas, R. Housley
> > >         Filename        : draft-ietf-pkix-dpv-dpd-req-03.txt
> > >         Pages           : 11
> > >         Date            : 28-Mar-02
> > >
> > >This document specifies the requirements for
> > Delegated Path Validation
> > >(DPV) and Delegated Path Discovery (DPD) for Public
> > Key Certificates.
> > >It also specifies the requirements for DPV and DPD
> > policy management.
> > >
> > >A URL for this Internet-Draft is:
> > >http://www.ietf.org/internet-drafts/draft-ietf-pkix-d
> > pv-dpd-req-03.txt
> > >
> > >To remove yourself from the IETF Announcement list,
> > send a message to
> > >ietf-announce-request with the word unsubscribe in
> > the body of the message.
> > >
> > >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-dpv-dpd-req-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-dpv-dpd-req-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.
> > >Content-Type: text/plain
> > >Content-ID:     <[e-mail]>
> > >
> > >ENCODING mime
> > >FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
> > >
> > ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-d
> pv-dpd-req-03.txt>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g31M0KY26537 for ietf-pkix-bks; Mon, 1 Apr 2002 14:00:20 -0800 (PST)
Received: from ext-mail.valicert.com ([66.206.205.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g31M0Km26533 for <[e-mail]>; Mon, 1 Apr 2002 14:00:20 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 1 Apr 2002 13:58:23 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Mon, 01 Apr 2002 13:58:22 -0800 (PST)
Received: by polaris.valicert.com with Internet Mail Service (5.5.2653.19) id <H57039L9>; Mon, 01 Apr 2002 13:59:58 -0800
Content-return: allowed
Date: Mon, 01 Apr 2002 13:59:58 -0800
From: Ambarish Malpani <[e-mail]>
Subject: Comments on draft-ietf-pkix-dpv-dpd-req-03.txt
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
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 Denis, Russ,
     Great work on the new draft!

A few comments:

1. In 2 places you equate the "root" with a self-signed cert. I
hope you intend to allow the trust anchor to be a non-self-signed
cert. The 2 places are Para 4 of Section 4 and Para 4 of Section 5.

2. Section 4 Para 9
    You require the DPV server to "obtain" the certificate from the
reference provided by the client. This is *not* a requirement. If
the server obtains the certificate by some other means, that is okay,
as long as it verifies that the certificate is indeed the one
being referred to by the client.

3. Section 4 Para  12
    In order to prevent replay attacks, you require the nonce to be
present in the response. As mentioned by Petra, if the response
contained the request hash, it doesn't need to contain the nonce. It
is still bound to the request. Present of the request nonce in the
reply shouldn't be a requirement in this case.

4. Section 4 Para 16
    You require a DPV response to be signed - error response
might not be signed (e.g. badly formatted request, etc.) Please
allow for that case.

That's it!

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Chief Architect                                          650.567.5457
ValiCert, Inc.                                  [e-mail]
1215 Terra Bella Ave.                         http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Tim Polk [mailto:[e-mail]]
> Sent: Friday, March 29, 2002 2:55 PM
> To: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-03.txt
> 
> 
> 
> Folks,
> 
> The editors have informed me that they believe the -03 draft 
> satisfies all 
> WG Last Call comments and meets the criteria of rough 
> consesnsus. My review 
> agrees with their position, and I would like to ship the 
> document to the 
> ADs as soon as possible.
> 
> If you have a dog in this fight, *please review the specification by 
> Tuesday COB.*  If I do not see any traffic on the list stating that 
> unresolved comments remain, I will forward the document to the ADs 
> Wednesday morning.
> 
> Thanks,
> 
> Tim Polk
> 
> At 07:03 AM 3/29/02 -0500, you 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           : Delegated Path Validation and 
> Delegated Path 
> > Discovery
> >                           Protocol Requirements (DPV&DPD-REQ)
> >         Author(s)       : D. Pinkas, R. Housley
> >         Filename        : draft-ietf-pkix-dpv-dpd-req-03.txt
> >         Pages           : 11
> >         Date            : 28-Mar-02
> >
> >This document specifies the requirements for Delegated Path 
> Validation
> >(DPV) and Delegated Path Discovery (DPD) for Public Key Certificates.
> >It also specifies the requirements for DPV and DPD policy management.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> eq-03.txt
> >
> >To remove yourself from the IETF Announcement list, send a message to
> >ietf-announce-request with the word unsubscribe in the body 
> of the message.
> >
> >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-dpv-dpd-req-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-dpv-dpd-req-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.
> >Content-Type: text/plain
> >Content-ID:     <[e-mail]>
> >
> >ENCODING mime
> >FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-03.txt
> >
> ><ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-r
> eq-03.txt>
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g31LT3q24641 for ietf-pkix-bks; Mon, 1 Apr 2002 13:29:03 -0800 (PST)
Received: from mta03-svc.ntlworld.com (mta03-svc.ntlworld.com [62.253.162.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g31LT1m24635 for <[e-mail]>; Mon, 1 Apr 2002 13:29:02 -0800 (PST)
Received: from salford.ac.uk ([213.107.136.218]) by mta03-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Mon, 1 Apr 2002 22:29:03 +0100
Message-ID: <[e-mail]>
Date: Mon, 01 Apr 2002 22:32:59 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Subject: Re: LDAP Certificate transfer syntax
References: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------52E1B1843D27887A5872A09B"
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.
--------------52E1B1843D27887A5872A09B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



"Housley, Russ" wrote:
> 
> David:
> 
> Is it possible to preserve the DER encoding.  If not, then the DER encoding
> must be restored in order to validate the signature?  This just seems like
> wasted processing to me.
> 

Russ

I quite agree. The revised text is meant to ensure that the DER or BER
encoding created by the client when the certificate was first sent to
the directory for storage is preserved as is. This is the purpose of the
sentence below in the revised text, viz:

> >Servers must preserve values in this syntax exactly as given when
> >storing and retrieving them.
> >

Perhaps I should say "as given to them by the client, when storing and
retrieving certificates"

David
--------------52E1B1843D27887A5872A09B
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------52E1B1843D27887A5872A09B--



Received: by above.proper.com (8.11.6/8.11.3) id g31GK1N10985 for ietf-pkix-bks; Mon, 1 Apr 2002 08:20:01 -0800 (PST)
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.11.6/8.11.3) with SMTP id g31GJxm10974 for <[e-mail]>; Mon, 1 Apr 2002 08:19:59 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 1 Apr 2002 16:19:07 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.80.211.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA29378; Mon, 1 Apr 2002 11:19:02 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g31GK0A06818; Mon, 1 Apr 2002 11:20:00 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <HKX1NBGJ>; Mon, 1 Apr 2002 11:17:37 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.16.94]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id HKX1NBGG; Mon, 1 Apr 2002 11:17:30 -0500
From: "Housley, Russ" <[e-mail]>
To: David Chadwick <[e-mail]>
Cc: LDAP BIS <[e-mail]>, PKIX <[e-mail]>
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Mon, 01 Apr 2002 11:10:05 -0500
Subject: Re: LDAP Certificate transfer syntax
In-Reply-To: <[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>

David:

Is it possible to preserve the DER encoding.  If not, then the DER encoding 
must be restored in order to validate the signature?  This just seems like 
wasted processing to me.

Russ


At 02:29 PM 4/1/2002 +0100, David Chadwick wrote:
>Colleagues
>
>Here is my proposed change to the section describing the LDAP syntax for
>cerificates in the PKIX id
><draft-pkix-ldap-schema-03.txt> which should be published before the end
>of April. As this is likely to be the most contentious part of the new
>ID, I thought it would be useful to distribute this text at the earlier
>possible moment.
>
>All constructive comments welcomed
>
>David
>
>
>3.3  Certificate Syntax
>
>A value in this transfer syntax is the binary octet string that results
>from BER or DER-encoding of an X.509 public key certificate.  The
>following string states the OID assigned to this syntax:
>
>       ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )
>
>Servers must preserve values in this syntax exactly as given when
>storing and retrieving them.
>
>Note. Due to the changes from X.509(1988) to X.509(1993) and subsequent
>changes to the ASN.1 definition to support certificate extensions in
>X.509(1997), no character string transfer syntax is defined for
>certificates. The BNF notation in RFC 1778 [12] for "User Certificate"
>MUST NOT be used. Values in this syntax MUST be transferred as BER or
>DER encoded octets. The use of the ;binary encoding option, i.e. by
>requesting or returning the attributes with descriptions
>"userCertificate;binary" or "caCertificate;binary" has no effect on the
>transfer syntax.
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g31DPZf26076 for ietf-pkix-bks; Mon, 1 Apr 2002 05:25:35 -0800 (PST)
Received: from mta07-svc.ntlworld.com (mta07-svc.ntlworld.com [62.253.162.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g31DPMm26046 for <[e-mail]>; Mon, 1 Apr 2002 05:25:34 -0800 (PST)
Received: from salford.ac.uk ([213.107.136.218]) by mta07-svc.ntlworld.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <[e-mail]>; Mon, 1 Apr 2002 14:25:12 +0100
Message-ID: <[e-mail]>
Date: Mon, 01 Apr 2002 14:29:06 +0100
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: LDAP BIS <[e-mail]>
CC: PKIX <[e-mail]>
Subject: LDAP Certificate transfer syntax
Content-Type: multipart/mixed; boundary="------------250B008BBD8EA315AC032912"
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.
--------------250B008BBD8EA315AC032912
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Colleagues

Here is my proposed change to the section describing the LDAP syntax for
cerificates in the PKIX id
<draft-pkix-ldap-schema-03.txt> which should be published before the end
of April. As this is likely to be the most contentious part of the new
ID, I thought it would be useful to distribute this text at the earlier
possible moment.

All constructive comments welcomed

David


3.3  Certificate Syntax

A value in this transfer syntax is the binary octet string that results
from BER or DER-encoding of an X.509 public key certificate.  The
following string states the OID assigned to this syntax:

      ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' )

Servers must preserve values in this syntax exactly as given when
storing and retrieving them. 

Note. Due to the changes from X.509(1988) to X.509(1993) and subsequent
changes to the ASN.1 definition to support certificate extensions in
X.509(1997), no character string transfer syntax is defined for
certificates. The BNF notation in RFC 1778 [12] for "User Certificate"
MUST NOT be used. Values in this syntax MUST be transferred as BER or
DER encoded octets. The use of the ;binary encoding option, i.e. by
requesting or returning the attributes with descriptions
"userCertificate;binary" or "caCertificate;binary" has no effect on the
transfer syntax.
--------------250B008BBD8EA315AC032912
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------250B008BBD8EA315AC032912--