RE: OCSP response pre-production

[Paul Hoffman / IMC <[e-mail]>]

At 9:10 PM +0200 9/30/03, Florian Oelmaier wrote:
>  > >I think in the long run this will harm the security of the protocol.
>>  >Major software vendors implementing OCSP-clients have to support
>>  >OCSP caching.
>>
>>  Why? They could just support remembering one bit that says whether or
>>  not the server handles nonces. A setting of "don't send a nonce"
>>  could be cleared every 100 or so requests, leading to an increase of
>>  about 1% of the load for both the client and the server.
>
>I know that this is possible. But I dont think many vendors will do it -
>if you dont write it down into the RfC.

In your earlier message, you said what "major software vendors" had 
to do, and now you are saying what vendors won't do. I was pointing 
out that they didn't have to do what you said, and that they might do 
something else (that I think is sensible for both the vendor and the 
customer).

>  So if you want such a thing to
>happen, just state it in the RfC please.

Yes, it would be good if we put this in as a MAY-level suggestion.

--Paul Hoffman, Director
--Internet Mail Consortium



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UMYFKP091852 for <[e-mail]>; Tue, 30 Sep 2003 15:34:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UMYFFa091851 for ietf-pkix-bks; Tue, 30 Sep 2003 15:34:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UMYAKQ091846; Tue, 30 Sep 2003 15:34:10 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0600201cbb9fb4872da1@[63.202.92.152]>
In-Reply-To: <000301c38786$8e6643e0$4228a8c0@hagen>
References: <000301c38786$8e6643e0$4228a8c0@hagen>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Tue, 30 Sep 2003 15:34:11 -0700
To: "Florian Oelmaier" <[e-mail]>, <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: OCSP response pre-production
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 9:10 PM +0200 9/30/03, Florian Oelmaier wrote:
>  > >I think in the long run this will harm the security of the protocol.
>>  >Major software vendors implementing OCSP-clients have to support
>>  >OCSP caching.
>>
>>  Why? They could just support remembering one bit that says whether or
>>  not the server handles nonces. A setting of "don't send a nonce"
>>  could be cleared every 100 or so requests, leading to an increase of
>>  about 1% of the load for both the client and the server.
>
>I know that this is possible. But I dont think many vendors will do it -
>if you dont write it down into the RfC.

In your earlier message, you said what "major software vendors" had 
to do, and now you are saying what vendors won't do. I was pointing 
out that they didn't have to do what you said, and that they might do 
something else (that I think is sensible for both the vendor and the 
customer).

>  So if you want such a thing to
>happen, just state it in the RfC please.

Yes, it would be good if we put this in as a MAY-level suggestion.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ULROKP089345 for <[e-mail]>; Tue, 30 Sep 2003 14:27:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8ULROVr089344 for ietf-pkix-bks; Tue, 30 Sep 2003 14:27:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ULRNKP089335 for <[e-mail]>; Tue, 30 Sep 2003 14:27:23 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Sep 2003 16:28:27 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: "'Florian Oelmaier'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 16:26:21 -0500
Message-ID: <000f01c38799$81922310$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <000001c38785$cf6a0da0$4228a8c0@hagen>
X-OriginalArrivalTime: 30 Sep 2003 21:28:27.0453 (UTC) FILETIME=[C95C6ED0:01C38799]
Sender: [e-mail]
Precedence: 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 dismiss my previous posting where I question a server generated
nonce to avoid scenario 1.2. I completely agree with Florian's view.

Miguel A Rodriguez
SeguriDATA
Mexico
  
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Tuesday, September 30, 2003 6:26 PM
> > To: [e-mail]
> > Subject: Re: OCSP response pre-production
> >
> >
> >
> > If I may attempt to add my 2 cents, the RFC says that
> >
> > "If nextUpdate is not set, the responder is indicating that
> > newer revocation information is available all the time."
> >
> > The behavior of our (experimental) client currently is:
> >
> > 1) We send a nonce
> > 	1.1) We get a nonce back
> > 		=> We check the nonce
> > 	1.2) We do not get a nonce back
> > 		=> We check "nextUpdate", if absent, we reject, as a
> > 		live responder should really provide a nonce, if present
> > 		we assume the responder is keyless or proxy and we check
> > 		the local clock thingies
> >
> > 2) We do not send a nonce
> > 	Whether we get a nonce back or not.
> > 		=> We check "nextUpdate", if absent, we know very well
> > 		that we could be subject to an replay attack, we decide
> > 		based on user config (I would tend to reject but we
> > 		kinda looked for it...), if present, we also
> > know we could
> > 		be subject to a replay attacka (as in 1.2 actually) but
> > 		about as bad as what we have with CRLs, so we accept
> > 		after checking the local clock thingies
> >
> > If the two sets [Nonce-capable server] and [live servers] are
> > the same and if they are respecting the above RFC quote, the
> > replay attacks seem to be minimized by the above client
> > behavior. Also, we play fairly nicely with keyless and proxy
> > responders.
> >
> > The only thing we really do not accept is a "live" server
> > pretending it is unable to include nonces...
> >
> > Now, the question is whether the distinction between "live"
> > and "caching" servers can actually be made (in real life)
> > from the "nextUpdate" field as indicated by the RFC above quote?
> >
> > --
> > Julien
> >
> >
> > On Tue, Sep 30, 2003 at 08:23:33AM -0700, Ambarish Malpani wrote:
> > >
> > >
> > > Hi Florian, Denis,
> > >     The proposal also adds not-very-desirable semantics to
requests
> > > being made by existing clients.
> > >
> > > All clients today that make requests with nonces expect
> > those nonces
> > > to come back in the response. With the semantics below,
> > todays clients
> > > would be indicating that it is okay to get a response w/o the
nonce.
> > >
> > >
> > > I think we are adding a lot of meaning in the nonce extension. My
> > > original rationale for nonces was to allow a client to force a
> > > response to its request and thus prevent any chance of a
> > reply. This
> > > leaves the options very simple:
> > >
> > > - If you (the client) want a fresh response, include a nonce in
the
> > > request.
> > > - If you don't care whether the response is fresh or not,
> > exclude a nonce
> > > 	in the request (and therefore, don't check to see
> > whether there is a
> > > nonce
> > > 	in the reply or not - the cached response that you get
> > back might
> > > have been
> > > 	generated for an earlier request that did contain a nonce)
> > >
> > > Yes, this doesn't cover all the possible options, but it
> > doesn't add a
> > > lot of complications to the protocol. As a client, if I do want to
> > > support all the cases identified by Florian below, I can
> > still do it -
> > > potentially at the cost of a couple of requests.
> > >
> > > Regards,
> > > Ambarish
> > >
> > >
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of Denis Pinkas
> > > > Sent: Tuesday, September 30, 2003 12:41 AM
> > > > To: Florian Oelmaier
> > > > Cc: [e-mail]
> > > > Subject: Re: OCSP response pre-production
> > > >
> > > >
> > > >
> > > > Florian,
> > > >
> > > > I have no problem with the new flow chart you propose below.
> > > >
> > > > Making the nonce extension critical or not in the request, as
> > > > you propose in
> > > > another e-mail, is a good proposal since it does not involve
> > > > an ASN.1 module
> > > > change (if can avoid a new error code), but only
> > > > "clarifications" in the text.
> > > >
> > > > It has the additional advantage of satisfying the "downgrade
> > > > to cache-only
> > > > iff that is all that is available", as requested by James.
> > > >
> > > > Denis
> > > >
> > > >
> > > > > I think a client should definitely and in every case reject
> > > > a response
> > > > > with a mismatching nonce. This is covered in RfC2560 in its
> > > > > current
> > > > > form: mismatching nonce => reject.
> > > > >
> > > > > So allow me to rephrase again based on your proposal:
> > > > >
> > > > > A) always includes a nonce into his request;
> > > > > B) checks the nonce in the response:
> > > > >
> > > > >      - if it matches with the nonce from the request,
> > then accept
> > > > >        the response (pending other checks),
> > > > >
> > > > >      - if it does not match with the nonce from the
> > request, then
> > > > >        reject the response
> > > > >
> > > > >      - if nonce is not present, then are a local trusted time
> > > > >        available and a policy for cache responses both
> > available ?
> > > > >
> > > > >           - if both a local trusted time is available and
> > > > there exists
> > > > >             a policy for cache responses, then compare the
time
> > > > >             difference between that local trusted clock and
the
> > > > >             producedAt field from ResponseData. If that
> > > > time difference
> > > > >             is below the limit stated by that policy, then
> > > > accept the
> > > > >             response (pending other checks).
> > > > >
> > > > >           - if not, then reject the response.
> > > > >
> > > > >
> > > > > [Additionally we add some checks:
> > > > >
> > > > > i) if nextUpdate is present and is lower than the current date
> > > > > from
> > > > > our trusted clock before sending the request, we
> > detected a clock
> > > > > problem in our "trusted" clocks.
> > > > >
> > > > > ii) if thisUpdate is too old for our limit stated in
> > the policy we
> > > > > reject the answer, too.
> > > > >
> > > > > iii) additionally some sanity checks:
> > > > > thisUpdate<=producedAt<=nextUpdate
> > > > >
> > > > > I have to double check, but I think thats all we do.]
> > > >
> > > >
> > > >
> > >
> > >
> >





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ULJiKP088935 for <[e-mail]>; Tue, 30 Sep 2003 14:19:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8ULJiQl088934 for ietf-pkix-bks; Tue, 30 Sep 2003 14:19:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ULJhKP088928 for <[e-mail]>; Tue, 30 Sep 2003 14:19:43 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 30 Sep 2003 16:19:47 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 16:17:41 -0500
Message-ID: <000e01c38798$4baeee00$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <000001c38785$cf6a0da0$4228a8c0@hagen>
X-OriginalArrivalTime: 30 Sep 2003 21:19:47.0968 (UTC) FILETIME=[93B95000:01C38798]
Sender: [e-mail]
Precedence: 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 also agree with this idea proposed by Julien Stern, checking the
nextUpdate field is a good way of distinguishing fresh responses from
cached or pre-produced ones (in fact I think the date checking makes
sense for this type of responses, with all the clock drift associated
problems, as in the case of CRLs). 

However I object the use of a server generated nonce to avoid condition
1.2 in Julien's statement. How is that different from a replay attack? 

Miguel A Rodriguez
SeguriDATA
Mexico

> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Florian Oelmaier
> Sent: Tuesday, September 30, 2003 2:05 PM
> To: 'Julien Stern'; [e-mail]
> Subject: RE: OCSP response pre-production
> 
> 
> 
> Thanks, Julien!
> 
> First: I love your client behaviour and your nextUpdate checking is
> cool.
> 
> Second: SyTrust ValidationWorks shows a similar behaviour in its
default
> configuration. So I am not alone out there. Hipp Hipp Hurray :)
> 
> We understood the RfC the same way and I like the flexibility of this
> approach.
> 
> And if a responder wants enforce nonce-checking on your client, it can
> simply include a server-generated nonce into all responses. Thus an
> attacker cannot get a response out of this OCSP responder that would
> force your client into 1.2.
> 
> --
> Florian Oelmaier
> SyTrust
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Julien Stern
> > Sent: Tuesday, September 30, 2003 6:26 PM
> > To: [e-mail]
> > Subject: Re: OCSP response pre-production
> >
> >
> >
> > If I may attempt to add my 2 cents, the RFC says that
> >
> > "If nextUpdate is not set, the responder is indicating that
> > newer revocation information is available all the time."
> >
> > The behavior of our (experimental) client currently is:
> >
> > 1) We send a nonce
> > 	1.1) We get a nonce back
> > 		=> We check the nonce
> > 	1.2) We do not get a nonce back
> > 		=> We check "nextUpdate", if absent, we reject, as a
> > 		live responder should really provide a nonce, if present
> > 		we assume the responder is keyless or proxy and we check
> > 		the local clock thingies
> >
> > 2) We do not send a nonce
> > 	Whether we get a nonce back or not.
> > 		=> We check "nextUpdate", if absent, we know very well
> > 		that we could be subject to an replay attack, we decide
> > 		based on user config (I would tend to reject but we
> > 		kinda looked for it...), if present, we also
> > know we could
> > 		be subject to a replay attacka (as in 1.2 actually) but
> > 		about as bad as what we have with CRLs, so we accept
> > 		after checking the local clock thingies
> >
> > If the two sets [Nonce-capable server] and [live servers] are
> > the same and if they are respecting the above RFC quote, the
> > replay attacks seem to be minimized by the above client
> > behavior. Also, we play fairly nicely with keyless and proxy
> > responders.
> >
> > The only thing we really do not accept is a "live" server
> > pretending it is unable to include nonces...
> >
> > Now, the question is whether the distinction between "live"
> > and "caching" servers can actually be made (in real life)
> > from the "nextUpdate" field as indicated by the RFC above quote?
> >
> > --
> > Julien
> >
> >





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UL6gKP088269 for <[e-mail]>; Tue, 30 Sep 2003 14:06:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UL6g8K088268 for ietf-pkix-bks; Tue, 30 Sep 2003 14:06:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UL6fKP088261 for <[e-mail]>; Tue, 30 Sep 2003 14:06:41 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd01.aul.t-online.de  by mailout07.sul.t-online.com with smtp  id 1A4Rhd-0001Uh-0G; Tue, 30 Sep 2003 23:06:37 +0200
Received: from hagen (STUO7EZFreHLX0l-xElAGqwgihWMEx78X9aV-B95fJnTMeWvQCgTkj@[80.128.92.21]) by fmrl01.sul.t-online.com with esmtp id 1A4RhZ-1x3MsS0; Tue, 30 Sep 2003 23:06:33 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 23:06:34 +0200
Organization: SyTrust
Message-ID: <000101c38796$bae09370$4228a8c0@hagen>
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
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-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>

> Michael Myers
> -------------
> > > The core issue is absolute certainty at the relying
> > > party (i.e. client-side) whether or not their nonce
> > > will be respected.
> 
> Florian Oelmaier
> ----------------
> > Dont try to explain a political decision with
> > technical issues.
> 
> 
> Florian,
> 
> Secure acquisition of the revocation status of a certified 
> public key is not a political issue.
> 

Sorry Mike. I was too emotional about that "political" thing. I hope you
accept my sincere apologies.

On the technical side: I also was to fast with my agreement to your
proposal. Seeing that OCSP-Errorcodes are not signed, I cannot find the
benefit in your proposal. Maybe I miss something - but it seems to offer
only little advantage at significant cost.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UKrRKP087764 for <[e-mail]>; Tue, 30 Sep 2003 13:53:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UKrRqw087763 for ietf-pkix-bks; Tue, 30 Sep 2003 13:53:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UKrQKP087758 for <[e-mail]>; Tue, 30 Sep 2003 13:53:26 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8UKrPt83722; Tue, 30 Sep 2003 13:53:25 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 13:56: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)
In-Reply-To: <000001c38790$4506f4b0$4228a8c0@hagen>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Myers
-------------
> > The core issue is absolute certainty at the relying
> > party (i.e. client-side) whether or not their nonce
> > will be respected.

Florian Oelmaier
----------------
> Dont try to explain a political decision with
> technical issues.


Florian,

Secure acquisition of the revocation status of a certified
public key is not a political issue.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UKKTKP086448 for <[e-mail]>; Tue, 30 Sep 2003 13:20:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UKKTYL086447 for ietf-pkix-bks; Tue, 30 Sep 2003 13:20:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UKKRKP086441 for <[e-mail]>; Tue, 30 Sep 2003 13:20:27 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd01.aul.t-online.de  by mailout09.sul.t-online.com with smtp  id 1A4Qyy-0001lZ-04; Tue, 30 Sep 2003 22:20:28 +0200
Received: from hagen (T5hovrZFYeU-YOVVrv2-tqBfuATzUmdu4VewEFmpauHGgaAB326YrT@[80.128.92.21]) by fmrl01.sul.t-online.com with esmtp id 1A4Qyp-1zNSVM0; Tue, 30 Sep 2003 22:20:19 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 22:20:19 +0200
Organization: SyTrust
Message-ID: <000001c38790$4506f4b0$4228a8c0@hagen>
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
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-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>

> As for the performance penalty of a few more messages, that 
> will happen regardless of how we resolve this due to having 
> to runtime determine server-side nonce capability.

Technically it IS possible to resolve the issue without performace or
network load penalty.

> The core issue is absolute certainty at the relying party (i.e.
> client-side) whether or not their nonce will be respected.  

Dont try to explain a political decision with technical issues. You
could do *EXACTLY* the same a lot more easy! Lets compare the new
proposal and the "old" way of doing things:

Situation: A client sends a request with nonce. The responder is not
able to generate nonces.

New: The responder has to send "NonceNotAccepted".
Old: Responder sends a nonce-less response.

The client has to decide if it wants to have a nonce-less response in
every case.

If no: 
New: The client cannot get a suitable response.
Old: The client cannot get a suitable response.

If yes:
New: Client sends a second request to get a nonce-less response.
Old: Client is able to use the response. 

So NO - this change is not about the client-side. Actually it only makes
client programming more complex. Nothing more, nothing less.

It is also NOT about security. Seeing that Error-Messages are NOT SIGNED
in OCSP, a man-in-the-middle could construct a "NonceNotAccepted"-error
response to a request, then intercept the next request without nonce and
replay a previously recorded response without nonce. Thus our responder
will (due to security reasons) continue to generate server-side nonces
to prevent such an attack scenario. 

So is it about the responder? Lets examine what will happen at the
responder:
- Developers of caching responders need to add an additional response
code. (BTW: Thus extension processing is not optional anymore within
OCSP-Responders - not even within dumb cache-replying machines)
- There is more load for the OCSP Responder to handle

There is only one advantage I can see: If I am a developer of a
non-caching proxy, I dont have to change my code :) 

So this IS a purely politicaly motivated change, not bringing any
security benefit but setting OCSP technically back. If you want me to
repeat my alternate proposal, send me a private mail :)

> > To summarize: I dont like it, but if this is the best
> > thing we can do from a political point of view - lets do it.
> 
> 
> I think we should too.  Am waiting for consensus.
 
And dont mistake me: I think we should find a better solution. Reading
my own analysis above, I think we should simply leave RfC2560 as it is
now. I hate myself for bringing up all that stuff :)

-- 
Florian Oelmaier
SyTrust




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UJB9KP083208 for <[e-mail]>; Tue, 30 Sep 2003 12:11:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UJB9IG083207 for ietf-pkix-bks; Tue, 30 Sep 2003 12:11:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UJB7KP083200; Tue, 30 Sep 2003 12:11:07 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd01.aul.t-online.de  by mailout08.sul.t-online.com with smtp  id 1A4Ptr-0002Zl-01; Tue, 30 Sep 2003 21:11:07 +0200
Received: from hagen (rCO3yBZUZe3oQ9zL2GRsxOgDC2A3c8rOCE4OlRFf-dlzYKdrvR0PE7@[80.128.92.21]) by fmrl01.sul.t-online.com with esmtp id 1A4PtX-1RzwQa0; Tue, 30 Sep 2003 21:10:47 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 21:10:47 +0200
Organization: SyTrust
Message-ID: <000301c38786$8e6643e0$4228a8c0@hagen>
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
Importance: Normal
In-Reply-To: <p06002018bb9f7b02b26d@[63.202.92.152]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >I think in the long run this will harm the security of the protocol.
> >Major software vendors implementing OCSP-clients have to support 
> >OCSP caching.
> 
> Why? They could just support remembering one bit that says whether or 
> not the server handles nonces. A setting of "don't send a nonce" 
> could be cleared every 100 or so requests, leading to an increase of 
> about 1% of the load for both the client and the server.

I know that this is possible. But I dont think many vendors will do it -
if you dont write it down into the RfC. So if you want such a thing to
happen, just state it in the RfC please.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UJ5rKP083049 for <[e-mail]>; Tue, 30 Sep 2003 12:05:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UJ5rwV083048 for ietf-pkix-bks; Tue, 30 Sep 2003 12:05:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UJ5pKP083043 for <[e-mail]>; Tue, 30 Sep 2003 12:05:51 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd01.aul.t-online.de  by mailout02.sul.t-online.com with smtp  id 1A4Pod-0000Rg-05; Tue, 30 Sep 2003 21:05:43 +0200
Received: from hagen (XpqtGcZHrebKE6JQ8bi-e02JlNTYLkdhfhyP0113r5bU+e-Xl9LFYL@[80.128.92.21]) by fmrl01.sul.t-online.com with esmtp id 1A4PoN-27Iqu00; Tue, 30 Sep 2003 21:05:27 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 21:05:26 +0200
Organization: SyTrust
Message-ID: <000001c38785$cf6a0da0$4228a8c0@hagen>
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
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-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>

Thanks, Julien!

First: I love your client behaviour and your nextUpdate checking is
cool. 

Second: SyTrust ValidationWorks shows a similar behaviour in its default
configuration. So I am not alone out there. Hipp Hipp Hurray :)

We understood the RfC the same way and I like the flexibility of this
approach.

And if a responder wants enforce nonce-checking on your client, it can
simply include a server-generated nonce into all responses. Thus an
attacker cannot get a response out of this OCSP responder that would
force your client into 1.2.

-- 
Florian Oelmaier
SyTrust

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Julien Stern
> Sent: Tuesday, September 30, 2003 6:26 PM
> To: [e-mail]
> Subject: Re: OCSP response pre-production
> 
> 
> 
> If I may attempt to add my 2 cents, the RFC says that
> 
> "If nextUpdate is not set, the responder is indicating that 
> newer revocation information is available all the time."
> 
> The behavior of our (experimental) client currently is:
> 
> 1) We send a nonce
> 	1.1) We get a nonce back
> 		=> We check the nonce
> 	1.2) We do not get a nonce back
> 		=> We check "nextUpdate", if absent, we reject, as a
> 		live responder should really provide a nonce, if present
> 		we assume the responder is keyless or proxy and we check
> 		the local clock thingies
> 
> 2) We do not send a nonce
> 	Whether we get a nonce back or not.
> 		=> We check "nextUpdate", if absent, we know very well
> 		that we could be subject to an replay attack, we decide
> 		based on user config (I would tend to reject but we
> 		kinda looked for it...), if present, we also 
> know we could
> 		be subject to a replay attacka (as in 1.2 actually) but
> 		about as bad as what we have with CRLs, so we accept
> 		after checking the local clock thingies
> 
> If the two sets [Nonce-capable server] and [live servers] are 
> the same and if they are respecting the above RFC quote, the 
> replay attacks seem to be minimized by the above client 
> behavior. Also, we play fairly nicely with keyless and proxy 
> responders.
> 
> The only thing we really do not accept is a "live" server 
> pretending it is unable to include nonces...
> 
> Now, the question is whether the distinction between "live" 
> and "caching" servers can actually be made (in real life) 
> from the "nextUpdate" field as indicated by the RFC above quote?
> 
> --
> Julien
> 
> 
> On Tue, Sep 30, 2003 at 08:23:33AM -0700, Ambarish Malpani wrote:
> > 
> > 
> > Hi Florian, Denis,
> >     The proposal also adds not-very-desirable semantics to requests 
> > being made by existing clients.
> > 
> > All clients today that make requests with nonces expect 
> those nonces 
> > to come back in the response. With the semantics below, 
> todays clients 
> > would be indicating that it is okay to get a response w/o the nonce.
> > 
> > 
> > I think we are adding a lot of meaning in the nonce extension. My 
> > original rationale for nonces was to allow a client to force a 
> > response to its request and thus prevent any chance of a 
> reply. This 
> > leaves the options very simple:
> > 
> > - If you (the client) want a fresh response, include a nonce in the 
> > request.
> > - If you don't care whether the response is fresh or not, 
> exclude a nonce
> > 	in the request (and therefore, don't check to see 
> whether there is a
> > nonce
> > 	in the reply or not - the cached response that you get 
> back might
> > have been
> > 	generated for an earlier request that did contain a nonce)
> > 
> > Yes, this doesn't cover all the possible options, but it 
> doesn't add a 
> > lot of complications to the protocol. As a client, if I do want to 
> > support all the cases identified by Florian below, I can 
> still do it - 
> > potentially at the cost of a couple of requests.
> > 
> > Regards,
> > Ambarish
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Denis Pinkas
> > > Sent: Tuesday, September 30, 2003 12:41 AM
> > > To: Florian Oelmaier
> > > Cc: [e-mail]
> > > Subject: Re: OCSP response pre-production
> > > 
> > > 
> > > 
> > > Florian,
> > > 
> > > I have no problem with the new flow chart you propose below.
> > > 
> > > Making the nonce extension critical or not in the request, as
> > > you propose in 
> > > another e-mail, is a good proposal since it does not involve 
> > > an ASN.1 module 
> > > change (if can avoid a new error code), but only 
> > > "clarifications" in the text.
> > > 
> > > It has the additional advantage of satisfying the "downgrade
> > > to cache-only 
> > > iff that is all that is available", as requested by James.
> > > 
> > > Denis
> > > 
> > > 
> > > > I think a client should definitely and in every case reject
> > > a response
> > > > with a mismatching nonce. This is covered in RfC2560 in its 
> > > > current
> > > > form: mismatching nonce => reject.
> > > > 
> > > > So allow me to rephrase again based on your proposal:
> > > > 
> > > > A) always includes a nonce into his request;
> > > > B) checks the nonce in the response:
> > > > 
> > > >      - if it matches with the nonce from the request, 
> then accept
> > > >        the response (pending other checks),
> > > > 
> > > >      - if it does not match with the nonce from the 
> request, then
> > > >        reject the response
> > > > 
> > > >      - if nonce is not present, then are a local trusted time 
> > > >        available and a policy for cache responses both 
> available ?
> > > >  
> > > >           - if both a local trusted time is available and
> > > there exists
> > > >             a policy for cache responses, then compare the time
> > > >             difference between that local trusted clock and the
> > > >             producedAt field from ResponseData. If that
> > > time difference
> > > >             is below the limit stated by that policy, then
> > > accept the
> > > >             response (pending other checks).
> > > > 
> > > >           - if not, then reject the response.
> > > > 
> > > > 
> > > > [Additionally we add some checks:
> > > > 
> > > > i) if nextUpdate is present and is lower than the current date 
> > > > from
> > > > our trusted clock before sending the request, we 
> detected a clock 
> > > > problem in our "trusted" clocks.
> > > > 
> > > > ii) if thisUpdate is too old for our limit stated in 
> the policy we
> > > > reject the answer, too.
> > > > 
> > > > iii) additionally some sanity checks:
> > > > thisUpdate<=producedAt<=nextUpdate
> > > > 
> > > > I have to double check, but I think thats all we do.]
> > > 
> > > 
> > > 
> > 
> > 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UIeQKP081573 for <[e-mail]>; Tue, 30 Sep 2003 11:40:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UIeQaA081571 for ietf-pkix-bks; Tue, 30 Sep 2003 11:40:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UIePKP081566 for <[e-mail]>; Tue, 30 Sep 2003 11:40:25 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8UIeOt77792; Tue, 30 Sep 2003 11:40:24 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 11:43:51 -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 V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Florian,

Responses embedded below.

Mike



> -----Original Message-----
> From: Florian Oelmaier [mailto:[e-mail]]
> Sent: Tuesday, September 30, 2003 10:45 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: RE: OCSP response pre-production
>
>
> Michael,
>
> Let me test my understanding. You are basically
> proposing: "Clients that would like to get a nonce
> but would also accept a response without nonce, have
> to send two requests if the responder does not
> support nonces".


We needed an error case anyway.  The question is what happens
when an error msg is received.


> I think in the long run this will harm the security
> of the protocol. Major software vendors implementing
> OCSP-clients have to support OCSP caching. You are
> telling the client vendor: In the high volume case
> you have to send two OCSP-requests, in the high
> security case one is sufficient. These major vendors
> will not be ready to send two requests (or are you,
> Ryan?) - thus they will not include a nonce at first.
> This way nonces will be a security tool for certain
> special cases and special clients. Major clients will
> not incorporate any nonces.


Well, there's high-volume vendors and then there's configuration
settings. I suspect Ryan won't have any problems with (7)
noncesNotAccepted.


> Additionally you are telling all the people using
> caching reponders out there: Make yourself ready,
> there will be some additional requests. Having to
> answer with an error at first, only to get a second
> request moments later - that's not really a good
> thing in high-performance situations.


Agree, but far better than signing engines all over the place or
making one's master signing server directly available to
Internet traffic.


> I would guess that some of our client installations
> would cease to use nonces with this changes at all -
> in fact I think I would change our default in the
> client to not include nonces (so I can support
> caching responders without getting the performance penalty).


Yet those clients *can* be configured in accordance with local
security policy, should that change post-install, and yet remain
deterministically interoperable.  This keeps nonces fully in
play.

As for the performance penalty of a few more messages, that will
happen regardless of how we resolve this due to having to
runtime determine server-side nonce capability.


> One could think of technically better solutions at
> the same security level. We could make the
> nonce-security a reality for all clients and let the
> responders decide if they can or cannot answer
> without additional network or performance load. I
> think we are barking up the wrong tree.


The core issue is absolute certainty at the relying party (i.e.
client-side) whether or not their nonce will be respected.  If
not, the RP can then make a security decision to accept the
increased risk of not using nonces.


> To summarize: I dont like it, but if this is the best
> thing we can do from a political point of view - lets do it.


I think we should too.  Am waiting for consensus.

Mike


>
> --
> Florian Oelmaier
> SyTrust
>
>
> On Tue, 30 Sep 2003 08:08:03 -0700, "Michael Myers"
> <[e-mail]> wrote :
>
> >
> > All,
> >
> > I was talking to some folks offlist on this subject
> yesterday
> > and thought I might ask if it's possible we could
> all get behind
> > the following simple fix.
> >
> >
> > SYNTAX:     Expand v1 OCSPResponseStatus syntax to
> >             include (7) noncesNotAccepted.
> >
> >
> > SEMANTICS:  Responders SHOULD respond back with the
> >             requestor's nonce but if can't then SHALL
> >             respond with an error message of the value
> >             noncesNotAccepted.
> >
> >             Requestors SHALL reject signed responses
> >             that fail to incorporate a supplied nonce.
> >
> >             Upon receipt of noncesNotRequired, requestors
> >             MAY retry the request without using a nonce.
> >             Requestors are STRONGLY ADVISED that doing
> >             so MAY subject them to additional risk.
> >
> > Thus, essentially, requestors can set "nonce
> always" but if they
> > want to they can have that overridden on a
> per-request basis.
> >
> > Opinions?
> >
> > Mike
> >
> >
> >
> >
> >
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UIRuKP081057 for <[e-mail]>; Tue, 30 Sep 2003 11:27:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UIRujp081056 for ietf-pkix-bks; Tue, 30 Sep 2003 11:27:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UIRpKQ081051; Tue, 30 Sep 2003 11:27:52 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002018bb9f7b02b26d@[63.202.92.152]>
In-Reply-To: <[e-mail]>
References: <> <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Tue, 30 Sep 2003 11:27:52 -0700
To: "Florian Oelmaier" <[e-mail]>, <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: OCSP response pre-production
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 5:45 PM +0000 9/30/03, Florian Oelmaier wrote:
>I think in the long run this will harm the security of the protocol. 
>Major software vendors implementing OCSP-clients have to support 
>OCSP caching.

Why? They could just support remembering one bit that says whether or 
not the server handles nonces. A setting of "don't send a nonce" 
could be cleared every 100 or so requests, leading to an increase of 
about 1% of the load for both the client and the server.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UHjRKP079099 for <[e-mail]>; Tue, 30 Sep 2003 10:45:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UHjRP6079098 for ietf-pkix-bks; Tue, 30 Sep 2003 10:45:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8UHjPKP079092 for <[e-mail]>; Tue, 30 Sep 2003 10:45:25 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 768 invoked by uid 1649); 30 Sep 2003 17:45:26 -0000
Date: 30 Sep 2003 17:45:26 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: <[e-mail]>
CC: [e-mail]
Subject: RE: OCSP response pre-production
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
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>

Michael,

Let me test my understanding. You are basically proposing: "Clients that would like to get a nonce but would also accept a response without nonce, have to send two requests if the responder does not support nonces".

I think in the long run this will harm the security of the protocol. Major software vendors implementing OCSP-clients have to support OCSP caching. You are telling the client vendor: In the high volume case you have to send two OCSP-requests, in the high security case one is sufficient. These major vendors will not be ready to send two requests (or are you, Ryan?) - thus they will not include a nonce at first. This way nonces will be a security tool for certain special cases and special clients. Major clients will not incorporate any nonces. 

Additionally you are telling all the people using caching reponders out there: Make yourself ready, there will be some additional requests. Having to answer with an error at first, only to get a second request moments later - that's not really a good thing in high-performance situations.

I would guess that some of our client installations would cease to use nonces with this changes at all - in fact I think I would change our default in the client to not include nonces (so I can support caching responders without getting the performance penalty).

One could think of technically better solutions at the same security level. We could make the nonce-security a reality for all clients and let the responders decide if they can or cannot answer without additional network or performance load. I think we are barking up the wrong tree. 

To summarize: I dont like it, but if this is the best thing we can do from a political point of view - lets do it.

-- 
Florian Oelmaier
SyTrust


On Tue, 30 Sep 2003 08:08:03 -0700, "Michael Myers" <[e-mail]> wrote :

> 
> All,
> 
> I was talking to some folks offlist on this subject yesterday
> and thought I might ask if it's possible we could all get behind
> the following simple fix.
> 
> 
> SYNTAX:     Expand v1 OCSPResponseStatus syntax to
>             include (7) noncesNotAccepted.
> 
> 
> SEMANTICS:  Responders SHOULD respond back with the
>             requestor's nonce but if can't then SHALL
>             respond with an error message of the value
>             noncesNotAccepted.
> 
>             Requestors SHALL reject signed responses
>             that fail to incorporate a supplied nonce.
> 
>             Upon receipt of noncesNotRequired, requestors
>             MAY retry the request without using a nonce.
>             Requestors are STRONGLY ADVISED that doing
>             so MAY subject them to additional risk.
> 
> Thus, essentially, requestors can set "nonce always" but if they
> want to they can have that overridden on a per-request basis.
> 
> Opinions?
> 
> Mike
> 
> 
> 
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UHQZKP078283 for <[e-mail]>; Tue, 30 Sep 2003 10:26:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UHQYFC078282 for ietf-pkix-bks; Tue, 30 Sep 2003 10:26:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UHQXKP078276 for <[e-mail]>; Tue, 30 Sep 2003 10:26:33 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8UHQYt74094; Tue, 30 Sep 2003 10:26:34 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 10:30:02 -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: <004a01c38771$d0476560$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ambarish,

Good.

I think I said the same thing as (a) but we can work on the
exact languange.

As for (b), I guess we'll first have to see if this new proposed
text goes forward more or less as written.  If so, then
unilateral server-side nonces are by definition non-conformant
due to the absence of any normative text associated with the
practice.  In which case I see no reason to discuss
non-conformant behavior.

Mike

> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Tuesday, September 30, 2003 9:42 AM
> To: 'Michael Myers'; [e-mail]
> Subject: RE: OCSP response pre-production
>
>
>
> I agree with the statements below.
>
> Mike, we should also add some statements of correct
> client behavior.
>
> My thoughts:
>     (a) If a client makes a request with a nonce, it
> MUST reject
> 		 a response that doesn't include the same nonce.
>     (b) If a client makes a request without a nonce,
> it MUST ignore the
> 		nonce extension in the response (it
> doesn't matter if there
> 		is a nonce in the reply or not, because
> the server might be
> 		returning a cached response produced in
> response to a
> previous
> 		request that was made with a nonce -
> although that wouldn't
> be
> 		the behavior of a regular http proxy).
>
>
>
> Ambarish
>
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of
> Michael Myers
> > Sent: Tuesday, September 30, 2003 8:08 AM
> > To: [e-mail]
> > Subject: RE: OCSP response pre-production
> >
> >
> >
> > All,
> >
> > I was talking to some folks offlist on this subject
> yesterday
> > and thought I might ask if it's possible we could all get
> > behind the following simple fix.
> >
> >
> > SYNTAX:     Expand v1 OCSPResponseStatus syntax to
> >             include (7) noncesNotAccepted.
> >
> >
> > SEMANTICS:  Responders SHOULD respond back with the
> >             requestor's nonce but if can't then SHALL
> >             respond with an error message of the value
> >             noncesNotAccepted.
> >
> >             Requestors SHALL reject signed responses
> >             that fail to incorporate a supplied nonce.
> >
> >             Upon receipt of noncesNotRequired, requestors
> >             MAY retry the request without using a nonce.
> >             Requestors are STRONGLY ADVISED that doing
> >             so MAY subject them to additional risk.
> >
> > Thus, essentially, requestors can set "nonce always" but if
> > they want to they can have that overridden on a
> per-request basis.
> >
> > Opinions?
> >
> > Mike
> >
> >
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UGgTKP075681 for <[e-mail]>; Tue, 30 Sep 2003 09:42:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UGgTCc075680 for ietf-pkix-bks; Tue, 30 Sep 2003 09:42:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UGgTKP075673 for <[e-mail]>; Tue, 30 Sep 2003 09:42:29 -0700 (PDT) (envelope-from [e-mail])
Received: from AMBARISHW2K (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id h8UGgI4c032143; Tue, 30 Sep 2003 09:42:19 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 09:42:18 -0700
Message-ID: <004a01c38771$d0476560$[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, Build 10.0.4510
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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 the statements below.

Mike, we should also add some statements of correct client behavior.

My thoughts:
    (a) If a client makes a request with a nonce, it MUST reject
		 a response that doesn't include the same nonce.
    (b) If a client makes a request without a nonce, it MUST ignore the
		nonce extension in the response (it doesn't matter if there
		is a nonce in the reply or not, because the server might be
		returning a cached response produced in response to a
previous
		request that was made with a nonce - although that wouldn't
be
		the behavior of a regular http proxy).



Ambarish

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Michael Myers
> Sent: Tuesday, September 30, 2003 8:08 AM
> To: [e-mail]
> Subject: RE: OCSP response pre-production
> 
> 
> 
> All,
> 
> I was talking to some folks offlist on this subject yesterday 
> and thought I might ask if it's possible we could all get 
> behind the following simple fix.
> 
> 
> SYNTAX:     Expand v1 OCSPResponseStatus syntax to
>             include (7) noncesNotAccepted.
> 
> 
> SEMANTICS:  Responders SHOULD respond back with the
>             requestor's nonce but if can't then SHALL
>             respond with an error message of the value
>             noncesNotAccepted.
> 
>             Requestors SHALL reject signed responses
>             that fail to incorporate a supplied nonce.
> 
>             Upon receipt of noncesNotRequired, requestors
>             MAY retry the request without using a nonce.
>             Requestors are STRONGLY ADVISED that doing
>             so MAY subject them to additional risk.
> 
> Thus, essentially, requestors can set "nonce always" but if 
> they want to they can have that overridden on a per-request basis.
> 
> Opinions?
> 
> Mike
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UGQQKP074908 for <[e-mail]>; Tue, 30 Sep 2003 09:26:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UGQQWi074907 for ietf-pkix-bks; Tue, 30 Sep 2003 09:26:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-102-tuesday.noc.nerim.net [62.4.17.102]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UGQOKP074899 for <[e-mail]>; Tue, 30 Sep 2003 09:26:25 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 10F6862D4F for <[e-mail]>; Tue, 30 Sep 2003 18:26:16 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 43DE940A6 for <[e-mail]>; Tue, 30 Sep 2003 18:26:17 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 28109-02 for <[e-mail]>; Tue, 30 Sep 2003 18:26:17 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 0237E409E for <[e-mail]>; Tue, 30 Sep 2003 18:26:17 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Tue, 30 Sep 2003 18:26:16 +0200
From: "Julien Stern" <[e-mail]>
Date: Tue, 30 Sep 2003 18:26:16 +0200
To: [e-mail]
Subject: Re: OCSP response pre-production
Message-ID: <[e-mail]>
References: <[e-mail]> <003a01c38766$d0369d80$[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <003a01c38766$d0369d80$[e-mail]>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

If I may attempt to add my 2 cents, the RFC says that

"If nextUpdate is not set, the responder is indicating that newer
revocation information is available all the time."

The behavior of our (experimental) client currently is:

1) We send a nonce
	1.1) We get a nonce back
		=> We check the nonce
	1.2) We do not get a nonce back
		=> We check "nextUpdate", if absent, we reject, as a
		live responder should really provide a nonce, if present
		we assume the responder is keyless or proxy and we check
		the local clock thingies

2) We do not send a nonce
	Whether we get a nonce back or not.
		=> We check "nextUpdate", if absent, we know very well
		that we could be subject to an replay attack, we decide
		based on user config (I would tend to reject but we
		kinda looked for it...), if present, we also know we could
		be subject to a replay attacka (as in 1.2 actually) but
		about as bad as what we have with CRLs, so we accept
		after checking the local clock thingies

If the two sets [Nonce-capable server] and [live servers] are the
same and if they are respecting the above RFC quote, the replay attacks
seem to be minimized by the above client behavior. Also, we play fairly
nicely with keyless and proxy responders.

The only thing we really do not accept is a "live" server pretending
it is unable to include nonces...

Now, the question is whether the distinction between "live" and
"caching" servers can actually be made (in real life) from the
"nextUpdate" field as indicated by the RFC above quote?

--
Julien


On Tue, Sep 30, 2003 at 08:23:33AM -0700, Ambarish Malpani wrote:
> 
> 
> Hi Florian, Denis,
>     The proposal also adds not-very-desirable semantics to requests
> being made by existing clients.
> 
> All clients today that make requests with nonces expect those nonces to
> come back in the response. With the semantics below, todays clients would
> be indicating that it is okay to get a response w/o the nonce.
> 
> 
> I think we are adding a lot of meaning in the nonce extension. My original
> rationale for nonces was to allow a client to force a response to its
> request
> and thus prevent any chance of a reply. This leaves the options very simple:
> 
> - If you (the client) want a fresh response, include a nonce in the request.
> - If you don't care whether the response is fresh or not, exclude a nonce
> 	in the request (and therefore, don't check to see whether there is a
> nonce
> 	in the reply or not - the cached response that you get back might
> have been
> 	generated for an earlier request that did contain a nonce)
> 
> Yes, this doesn't cover all the possible options, but it doesn't add a lot
> of complications to the protocol. As a client, if I do want to support all
> the cases identified by Florian below, I can still do it - potentially at
> the
> cost of a couple of requests.
> 
> Regards,
> Ambarish
> 
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Denis Pinkas
> > Sent: Tuesday, September 30, 2003 12:41 AM
> > To: Florian Oelmaier
> > Cc: [e-mail]
> > Subject: Re: OCSP response pre-production
> > 
> > 
> > 
> > Florian,
> > 
> > I have no problem with the new flow chart you propose below.
> > 
> > Making the nonce extension critical or not in the request, as 
> > you propose in 
> > another e-mail, is a good proposal since it does not involve 
> > an ASN.1 module 
> > change (if can avoid a new error code), but only 
> > "clarifications" in the text.
> > 
> > It has the additional advantage of satisfying the "downgrade 
> > to cache-only 
> > iff that is all that is available", as requested by James.
> > 
> > Denis
> > 
> > 
> > > I think a client should definitely and in every case reject 
> > a response 
> > > with a mismatching nonce. This is covered in RfC2560 in its current
> > > form: mismatching nonce => reject.
> > > 
> > > So allow me to rephrase again based on your proposal:
> > > 
> > > A) always includes a nonce into his request;
> > > B) checks the nonce in the response:
> > > 
> > >      - if it matches with the nonce from the request, then accept
> > >        the response (pending other checks),
> > > 
> > >      - if it does not match with the nonce from the request, then
> > >        reject the response
> > > 
> > >      - if nonce is not present, then are a local trusted time 
> > >        available and a policy for cache responses both available ?
> > >  
> > >           - if both a local trusted time is available and 
> > there exists
> > >             a policy for cache responses, then compare the time
> > >             difference between that local trusted clock and the
> > >             producedAt field from ResponseData. If that 
> > time difference
> > >             is below the limit stated by that policy, then 
> > accept the
> > >             response (pending other checks).
> > > 
> > >           - if not, then reject the response.
> > > 
> > > 
> > > [Additionally we add some checks:
> > > 
> > > i) if nextUpdate is present and is lower than the current date from 
> > > our trusted clock before sending the request, we detected a clock 
> > > problem in our "trusted" clocks.
> > > 
> > > ii) if thisUpdate is too old for our limit stated in the policy we 
> > > reject the answer, too.
> > > 
> > > iii) additionally some sanity checks: 
> > > thisUpdate<=producedAt<=nextUpdate
> > > 
> > > I have to double check, but I think thats all we do.]
> > 
> > 
> > 
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UFOIKP071696 for <[e-mail]>; Tue, 30 Sep 2003 08:24:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UFOImP071695 for ietf-pkix-bks; Tue, 30 Sep 2003 08:24:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UFOHKP071683 for <[e-mail]>; Tue, 30 Sep 2003 08:24:17 -0700 (PDT) (envelope-from [e-mail])
Received: from AMBARISHW2K (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id h8UFNY4c032091; Tue, 30 Sep 2003 08:23:34 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 08:23:33 -0700
Message-ID: <003a01c38766$d0369d80$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8UFOHKP071690
Sender: [e-mail]
Precedence: 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 Florian, Denis,
    The proposal also adds not-very-desirable semantics to requests
being made by existing clients.

All clients today that make requests with nonces expect those nonces to
come back in the response. With the semantics below, todays clients would
be indicating that it is okay to get a response w/o the nonce.


I think we are adding a lot of meaning in the nonce extension. My original
rationale for nonces was to allow a client to force a response to its
request
and thus prevent any chance of a reply. This leaves the options very simple:

- If you (the client) want a fresh response, include a nonce in the request.
- If you don't care whether the response is fresh or not, exclude a nonce
	in the request (and therefore, don't check to see whether there is a
nonce
	in the reply or not - the cached response that you get back might
have been
	generated for an earlier request that did contain a nonce)

Yes, this doesn't cover all the possible options, but it doesn't add a lot
of complications to the protocol. As a client, if I do want to support all
the cases identified by Florian below, I can still do it - potentially at
the
cost of a couple of requests.

Regards,
Ambarish


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Denis Pinkas
> Sent: Tuesday, September 30, 2003 12:41 AM
> To: Florian Oelmaier
> Cc: [e-mail]
> Subject: Re: OCSP response pre-production
> 
> 
> 
> Florian,
> 
> I have no problem with the new flow chart you propose below.
> 
> Making the nonce extension critical or not in the request, as 
> you propose in 
> another e-mail, is a good proposal since it does not involve 
> an ASN.1 module 
> change (if can avoid a new error code), but only 
> "clarifications" in the text.
> 
> It has the additional advantage of satisfying the "downgrade 
> to cache-only 
> iff that is all that is available", as requested by James.
> 
> Denis
> 
> 
> > I think a client should definitely and in every case reject 
> a response 
> > with a mismatching nonce. This is covered in RfC2560 in its current
> > form: mismatching nonce => reject.
> > 
> > So allow me to rephrase again based on your proposal:
> > 
> > A) always includes a nonce into his request;
> > B) checks the nonce in the response:
> > 
> >      - if it matches with the nonce from the request, then accept
> >        the response (pending other checks),
> > 
> >      - if it does not match with the nonce from the request, then
> >        reject the response
> > 
> >      - if nonce is not present, then are a local trusted time 
> >        available and a policy for cache responses both available ?
> >  
> >           - if both a local trusted time is available and 
> there exists
> >             a policy for cache responses, then compare the time
> >             difference between that local trusted clock and the
> >             producedAt field from ResponseData. If that 
> time difference
> >             is below the limit stated by that policy, then 
> accept the
> >             response (pending other checks).
> > 
> >           - if not, then reject the response.
> > 
> > 
> > [Additionally we add some checks:
> > 
> > i) if nextUpdate is present and is lower than the current date from 
> > our trusted clock before sending the request, we detected a clock 
> > problem in our "trusted" clocks.
> > 
> > ii) if thisUpdate is too old for our limit stated in the policy we 
> > reject the answer, too.
> > 
> > iii) additionally some sanity checks: 
> > thisUpdate<=producedAt<=nextUpdate
> > 
> > I have to double check, but I think thats all we do.]
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UF4ZKP070133 for <[e-mail]>; Tue, 30 Sep 2003 08:04:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UF4ZdG070132 for ietf-pkix-bks; Tue, 30 Sep 2003 08:04:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UF4YKP070124 for <[e-mail]>; Tue, 30 Sep 2003 08:04:34 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8UF4Zt67226 for <[e-mail]>; Tue, 30 Sep 2003 08:04:35 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 08:08: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)
In-Reply-To: <000001c386e5$8de650a0$4228a8c0@hagen>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

All,

I was talking to some folks offlist on this subject yesterday
and thought I might ask if it's possible we could all get behind
the following simple fix.


SYNTAX:     Expand v1 OCSPResponseStatus syntax to
            include (7) noncesNotAccepted.


SEMANTICS:  Responders SHOULD respond back with the
            requestor's nonce but if can't then SHALL
            respond with an error message of the value
            noncesNotAccepted.

            Requestors SHALL reject signed responses
            that fail to incorporate a supplied nonce.

            Upon receipt of noncesNotRequired, requestors
            MAY retry the request without using a nonce.
            Requestors are STRONGLY ADVISED that doing
            so MAY subject them to additional risk.

Thus, essentially, requestors can set "nonce always" but if they
want to they can have that overridden on a per-request basis.

Opinions?

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UDxfKP065144 for <[e-mail]>; Tue, 30 Sep 2003 06:59:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UDxeMN065143 for ietf-pkix-bks; Tue, 30 Sep 2003 06:59:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ascertia.com.pk ([203.81.202.44]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8UDxbKP065123 for <[e-mail]>; Tue, 30 Sep 2003 06:59:38 -0700 (PDT) (envelope-from [e-mail])
Received: From ascertiafm (unverified [192.168.0.156]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v5.0.4) with SMTP id <[e-mail]>; Tue, 30 Sep 2003 19:03:13 +0500
Message-ID: <001801c3875b$970ed050$[e-mail]>
From: "Faisal Maqsood" <[e-mail]>
To: <[e-mail]>
Subject: Self-Issued certificate requirements?
Date: Tue, 30 Sep 2003 19:03:11 +0500
Organization: Ascertia Ltd
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0015_01C38785.7E8D85B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
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>

This is a multi-part message in MIME format.

------=_NextPart_000_0015_01C38785.7E8D85B0
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi All,

RFC-3280 defines Self Signed certificate as:
"A certificate is self-issued if the DNs that appear in the subject and =
issuer fields are  identical and are not empty."

There might be two condition for self-issued certificate:
  1.. Version-1 certificate and has not any extension.
  2.. Version-3 certificate with set of extension/s.
For version-1 it is clear but are there any extra required things for =
version-3 self-issued certificates?
I mean for self-issued certificate is there any requirement that it Must =
be a CA certificate?
I mean BasicConstraints =3D ?, Path Length =3D ?, KeyUsage =3D ? etc.

Regards,
FAISAL MAQSOOD


------=_NextPart_000_0015_01C38785.7E8D85B0
Content-Type: text/html;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Dwindows-1252" =
http-equiv=3DContent-Type><BASE=20
href=3D"file://F:\___Faisal-Data-Priv\Email Signature\">
<META content=3D"MSHTML 5.00.3502.5390" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>Hi All,</DIV>
<DIV>&nbsp;</DIV>
<DIV>RFC-3280 defines Self Signed certificate as:</DIV>
<DIV>"<EM>A certificate is self-issued if the DNs that appear in the =
subject and=20
issuer fields are &nbsp;identical and are not empty.</EM>"</DIV>
<DIV>&nbsp;</DIV>
<DIV>There might be two condition for self-issued certificate:</DIV>
<OL>
  <LI>Version-1 certificate and has not any extension.</LI>
  <LI>Version-3 certificate with set of extension/s.</LI></OL>
<DIV>For version-1 it is clear but are there any extra required things =
for=20
version-3 self-issued certificates?</DIV>
<DIV>I mean for self-issued certificate is there any requirement that=20
it&nbsp;Must be a CA certificate?</DIV>
<DIV>I mean BasicConstraints =3D ?, Path Length =3D ?, KeyUsage =3D ? =
etc.</DIV>
<DIV>&nbsp;</DIV>
<DIV>Regards,</DIV>
<DIV>FAISAL MAQSOOD</DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0015_01C38785.7E8D85B0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UC0NKP058058 for <[e-mail]>; Tue, 30 Sep 2003 05:00:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UC0Nx5058057 for ietf-pkix-bks; Tue, 30 Sep 2003 05:00:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UC0MKP058050 for <[e-mail]>; Tue, 30 Sep 2003 05:00:22 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA22362; Tue, 30 Sep 2003 14:00:16 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 30 Sep 2003 14:00:17 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h8UC0FQ02975; Tue, 30 Sep 2003 14:00:15 +0200 (MEST)
Date: Tue, 30 Sep 2003 14:00:15 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: OCSP response pre-production
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At least, in X509 this is not (no longer) a difference
between an exension being critical or not, i.e, saying that
you have to treat it differently depending on whether the
criticallity bit is set or not as soon as you know to
treat it at all.

Since extensions are borrowed from X509 I am not sure that it
is a good idea to define different semantics depending on
the criticality bit. 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UBQ7KP056408 for <[e-mail]>; Tue, 30 Sep 2003 04:26:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UBQ7MX056407 for ietf-pkix-bks; Tue, 30 Sep 2003 04:26:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.fre.skanova.net (smtp1.fre.skanova.net [195.67.227.94]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UBQ5KP056401 for <[e-mail]>; Tue, 30 Sep 2003 04:26:06 -0700 (PDT) (envelope-from [e-mail])
Received: from arport (t11o913p33.telia.com [213.64.28.33]) by smtp1.fre.skanova.net (8.12.10/8.12.10) with SMTP id h8UBPncG020905; Tue, 30 Sep 2003 13:25:55 +0200 (CEST)
Message-ID: <029f01c38745$5608db20$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Nakagawa" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: request for reviewing our interoperability experiment report
Date: Tue, 30 Sep 2003 13:23:43 +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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 Nakagawa-San,
May I offer some comments not so much on the report itself, but
on the architectures that you are working with?  The described
CA structures represent one of three IMO entirely different ways
to apply PKI:

1. The "Classic".  Often using Cross-Certification (CC) and is fairly complex. 
    Used by the FED-PKI and the PKIs described in the report.  Adding
    CP extensions as "application trust filters", things get even more complex
    to scale-up as the extensions are (and will likely continue to be) never
    agreed upon except within certain "communities".  It is interesting to
    note that AFAIK, no commercial TTP CA make their
    issuance depending on CP extensions.  I.e., they all use the
   "universal issuing formula" CA <=> Policy.

2. Relying-party-only.   RP=CA.  Limited interoperability concerns but
    potentially awkward out-of-band RA-arrangements when the number
    of external partners increase.

3. The bank-model PKI [*].  Builds on legacy IT architectures and is
    simpler (but magnitudes more flexible) compared to the "Classic".
Short "promotional" description: http://www.x-obi.com/OBI400/b2bsign.pdf
Long(-winding) description: http://www.x-obi.com/OBI400/pki4org.pdf

Regarding interoperability I noted that you did not mention the four-corner
model which if I'm not misinformed possibly to be used by the coming Japanese
government PKI hosted by Identrus.  This system eliminates CC and
interoperability (as it is a closed trust-network) but dramatically
complicates RP software handling as there are no standards for
managing independent (they all are) four-corner trust-networks.
Most of these competing trust-networks require you to pay license
fees and only use certified software.  This is how the Swedish
banks currently operate.  A short [negative] description of four-corner:
http://www.x-obi.com/OBI400/e-government-ID-A.Rundgren.pdf

Press-release indicating that the Japanese government indeed
is considering supporting four-corner models:
http://www.identrus.com/company/press_releases/release_030717.html

Regards
Anders Rundgren

*] My participation in more or less related standards:
http://shibboleth.internet2.edu/minutes/SHIB-05-Sept-2001.html


----- Original Message ----- 
From: "Nakagawa" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, September 29, 2003 11:50
Subject: request for reviewing our interoperability experiment report



Dear PKIX list members,

Korea PKI Forum, PKI Forum Singapore, Chinese Taipei PKI Forum, and Japan
PKI Forum are pleased to announce the completion of the Final Report for
the Experiment in PKI Interoperability in Asia region in 2002. These
four countries/areas have been conducting the Experiment in PKI
interoperability since 2001, and compiled the first report for the 2001
experiment in the middle of 2002. A report compiled this time is
extended version of the previous one. 

In 2002, we have conducted 3 experiments as follows: 

1) CA-CA Interoperability Experiment with Cross Certification / Cross
Recognition models;

2) Path Processing Experiment intending to Resolve the certificate path
processing issues of repository by clarifying the path processing logic
described in RFC3280;

3) PKCS#11 Experiment tempting to approach PKI application
interoperability using a commonly defined API (application interface).
The Final Report contains the recommended technical specifications and
the lessons learnt, which are valuable for CA operators, VA (validation
authority) and application developers when dealing with relevant
interoperability matters.

In addition to this overall project result document, other five documents
were developed as appendixes, which are: 
- Appendix 1. IWG Recommended Profiles
- Appendix 2. CA-CA Interoperability Interface Specification for
experiment
- Appendix 3. Certificate Path Processing Implementation Guideline
- Appendix 4. Certificate Path Processing Testing Guideline
- Appendix 5. PKCS#11 Testing

It will be highly appreciated if IETF members examine the
report and let us know your thoughts/comments.
You can download the report and the appendix from:

Achieving PKI Interoperability 2003 -Results of the JKST-IWG Interoperability project-
http://www.japanpkiforum.jp/shiryou/IWG_2002/FinalReport2003-Version1.0.pdf
Appendix
http://www.japanpkiforum.jp/shiryou/IWG_2002/Appendix.pdf

Regards,

-- 
Hiroyuki Nakagawa
Japan PKI Forum


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8UAI3KP053187 for <[e-mail]>; Tue, 30 Sep 2003 03:18:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8UAI3O1053186 for ietf-pkix-bks; Tue, 30 Sep 2003 03:18:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8UAI1KP053181 for <[e-mail]>; Tue, 30 Sep 2003 03:18:01 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 15974 invoked by uid 1649); 30 Sep 2003 10:17:56 -0000
Date: 30 Sep 2003 10:17:56 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: "Manger, James H" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
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 have no problem with your proposal, but allow me to add one further differentiation to your point 3:

------ 

I think the options a responder might want to signal are instead:

1. Here is an answer..  it is cached as they are the only type I produce
2. Here is an answer..  it is cached, though I could have produced a custom-made response if you wanted it
3. Here is a custom-made answer tailored to the request
4. Here is a custom-made answer without having requested it
5. ERROR..  I cannot produce custom-made answers
6. ERROR..  I insist that clients use nonces for extra protection

------ 

-- 
Florian Oelmaier
SyTrust

On Tue, 30 Sep 2003 13:03:23 +1000, "Manger, James H" <[e-mail]> wrote :

> 
> Item B) should be:
> 
> B) Client wants to get a custom-made response, but will also accept a pre-produced/cached response IF AND ONLY IF THE SYSTEM IS INCAPABLE OF PROVIDING A CUSTOM-MADE RESPONSE.
> 
> 
> I think the options a responder might want to signal are instead:
> 
> 1. Here is an answer..  it is cached as they are the only type I produce
> 2. Here is an answer..  it is cached, though I could have produced a custom-made response if you wanted it
> 3. Here is a custom-made answer
> 4. ERROR..  I cannot produce custom-made answers
> 5. ERROR..  I insist that clients use nonces for extra protection
> 
> 
> 1 & 2 could be distinguished by the absence and presence of the nonce extension in the response respectively (the value of the response nonce is irrelevant).
> 
> 
> 
> -----Original Message-----
> From: Florian Oelmaier [mailto:[e-mail]]
> Sent: Tuesday, 30 September 2003 9:58 AM
> To: 'Michael Myers'; [e-mail]
> Subject: RE: OCSP response pre-production
> 
> > We have discovered a hole.  To give it a name let's call it 
> > Nonce Capability Discovery.  This hole will not be filled by 
> > artful requirements language alone.  We need proposed technical
> > components: a few bits of ASN.1 and associated semantics.
> 
> So we need some additional signalling between client and responder. I
> tried to list all the items a client would like to signal to the
> responder and the other way round.
> 
> The client has 3 options that he would like to signal to the responder:
> A) Client will accept a pre-produced/cached response. 
> B) Client wants to get a custom-made response, but will also accept a
> pre-produced/cached response.
> C) Client wants to get a custom-made response and will not accept
> pre-produced/cached responses.
> 
> A responder has 5 options that he would like to signal to the client:
> 1) Responder wants others to be able to cache (replay) this response
> 2) The response is a cached copy from another soure or was pre-produced
> 3) This is a custom-made response to a particular request (this
> obviously includes 4)
> 4) This particular response should not be used in any type of caching
> (replaying) 
> 5) Error: This Responder cannot produce custom-made responses
> 
> What about the following proposal (numbers corresponding to the signals
> above):
> 
> A) Client does not include nonce into request.
> B) Client includes nonce into request.
> C) Client includes nonce into request and marks it CRITICAL.
> 
> 1) Responder does not include nonce into response.
> 2) Responder does not include nonce into response.
> 3) Responder copies the nonce of the request into the response
> 4) If the request did not contain a nonce, the responder generates a
> nonce for the response
> 5) We add a new error code 7: "Nonce extension cannot be processed"
> 
> Advantage: We only need to change minor things in the RfC:
> - allow for CRITICAL on extensions
> - add a new error code
> - add some clarifications / text.
> 
> Disadvantage of this proposal: 
> - we miss the opportunity to signal the "source of validation" - CRL vs.
> fresh/live data.
> - We cannot distinguish 1) and 2).
> 
> -- 
> Florian Oelmaier
> SyTrust
> 
> 
> 
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U7f6KP034898 for <[e-mail]>; Tue, 30 Sep 2003 00:41:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8U7f6cd034897 for ietf-pkix-bks; Tue, 30 Sep 2003 00:41:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U7f1KP034867 for <[e-mail]>; Tue, 30 Sep 2003 00:41:05 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA30206; Tue, 30 Sep 2003 09:46:42 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA24613; Tue, 30 Sep 2003 09:42:14 +0200
Message-ID: <[e-mail]>
Date: Tue, 30 Sep 2003 09:40:49 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Florian Oelmaier <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP response pre-production
References: <002c01c386a3$a538a510$4228a8c0@hagen>
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>

Florian,

I have no problem with the new flow chart you propose below.

Making the nonce extension critical or not in the request, as you propose in 
another e-mail, is a good proposal since it does not involve an ASN.1 module 
change (if can avoid a new error code), but only "clarifications" in the text.

It has the additional advantage of satisfying the "downgrade to cache-only 
iff that is all that is available", as requested by James.

Denis


> I think a client should definitely and in every case reject a response
> with a mismatching nonce. This is covered in RfC2560 in its current
> form: mismatching nonce => reject.
> 
> So allow me to rephrase again based on your proposal:
> 
> A) always includes a nonce into his request;
> B) checks the nonce in the response:
> 
>      - if it matches with the nonce from the request, then accept
>        the response (pending other checks),
> 
>      - if it does not match with the nonce from the request, then
>        reject the response
> 
>      - if nonce is not present, then are a local trusted time 
>        available and a policy for cache responses both available ?
>  
>           - if both a local trusted time is available and there exists
>             a policy for cache responses, then compare the time
>             difference between that local trusted clock and the
>             producedAt field from ResponseData. If that time difference
>             is below the limit stated by that policy, then accept the
>             response (pending other checks).
> 
>           - if not, then reject the response.
> 
> 
> [Additionally we add some checks: 
> 
> i) if nextUpdate is present and is lower than the current date from our
> trusted clock before sending the request, we detected a clock problem in
> our "trusted" clocks.
> 
> ii) if thisUpdate is too old for our limit stated in the policy we
> reject the answer, too.
> 
> iii) additionally some sanity checks: thisUpdate<=producedAt<=nextUpdate
> 
> I have to double check, but I think thats all we do.]





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U71bKP021827 for <[e-mail]>; Tue, 30 Sep 2003 00:01:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8U71b9f021826 for ietf-pkix-bks; Tue, 30 Sep 2003 00:01:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbo.vtcif.telstra.com.au (mailbo.vtcif.telstra.com.au [202.12.144.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U71aKP021761 for <[e-mail]>; Tue, 30 Sep 2003 00:01:36 -0700 (PDT) (envelope-from [e-mail])
Received: by mailbo.vtcif.telstra.com.au (Postfix, from userid 5) id 6A5AB240E8; Tue, 30 Sep 2003 17:01:21 +1000 (EST)
Received: from mailbi.vtcif.telstra.com.au(202.12.142.19) via SMTP by mailbo.vtcif.telstra.com.au, id smtpdUHaa2m; Tue Sep 30 17:00:46 2003
Received: from mailbi.vtcif.telstra.com.au (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 125BF563F8 for <[e-mail]>; Tue, 30 Sep 2003 13:35:24 +1000 (EST)
Received: from mail.cdn.telstra.com.au (mail.cdn.telstra.com.au [144.135.138.138]) by mailbi.vtcif.telstra.com.au (Postfix) with ESMTP id 2E2EB267B8 for <[e-mail]>; Tue, 30 Sep 2003 13:03:41 +1000 (EST)
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id NAA21073 for <[e-mail]>; Tue, 30 Sep 2003 13:03:40 +1000 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 13:03:23 +1000
Message-ID: <[e-mail]>
Thread-Topic: OCSP response pre-production
Thread-Index: AcOG91iKqOV9Wd5+QVG2gfHIQFF/0gAAmlqQ
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8U71bKP021821
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Item B) should be:

B) Client wants to get a custom-made response, but will also accept a pre-produced/cached response IF AND ONLY IF THE SYSTEM IS INCAPABLE OF PROVIDING A CUSTOM-MADE RESPONSE.


I think the options a responder might want to signal are instead:

1. Here is an answer..  it is cached as they are the only type I produce
2. Here is an answer..  it is cached, though I could have produced a custom-made response if you wanted it
3. Here is a custom-made answer
4. ERROR..  I cannot produce custom-made answers
5. ERROR..  I insist that clients use nonces for extra protection


1 & 2 could be distinguished by the absence and presence of the nonce extension in the response respectively (the value of the response nonce is irrelevant).



-----Original Message-----
From: Florian Oelmaier [mailto:[e-mail]]
Sent: Tuesday, 30 September 2003 9:58 AM
To: 'Michael Myers'; [e-mail]
Subject: RE: OCSP response pre-production

> We have discovered a hole.  To give it a name let's call it 
> Nonce Capability Discovery.  This hole will not be filled by 
> artful requirements language alone.  We need proposed technical
> components: a few bits of ASN.1 and associated semantics.

So we need some additional signalling between client and responder. I
tried to list all the items a client would like to signal to the
responder and the other way round.

The client has 3 options that he would like to signal to the responder:
A) Client will accept a pre-produced/cached response. 
B) Client wants to get a custom-made response, but will also accept a
pre-produced/cached response.
C) Client wants to get a custom-made response and will not accept
pre-produced/cached responses.

A responder has 5 options that he would like to signal to the client:
1) Responder wants others to be able to cache (replay) this response
2) The response is a cached copy from another soure or was pre-produced
3) This is a custom-made response to a particular request (this
obviously includes 4)
4) This particular response should not be used in any type of caching
(replaying) 
5) Error: This Responder cannot produce custom-made responses

What about the following proposal (numbers corresponding to the signals
above):

A) Client does not include nonce into request.
B) Client includes nonce into request.
C) Client includes nonce into request and marks it CRITICAL.

1) Responder does not include nonce into response.
2) Responder does not include nonce into response.
3) Responder copies the nonce of the request into the response
4) If the request did not contain a nonce, the responder generates a
nonce for the response
5) We add a new error code 7: "Nonce extension cannot be processed"

Advantage: We only need to change minor things in the RfC:
- allow for CRITICAL on extensions
- add a new error code
- add some clarifications / text.

Disadvantage of this proposal: 
- we miss the opportunity to signal the "source of validation" - CRL vs.
fresh/live data.
- We cannot distinguish 1) and 2).

-- 
Florian Oelmaier
SyTrust




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U5t6KP098478 for <[e-mail]>; Mon, 29 Sep 2003 22:55:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8U5t61o098476 for ietf-pkix-bks; Mon, 29 Sep 2003 22:55:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailo.ntcif.telstra.com.au ([202.12.233.17]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U5t4KP098425 for <[e-mail]>; Mon, 29 Sep 2003 22:55:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from uucp@localhost) by mailo.ntcif.telstra.com.au (8.8.2/8.6.9) id PAA13668 for <[e-mail]>; Tue, 30 Sep 2003 15:54:56 +1000 (EST)
Received: from maili.ntcif.telstra.com.au(202.12.162.17) via SMTP by mailo.ntcif.telstra.com.au, id smtpdVgaqei; Tue Sep 30 15:45:58 2003
Received: (from uucp@localhost) by maili.ntcif.telstra.com.au (8.8.2/8.6.9) id PAA01209 for <[e-mail]>; Tue, 30 Sep 2003 15:43:02 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdaEaWZu; Tue Sep 30 15:18:23 2003
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA11799 for <[e-mail]>; Tue, 30 Sep 2003 15:18:22 +1000 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 15:18:04 +1000
Message-ID: <[e-mail]>
Thread-Topic: OCSP response pre-production
Thread-Index: AcOHA/VhnQfoIp6NS4emCEM6XOqevQAAlZhQ
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8U5t5KP098469
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Clients may prefer a nonce-based (not clock-based) freshness guarantee when available.  Clients may also be willing to accept cache-only responders (with their clock-based freshness) when necessary, as they can offer advantages for large-scale systems.

Clients may want both these options, but they do not want to allow an attacker to choose when the "downgrade to cache-only" occurs.


A solution:
1) Responders that can include the request nonce in the response MUST indicate this capability.  Including the nonce extension in the response (even if the request didn't have one) seems like a reasonable way to indicate this.
2) If a request includes a nonce a client MUST reject the response if it also contains a nonce but that nonce has a different value.
3) Client MUST NOT reject responses with nonces just because the request didn't include a nonce.

Note: Dynamic responders can still cache responses with nonces to respond to subsequent nonceless requests.
Note: Cache-only systems can pre-produce responses without nonces to respond to any request.


I suspect current clients already do 2) & 3).  Perhaps only Florian's responder currently does 1), but this is not a huge problem.  Clients that support "downgrade to cache-only iff that is all that is available" can be configured for this on a per-responder basis if necessary.



(So I don't like Denis's "New text proposal")


-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Monday, 29 September 2003 8:07 PM
To: Deacon, Alex
Cc: [e-mail]
Subject: Re: OCSP response pre-production (was RE: POLL: Use of nonces
in OCSP)

...
New text proposal:

     "Upon receipt of a request containing a nonce,
      a responder SHALL include the value of such nonce
      in the production of the associated response,
      if it is not using cached pre-produced responses.
      If the responder is using cached pre-produced responses,
      then it MAY send back a response with or without a nonce."

      "Clients that elect to include a request nonce
      MAY reject responses that fail to include
      the client's nonce from the associated request.
      Alternatively they MAY ignore the nonce field and accept
      the response, if they have a local trusted clock and are
      satisfied with the time difference between their local
      trusted clock and the producedAt field from ResponseData".



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U0LrKP063735 for <[e-mail]>; Mon, 29 Sep 2003 17:21:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8U0Lq5f063734 for ietf-pkix-bks; Mon, 29 Sep 2003 17:21:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8U0LnKQ063729 for <[e-mail]>; Mon, 29 Sep 2003 17:21:51 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002025bb9e7a87271c@[63.202.92.152]>
In-Reply-To: <000001c386e5$8de650a0$4228a8c0@hagen>
References: <000001c386e5$8de650a0$4228a8c0@hagen>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Mon, 29 Sep 2003 17:21:48 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Man-in-the-middle attacks (was: OCSP response pre-production)
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>

The problem I am seeing with the proposals that it is OK for the 
responder to send nonce-less responses to queries with nonces is that 
it allows a man-in-the-middle to perform a fairly trivial replay 
attack. A sophisticated man-in-the-middle might capture every 
request, strip out the nonce (and signature, if any), pass it on to 
the server, and then send back all the responses with no nonces, so 
that the client expects no nonces from the server and won't be at all 
suspicious when snookered with a replay attack.

If we go for the minority proposal of allowing responders to ignore 
nonces in the queries, we will certainly need to beef up the Security 
Considerations section, and probably section 4.4.1 as well.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TNwVKP062727 for <[e-mail]>; Mon, 29 Sep 2003 16:58:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8TNwVCE062726 for ietf-pkix-bks; Mon, 29 Sep 2003 16:58:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TNwTKP062721 for <[e-mail]>; Mon, 29 Sep 2003 16:58:30 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd00.aul.t-online.de  by mailout05.sul.t-online.com with smtp  id 1A47uR-0007S1-02; Tue, 30 Sep 2003 01:58:31 +0200
Received: from hagen (rxTOXiZpQeDgPojen2P+qcpt9h0xzgeok1Q1WZstSG44A3oAueU7Ua@[80.128.89.215]) by fmrl00.sul.t-online.com with esmtp id 1A47uH-09h6uW0; Tue, 30 Sep 2003 01:58:21 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 01:58:17 +0200
Organization: SyTrust
Message-ID: <000001c386e5$8de650a0$4228a8c0@hagen>
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
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-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>

> We have discovered a hole.  To give it a name let's call it 
> Nonce Capability Discovery.  This hole will not be filled by 
> artful requirements language alone.  We need proposed technical
> components: a few bits of ASN.1 and associated semantics.

So we need some additional signalling between client and responder. I
tried to list all the items a client would like to signal to the
responder and the other way round.

The client has 3 options that he would like to signal to the responder:
A) Client will accept a pre-produced/cached response. 
B) Client wants to get a custom-made response, but will also accept a
pre-produced/cached response.
C) Client wants to get a custom-made response and will not accept
pre-produced/cached responses.

A responder has 5 options that he would like to signal to the client:
1) Responder wants others to be able to cache (replay) this response
2) The response is a cached copy from another soure or was pre-produced
3) This is a custom-made response to a particular request (this
obviously includes 4)
4) This particular response should not be used in any type of caching
(replaying) 
5) Error: This Responder cannot produce custom-made responses

What about the following proposal (numbers corresponding to the signals
above):

A) Client does not include nonce into request.
B) Client includes nonce into request.
C) Client includes nonce into request and marks it CRITICAL.

1) Responder does not include nonce into response.
2) Responder does not include nonce into response.
3) Responder copies the nonce of the request into the response
4) If the request did not contain a nonce, the responder generates a
nonce for the response
5) We add a new error code 7: "Nonce extension cannot be processed"

Advantage: We only need to change minor things in the RfC:
- allow for CRITICAL on extensions
- add a new error code
- add some clarifications / text.

Disadvantage of this proposal: 
- we miss the opportunity to signal the "source of validation" - CRL vs.
fresh/live data.
- We cannot distinguish 1) and 2).

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TNefKP062140 for <[e-mail]>; Mon, 29 Sep 2003 16:40:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8TNef94062139 for ietf-pkix-bks; Mon, 29 Sep 2003 16:40:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TNeeKP062130 for <[e-mail]>; Mon, 29 Sep 2003 16:40:40 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Sep 2003 16:40:25 -0700
Received: from 157.54.8.155 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 29 Sep 2003 16:40:37 -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.6713); Mon, 29 Sep 2003 16:40:37 -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(6.0.3790.0); Mon, 29 Sep 2003 16:40:36 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Mon, 29 Sep 2003 16:40:35 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: OCSP response pre-production
Date: Mon, 29 Sep 2003 16:40:20 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP response pre-production
thread-index: AcOEgkw74jv3Wo8DSy6E0YMn+7SFkQBmvKPQADFfHvA=
From: "Ryan M. Hurst" <[e-mail]>
To: "Manger, James H" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 29 Sep 2003 23:40:35.0833 (UTC) FILETIME=[14A17690:01C386E3]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8TNeeKP062133
Sender: [e-mail]
Precedence: 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 I see it there are several problems here:

First the RFC isn't clear on what the client is asking when it includes
a nonce, my take has always been that a request with a nonce is a
request that the client would like to have generated dynamically for it;
it seams from the other responses on the thread that this is was the
common interpretation. I think Mikes proposed text resolves this issue.

Next if a server can't generate a response dynamically (or forward it to
someone who can) what is he to return? I see several options here:
1. Expand section "4.4.1  Nonce" to include nonceNotSupported, this
could be returned by the server indicating to the client that it does
not support dynamic responses.

NOTE: I am not sure why the client needs to know this, but extra
information always helps in diagnostics so I am not apposed to this.

2. If a server can't support a nonce it returns internalError
NOTE: notAuthorized is also an option; authorization is a function of
policy and in this case the policy does not support the generation of
dynamic responses.

And finally what is a server supposed to return if it receives a request
without a nonce? I see several options these include:
1. Answer him! Nonce's only protect the client; if the client doesn't
want a nonce don't give him one.
2. Return internalError or notAuthorized as per above, this allows
servers in environments who want

The server to enforce client policy to refuse to answer questions that
he thinks may be questionable.

In the end I the decision to use a response is the clients, the decision
to send one is the server and the return can give a little detail or
allot.

Ryan





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TJAbKP050687 for <[e-mail]>; Mon, 29 Sep 2003 12:10:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8TJAb7S050686 for ietf-pkix-bks; Mon, 29 Sep 2003 12:10:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TJAZKP050681 for <[e-mail]>; Mon, 29 Sep 2003 12:10:35 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8TJAat29530 for <[e-mail]>; Mon, 29 Sep 2003 12:10:36 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Mon, 29 Sep 2003 12:14:06 -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 V6.00.2800.1106
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,

We have discovered a hole.  To give it a name let's call it
Nonce Capability Discovery.  This hole will not be filled by
artful requirements language alone.  We need proposed technical
components: a few bits of ASN.1 and associated semantics.

Mike








Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TG6pKP042418 for <[e-mail]>; Mon, 29 Sep 2003 09:06:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8TG6pUf042417 for ietf-pkix-bks; Mon, 29 Sep 2003 09:06:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TG6nKP042412 for <[e-mail]>; Mon, 29 Sep 2003 09:06:50 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd03.aul.t-online.de  by mailout08.sul.t-online.com with smtp  id 1A40Xy-0001LQ-00; Mon, 29 Sep 2003 18:06:50 +0200
Received: from hagen (SOOyRTZareXel3Hkm4ukwyJez4snVLIXTldg8ZSAHFjfqEs4l2h0wx@[217.80.248.68]) by fmrl03.sul.t-online.com with esmtp id 1A40Xh-17zUo40; Mon, 29 Sep 2003 18:06:33 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Mon, 29 Sep 2003 18:06:30 +0200
Organization: SyTrust
Message-ID: <002c01c386a3$a538a510$4228a8c0@hagen>
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.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I think a client should definitely and in every case reject a response
with a mismatching nonce. This is covered in RfC2560 in its current
form: mismatching nonce => reject.

So allow me to rephrase again based on your proposal:

A) always includes a nonce into his request;
B) checks the nonce in the response:

     - if it matches with the nonce from the request, then accept
       the response (pending other checks),

     - if it does not match with the nonce from the request, then
       reject the response

     - if nonce is not present, then are a local trusted time 
       available and a policy for cache responses both available ?
 
          - if both a local trusted time is available and there exists
            a policy for cache responses, then compare the time
            difference between that local trusted clock and the
            producedAt field from ResponseData. If that time difference
            is below the limit stated by that policy, then accept the
            response (pending other checks).

          - if not, then reject the response.


[Additionally we add some checks: 

i) if nextUpdate is present and is lower than the current date from our
trusted clock before sending the request, we detected a clock problem in
our "trusted" clocks.

ii) if thisUpdate is too old for our limit stated in the policy we
reject the answer, too.

iii) additionally some sanity checks: thisUpdate<=producedAt<=nextUpdate

I have to double check, but I think thats all we do.]




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TFivKP041437 for <[e-mail]>; Mon, 29 Sep 2003 08:44:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8TFiv64041436 for ietf-pkix-bks; Mon, 29 Sep 2003 08:44:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TFiqKP041428 for <[e-mail]>; Mon, 29 Sep 2003 08:44:54 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA15476; Mon, 29 Sep 2003 17:50:39 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id RAA15336; Mon, 29 Sep 2003 17:46:15 +0200
Message-ID: <[e-mail]>
Date: Mon, 29 Sep 2003 17:44:52 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Florian Oelmaier <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP response pre-production
References: <002201c3869c$7aae9db0$4228a8c0@hagen>
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>

Florian,

>>[Florian]

>>>Client Type I) Given you have a client with the following behaviour:
>>>A) always includes a nonce into his request
>>>B) accepts responses without nonce

>>If a client Type I "accepts responses without nonce" (i.e. "B 
>>condition")then a nonce generated by the server is ignored by 
 >>the client and thus does not help, and "do NOT allow
 >>Client Type I operate securely".

> Why should the client *ignore* the nonce? The client will check the
> nonce when it is included in the response while simultaneous accepting
> responses without nonce. Although I have not tested it, I dont think any
> client out there that accepts nonce-less responses to his nonce-requests
> IGNORES the nonce. After all a mismatching nonce definitely indicates a
> replay attack while a response without nonce just indicates no
> protection against replay attacks.

No, this is not as simple. What you say is true, if only real-time responses 
are being used. Since we also want to allow for cached-responses, the story 
is a litte more complicated.

> This way the responder can decide wether to protect the client against
> replay attacks (through server-generated nonces).

> So allow me to define the behaviour of "Client Type I" more clearly:
> A) always includes a nonce into his request
> B) checks if the nonces match if the response included a nonce
> C) accepts responses without nonce

Not exactly. Proposed rephrasing for a "Client Type I":

  A) always includes a nonce into his request;
  B) checks the nonce in the response:

       - if it matches with the nonce from the request, then accept
         the response (pending other checks),

       - if it does not match with the nonce from the request or if it
         is not present, then are a local trusted time available and
         a policy for cache responses both available ?

              - if both a local trusted time is available and there exists
                a policy for cache responses, then compare the time
                difference between that local trusted clock and the
                producedAt field from ResponseData. If that time difference
                is below the limit stated by that policy, then accept the
                response (pending other checks).

              - if not, then reject the response.

Denis



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TFhGKP041311 for <[e-mail]>; Mon, 29 Sep 2003 08:43:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8TFhGhq041310 for ietf-pkix-bks; Mon, 29 Sep 2003 08:43:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TFhEKP041305 for <[e-mail]>; Mon, 29 Sep 2003 08:43:14 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd03.aul.t-online.de  by mailout03.sul.t-online.com with smtp  id 1A40B9-00088v-01; Mon, 29 Sep 2003 17:43:15 +0200
Received: from hagen (Zkgg6QZEZecAPKWRaOddt+tIEfOraQ5Sg47FlE9FhG4Vn860vLaxc5@[217.80.248.68]) by fmrl03.sul.t-online.com with esmtp id 1A40Ay-1Z3ABs0; Mon, 29 Sep 2003 17:43:04 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>
Cc: <[e-mail]>
Subject: [offlist] RE: Not using nonce does not necessarily allow replay attacks ...
Date: Mon, 29 Sep 2003 17:43:00 +0200
Organization: SyTrust
Message-ID: <002301c386a0$5d2c4ea0$4228a8c0@hagen>
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.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I actually believe that nonce are essentially pointless for 
> any server without access to "live" revocation information.

In theory your are right. In the real world you cannot always rely on a
synchronized time (throughout a company for example). Mind: I am not
talking about attacks, but I am talking about interoperability problems
and rejected validations. While certs usually have a long duration (to
long for small clock skews to become a problem), validation is a major
problem with clocks having a difference of a few hours. This way using
nonces are an advantage even for CRL-based responders. I will not argue,
if this advantage is worth the trouble or not - but this argumentation
is very common out there.

For example: one of the points for using OCSP at some of our customers
was to reduce the issues coming up due to not-synchronized times. Using
nonces in OCSP and setting very late nextUpdate values while
simultaneous disabling OCSP-client caching does the trick in a closed
environment while maintaining a high security standard. 

> I think the real info clients should be able to obtain from
> the servers is whether they provide "live" info.

I agree. But I am not sure if this information should be connected with
the nonce-system. Here at SyTrust we currently judge this by comparing
nextUpdate, thisUpdate and producedAt. When
nextUpdate=producedAt=thisUpdate we assume that this is a "live"
response (we allow a few seconds difference). Seeing that this is not
what was meant by these three times and that nextUpdate is optional, I
am not really glad with that system. So it would be nice to have such a
signalling.

Mind: There are responders not includind "nextUpdate" into there
response when they have live access to the data.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TFFaKP039684 for <[e-mail]>; Mon, 29 Sep 2003 08:15:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8TFFa8a039683 for ietf-pkix-bks; Mon, 29 Sep 2003 08:15:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TFFYKP039677 for <[e-mail]>; Mon, 29 Sep 2003 08:15:35 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd03.aul.t-online.de  by mailout03.sul.t-online.com with smtp  id 1A3zkG-0005Od-0M; Mon, 29 Sep 2003 17:15:28 +0200
Received: from hagen (EY8wwQZ6geytrilvUDBnywYbSdtiYn5PG4wAKqjiFlxHBV8EO7g5ch@[217.80.248.68]) by fmrl03.sul.t-online.com with esmtp id 1A3zk4-0jd19s0; Mon, 29 Sep 2003 17:15:16 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Manger, James H'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Mon, 29 Sep 2003 17:15:12 +0200
Organization: SyTrust
Message-ID: <002201c3869c$7aae9db0$4228a8c0@hagen>
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.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
X-Seen: false
X-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>

> [Florian]
> 
> > Client Type I) Given you have a client with the following behaviour:
> > A) always includes a nonce into his request
> > B) accepts responses without nonce
>
> If a client Type I "accepts responses without nonce" (i.e. "B 
> condition") 
> then a nonce generated by the server is ignored by the client 
> and thus does 
> not help, and "do NOT allow Client Type I operate securely".

Why should the client *ignore* the nonce? The client will check the
nonce when it is included in the response while simultaneous accepting
responses without nonce. Although I have not tested it, I dont think any
client out there that accepts nonce-less responses to his nonce-requests
IGNORES the nonce. After all a mismatching nonce definitely indicates a
replay attack while a response without nonce just indicates no
protection against replay attacks.

This way the responder can decide wether to protect the client against
replay attacks (through server-generated nonces).

So allow me to define the behaviour of "Client Type I" more clearly:
A) always includes a nonce into his request
B) checks if the nonces match if the response included a nonce
C) accepts responses without nonce

-- 
Florian Oelmaier
SyTrust

PS: -> James: To allow replay protection, a pre-defined nonce would not
help. So in my scenario it should be the usual non-predictable random
string. 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TEvdKP038811 for <[e-mail]>; Mon, 29 Sep 2003 07:57:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8TEvcZg038810 for ietf-pkix-bks; Mon, 29 Sep 2003 07:57:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TEvcKP038804 for <[e-mail]>; Mon, 29 Sep 2003 07:57:38 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19483; Mon, 29 Sep 2003 10:57:31 -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-x509-ipaddr-as-extn-03.txt
Date: Mon, 29 Sep 2003 10:57:31 -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		: X.509 Extensions for IP Addresses and AS Identifiers
	Author(s)	: C. Lynn et al.
	Filename	: draft-ietf-pkix-x509-ipaddr-as-extn-03.txt
	Pages		: 30
	Date		: 2003-9-29
	
This document defines two X.509 v3 certificate extensions.  The first
binds a list of IP address blocks, or prefixes, to the subject of a
certificate.  The second binds a list of autonomous system
identifiers to the subject of a certificate.  These extensions may be
used to convey the authorization of the subject to use the IP
addresses and autonomous system identifiers contained in the
extensions.
Please send comments on this draft to the [e-mail] mail
list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-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-x509-ipaddr-as-extn-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-x509-ipaddr-as-extn-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-03.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TEnMKP038481 for <[e-mail]>; Mon, 29 Sep 2003 07:49:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8TEnMDo038480 for ietf-pkix-bks; Mon, 29 Sep 2003 07:49:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from main.giknpc.com.ua (backup.adm.dp.ua [212.86.233.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TEnDKP038470 for <[e-mail]>; Mon, 29 Sep 2003 07:49:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from vf@localhost) by main.giknpc.com.ua (8.11.6/8.11.6) id h8TEn1100403; Mon, 29 Sep 2003 17:49:01 +0300
Date: Mon, 29 Sep 2003 17:49:01 +0300
From: Vadim Fedukovich <[e-mail]>
To: [e-mail]
Cc: Julien Stern <[e-mail]>
Subject: Re: Not using nonce does not necessarily allow replay attacks ...
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: 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, Sep 29, 2003 at 11:26:17AM +0200, Julien Stern wrote:
> 
> Having recently looked into much detail at RFC2560, I feel there are
> really two totally different scenarios possible:
> 
> 1) Responder with a "live" backend (Nonce MUST be used)
> 2) Responder with a CRL backend (Nonce do not matter)
> 
> CASE 1) The responder has access to timely information,
> the "thisUpdate" field should be equal to the "producedAt" field
> and the "nextUpdate" field should be absent. Nonces must clearly
> be used to prevent replay attacks. Server should add a nonce even
> to nonceless requests.

What's the point to respond with a nonce to a request without one?
If a client did not include a nonce he knows is unique there's nothing
to compare with so any old response with any nonce would be fine

regards,
Vadim


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TA7EKP025491 for <[e-mail]>; Mon, 29 Sep 2003 03:07:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8TA7EAp025490 for ietf-pkix-bks; Mon, 29 Sep 2003 03:07:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TA75KP025478 for <[e-mail]>; Mon, 29 Sep 2003 03:07:07 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA19204; Mon, 29 Sep 2003 12:12:49 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA12943; Mon, 29 Sep 2003 12:08:25 +0200
Message-ID: <[e-mail]>
Date: Mon, 29 Sep 2003 12:07:02 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "Deacon, Alex" <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP response pre-production (was RE: POLL:  Use of nonces in OCSP)
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>

Alex,

I support the idea, ... with some changes.

> Hi Russ,
> 
> Agreed, however we do not have control of all OCSP clients.  In the case
> where a responder is using pre-produced responses and can't respond to a
> request with a nonce, the responder can do one of two things:
> 
> 1) Send the pre-produced response without the nonce
> 2) return a malformedReqest OCSPResponseStatus
> 
> I feel that the first choice is better as it gives clients a chance to
> accept the response, even though it does not contain a nonce.   

> For clients that require a nonce not matter what the outcome of both optoins
> is the same...i.e. the response is rejected.

If a nonce is present in the request then the server SHALL send back a 
response with the same nonce, if it is not using cached pre-produced responses.

If the server is using cached pre-produced responses, then he MAY send back 
a response with or without a nonce. In such a case, the client SHOULD check 
the freshness of the response using the producedAt field from ResponseData 
which is only possible if the client has a local trusted clock.

New text proposal:

     "Upon receipt of a request containing a nonce,
      a responder SHALL include the value of such nonce
      in the production of the associated response,
      if it is not using cached pre-produced responses.
      If the responder is using cached pre-produced responses,
      then it MAY send back a response with or without a nonce."

      "Clients that elect to include a request nonce
      MAY reject responses that fail to include
      the client's nonce from the associated request.
      Alternatively they MAY ignore the nonce field and accept
      the response, if they have a local trusted clock and are
      satisfied with the time difference between their local
      trusted clock and the producedAt field from ResponseData".

Denis

> Alex
> 
> 
> 
> 
> 
>>-----Original Message-----
>>From: Russ Housley [mailto:[e-mail]]
>>Sent: Friday, September 26, 2003 9:31 AM
>>To: Deacon, Alex
>>Cc: [e-mail]
>>Subject: RE: POLL: Use of nonces in OCSP
>>
>>
>>Alex:
>>
>>To support such an environment, the client should not include 
>>a nonce in 
>>the request.  Do you have control over the clients?  If so, 
>>then the change 
>>will not cause you a problem.
>>
>>Russ
>>
>>At 05:12 PM 9/25/2003 -0700, Deacon, Alex wrote:
>>
>>
>>
>>>Hi Mike,
>>>
>>>Although this new text would not break the existing VeriSign 
>>
>>OCSP code base,
>>
>>>it will break the (soon to be deployed) next generation of our OCSP
>>>services.  These services are designed to serve PKI's with a 
>>
>>high volume of
>>
>>>RP's (such as TLS server and code signing CA's) and rely on response
>>>pre-production, distribution and caching through out the network.
>>>
>>>In such a deployment it is not possible for a responder to 
>>
>>include a nonce
>>
>>>in the response.
>>>
>>>Regards,
>>>Alex
>>>
>>>
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Michael Myers [mailto:[e-mail]]
>>>>Sent: Wednesday, September 24, 2003 7:38 AM
>>>>To: [e-mail]
>>>>Cc: Stephen Kent; Ambarish Malpani
>>>>Subject: POLL: Use of nonces in OCSP
>>>>
>>>>
>>>>
>>>>All,
>>>>
>>>>Recent list traffic indicates there might be some confusion out
>>>>there regarding the use of nonces in OCSP.  This is
>>>>understandable since RFC 2560 is regrettably silent on the
>>>>point.  It seems that most folks correctly inferred our original
>>>>intent but absent normative language there's a possibility that
>>>>some may not.
>>>>
>>>>After some discussion with the Chairs and the AD, we will take
>>>>action to clarify our original intent in one fashion or another
>>>>but first need to poll IMPLEMENTORS to determine how many, if
>>>>any, implementations of OCSP would break as a consequence of the
>>>>following normative language:
>>>>
>>>>    "Clients that elect to include a request nonce
>>>>     SHALL reject responses that fail to include
>>>>     the client's nonce from the associated request."
>>>>
>>>>    "Correspondingly, upon receipt of a request
>>>>     containing a nonce, a responder SHALL include
>>>>     the value of such nonce in the production of
>>>>     the associated response."
>>>>
>>>>IMPLEMENTORS ONLY, please, and just yes/no or equivalent.
>>>>
>>>>Mike
>>>>
>>>>
>>>
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TA3aKP025080 for <[e-mail]>; Mon, 29 Sep 2003 03:03:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8TA3ax8025079 for ietf-pkix-bks; Mon, 29 Sep 2003 03:03:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8TA3OKP025068 for <[e-mail]>; Mon, 29 Sep 2003 03:03:25 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA46960; Mon, 29 Sep 2003 12:09:04 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id MAA12932; Mon, 29 Sep 2003 12:04:40 +0200
Message-ID: <[e-mail]>
Date: Mon, 29 Sep 2003 12:03:16 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: "Manger, James H" <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP response pre-production
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>

(...)

[Florian]

> Client Type I) Given you have a client with the following behaviour:
> A) always includes a nonce into his request
> B) accepts responses without nonce

(...)

[James]

> So the proposed server-generated nonces are simply a mechanism to allow
> Client Type I operate securely. I fully agree with you, that such a
> client behaviour (accepting responses without nonce) seems to be
> desirable from an operating point of view.

If a client Type I "accepts responses without nonce" (i.e. "B condition") 
then a nonce generated by the server is ignored by the client and thus does 
not help, and "do NOT allow Client Type I operate securely".

Denis



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8T9pGKP024372 for <[e-mail]>; Mon, 29 Sep 2003 02:51:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8T9pGVe024371 for ietf-pkix-bks; Mon, 29 Sep 2003 02:51:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mgate11.so-net.ne.jp (mgate11.so-net.ne.jp [210.139.254.158]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8T9pDKP024365 for <[e-mail]>; Mon, 29 Sep 2003 02:51:14 -0700 (PDT) (envelope-from [e-mail])
Received: from mail.dc5.so-net.ne.jp (mspool14.so-net.ne.jp [210.139.248.14]) by mgate11.so-net.ne.jp  with ESMTP id h8T9p7929668; Mon, 29 Sep 2003 18:51:07 +0900 (JST)
Received: from [192.168.1.21] (p6e0140.tokynt01.ap.so-net.ne.jp [218.110.1.64]) by mail.dc5.so-net.ne.jp  with ESMTP id h8T9p7P29561; Mon, 29 Sep 2003 18:51:07 +0900 (JST)
Date: Mon, 29 Sep 2003 18:50:47 +0900
From: Nakagawa <[e-mail]>
To: [e-mail]
Subject: request for reviewing our interoperability experiment report
Cc: [e-mail]
Message-Id: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Becky! ver. 2.06.02
Sender: [e-mail]
Precedence: 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 PKIX list members,

Korea PKI Forum, PKI Forum Singapore, Chinese Taipei PKI Forum, and Japan
PKI Forum are pleased to announce the completion of the Final Report for
the Experiment in PKI Interoperability in Asia region in 2002. These
four countries/areas have been conducting the Experiment in PKI
interoperability since 2001, and compiled the first report for the 2001
experiment in the middle of 2002. A report compiled this time is
extended version of the previous one. 

In 2002, we have conducted 3 experiments as follows: 

1) CA-CA Interoperability Experiment with Cross Certification / Cross
Recognition models;

2) Path Processing Experiment intending to Resolve the certificate path
processing issues of repository by clarifying the path processing logic
described in RFC3280;

3) PKCS#11 Experiment tempting to approach PKI application
interoperability using a commonly defined API (application interface).
The Final Report contains the recommended technical specifications and
the lessons learnt, which are valuable for CA operators, VA (validation
authority) and application developers when dealing with relevant
interoperability matters.

In addition to this overall project result document, other five documents
were developed as appendixes, which are: 
- Appendix 1. IWG Recommended Profiles
- Appendix 2. CA-CA Interoperability Interface Specification for
experiment
- Appendix 3. Certificate Path Processing Implementation Guideline
- Appendix 4. Certificate Path Processing Testing Guideline
- Appendix 5. PKCS#11 Testing

It will be highly appreciated if IETF members examine the
report and let us know your thoughts/comments.
You can download the report and the appendix from:

Achieving PKI Interoperability 2003 -Results of the JKST-IWG Interoperability project-
http://www.japanpkiforum.jp/shiryou/IWG_2002/FinalReport2003-Version1.0.pdf
Appendix
http://www.japanpkiforum.jp/shiryou/IWG_2002/Appendix.pdf

Regards,

-- 
Hiroyuki Nakagawa
Japan PKI Forum


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8T9QMKP023488 for <[e-mail]>; Mon, 29 Sep 2003 02:26:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8T9QM4W023487 for ietf-pkix-bks; Mon, 29 Sep 2003 02:26:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from kraid.nerim.net (smtp-101-monday.nerim.net [62.4.16.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8T9QKKP023481 for <[e-mail]>; Mon, 29 Sep 2003 02:26:21 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by kraid.nerim.net (Postfix) with ESMTP id B24EF40E4D for <[e-mail]>; Mon, 29 Sep 2003 11:26:17 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id 74DAE427C for <[e-mail]>; Mon, 29 Sep 2003 11:26:17 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 16236-04 for <[e-mail]>; Mon, 29 Sep 2003 11:26:17 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id 4707140C2 for <[e-mail]>; Mon, 29 Sep 2003 11:26:17 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Mon, 29 Sep 2003 11:26:17 +0200
From: "Julien Stern" <[e-mail]>
Date: Mon, 29 Sep 2003 11:26:17 +0200
To: [e-mail]
Subject: Not using nonce does not necessarily allow replay attacks ...
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Sep 25, 2003 at 05:41:26PM -0700, Michael Myers wrote:
> 
> The recent OCSP poll on the use of nonces has surfaced concerns
> regarding OCSP response pre-production.
> 
> Let's use this thread to discuss the issue and so keep the POLL:
> thread clear for break/no-break responses.

Having recently looked into much detail at RFC2560, I feel there are
really two totally different scenarios possible:

1) Responder with a "live" backend (Nonce MUST be used)
2) Responder with a CRL backend (Nonce do not matter)

CASE 1) The responder has access to timely information,
the "thisUpdate" field should be equal to the "producedAt" field
and the "nextUpdate" field should be absent. Nonces must clearly
be used to prevent replay attacks. Server should add a nonce even
to nonceless requests.

CASE 2) The responder is backed by a CRL, (or is acting as a keyless
proxy). The "thisUpdate" field should be the production time of the CRL,
the "nextUpdate" field the production time of the next one. Nonce should
not be used as they hinder caching and do not provide any extra security
in that setting. Sure, you can do a replay attack, but you will only
replay the same data as it won't change until the "nextUpdate" time.
Some attacks might be possible around local clock problem, but this
scenario has essentially the same security as CRLs at a much lower
traffic cost. Nonced requests should be rejected or forwarded.

I actually believe that nonce are essentially pointless for any server
without access to "live" revocation information. I think the real info
clients should be able to obtain from the servers is whether they
provide "live" info. This could be indicated by systematic inclusion of
nonces by the server even for nonceless requests. If a server does not
send a nonce, it means his info is not timely anyway, and the nextUpdate
field should be checked in order to minimize (not prevent as clocks are
not perfect) replay attacks.

If a client knows in advance if the server is "live" or CRL based, I
believe there is no difficulty. The major difficulty for a client is
to figure out whether a server is live or not.

The only thing I would (personaly humbly) truly mandate is to consider
as malformed a response without a nonce and without a "nextUpdate"
field. A replayable response without an expiration date is just plain
bad. This is why I believe it should be mandatory for "live" servers to
include a nonce in every response.

--
Julien


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8T0enKP043863 for <[e-mail]>; Sun, 28 Sep 2003 17:40:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8T0enrT043862 for ietf-pkix-bks; Sun, 28 Sep 2003 17:40:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailo.ntcif.telstra.com.au ([202.12.233.17]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8T0elKP043853 for <[e-mail]>; Sun, 28 Sep 2003 17:40:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from uucp@localhost) by mailo.ntcif.telstra.com.au (8.8.2/8.6.9) id KAA04098 for <[e-mail]>; Mon, 29 Sep 2003 10:40:34 +1000 (EST)
Received: from webi.ntcif.telstra.com.au(202.12.162.19), claiming to be "mailbi.ntcif.telstra.com.au" via SMTP by mailo.ntcif.telstra.com.au, id smtpdX0aWce; Mon Sep 29 10:37:29 2003
Received: (from uucp@localhost) by mailbi.ntcif.telstra.com.au (8.8.2/8.6.9) id KAA29804 for <[e-mail]>; Mon, 29 Sep 2003 10:37:23 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpddqaWF5; Mon Sep 29 10:36:40 2003
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA18378 for <[e-mail]>; Mon, 29 Sep 2003 10:36:39 +1000 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: OCSP response pre-production
Date: Mon, 29 Sep 2003 10:36:25 +1000
Message-ID: <[e-mail]>
Thread-Topic: OCSP response pre-production
Thread-Index: AcOEgkw74jv3Wo8DSy6E0YMn+7SFkQBmvKPQ
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8T0enKP043858
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Nice solution, Florian.


Adding a nonce at the server when the client didn't include one *sounds* silly.  A different way of describing the same solution would be...

A server that can handle nonces should indicate this ability when responding to a request that did not include a nonce.  One way to indicate this is to include a nonce in the response.
Note: the same "nonce" can be included in every response to requests without nonces.  This still allows responses to nonce-less requests to be cached.  It might even be worth defining a "standard" "nonce" for this purpose (eg a empty octet string or a single 0x00 byte).

Responses from cache-only OCSP systems will not include the nonce extension.
Responses from other (nonce-capable) OCSP systems will include the nonce extension (populated with the request's nonce if present or some "dummy" value otherwise).

This allows clients to distinguish cache-only OCSP systems from the others.  Consequently, clients can be configured to ask for the freshest possible response (include a nonce) but accept nonce-less responses **only if** that is the best the system has to offer.  An attacker cannot make a nonce-capable system look like a cache-only system.



----------
From: Florian Oelmaier [mailto:[e-mail]]
Sent: Saturday, 27 September 2003 7:29 AM
To: 'Deacon, Alex'; 'Michael Myers'; 'David Engberg'
Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; [e-mail]; 'Russ
Housley'; 'Stephen Kent'; 'Tim Polk'
Subject: RE: OCSP response pre-production

> I don't understand how adding a server generated nonce would 
> help in this situation.  How does this help the client 
> protect against replay attacks?
> 
> Alex



Client Type I) Given you have a client with the following behaviour:
A) always includes a nonce into his request
B) accepts responses without nonce

If an attacker is able to get a response without nonce from a responder,
he can replay that response to your client and the client will accept it
(rule B). So we have to ensure, that the attacker is NOT able to get a
response without nonce. Thus we simply add a server-generated nonce to
every response not already having a copy of a request-nonce.

This way, an attacker cannot get a response without a nonce. In
conclusion he can not get data to fool your client.




Client Type II) Given you have a client with the following behaviour:
A) does not includes a nonce into his request

A server generated nonce does not help this client anything (but also
does not harm it). He is in every case in danger of replay attacks.
(BTW: an attacker would use such a client to get a response without
nonce from your OCSP responder.)



Client Type III) Given you have a client with the following behaviour:
A) always includes a nonce into his request
B) does NOT accept responses without nonce

This client is never subject to a replay attack. A server generated
nonce does not improve anything (but also does not harm it).




So the proposed server-generated nonces are simply a mechanism to allow
Client Type I operate securely. I fully agree with you, that such a
client behaviour (accepting responses without nonce) seems to be
desirable from an operating point of view.

-- 
Florian Oelmaier
SyTrust

> 
> 
> > -----Original Message-----
> > From: Florian Oelmaier [mailto:[e-mail]]
> > Sent: Friday, September 26, 2003 10:37 AM
> > To: 'Michael Myers'; 'David Engberg'
> > Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; [e-mail]; 'Russ
> > Housley'; 'Stephen Kent'; 'Tim Polk'
> > Subject: RE: OCSP response pre-production
> > 
> > 
> > 
> > [...]
> > 
> > > Thus "Maybe the nonce is incorporated, maybe not" is
> > > equivalent to NOT sending a nonce in the first place.  Which 
> > > rather defeats the purpose of sending a nonce.
> > 
> > Thats true. But this can be "cured"! If an OCSP-Responders
> > that is able
> > to use nonces, detects a request without nonce, he simply includes a
> > self-generated nonce into his response. Thus an attacker is 
> > not able to
> > obtain a response without nonce from this particular 
> > responder. Thus he
> > cannot fool the client with a replay attack.
> > 
> > The client behaviour you describe is exactly the reason why our 
> > responder (in its default configuration) will currently 
> ALWAYS include 
> > a nonce into the response (even at the cost of generating one
> > by itself).
> > 
> > This way nonces are of value when used with a responder 
> being able to 
> > use them while simultaneous allowing response pre-production.
> > 
> > --
> > Florian Oelmaier
> > SyTrust
> > 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8SDMcKP023169 for <[e-mail]>; Sun, 28 Sep 2003 06:22:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8SDMcoh023168 for ietf-pkix-bks; Sun, 28 Sep 2003 06:22:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8SDMbKP023161 for <[e-mail]>; Sun, 28 Sep 2003 06:22:37 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc12) with ESMTP id <2003092813222701400fausve>; Sun, 28 Sep 2003 13:22:28 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1A3bY0-00037F-00; Sun, 28 Sep 2003 09:25:12 -0400
Message-ID: <[e-mail]>
Date: Sun, 28 Sep 2003 09:25:11 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vadim Fedukovich <[e-mail]>
CC: [e-mail]
Subject: Re: would a key-less responder make better security
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Vadim Fedukovich wrote:
> Why not compare with a responder using CA status database instead of CRLs?
> Database could be locked to serialize events and this makes it possible
> to report current status with no chance at all for race on "this-day" status.
>
> At least one responder do use CA database for reporting.
> Yes, here's the same risk of responder/host compromise and precise status
> reporting trade-off.

Exactly:  only a responder that actually runs AT the CA will ever truly 
give you a fresh response when you send it a nonce.  Any responder based 
on multi-hour CRLs will only give you the illusion of freshness.

Of course, if you need to support more than a trivial PKI with one 
physical site, a single responder running at the CA won't scale to your 
needs, even if you accept the security risk of thousands of online 
requests per minute into your CA environment.


> Yes any signing or verifying signatures software is in sharp contrast
> with popular gaming PC stuff. I'd consider this issue as general need
> for secure code and a bit irrelevant caching- or signing OCSP responder.

Ultimately, one needs to consider why it is a good idea for CAs (or at 
least the root) in a real PKI to be deployed offline.  If your 
firewalls, IDS, HSM, web servers, and armed guards are perfect, you 
don't need an offline CA, but most people choose not to make that 
assumption.

The difference between compromising a Traditional OCSP responder and a 
Distributed (caching-only) OCSP responder is similar to the difference 
between compromising a CA versus its LDAP directory.  By compromising a 
CA, I can forge a certificate or CRL that will be universally accepted, 
saying whatever I like.  This attack may not be detected until its 
consequences are felt.

Compromising the LDAP directory could allow me to replay a CRL for a few 
hours after its replacement is published, but that's about it. 
Attempting to replay an expired CRL will be immediately noticed by every 
client, who will call the IT department to complain.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8SBPKKP019479 for <[e-mail]>; Sun, 28 Sep 2003 04:25:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8SBPJAu019478 for ietf-pkix-bks; Sun, 28 Sep 2003 04:25:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.aauckland.ac.nz [130.216.33.151] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8SBPHKP019471 for <[e-mail]>; Sun, 28 Sep 2003 04:25:18 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h8SBPChL002852; Sun, 28 Sep 2003 23:25:12 +1200
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h8SBPo007393; Sun, 28 Sep 2003 23:25:50 +1200
Date: Sun, 28 Sep 2003 23:25:50 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: would a key-less responder make better security
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>

Vadim Fedukovich <[e-mail]> writes:
 
>both attack types mentioned have an established business so to say: one can
>try own the host or try to get host effectively down. Both results in an
>asset of some sort. One should expect there will be man-in-the-middle if it
>could result in something better that just demonstration.

The difference between a simple [0] attack on the two types of responder is
that if someone DOSes my responder, I can report it to the RP as a potential
problem and they can fall back to a secondary mechanism, e.g.make decisions
based on a floor-limit mechanism, use another channel for checking, refuse to
do anything until things are back to normal, or whatever, depending on what
the accepted practice is in their industry.  If someone replays "Everything's
OK" messages, I have no idea that there's a problem.  Allowing cached
responses is therefore "better" only in the sense that the RP is made
oblivious to the fact that someone's attacking them.  This seems to be a very
odd definition of "better"... it's a bit like anaesthetising someone so they
don't notice a mugger beating them over the head with a baseball bat in order
to steal their money.

Peter.

[0] Meaning something other than some haxor 0wning your server, in which case
    all bets are off no matter what model you're using.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8S6MhKP072163 for <[e-mail]>; Sat, 27 Sep 2003 23:22:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8S6MhBm072162 for ietf-pkix-bks; Sat, 27 Sep 2003 23:22:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from localhost.intranet (cl0.unity.net [195.24.141.128]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8S6MZKP072102 for <[e-mail]>; Sat, 27 Sep 2003 23:22:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from vf@localhost) by localhost.intranet (8.9.3/8.8.8/Debian/GNU) id JAA00714; Sun, 28 Sep 2003 09:11:05 +0300
Date: Sun, 28 Sep 2003 09:11:05 +0300
From: Vadim Fedukovich <[e-mail]>
To: [e-mail]
Cc: David Engberg <[e-mail]>
Subject: Re: would a key-less responder make better security
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Sep 26, 2003 at 03:26:59PM -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>

hi David,

On Fri, Sep 26, 2003 at 03:26:59PM -0400, David Engberg wrote:
> 
> Vadim -
> 
> Thanks for the feedback on the nonce paper.
> 
> Anecdotal evidence from CERT advisories and similar sources indicates 
> that network takeover attacks and denials-of-service are much more 
> common than man-in-the-middle (e.g. "replay") attacks, but this is 
> hardly scientific.  If I wanted to severely disrupt your PKI, I know 
> which attack I would attempt first, however.

both attack types mentioned have an established business so to say:
one can try own the host or try to get host effectively down. Both results
in an asset of some sort. One should expect there will be man-in-the-middle
if it could result in something better that just demonstration.

Most important here, "replay" is not exactly "man-in-the-middle".
Schoolbook man-in-the-middle use it's own keys to decrypt messages intended
for someone else and re-encrypt with recipient key.
Replay copy a message and use it to replace some other response the next
minute (or maybe msec) without changing saved copy of 1st message.

> In practice, an out-of-sync clock on a client is noticed and corrected 
> immediately since current, valid responses will be constantly rejected. 
>   However, an attacker that knew of an unnoticed backwards (not 
> forwards) clock skew on a specific client could theoretically replay a 
> stored response from this period to that client.  Obviously, a serious 
> clock skew will screw up many other parts of your PKI as well (accepting 
> expired certificates, etc.).

There are well-known race attacks that stands on tiny time slice while
manipulating files that makes no chance for a human typing commands
with shell but still allow a process to catch it.

> I strongly disagree with your third point.  An attack on a caching-only 
> responder can only replay "valid" responses that have not already 
> expired.  If the responder issued a "valid" response for cert #1234 in 
> the morning and you compromise it at noon, you could keep replyaing that 
> response for the rest of that "day" only.  After expiration, every 
> client will reject the response.  These responses are typically the same 
> duration as the CRL, so this is similar to saying that "if I compromise 
> your LDAP directory, I can replay your CRL for the rest of the day." 
> Obviously, a traditional OCSP responder based off of the same CRL will 
> keep providing the same "valid" response throughout that day until the 
> next CRL is released, but it will give you the illusion of freshness 
> with its nonces.

Sure a practical attack would try to race status update process
instead of replaying last year status.

Why not compare with a responder using CA status database instead of CRLs?
Database could be locked to serialize events and this makes it possible
to report current status with no chance at all for race on "this-day" status.

At least one responder do use CA database for reporting.
Yes, here's the same risk of responder/host compromise and precise status
reporting trade-off.

> Contrast this with what I can do if I attack your key-bearing server in 
> the same way that Kerberos was compromised last year.  I can create a 
> response for ANY certificate that says it is revoked or that it is 
> valid.  This can be used to reinstate a stolen ID card that was revoked 
> six months ago, which may allow me to walk in to a secure facility, or 
> it can be used to falsely revoke any valid certificate, potentially 
> disrupting critical operations.  This is much more severe than the risk 
> of keeping a certificate valid for a few extra minutes or hours on the 
> day it is revoked.

Yes any signing or verifying signatures software is in sharp contrast
with popular gaming PC stuff. I'd consider this issue as general need
for secure code and a bit irrelevant caching- or signing OCSP responder.

Yes, a race attack would unlikely let a human walk in a secure facility
but could let some faster event happen.

regards,
Vadim

> 
> Thanks,
> David
> 
> 
> Vadim Fedukovich wrote:
> > On Thu, Sep 25, 2003 at 05:44:53PM -0400, David Engberg wrote:
> > 
> >>
> >>No, we would not like to see the language change.  Yes, it would break 
> >>existing deployments based on caching-only responders.
> >>
> >>
> >>Explanation:
> >>
> >>There is a (strong) case to be made that a large OCSP deployment based 
> >>around caching-only responders with no private keys to protect can be 
> >>more secure against real-world attacks than one based entirely on 
> >>live-signing responders using nonces:
> >>
> >>    http://www.corestreet.com/whitepapers/nonce-sense.pdf
> > 
> > 
> > So, "a server without any signing key will have nothing to lose"
> > as I read it. Yes, it makes some sense. However some people still
> > chose SSL-capable web servers sometimes.
> > 
> > Something missing in this paper is a trade-off analysis like what kind
> > of responder fits business better:
> >   fresh response indicating current status with a risk of responder's
> >   key compromise because of a buffer overflow
> > or
> >   somewhat stale responses with less risk of compromising the key
> >   used by another task maybe on another host.
> > Such an analysis might include human errors and program bugs statistics
> > 
> > Also missing the case mentioned by Peter Gutmann with out-of-sync
> > clock at the client.
> > 
> > At last, old stale responses might be replayed by an attacker in case of
> > successful buffer overflow to keep already revoked certificate "valid".
> > This means bug-free responder software is a point with no route-around
> > either with or without signing key online.
> > 
> > I do believe 3 points mentioned contribute to "real-world security"
> > so it's hard to agree with "significantly higher overall security"
> > wording in the paper.
> > 
> > regards,
> > Vadim
> > 
> > 
> >>It would be undesirable to change the specification to break existing 
> >>implementations and deployments that chose this route.
> >>
> >>
> > 
> > 

-- 
Naina library: http://www.unity.net/~vf/naina_r1.tgz


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8S347KP038007 for <[e-mail]>; Sat, 27 Sep 2003 20:04:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8S34740038006 for ietf-pkix-bks; Sat, 27 Sep 2003 20:04:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8S345KP037998 for <[e-mail]>; Sat, 27 Sep 2003 20:04:05 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip21.124-173-207.eli-du.nwlink.com [207.173.124.21]) by smtp1.pacifier.net (Postfix) with ESMTP id 98A716F91F; Sat, 27 Sep 2003 20:04:01 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Subject: WG last call re draft-pkix-acpolicies-extn-03.txt
Date: Sat, 27 Sep 2003 20:05:35 -0700
Message-ID: <003601c3856d$6c1b6510$[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, Build 10.0.2627
In-Reply-To: <p06002001bb8f6665c4e7@[12.159.173.165]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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,

No judgement on good or badness of concept however the following present
implementation issues:

1.  Section 2.3 says that this document defines two policies which are
SIMILAR to those for public keys and then appears to use the save value.
Is this intended and if so then the text should be cleaned up.

2.  What is the correct behavior if the extension is non-criticial, the
extension is recognized, but none of the policy identifiers are
recognized?



ASN Module:

1.  Need to uncomment the imports statement

2.  need to add a semi-colon following the import of PolicyQualifiedId

3.  PolicyQualifiedId needs to be imported form PKIXImplicit88.

4.  id-pkix needs to be imported.

5.  ac-policies does needs to have "SYNTAX" and "IDENTIFIED BY" changed
as this is not correct 1988 syntax.

6.  EXTENSION is not an identified type.

7.  ac-policiesSyntax should start with an upper case letter as it is a
type.

8.  acPolicyId should start with an upper case letter as it is a type.


Jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8RJq4KP023134 for <[e-mail]>; Sat, 27 Sep 2003 12:52:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8RJq4JU023133 for ietf-pkix-bks; Sat, 27 Sep 2003 12:52:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8RJpnKQ023119; Sat, 27 Sep 2003 12:51:49 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002024bb9b9916d9f3@[63.202.92.152]>
In-Reply-To: <002a01c3852a$da0e3270$4228a8c0@hagen>
References: <002a01c3852a$da0e3270$4228a8c0@hagen>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Sat, 27 Sep 2003 12:53:47 -0700
To: "Florian Oelmaier" <[e-mail]>, "'Deacon, Alex'" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, "'Michael Myers'" <[e-mail]>, "'David Engberg'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: OCSP response pre-production
Cc: "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'Tim Polk'" <[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:09 PM +0200 9/27/03, Florian Oelmaier wrote:
>with all due respect: Please quote the paragraph of RfC 2560 stating
>that a response without nonce is "malformed".

This is exactly what we are trying to write up now.

>I am very sure that all client
>implementors out there are aware of this situation. All my test of OCSP
>clients back this statement up - most reject these reponses, but all are
>able to deal with the situation.

This is a very valuable data point, and one that is quite relevant to 
Mike's initial question. If it is true (we'd need to ask the 
implementers again), it would certainly make it possibl for the WG to 
go towards a solution like Alex's which puts the onus on the client 
to decide what to do with a response from a server that didn't do 
what it was told to.

>Summary: Right now the RfC is VERY CLEAR in this point: a response
>without nonce to a request with nonce is NOT MALFORMED and completely
>conform with RfC2560.

It is malformed if you read section 4.4.1 as requiring a nonce in the 
response when it was included in the query, as many people here have 
interpreted. "Optional" doesn't mean "can be put in or omitted at 
will".

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8RJhKKP022740 for <[e-mail]>; Sat, 27 Sep 2003 12:43:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8RJhKK4022739 for ietf-pkix-bks; Sat, 27 Sep 2003 12:43:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8RJhJKP022734 for <[e-mail]>; Sat, 27 Sep 2003 12:43:19 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8RJhKt52800 for <[e-mail]>; Sat, 27 Sep 2003 12:43:20 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Sat, 27 Sep 2003 12:46:53 -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: <002a01c3852a$da0e3270$4228a8c0@hagen>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"malformed" should be used to signal server-side syntax parsing
errors.

Yes, we have a hole with respect to signaling
"nonces-not-supported" and the consequent client-side behavior
in that instance.

I have several inputs along those lines, some privately
communicated.  Once I get this formed up into a coherent path
forward, I'll toss it out for discussion.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8RJ9hKP021156 for <[e-mail]>; Sat, 27 Sep 2003 12:09:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8RJ9hmc021155 for ietf-pkix-bks; Sat, 27 Sep 2003 12:09:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8RJ9fKP021136; Sat, 27 Sep 2003 12:09:41 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd08.aul.t-online.de  by mailout07.sul.t-online.com with smtp  id 1A3KRX-0005vM-02; Sat, 27 Sep 2003 21:09:23 +0200
Received: from hagen (ThqmqoZXre2cj3usZWtmZz72MLj8VwaMeA-9NaoeiwrEYMlImp61Zx@[217.228.237.228]) by fmrl08.sul.t-online.com with esmtp id 1A3KRS-1Inczg0; Sat, 27 Sep 2003 21:09:18 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Paul Hoffman / IMC'" <[e-mail]>, "'Deacon, Alex'" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, "'Michael Myers'" <[e-mail]>, "'David Engberg'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, <[e-mail]>
Cc: "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'Tim Polk'" <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Sat, 27 Sep 2003 21:09:17 +0200
Organization: SyTrust
Message-ID: <002a01c3852a$da0e3270$4228a8c0@hagen>
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
In-Reply-To: <p06002019bb9b7d1148a4@[63.202.92.152]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-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>

> >   As I stated in my response to Russ, the responder could reject a 
> >request with a nonce, but why not reply with a request 
> without a nonce, 
> >and let the client decided if it wants to accept or reject it.
> 
> This does not make sense from an interoperability standpoint. If the 
> responder does not have control of the clients, why do you say that 
> the responder should send back malformed responses and let the client 
> deal with them? If you have no control over the clients, you cannot 
> assume that clients will be able to deal with malformed responses.

Paul,

with all due respect: Please quote the paragraph of RfC 2560 stating
that a response without nonce is "malformed". This statement is simply
not true - if you wanted it to be true, you should have included it into
the RfC 3 years ago. 

As it stands now, nonces are optional on both sides: server and client.
If the server does not support nonces, it may as well respond without
nonce. This is conform with the published state of RfC2560 and the
clients have to deal with it. I am very sure that all client
implementors out there are aware of this situation. All my test of OCSP
clients back this statement up - most reject these reponses, but all are
able to deal with the situation.

-- 
Florian Oelmaier
SyTrust


PS: Currently RfC2560 states:

--------------
[...]
An OCSP request contains the following data:

   -- protocol version
   -- service request
   -- target certificate identifier
   -- optional extensions which MAY be processed by the OCSP Responder
[...]
A definitive response message is composed of:

   -- version of the response syntax
   -- name of the responder
   -- responses for each of the certificates in a request
   -- optional extensions
   -- signature algorithm OID
   -- signature computed across hash of the response
[...]
This section defines some standard extensions, based on the extension
model employed in X.509 version 3 certificates see [RFC2459]. Support
for all extensions is optional for both clients and responders.
[...]
--------------

Summary: Right now the RfC is VERY CLEAR in this point: a response
without nonce to a request with nonce is NOT MALFORMED and completely
conform with RfC2560.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8RHqQKP018145 for <[e-mail]>; Sat, 27 Sep 2003 10:52:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8RHqQ6q018144 for ietf-pkix-bks; Sat, 27 Sep 2003 10:52:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8RHq2KQ018134; Sat, 27 Sep 2003 10:52:03 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002019bb9b7d1148a4@[63.202.92.152]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Sat, 27 Sep 2003 10:54:19 -0700
To: "Deacon, Alex" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, Michael Myers <[e-mail]>, David Engberg	 <[e-mail]>, [e-mail], Ambarish Malpani	 <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: OCSP response pre-production
Cc: Russ Housley <[e-mail]>, Stephen Kent <[e-mail]>, Tim Polk <[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 2:08 PM -0700 9/26/03, Deacon, Alex wrote:
>This summary assumes that the OCSP responder has control of the OCSP
>clients.

No, it very explicitly doesn't.

>   This may not be the case, especially when responding to OCSP
>requests for certs issued from SSL CA's (i.e. every flavor of browser/ocsp
>client on earth).

Correct.

>   As I stated in my response to Russ, the responder could
>reject a request with a nonce, but why not reply with a request without a
>nonce, and let the client decided if it wants to accept or reject it.

This does not make sense from an interoperability standpoint. If the 
responder does not have control of the clients, why do you say that 
the responder should send back malformed responses and let the client 
deal with them? If you have no control over the clients, you cannot 
assume that clients will be able to deal with malformed responses.

>   If a
>client requires that the nonce in the result, the result is the same, the
>response is rejected.

No, the new result is that the client is confused by the malformed 
response. This is much worse.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8RHpbKP018121 for <[e-mail]>; Sat, 27 Sep 2003 10:51:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8RHpajt018120 for ietf-pkix-bks; Sat, 27 Sep 2003 10:51:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8RHpXKQ018113; Sat, 27 Sep 2003 10:51:33 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0600201abb9b7ed6b2f0@[63.202.92.152]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Sat, 27 Sep 2003 10:53:48 -0700
To: "Deacon, Alex" <[e-mail]>, "'Russ Housley'" <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: OCSP response pre-production (was RE: POLL:  Use of nonces in OCS 	P)
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:55 PM -0700 9/26/03, Deacon, Alex wrote:
>Hi Russ,
>
>Agreed, however we do not have control of all OCSP clients.  In the case
>where a responder is using pre-produced responses and can't respond to a
>request with a nonce, the responder can do one of two things:
>
>1) Send the pre-produced response without the nonce
>2) return a malformedReqest OCSPResponseStatus

That's not the correct status: "internalError" is much more 
appropriate. The request is *not* malformed: it is the responder that 
has an error (namely, that it cannot handle a valid request).

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8R0dLKP018209 for <[e-mail]>; Fri, 26 Sep 2003 17:39:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8R0dLgq018208 for ietf-pkix-bks; Fri, 26 Sep 2003 17:39:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8R0dJKP018198 for <[e-mail]>; Fri, 26 Sep 2003 17:39:19 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Sep 2003 19:39:25 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: "'Julien Pierre'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP and Nonces
Date: Fri, 26 Sep 2003 19:37:02 -0500
Message-ID: <003201c3848f$7b017a30$[e-mail]>
MIME-Version: 1.0
Content-Type: application/pkcs7-mime; smime-type=signed-data; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 27 Sep 2003 00:39:25.0859 (UTC) FILETIME=[CD736F30:01C3848F]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEggUsQ29u
dGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9InVzLWFzY2lpIg0KQ29udGVudC1UcmFu
c2Zlci1FbmNvZGluZzogN2JpdA0KDQoNCj4gPiBDYWNoZWQgcmVzcG9uc2VzIGNhbiBiZSB0cmVh
dGVkIGFzIENSTHMgKGNoZWNrZWQgZm9yIHRpbWUgdmFsaWRpdHkNCj4gPiB1c2luZyB0aGUgVGhp
c1VwZGF0ZSBhbmQgTmV4dFVwZGF0ZSBmaWVsZHMpLiBXZSBkb24ndCB3b3JyeSBhYm91dA0KPiA+
IHJlcGxheSBhdHRhY2tzIHdoZW4gdXNpbmcgQ1JMcy4NCj4gPg0KPiANCj4gRG9uJ3QgYmUgc28g
c3VyZS4gSSBoYXZlIGFjdHVhbGx5IHdyaXR0ZW4gc29tZSB2ZXJ5IHBhcmFub2lkIGNvZGUgaW4g
YQ0KPiBzZXJ2ZXIgYXBwbGljYXRpb24sIHdoaWNoIGNhbiBiZSBjb25maWd1cmVkIHRvIHJlcXVp
cmUgQ1JMcyB0byBiZQ0Kd2l0aGluDQo+IGEgY2VydGFpbiAiYWdlIiwgcmVnYXJkbGVzcyBvZiB0
aGUgdmFsdWUgb2YgbmV4dHVwZGF0ZS4gVGhpcw0KYXBwbGljYXRpb24NCj4gc2V0dGluZyBpcyBw
YXJ0aWN1bGFybHkgdXNlZnVsIGlmIHRoZXJlIGlzIG5vIG5leHR1cGRhdGUgaW4gdGhlIENSTCBp
bg0KPiB0aGUgZmlyc3QgcGxhY2UuDQo+IEluIHRoaXMgY2FzZSwgdGhlIHNlcnZlciBjb25zaWRl
cnMgdGhhdCB0aGF0IGl0IGNhbm5vdCBwZXJmb3JtIGFuDQo+IHVwLXRvLWRhdGUgcmV2b2NhdGlv
biBjaGVjayBvZiB0aGUgY2xpZW50IGNlcnRpZmljYXRlIGJlY2F1c2UgdGhlIENSTA0KaXQNCj4g
aGFzIGlzIHRvbyBvbGQuIEl0IHdpbGwgdGhlbiBlaXRoZXIgcmVqZWN0IGFsbCBjbGllbnQgY2Vy
dHMgZnJvbSB0aGUNCj4gaXNzdWVyLCB1bnRpbCBpdCBhY3F1aXJlcyBhbiBhZGVxdWF0ZWx5IHJl
Y2VudCBDUkwsIG9yIHdpbGwgc2h1dA0KaXRzZWxmDQo+IGRvd24gKGlmIHRoZSBzeXNhZG1pbiBp
cyByZWFsbHkgdmVyeSBwYXJhbm9pZCkuIENlcnRhaW5seSB0aGlzIGRvZXNuJ3QNCj4gZm9sbG93
IHRoZSBzdGFuZGFyZCwgYnV0IHRoZSBhcHBsaWNhdGlvbiB1c2luZyBDUkxzICpjYW4qIHByb3Rl
Y3QNCml0c2VsZg0KPiBhZ2FpbnN0IENSTCByZXBsYXkgYXR0YWNrcyBpbiB0aGlzIHdheS4NCg0K
T0ssIHNvIHlvdSBjYW4gcHJvdGVjdCBpbiBzb21lIHdheSB3aXRob3V0IHVzaW5nIG5vbmNlcywg
cmlnaHQ/DQpNeSBwb2ludCB3YXMgdGhhdCBub25jZXMgbWFrZSBzZW5zZSBvbmx5IGZvciBmcmVz
aCBPQ1NQIHJlc3BvbnNlcy4NCkNhY2hlZCByZXNwb25zZXMgY2FuIGJlIHRyZWF0ZWQgYXMgQ1JM
cyBhcyB5b3UgcG9pbnRlZCBvdXQuDQoNCk1pZ3VlbCBBIFJvZHJpZ3Vleg0KU2VndXJpREFUQQ0K
TWV4aWNvDQoNCgAAAAAAAKCCAyYwggMiMIICi6ADAgECAhUwMDAwMDEwMDAwMDE1MDAwMDAwMTAw
DQYJKoZIhvcNAQEFBQAwgb4xITAfBgNVBAMTGEFudG9uaW8gIFJlc2VuZGl6ICBMaW1hczExMC8G
A1UECRMoUHJpdi4gU3RhIEx1Y2lhIDczICA3MyAgMzA0ICBPbGl2YXIgIDEyMzEOMAwGA1UEERMF
MDE0MDAxCzAJBgNVBAYTAk1YMQ8wDQYDVQQIEwZNZXhpY28xHzAdBgNVBAcTFkFsdmFybyBPYnJl
Z29uICBNZXhpY28xFzAVBgNVBC0DDgBSRUxBNzIxMTE0M0w3MB4XDTAzMDUyNjAwMDAwMFoXDTA0
MDUyNTAwMDAwMFowVzETMBEGA1UEChMKU2VndXJpREFUQTEPMA0GA1UEAxMGTWFycyAzMQswCQYD
VQQGEwJNWDEiMCAGCSqGSIb3DQEJARYTbWFyc0BzZWd1cmlkYXRhLmNvbTCBnzANBgkqhkiG9w0B
AQEFAAOBjQAwgYkCgYEApcHJ2NPJy2xUVbjjfTgOdcXOEg3MBPVPZvdGv20rCDrVCLaKQ32hmrN3
xmnbtWQQQe0tAVU/2x5HWpfpII4PErkeEor0c30dqlEosLuIRqV6fa+oKguJb9qY6uF4Vudl1hqp
vmCoZOLIZvBO+uWUS5kOl7WXp0r52/rQ1C5AkPkCAwEAAaOBgTB/MDIGA1UdHwQrMCkwJ6AloCOG
IWh0dHA6Ly8xOTIuMTY4LjAuMTczL2NybC9sYXN0LmNybDAdBgNVHSUEFjAUBggrBgEFBQcDBAYI
KwYBBQUHAwIwCQYDVR0TBAIwADAMBgNVHQ8EBQMDB+gAMBEGCWCGSAGG+EIBAQQEAwIAoDANBgkq
hkiG9w0BAQUFAAOBgQCZRh7aM5ikilSUW2OjOmUfnGFk80uJvqkbDu7irZhtKG0VC0hPx+V+DamR
+D4xLs3auUWRWkk2F/xs89SMCG7naaONRJgtZg8oYlHt0KjDun0JESNWv7ShvzYv0SQmM7FCI9ii
AOYOj3voh5DLkNjFJo4W69UY+JNX+vTy8xunKzGCBCMwggQfAgEBMIHYMIG+MSEwHwYDVQQDExhB
bnRvbmlvICBSZXNlbmRpeiAgTGltYXMxMTAvBgNVBAkTKFByaXYuIFN0YSBMdWNpYSA3MyAgNzMg
IDMwNCAgT2xpdmFyICAxMjMxDjAMBgNVBBETBTAxNDAwMQswCQYDVQQGEwJNWDEPMA0GA1UECBMG
TWV4aWNvMR8wHQYDVQQHExZBbHZhcm8gT2JyZWdvbiAgTWV4aWNvMRcwFQYDVQQtAw4AUkVMQTcy
MTExNDNMNwIVMDAwMDAxMDAwMDAxNTAwMDAwMDEwMAkGBSsOAwIaBQCgggKgMBgGCSqGSIb3DQEJ
AzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAzMDkyNzAwMzcwMVowIwYJKoZIhvcNAQkE
MRYEFAffLkant7N4KNA0ohyiDtdSt9tQMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwBwYF
Kw4DAhowDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC
AgEoMAoGCCqGSIb3DQIFMIHpBgkrBgEEAYI3EAQxgdswgdgwgb4xITAfBgNVBAMTGEFudG9uaW8g
IFJlc2VuZGl6ICBMaW1hczExMC8GA1UECRMoUHJpdi4gU3RhIEx1Y2lhIDczICA3MyAgMzA0ICBP
bGl2YXIgIDEyMzEOMAwGA1UEERMFMDE0MDAxCzAJBgNVBAYTAk1YMQ8wDQYDVQQIEwZNZXhpY28x
HzAdBgNVBAcTFkFsdmFybyBPYnJlZ29uICBNZXhpY28xFzAVBgNVBC0DDgBSRUxBNzIxMTE0M0w3
AhUwMDAwMDEwMDAwMDE1MDAwMDAwMTAwgesGCyqGSIb3DQEJEAILMYHboIHYMIG+MSEwHwYDVQQD
ExhBbnRvbmlvICBSZXNlbmRpeiAgTGltYXMxMTAvBgNVBAkTKFByaXYuIFN0YSBMdWNpYSA3MyAg
NzMgIDMwNCAgT2xpdmFyICAxMjMxDjAMBgNVBBETBTAxNDAwMQswCQYDVQQGEwJNWDEPMA0GA1UE
CBMGTWV4aWNvMR8wHQYDVQQHExZBbHZhcm8gT2JyZWdvbiAgTWV4aWNvMRcwFQYDVQQtAw4AUkVM
QTcyMTExNDNMNwIVMDAwMDAxMDAwMDAxNTAwMDAwMDEwMA0GCSqGSIb3DQEBAQUABIGASbz6pGWG
ZRcXmguFv5fL6UkkSBi+czI8YG32Pwo/BYwN4eOZZTQXqESrB3om4XOU3rw6pPfqPu1HuFcC3qhp
FG5WBJ80ro3VY2ySDFc2xxSuu94P+9rPJThPZfLbuupYMB7RpUa84A66u2PwTWUE6kTaqv38uQbP
z0mWIiHpApMAAAAAAAA=




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QMr2KP013673 for <[e-mail]>; Fri, 26 Sep 2003 15:53:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QMr2Nw013672 for ietf-pkix-bks; Fri, 26 Sep 2003 15:53:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QMr0KP013657 for <[e-mail]>; Fri, 26 Sep 2003 15:53:01 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Sep 2003 17:54:05 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 17:51:59 -0500
Message-ID: <000501c38480$ce62fd20$[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, Build 10.0.2627
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 26 Sep 2003 22:54:05.0890 (UTC) FILETIME=[1674B220:01C38481]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Cached (pre-produced) responses can be treated as CRLs (checked for time
validity using the ThisUpdate and NextUpdate fields). We don't worry
about replay attacks when using CRLs. 

If we want to enable the client to work with both fresh and cached
responses we could include a nonce in the request and accept responses
without it. Of course this means that we are giving up prevention
against replay attacks. This prevention only makes sense for fresh
responses. The bad scenario is a replay attack for fresh responses, how
can we avoid it? Maybe by having a way to distinguish fresh responses
from cached ones. Then the client can reject a fresh response without
the nonce included in the request. 

Opinions are welcomed,

Miguel A Rodriguez
SeguriDATA 
Mexico




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QMLjKP012182 for <[e-mail]>; Fri, 26 Sep 2003 15:21:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QMLj0R012181 for ietf-pkix-bks; Fri, 26 Sep 2003 15:21:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QMLiKP012176 for <[e-mail]>; Fri, 26 Sep 2003 15:21:44 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8QMLjt15750; Fri, 26 Sep 2003 15:21:45 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Deacon, Alex" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 15:25:17 -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]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alex,

I will, once I get them all integrated.  Given the volume of
today's discussions, that will likely be sometime early next
week.

Mike



> -----Original Message-----
> From: Deacon, Alex [mailto:[e-mail]]
> Sent: Friday, September 26, 2003 3:13 PM
> To: 'Michael Myers'; Deacon, Alex; [e-mail]
> Subject: RE: OCSP response pre-production
>
>
>
> Mike,
>
> As there has been some suggested changes to the text,
> can you post the most
> recent wording to get everyone back on the same page?
>
> Thanks
> Alex
>
>
> > -----Original Message-----
> > From: Michael Myers [mailto:[e-mail]]
> > Sent: Friday, September 26, 2003 2:35 PM
> > To: Deacon, Alex; [e-mail]
> > Subject: RE: OCSP response pre-production
> >
> >
> > Alex,
> >
> > I'm willing to discuss client-side "nonce
> capability discovery"
> > via this mechanism but it's clearly a v2 proposition.
> > Meanwhile, we're working to clarify what we meant
> in v1 when we
> > defined nonces in the first place.  The poll
> clearly establishes
> > a nearly unanimous consensus that the common
> understanding in
> > place at the time found its way into running code
> in all but, to
> > date, one case.  I propose we proceed on this basis.
> >
> > Mike
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Deacon, Alex [mailto:[e-mail]]
> > > Sent: Friday, September 26, 2003 2:09 PM
> > > To: 'Ryan M. Hurst'; Paul Hoffman / IMC; Michael
> > > Myers; David Engberg;
> > > [e-mail]; Ambarish Malpani; [e-mail]
> > > Cc: Russ Housley; Stephen Kent; Tim Polk
> > > Subject: RE: OCSP response pre-production
> > >
> > >
> > >
> > > This summary assumes that the OCSP responder has
> > > control of the OCSP clients.  This may not be the
> > > case, especially when responding to OCSP requests
> > > for certs issued from SSL CA's (i.e. every flavor
> > > of browser/ocsp client on earth).  As I stated in
> > > my response to Russ, the responder could reject a
> > > request with a nonce, but why not reply with a
> > > request without a nonce, and let the client decided
> > > if it wants to accept or reject it.  If a client
> > > requires that the nonce in the result, the result
> > > is the same, the response is rejected.
> > >
> > > Alex
> >
> >
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QMCiKP011898 for <[e-mail]>; Fri, 26 Sep 2003 15:12:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QMCiA0011896 for ietf-pkix-bks; Fri, 26 Sep 2003 15:12:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QMCiKP011891 for <[e-mail]>; Fri, 26 Sep 2003 15:12:44 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc02.vcorp.ad.vrsn.com (verisign.com [65.205.251.54]) by peacock.verisign.com (8.12.10/) with ESMTP id h8QMCjOh012104; Fri, 26 Sep 2003 15:12:45 -0700 (PDT)
Received: by mou1wnexc02.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <TTLKB9F0>; Fri, 26 Sep 2003 15:12:45 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, "Deacon, Alex" <[e-mail]>, [e-mail]
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 15:12:45 -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>

Mike,

As there has been some suggested changes to the text, can you post the most
recent wording to get everyone back on the same page?

Thanks
Alex


> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Friday, September 26, 2003 2:35 PM
> To: Deacon, Alex; [e-mail]
> Subject: RE: OCSP response pre-production
> 
> 
> Alex,
> 
> I'm willing to discuss client-side "nonce capability discovery"
> via this mechanism but it's clearly a v2 proposition.
> Meanwhile, we're working to clarify what we meant in v1 when we
> defined nonces in the first place.  The poll clearly establishes
> a nearly unanimous consensus that the common understanding in
> place at the time found its way into running code in all but, to
> date, one case.  I propose we proceed on this basis.
> 
> Mike
> 
> 
> 
> 
> > -----Original Message-----
> > From: Deacon, Alex [mailto:[e-mail]]
> > Sent: Friday, September 26, 2003 2:09 PM
> > To: 'Ryan M. Hurst'; Paul Hoffman / IMC; Michael
> > Myers; David Engberg;
> > [e-mail]; Ambarish Malpani; [e-mail]
> > Cc: Russ Housley; Stephen Kent; Tim Polk
> > Subject: RE: OCSP response pre-production
> >
> >
> >
> > This summary assumes that the OCSP responder has
> > control of the OCSP clients.  This may not be the
> > case, especially when responding to OCSP requests
> > for certs issued from SSL CA's (i.e. every flavor
> > of browser/ocsp client on earth).  As I stated in
> > my response to Russ, the responder could reject a
> > request with a nonce, but why not reply with a
> > request without a nonce, and let the client decided
> > if it wants to accept or reject it.  If a client
> > requires that the nonce in the result, the result
> > is the same, the response is rejected.
> >
> > Alex
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QLVuKP010391 for <[e-mail]>; Fri, 26 Sep 2003 14:31:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QLVuWe010390 for ietf-pkix-bks; Fri, 26 Sep 2003 14:31:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QLVsKP010384 for <[e-mail]>; Fri, 26 Sep 2003 14:31:55 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8QLVtt13588; Fri, 26 Sep 2003 14:31:55 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Deacon, Alex" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 14:35:29 -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]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Alex,

I'm willing to discuss client-side "nonce capability discovery"
via this mechanism but it's clearly a v2 proposition.
Meanwhile, we're working to clarify what we meant in v1 when we
defined nonces in the first place.  The poll clearly establishes
a nearly unanimous consensus that the common understanding in
place at the time found its way into running code in all but, to
date, one case.  I propose we proceed on this basis.

Mike




> -----Original Message-----
> From: Deacon, Alex [mailto:[e-mail]]
> Sent: Friday, September 26, 2003 2:09 PM
> To: 'Ryan M. Hurst'; Paul Hoffman / IMC; Michael
> Myers; David Engberg;
> [e-mail]; Ambarish Malpani; [e-mail]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> Subject: RE: OCSP response pre-production
>
>
>
> This summary assumes that the OCSP responder has
> control of the OCSP clients.  This may not be the
> case, especially when responding to OCSP requests
> for certs issued from SSL CA's (i.e. every flavor
> of browser/ocsp client on earth).  As I stated in
> my response to Russ, the responder could reject a
> request with a nonce, but why not reply with a
> request without a nonce, and let the client decided
> if it wants to accept or reject it.  If a client
> requires that the nonce in the result, the result
> is the same, the response is rejected.
>
> Alex




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QLTNKP010277 for <[e-mail]>; Fri, 26 Sep 2003 14:29:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QLTNxp010276 for ietf-pkix-bks; Fri, 26 Sep 2003 14:29:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QLTLKP010270 for <[e-mail]>; Fri, 26 Sep 2003 14:29:22 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd07.aul.t-online.de  by mailout09.sul.t-online.com with smtp  id 1A3099-0002rB-03; Fri, 26 Sep 2003 23:29:03 +0200
Received: from hagen (rfrBQBZBreR5-PoEDAZk9zkfDcTNyExjjoluyrcIeTeOkwHgTZfZ6T@[80.128.89.200]) by fmrl07.sul.t-online.com with esmtp id 1A3098-1W8E0e0; Fri, 26 Sep 2003 23:29:02 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Deacon, Alex'" <[e-mail]>, "'Michael Myers'" <[e-mail]>, "'David Engberg'" <[e-mail]>
Cc: "'Ryan M. Hurst'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, <[e-mail]>, "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'Tim Polk'" <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 23:29:00 +0200
Organization: SyTrust
Message-ID: <004101c38475$342f48e0$4228a8c0@hagen>
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
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-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>

> Florian,
> 
> I don't understand how adding a server generated nonce would 
> help in this situation.  How does this help the client 
> protect against replay attacks?
> 
> Alex



Client Type I) Given you have a client with the following behaviour:
A) always includes a nonce into his request
B) accepts responses without nonce

If an attacker is able to get a response without nonce from a responder,
he can replay that response to your client and the client will accept it
(rule B). So we have to ensure, that the attacker is NOT able to get a
response without nonce. Thus we simply add a server-generated nonce to
every response not already having a copy of a request-nonce.

This way, an attacker cannot get a response without a nonce. In
conclusion he can not get data to fool your client.




Client Type II) Given you have a client with the following behaviour:
A) does not includes a nonce into his request

A server generated nonce does not help this client anything (but also
does not harm it). He is in every case in danger of replay attacks.
(BTW: an attacker would use such a client to get a response without
nonce from your OCSP responder.)



Client Type III) Given you have a client with the following behaviour:
A) always includes a nonce into his request
B) does NOT accept responses without nonce

This client is never subject to a replay attack. A server generated
nonce does not improve anything (but also does not harm it).




So the proposed server-generated nonces are simply a mechanism to allow
Client Type I operate securely. I fully agree with you, that such a
client behaviour (accepting responses without nonce) seems to be
desirable from an operating point of view.

-- 
Florian Oelmaier
SyTrust

> 
> 
> > -----Original Message-----
> > From: Florian Oelmaier [mailto:[e-mail]]
> > Sent: Friday, September 26, 2003 10:37 AM
> > To: 'Michael Myers'; 'David Engberg'
> > Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; [e-mail]; 'Russ
> > Housley'; 'Stephen Kent'; 'Tim Polk'
> > Subject: RE: OCSP response pre-production
> > 
> > 
> > 
> > [...]
> > 
> > > Thus "Maybe the nonce is incorporated, maybe not" is
> > > equivalent to NOT sending a nonce in the first place.  Which 
> > > rather defeats the purpose of sending a nonce.
> > 
> > Thats true. But this can be "cured"! If an OCSP-Responders
> > that is able
> > to use nonces, detects a request without nonce, he simply includes a
> > self-generated nonce into his response. Thus an attacker is 
> > not able to
> > obtain a response without nonce from this particular 
> > responder. Thus he
> > cannot fool the client with a replay attack.
> > 
> > The client behaviour you describe is exactly the reason why our 
> > responder (in its default configuration) will currently 
> ALWAYS include 
> > a nonce into the response (even at the cost of generating one
> > by itself).
> > 
> > This way nonces are of value when used with a responder 
> being able to 
> > use them while simultaneous allowing response pre-production.
> > 
> > --
> > Florian Oelmaier
> > SyTrust
> > 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QLCRKP009360 for <[e-mail]>; Fri, 26 Sep 2003 14:12:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QLCRuh009359 for ietf-pkix-bks; Fri, 26 Sep 2003 14:12:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QLCQKP009354 for <[e-mail]>; Fri, 26 Sep 2003 14:12:26 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id h8QLBe74006175; Fri, 26 Sep 2003 14:11:40 -0700 (PDT)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <TK16VVZ9>; Fri, 26 Sep 2003 14:11:40 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Florian Oelmaier'" <[e-mail]>, "'Michael Myers'" <[e-mail]>, "'David Engberg'" <[e-mail]>
Cc: "'Ryan M. Hurst'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, [e-mail], "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'Tim Polk'" <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 14:11: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>

Florian,

I don't understand how adding a server generated nonce would help in this
situation.  How does this help the client protect against replay attacks?

Alex


> -----Original Message-----
> From: Florian Oelmaier [mailto:[e-mail]]
> Sent: Friday, September 26, 2003 10:37 AM
> To: 'Michael Myers'; 'David Engberg'
> Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; [e-mail]; 'Russ
> Housley'; 'Stephen Kent'; 'Tim Polk'
> Subject: RE: OCSP response pre-production
> 
> 
> 
> [...]
> 
> > Thus "Maybe the nonce is incorporated, maybe not" is 
> > equivalent to NOT sending a nonce in the first place.  Which 
> > rather defeats the purpose of sending a nonce.
> 
> Thats true. But this can be "cured"! If an OCSP-Responders 
> that is able
> to use nonces, detects a request without nonce, he simply includes a
> self-generated nonce into his response. Thus an attacker is 
> not able to
> obtain a response without nonce from this particular 
> responder. Thus he
> cannot fool the client with a replay attack.
> 
> The client behaviour you describe is exactly the reason why our
> responder (in its default configuration) will currently 
> ALWAYS include a
> nonce into the response (even at the cost of generating one 
> by itself).
> 
> This way nonces are of value when used with a responder being able to
> use them while simultaneous allowing response pre-production.
> 
> -- 
> Florian Oelmaier
> SyTrust
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QL9pKP009230 for <[e-mail]>; Fri, 26 Sep 2003 14:09:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QL9pX8009229 for ietf-pkix-bks; Fri, 26 Sep 2003 14:09:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QL9oKP009222; Fri, 26 Sep 2003 14:09:50 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id h8QL8q74005300; Fri, 26 Sep 2003 14:08:52 -0700 (PDT)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <TK16VVNF>; Fri, 26 Sep 2003 14:08:52 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>, Paul Hoffman / IMC <[e-mail]>, Michael Myers <[e-mail]>, David Engberg <[e-mail]>, [e-mail], Ambarish Malpani <[e-mail]>, [e-mail]
Cc: Russ Housley <[e-mail]>, Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 14:08:51 -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>

This summary assumes that the OCSP responder has control of the OCSP
clients.  This may not be the case, especially when responding to OCSP
requests for certs issued from SSL CA's (i.e. every flavor of browser/ocsp
client on earth).  As I stated in my response to Russ, the responder could
reject a request with a nonce, but why not reply with a request without a
nonce, and let the client decided if it wants to accept or reject it.  If a
client requires that the nonce in the result, the result is the same, the
response is rejected.

Alex


> -----Original Message-----
> From: Ryan M. Hurst [mailto:[e-mail]]
> Sent: Friday, September 26, 2003 10:01 AM
> To: Paul Hoffman / IMC; Michael Myers; David Engberg;
> [e-mail]; Ambarish Malpani; [e-mail]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> Subject: RE: OCSP response pre-production
> 
> 
> 
> I concur with this, er "me too" :)
> 
> Ryan
> 
> -----Original Message-----
> From: Paul Hoffman / IMC [mailto:[e-mail]] 
> Sent: Friday, September 26, 2003 9:40 AM
> To: Michael Myers; Ryan M. Hurst; David Engberg; [e-mail];
> Ambarish Malpani; [e-mail]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> Subject: RE: OCSP response pre-production
> 
> I hate to send "me too" responses, but everything Mike says in his 
> extended discussion is exactly right. My summary would be:
> 
> - If you can't sign, you must reject requests with nonces.
> 
> - Caching servers can ask a different server to sign. They can 
> respond to all requests that don't ahve nonces, and they (probably 
> selectively) send back the requests that have nonces to a server 
> willing to sign them.
> 
> - If you control the OCSP clients and you don't want to sign the 
> responses, inhibit the clients from sending requests with nonces.
> 
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium
> 
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QKtIKP008582 for <[e-mail]>; Fri, 26 Sep 2003 13:55:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QKtICN008581 for ietf-pkix-bks; Fri, 26 Sep 2003 13:55:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QKtIKP008576 for <[e-mail]>; Fri, 26 Sep 2003 13:55:18 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id h8QKtH74001701; Fri, 26 Sep 2003 13:55:17 -0700 (PDT)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <TK16VTTV>; Fri, 26 Sep 2003 13:55:17 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Russ Housley'" <[e-mail]>, "Deacon, Alex" <[e-mail]>
Cc: [e-mail]
Subject: OCSP response pre-production (was RE: POLL:  Use of nonces in OCS P)
Date: Fri, 26 Sep 2003 13:55:11 -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>

Hi Russ,

Agreed, however we do not have control of all OCSP clients.  In the case
where a responder is using pre-produced responses and can't respond to a
request with a nonce, the responder can do one of two things:

1) Send the pre-produced response without the nonce
2) return a malformedReqest OCSPResponseStatus

I feel that the first choice is better as it gives clients a chance to
accept the response, even though it does not contain a nonce.   

For clients that require a nonce not matter what the outcome of both optoins
is the same...i.e. the response is rejected.

Alex




> -----Original Message-----
> From: Russ Housley [mailto:[e-mail]]
> Sent: Friday, September 26, 2003 9:31 AM
> To: Deacon, Alex
> Cc: [e-mail]
> Subject: RE: POLL: Use of nonces in OCSP
> 
> 
> Alex:
> 
> To support such an environment, the client should not include 
> a nonce in 
> the request.  Do you have control over the clients?  If so, 
> then the change 
> will not cause you a problem.
> 
> Russ
> 
> At 05:12 PM 9/25/2003 -0700, Deacon, Alex wrote:
> 
> 
> >Hi Mike,
> >
> >Although this new text would not break the existing VeriSign 
> OCSP code base,
> >it will break the (soon to be deployed) next generation of our OCSP
> >services.  These services are designed to serve PKI's with a 
> high volume of
> >RP's (such as TLS server and code signing CA's) and rely on response
> >pre-production, distribution and caching through out the network.
> >
> >In such a deployment it is not possible for a responder to 
> include a nonce
> >in the response.
> >
> >Regards,
> >Alex
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Michael Myers [mailto:[e-mail]]
> > > Sent: Wednesday, September 24, 2003 7:38 AM
> > > To: [e-mail]
> > > Cc: Stephen Kent; Ambarish Malpani
> > > Subject: POLL: Use of nonces in OCSP
> > >
> > >
> > >
> > > All,
> > >
> > > Recent list traffic indicates there might be some confusion out
> > > there regarding the use of nonces in OCSP.  This is
> > > understandable since RFC 2560 is regrettably silent on the
> > > point.  It seems that most folks correctly inferred our original
> > > intent but absent normative language there's a possibility that
> > > some may not.
> > >
> > > After some discussion with the Chairs and the AD, we will take
> > > action to clarify our original intent in one fashion or another
> > > but first need to poll IMPLEMENTORS to determine how many, if
> > > any, implementations of OCSP would break as a consequence of the
> > > following normative language:
> > >
> > >     "Clients that elect to include a request nonce
> > >      SHALL reject responses that fail to include
> > >      the client's nonce from the associated request."
> > >
> > >     "Correspondingly, upon receipt of a request
> > >      containing a nonce, a responder SHALL include
> > >      the value of such nonce in the production of
> > >      the associated response."
> > >
> > > IMPLEMENTORS ONLY, please, and just yes/no or equivalent.
> > >
> > > Mike
> > >
> > >
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QKDOKP006700 for <[e-mail]>; Fri, 26 Sep 2003 13:13:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QKDO9x006699 for ietf-pkix-bks; Fri, 26 Sep 2003 13:13:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from zephir.uk.clara.net (zephir.uk.clara.net [195.8.69.53]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QKDMKP006692; Fri, 26 Sep 2003 13:13:22 -0700 (PDT) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=drh-consultancy.co.uk) by zephir.uk.clara.net with asmtp (Exim 4.22) id 1A2yxt-0003pV-Dl; Fri, 26 Sep 2003 21:13:21 +0100
Message-ID: <[e-mail]>
Date: Fri, 26 Sep 2003 21:15:20 +0100
From: Dr Stephen N Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman / IMC <[e-mail]>
CC: Michael Myers <[e-mail]>, "Ryan M. Hurst" <[e-mail]>, David Engberg <[e-mail]>, [e-mail], Ambarish Malpani <[e-mail]>, [e-mail], Russ Housley <[e-mail]>, Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>
Subject: Re: OCSP response pre-production
References: <[e-mail]> <p06002082bb9a1bcb12da@[63.202.92.152]> <[e-mail]> <p0600208dbb9a44b01e4d@[63.202.92.152]>
In-Reply-To: <p0600208dbb9a44b01e4d@[63.202.92.152]>
X-Enigmail-Version: 0.76.7.0
X-Enigmail-Supports: pgp-inline, pgp-mime
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh
Sender: [e-mail]
Precedence: 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 / IMC wrote:

> A different wording would be, "If a request 
> includes a nonce, the response MUST must either include the nonce or be 
> a failure."
> 

In which case my followup question would be how would the responder 
signal failure to the client?

None of the standard error codes seems entirely appropriate.

Then there the additional issue of how the error code can be sent in 
such a way that an attacker could give the impression that a responder 
can't sign nonces when it can.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QJfSKP005521 for <[e-mail]>; Fri, 26 Sep 2003 12:41:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QJfSTJ005520 for ietf-pkix-bks; Fri, 26 Sep 2003 12:41:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QJfRKP005515 for <[e-mail]>; Fri, 26 Sep 2003 12:41:27 -0700 (PDT) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Sep 2003 12:41:23 -0700
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Fri, 26 Sep 2003 12:41:23 -0700
Received: from 157.54.8.23 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 26 Sep 2003 12:41:22 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Sep 2003 12:41:22 -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(6.0.3790.0); Fri, 26 Sep 2003 12:40:42 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 26 Sep 2003 12:41:21 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 12:41:20 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP response pre-production
Thread-Index: AcOEZfXgoHDf0E1LRxy+UYdMvRz6BwAABhuA
From: "Ryan M. Hurst" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "Michael Myers" <[e-mail]>, "David Engberg" <[e-mail]>
Cc: "Ambarish Malpani" <[e-mail]>, <[e-mail]>, "Russ Housley" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Tim Polk" <[e-mail]>
X-OriginalArrivalTime: 26 Sep 2003 19:41:21.0384 (UTC) FILETIME=[29791E80:01C38466]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8QJfRKP005516
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Florian - the client can protect itself from replays if it cares to by
simply not trusting a response without a nonce; there is no need to
generate a server side nonce since the client can't do anything with it
anyhow.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Florian Oelmaier
Sent: Friday, September 26, 2003 10:37 AM
To: 'Michael Myers'; 'David Engberg'
Cc: Ryan M. Hurst; 'Ambarish Malpani'; [e-mail]; 'Russ
Housley'; 'Stephen Kent'; 'Tim Polk'
Subject: RE: OCSP response pre-production


[...]

> Thus "Maybe the nonce is incorporated, maybe not" is 
> equivalent to NOT sending a nonce in the first place.  Which 
> rather defeats the purpose of sending a nonce.

Thats true. But this can be "cured"! If an OCSP-Responders that is able
to use nonces, detects a request without nonce, he simply includes a
self-generated nonce into his response. Thus an attacker is not able to
obtain a response without nonce from this particular responder. Thus he
cannot fool the client with a replay attack.

The client behaviour you describe is exactly the reason why our
responder (in its default configuration) will currently ALWAYS include a
nonce into the response (even at the cost of generating one by itself).

This way nonces are of value when used with a responder being able to
use them while simultaneous allowing response pre-production.

-- 
Florian Oelmaier
SyTrust






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QJW7KP005072 for <[e-mail]>; Fri, 26 Sep 2003 12:32:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QJW70h005071 for ietf-pkix-bks; Fri, 26 Sep 2003 12:32:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QJVkKQ005046; Fri, 26 Sep 2003 12:31:46 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0600208dbb9a44b01e4d@[63.202.92.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06002082bb9a1bcb12da@[63.202.92.152]> <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Fri, 26 Sep 2003 12:34:02 -0700
To: Dr Stephen Henson <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: OCSP response pre-production
Cc: Michael Myers <[e-mail]>, "Ryan M. Hurst" <[e-mail]>, David Engberg <[e-mail]>, [e-mail], Ambarish Malpani <[e-mail]>, [e-mail], Russ Housley <[e-mail]>, Stephen Kent <[e-mail]>, Tim Polk <[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 6:22 PM +0100 9/26/03, Dr Stephen Henson wrote:
>Firstly as I mentioned before I've no problem with nonces and the 
>proposed wording.
>
>However I'm a bit confused by this:
>
>Paul Hoffman / IMC wrote:
>>
>>
>>- If you can't sign, you must reject requests with nonces.
>>
>
>and the proposed wording:
>
>Michael Myers wrote:
>>
>>     "Correspondingly, upon receipt of a request
>>      containing a nonce, a responder SHALL include
>>      the value of such nonce in the production of
>>      the associated response."
>>
>
>Which seems to suggest to me that a responder isn't allowed to 
>reject requests with nonces or am I misinterpreting it?

You are misinterpreting it. How would a responder that doesn't sign 
nonces respond at all? A different wording would be, "If a request 
includes a nonce, the response MUST must either include the nonce or 
be a failure."

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QJRfKP004906 for <[e-mail]>; Fri, 26 Sep 2003 12:27:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QJRfUA004905 for ietf-pkix-bks; Fri, 26 Sep 2003 12:27:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QJRcKP004898 for <[e-mail]>; Fri, 26 Sep 2003 12:27:40 -0700 (PDT) (envelope-from [e-mail])
Received: from corestreet.com (engberg.corestreet.com [192.168.2.87]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id h8QJRYxh010590; Fri, 26 Sep 2003 15:27:34 -0400
Message-ID: <[e-mail]>
Date: Fri, 26 Sep 2003 15:26:59 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet, Ltd.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Vadim Fedukovich <[e-mail]>
CC: [e-mail]
Subject: Re: would a key-less responder make better security
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Vadim -

Thanks for the feedback on the nonce paper.

Anecdotal evidence from CERT advisories and similar sources indicates 
that network takeover attacks and denials-of-service are much more 
common than man-in-the-middle (e.g. "replay") attacks, but this is 
hardly scientific.  If I wanted to severely disrupt your PKI, I know 
which attack I would attempt first, however.

In practice, an out-of-sync clock on a client is noticed and corrected 
immediately since current, valid responses will be constantly rejected. 
  However, an attacker that knew of an unnoticed backwards (not 
forwards) clock skew on a specific client could theoretically replay a 
stored response from this period to that client.  Obviously, a serious 
clock skew will screw up many other parts of your PKI as well (accepting 
expired certificates, etc.).

I strongly disagree with your third point.  An attack on a caching-only 
responder can only replay "valid" responses that have not already 
expired.  If the responder issued a "valid" response for cert #1234 in 
the morning and you compromise it at noon, you could keep replyaing that 
response for the rest of that "day" only.  After expiration, every 
client will reject the response.  These responses are typically the same 
duration as the CRL, so this is similar to saying that "if I compromise 
your LDAP directory, I can replay your CRL for the rest of the day." 
Obviously, a traditional OCSP responder based off of the same CRL will 
keep providing the same "valid" response throughout that day until the 
next CRL is released, but it will give you the illusion of freshness 
with its nonces.

Contrast this with what I can do if I attack your key-bearing server in 
the same way that Kerberos was compromised last year.  I can create a 
response for ANY certificate that says it is revoked or that it is 
valid.  This can be used to reinstate a stolen ID card that was revoked 
six months ago, which may allow me to walk in to a secure facility, or 
it can be used to falsely revoke any valid certificate, potentially 
disrupting critical operations.  This is much more severe than the risk 
of keeping a certificate valid for a few extra minutes or hours on the 
day it is revoked.

Thanks,
David


Vadim Fedukovich wrote:
> On Thu, Sep 25, 2003 at 05:44:53PM -0400, David Engberg wrote:
> 
>>
>>No, we would not like to see the language change.  Yes, it would break 
>>existing deployments based on caching-only responders.
>>
>>
>>Explanation:
>>
>>There is a (strong) case to be made that a large OCSP deployment based 
>>around caching-only responders with no private keys to protect can be 
>>more secure against real-world attacks than one based entirely on 
>>live-signing responders using nonces:
>>
>>    http://www.corestreet.com/whitepapers/nonce-sense.pdf
> 
> 
> So, "a server without any signing key will have nothing to lose"
> as I read it. Yes, it makes some sense. However some people still
> chose SSL-capable web servers sometimes.
> 
> Something missing in this paper is a trade-off analysis like what kind
> of responder fits business better:
>   fresh response indicating current status with a risk of responder's
>   key compromise because of a buffer overflow
> or
>   somewhat stale responses with less risk of compromising the key
>   used by another task maybe on another host.
> Such an analysis might include human errors and program bugs statistics
> 
> Also missing the case mentioned by Peter Gutmann with out-of-sync
> clock at the client.
> 
> At last, old stale responses might be replayed by an attacker in case of
> successful buffer overflow to keep already revoked certificate "valid".
> This means bug-free responder software is a point with no route-around
> either with or without signing key online.
> 
> I do believe 3 points mentioned contribute to "real-world security"
> so it's hard to agree with "significantly higher overall security"
> wording in the paper.
> 
> regards,
> Vadim
> 
> 
>>It would be undesirable to change the specification to break existing 
>>implementations and deployments that chose this route.
>>
>>
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QJGvKP004441 for <[e-mail]>; Fri, 26 Sep 2003 12:16:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QJGvtH004440 for ietf-pkix-bks; Fri, 26 Sep 2003 12:16:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QJGtKP004435 for <[e-mail]>; Fri, 26 Sep 2003 12:16:55 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8QJGqt08164; Fri, 26 Sep 2003 12:16:52 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "David Engberg" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 12:20: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)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave,

An offline signing server is arguably a good security practice
but I'm having difficulty resolving that against the fact that
we're talking about an online protocol.

Mike




> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> David Engberg
> Sent: Friday, September 26, 2003 10:54 AM
> To: Michael Myers
> Cc: Ryan M. Hurst; [e-mail]; Ambarish Malpani;
> [e-mail]; Russ Housley; Stephen Kent; Tim Polk
> Subject: Re: OCSP response pre-production
>
>
>
>
>
> Michael Myers wrote:
> > With apologies, may I ask a slightly pointed
> question to make
> > sure we understand each other?  Are you saying that
> CoreStreet's
> > RTC Responder would NOT incorporate a nonce if it
> received such
> > in a request?
>
> Correct.  The RTC Responder has no private keys to
> sign on its own, and
> will not relay to a master authority since it is used
> with an offline
> master authority.  This eliminates the risk of remote
> key compromise and
> allows for orders-of-magnitude better resistance to
> denials of service.
>
>
> > All reasonable concerns regarding high-assurance security
> > practices.  But then, use of nonces lies squarely
> within that
> > realm too.
>
> Exactly.  So the ideal is a security protocol that
> allows implementors
> and deployers to address all risks based on their
> requirements, rather
> than mandating a policy for one risk that severely
> increases other
> risks.  I would choose to not mandate that every
> responder must be able
> to sign responses to be OCSP-compliant.
>
>
> >>Is there any reason not to change the responder
> >>language to SHOULD while maintaing the client language as
> >>SHALL?
> >
> > A client asserts a nonce for very specific security
> needs.  If
> > the specification allows for selective respect of
> these needs,
> > the core assurances of the nonce are lost since the
> client will
> > be unable to conclusively determine if it's being subject to
> > replay nor will it have certain knowledge of the most recent
> > revocation data.
> >
> > Thus "Maybe the nonce is incorporated, maybe not"
> is equivalent
> > to NOT sending a nonce in the first place.  Which
> rather defeats
> > the purpose of sending a nonce.
>
> This sounds like an argument for the behavioral rules
> of the client
> (SHALL).  I would suggest separating this from the
> mandating the
> security behavior of the responder (SHOULD).
>
> Thanks,
> Dave




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QIH2KP001295 for <[e-mail]>; Fri, 26 Sep 2003 11:17:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QIH1PJ001294 for ietf-pkix-bks; Fri, 26 Sep 2003 11:17:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from main.giknpc.com.ua (backup.adm.dp.ua [212.86.233.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QIGjKP001279 for <[e-mail]>; Fri, 26 Sep 2003 11:16:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from vf@localhost) by main.giknpc.com.ua (8.11.6/8.11.6) id h8QIGX219901 for [e-mail]; Fri, 26 Sep 2003 21:16:33 +0300
Date: Fri, 26 Sep 2003 21:16:33 +0300
From: Vadim Fedukovich <[e-mail]>
To: [e-mail]
Subject: would a key-less responder make better security (was: POLL: Use of nonces in OCSP)
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Sep 25, 2003 at 05:44:53PM -0400, David Engberg wrote:
> 
> 
> No, we would not like to see the language change.  Yes, it would break 
> existing deployments based on caching-only responders.
> 
> 
> Explanation:
> 
> There is a (strong) case to be made that a large OCSP deployment based 
> around caching-only responders with no private keys to protect can be 
> more secure against real-world attacks than one based entirely on 
> live-signing responders using nonces:
> 
>     http://www.corestreet.com/whitepapers/nonce-sense.pdf

So, "a server without any signing key will have nothing to lose"
as I read it. Yes, it makes some sense. However some people still
chose SSL-capable web servers sometimes.

Something missing in this paper is a trade-off analysis like what kind
of responder fits business better:
  fresh response indicating current status with a risk of responder's
  key compromise because of a buffer overflow
or
  somewhat stale responses with less risk of compromising the key
  used by another task maybe on another host.
Such an analysis might include human errors and program bugs statistics

Also missing the case mentioned by Peter Gutmann with out-of-sync
clock at the client.

At last, old stale responses might be replayed by an attacker in case of
successful buffer overflow to keep already revoked certificate "valid".
This means bug-free responder software is a point with no route-around
either with or without signing key online.

I do believe 3 points mentioned contribute to "real-world security"
so it's hard to agree with "significantly higher overall security"
wording in the paper.

regards,
Vadim

> It would be undesirable to change the specification to break existing 
> implementations and deployments that chose this route.
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHtMKP000200 for <[e-mail]>; Fri, 26 Sep 2003 10:55:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QHtMoH000199 for ietf-pkix-bks; Fri, 26 Sep 2003 10:55:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHtLKP000189 for <[e-mail]>; Fri, 26 Sep 2003 10:55:21 -0700 (PDT) (envelope-from [e-mail])
Received: from corestreet.com (engberg.corestreet.com [192.168.2.87]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id h8QHt1xh009665; Fri, 26 Sep 2003 13:55:01 -0400
Message-ID: <[e-mail]>
Date: Fri, 26 Sep 2003 13:54:26 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet, Ltd.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: "Ryan M. Hurst" <[e-mail]>, [e-mail], Ambarish Malpani <[e-mail]>, [e-mail], Russ Housley <[e-mail]>, Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>
Subject: Re: OCSP response pre-production
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael Myers wrote:
> With apologies, may I ask a slightly pointed question to make
> sure we understand each other?  Are you saying that CoreStreet's
> RTC Responder would NOT incorporate a nonce if it received such
> in a request?

Correct.  The RTC Responder has no private keys to sign on its own, and 
will not relay to a master authority since it is used with an offline 
master authority.  This eliminates the risk of remote key compromise and 
allows for orders-of-magnitude better resistance to denials of service.


> All reasonable concerns regarding high-assurance security
> practices.  But then, use of nonces lies squarely within that
> realm too.

Exactly.  So the ideal is a security protocol that allows implementors 
and deployers to address all risks based on their requirements, rather 
than mandating a policy for one risk that severely increases other 
risks.  I would choose to not mandate that every responder must be able 
to sign responses to be OCSP-compliant.


>>Is there any reason not to change the responder
>>language to SHOULD while maintaing the client language as
>>SHALL?
> 
> A client asserts a nonce for very specific security needs.  If
> the specification allows for selective respect of these needs,
> the core assurances of the nonce are lost since the client will
> be unable to conclusively determine if it's being subject to
> replay nor will it have certain knowledge of the most recent
> revocation data.
> 
> Thus "Maybe the nonce is incorporated, maybe not" is equivalent
> to NOT sending a nonce in the first place.  Which rather defeats
> the purpose of sending a nonce.

This sounds like an argument for the behavioral rules of the client 
(SHALL).  I would suggest separating this from the mandating the 
security behavior of the responder (SHOULD).

Thanks,
Dave



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHbbKP099127 for <[e-mail]>; Fri, 26 Sep 2003 10:37:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QHba4K099126 for ietf-pkix-bks; Fri, 26 Sep 2003 10:37:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHbZKP099121 for <[e-mail]>; Fri, 26 Sep 2003 10:37:35 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd07.aul.t-online.de  by mailout03.sul.t-online.com with smtp  id 1A2wX5-0006Xf-01; Fri, 26 Sep 2003 19:37:31 +0200
Received: from hagen (VrjYSiZpoe2cLIWuMWDqYrQeFFTL9VS6-ACY2qysOQlrT-X5T7w6wx@[80.128.89.200]) by fmrl07.sul.t-online.com with esmtp id 1A2wWv-1qHTCC0; Fri, 26 Sep 2003 19:37:21 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, "'David Engberg'" <[e-mail]>
Cc: "'Ryan M. Hurst'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, <[e-mail]>, "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'Tim Polk'" <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 19:37:19 +0200
Organization: SyTrust
Message-ID: <003201c38454$d6468150$4228a8c0@hagen>
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
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-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>

[...]

> Thus "Maybe the nonce is incorporated, maybe not" is 
> equivalent to NOT sending a nonce in the first place.  Which 
> rather defeats the purpose of sending a nonce.

Thats true. But this can be "cured"! If an OCSP-Responders that is able
to use nonces, detects a request without nonce, he simply includes a
self-generated nonce into his response. Thus an attacker is not able to
obtain a response without nonce from this particular responder. Thus he
cannot fool the client with a replay attack.

The client behaviour you describe is exactly the reason why our
responder (in its default configuration) will currently ALWAYS include a
nonce into the response (even at the cost of generating one by itself).

This way nonces are of value when used with a responder being able to
use them while simultaneous allowing response pre-production.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHS4KP098407 for <[e-mail]>; Fri, 26 Sep 2003 10:28:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QHS4h6098406 for ietf-pkix-bks; Fri, 26 Sep 2003 10:28:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHS3KP098392; Fri, 26 Sep 2003 10:28:03 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Sep 2003 10:27:59 -0700
Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 26 Sep 2003 10:27:59 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Sep 2003 10:28:02 -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(6.0.3790.0); Fri, 26 Sep 2003 10:27:58 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 26 Sep 2003 10:27:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 10:27:57 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP response pre-production
Thread-Index: AcOEUoW/nteqdD5/Si2CLyaSvTwO5QAANNsA
From: "Ryan M. Hurst" <[e-mail]>
To: "Dr Stephen Henson" <[e-mail]>, "Paul Hoffman / IMC" <[e-mail]>
Cc: "Michael Myers" <[e-mail]>, "David Engberg" <[e-mail]>, <[e-mail]>, "Ambarish Malpani" <[e-mail]>, <[e-mail]>, "Russ Housley" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Tim Polk" <[e-mail]>
X-OriginalArrivalTime: 26 Sep 2003 17:27:57.0920 (UTC) FILETIME=[87096E00:01C38453]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8QHS3KP098400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

That's a good point, how about:

"Correspondingly, if a responder has only supports pre-produced
responses it may reject request that include a nonce, otherwise upon
receipt of a request containing a nonce, a responder SHALL include the
value of such nonce in the production of the associated response."

Ryan


-----Original Message-----
From: Dr Stephen Henson [mailto:[e-mail]] 
Sent: Friday, September 26, 2003 10:22 AM
To: Paul Hoffman / IMC
Cc: Michael Myers; Ryan M. Hurst; David Engberg; [e-mail];
Ambarish Malpani; [e-mail]; Russ Housley; Stephen Kent; Tim
Polk
Subject: Re: OCSP response pre-production

Firstly as I mentioned before I've no problem with nonces and the 
proposed wording.

However I'm a bit confused by this:

Paul Hoffman / IMC wrote:
> 
> 
> - If you can't sign, you must reject requests with nonces.
> 

and the proposed wording:

Michael Myers wrote:
> 
>     "Correspondingly, upon receipt of a request
>      containing a nonce, a responder SHALL include
>      the value of such nonce in the production of
>      the associated response."
> 

Which seems to suggest to me that a responder isn't allowed to reject 
requests with nonces or am I misinterpreting it?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHR4KP098328 for <[e-mail]>; Fri, 26 Sep 2003 10:27:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QHR4m8098327 for ietf-pkix-bks; Fri, 26 Sep 2003 10:27:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHR2KP098322 for <[e-mail]>; Fri, 26 Sep 2003 10:27:03 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8QHQtt03970; Fri, 26 Sep 2003 10:26:55 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "David Engberg" <[e-mail]>
Cc: "Ryan M. Hurst" <[e-mail]>, <[e-mail]>, "Ambarish Malpani" <[e-mail]>, <[e-mail]>, "Russ Housley" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Tim Polk" <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 10:30:28 -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 V6.00.2800.1106
Sender: [e-mail]
Precedence: 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: David Engberg [mailto:[e-mail]]
> . . .
> I should have clarified in my poll response that an
> extant signing server (CoreStreet's RTC Responder,
> part of the RTC VA) is broken by the change unless
> the responder SHALL is changed to SHOULD.

OK.  That's the first one.

With apologies, may I ask a slightly pointed question to make
sure we understand each other?  Are you saying that CoreStreet's
RTC Responder would NOT incorporate a nonce if it received such
in a request?


> I do not believe that Ryan's solution fits the needs
> of a large scale, high security deployment.  By
> forcing OCSP deployments to leave a key-bearing master
> server online, you are exposing your infrastructure
> to the risks of remote compromise (e.g.
> http://www.cert.org/advisories/CA-2002-29.html) and
> denial-of-service. Both of these attacks are more common and
> catastrophic in the real world than any sort of
> man-in-the-middle replay of short-lived responses.

All reasonable concerns regarding high-assurance security
practices.  But then, use of nonces lies squarely within that
realm too.

> . . .
>
> Is there any reason not to change the responder
> language to SHOULD while maintaing the client language as
SHALL?

A client asserts a nonce for very specific security needs.  If
the specification allows for selective respect of these needs,
the core assurances of the nonce are lost since the client will
be unable to conclusively determine if it's being subject to
replay nor will it have certain knowledge of the most recent
revocation data.

Thus "Maybe the nonce is incorporated, maybe not" is equivalent
to NOT sending a nonce in the first place.  Which rather defeats
the purpose of sending a nonce.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHMwKP098086 for <[e-mail]>; Fri, 26 Sep 2003 10:22:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QHMwI8098085 for ietf-pkix-bks; Fri, 26 Sep 2003 10:22:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHMvKP098067 for <[e-mail]>; Fri, 26 Sep 2003 10:22:57 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 26 Sep 2003 12:24:01 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: <[e-mail]>
Subject: OCSP and Nonces
Date: Fri, 26 Sep 2003 12:21:34 -0500
Message-ID: <000401c38452$a58075f0$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C38428.BCACB7E0"
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.2800.1165
X-OriginalArrivalTime: 26 Sep 2003 17:24:01.0968 (UTC) FILETIME=[FA660300:01C38452]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01C38428.BCACB7E0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The use of nonces to prevent replay attacks is incompatible with the use
of cached responses.
=20
>From the client side, what is the difference between not including a
nonce at all and accepting responses without it?
=20
>From the server side, as Ryan Hurst said, the presence of a nonce can be
viewed as an indication that the client is looking for a =93fresh=94
response. What if the responder can=92t provide one?=20
=20
Cached responses can be treated as CRLs (checked for time validity using
the ThisUpdate and NextUpdate fields). We don=92t worry about replay
attacks when using CRLs.=20
=20
If we want to enable the client to work with both fresh and cached
responses we could include a nonce in the request and accept responses
without it. Of course this means that we are giving up prevention
against replay attacks. This prevention only makes sense for fresh
responses. The bad scenario is a replay attack for fresh responses, how
can we avoid it? Maybe by having a way to distinguish fresh responses
from cached ones. Then the client can reject a fresh response without
the nonce included in the request.=20
=20
Opinions are welcomed,
=20
Miguel A. Rodriguez
Software Engineer
SeguriDATA
Panzacola 62, Piso 1
Colonia Villa Coyoac=E1n
04000 - M=E9xico, D.F.
Phone: [phone]
Fax: [phone]
=20

------=_NextPart_000_0005_01C38428.BCACB7E0
Content-Type: text/html;
	charset="iso-8859-1"
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=3Diso-8859-1">


<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@01C38428.B93DCFE0">
<!--[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>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Arial Narrow";
	panose-1:2 11 5 6 2 2 2 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:647 0 0 0 159 0;}
 /* 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;}
span.GramE
	{mso-style-name:"";
	mso-gram-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;}
 /* List Definitions */
 @list l0
	{mso-list-id:1679503650;
	mso-list-type:hybrid;
	mso-list-template-ids:1028919774 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
@list l1
	{mso-list-id:1828546001;
	mso-list-type:hybrid;
	mso-list-template-ids:2098463726 67698703 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l1:level1
	{mso-level-tab-stop:36.0pt;
	mso-level-number-position:left;
	text-indent:-18.0pt;}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</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'>The use of <span class=3DSpellE>nonces</span> to =
prevent
replay attacks is incompatible with the use of cached =
responses.<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'>From the client side, what is the difference between =
not
including a nonce at all and accepting responses without =
it?<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'>From the server side, as Ryan Hurst said, the =
presence of a
nonce can be viewed as an indication that the client is looking for a =
&#8220;fresh&#8221;
response. What if the responder can&#8217;t provide one? =
<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'>Cached responses can be treated as <span =
class=3DSpellE>CRLs</span>
(checked for time validity using the <span =
class=3DSpellE>ThisUpdate</span> and <span
class=3DSpellE>NextUpdate</span> fields). We don&#8217;t worry about =
replay
attacks when using <span class=3DSpellE>CRLs</span>. =
<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'>If we want to enable the client to work with both =
fresh and
cached responses we could include a nonce in the request and accept =
responses
without it. Of course this means that we are giving up prevention =
against
replay attacks. This prevention only makes sense for fresh responses. =
The bad
scenario is a replay attack for fresh responses, how can we avoid it? =
<span
class=3DGramE>Maybe by having a way to distinguish fresh responses from =
cached
ones.</span> Then the client can reject a fresh response without the =
nonce
included in the request. <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'>Opinions are welcomed,<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 color=3Dmaroon face=3D"Arial =
Narrow"><span
style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;mso-no-proof:
yes'>Miguel A. Rodriguez</span></font><span =
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;mso-no-proof:
yes'>Software Engineer</span></font><span =
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;mso-no-proof:
yes'>SeguriDA</span></font><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>TA</span></font><span =
lang=3DES-MX
style=3D'mso-ansi-language:ES-MX;mso-no-proof:yes'><o:p></o:p></span></p>=


<p class=3DMsoNormal><font size=3D2 color=3Dmaroon face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:maroon;
mso-ansi-language:ES-MX;mso-no-proof:yes'>Panzacola 62, Piso 1<br>
Colonia Villa Coyoac=E1n<br>
04000 - M=E9xico, D.F.<br>
Phone: +52 (55)&nbsp;5339-0158<br>
Fax: </span></font><font size=3D2 color=3Dblack face=3D"Arial =
Narrow"><span
lang=3DES-MX style=3D'font-size:10.0pt;font-family:"Arial =
Narrow";color:black;
mso-ansi-language:ES-MX;mso-no-proof:yes'>[phone] =
5829</span></font><span
lang=3DES-MX style=3D'mso-ansi-language:ES-MX'><o:p></o:p></span></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
lang=3DES-MX
style=3D'font-size:12.0pt;mso-ansi-language:ES-MX'><o:p>&nbsp;</o:p></spa=
n></font></p>

</div>

</body>

</html>

------=_NextPart_000_0005_01C38428.BCACB7E0--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHKEKP097914 for <[e-mail]>; Fri, 26 Sep 2003 10:20:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QHKEPh097913 for ietf-pkix-bks; Fri, 26 Sep 2003 10:20:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHKBKP097898; Fri, 26 Sep 2003 10:20:12 -0700 (PDT) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=drh-consultancy.co.uk) by anchor-post-34.mail.demon.net with esmtp (Exim 3.35 #1) id 1A2wGG-0006PG-0Y; Fri, 26 Sep 2003 18:20:08 +0100
Message-ID: <[e-mail]>
Date: Fri, 26 Sep 2003 18:22:25 +0100
From: Dr Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Paul Hoffman / IMC <[e-mail]>
CC: Michael Myers <[e-mail]>, "Ryan M. Hurst" <[e-mail]>, David Engberg <[e-mail]>, [e-mail], Ambarish Malpani <[e-mail]>, [e-mail], Russ Housley <[e-mail]>, Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>
Subject: Re: OCSP response pre-production
References: <[e-mail]> <p06002082bb9a1bcb12da@[63.202.92.152]>
In-Reply-To: <p06002082bb9a1bcb12da@[63.202.92.152]>
X-Enigmail-Version: 0.76.7.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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>

Firstly as I mentioned before I've no problem with nonces and the 
proposed wording.

However I'm a bit confused by this:

Paul Hoffman / IMC wrote:
> 
> 
> - If you can't sign, you must reject requests with nonces.
> 

and the proposed wording:

Michael Myers wrote:
> 
>     "Correspondingly, upon receipt of a request
>      containing a nonce, a responder SHALL include
>      the value of such nonce in the production of
>      the associated response."
> 

Which seems to suggest to me that a responder isn't allowed to reject 
requests with nonces or am I misinterpreting it?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHAEKP097238 for <[e-mail]>; Fri, 26 Sep 2003 10:10:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QHAEbq097237 for ietf-pkix-bks; Fri, 26 Sep 2003 10:10:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QHACKP097227 for <[e-mail]>; Fri, 26 Sep 2003 10:10:12 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 26 Sep 2003 10:10:27 -0700
Received: from 157.54.8.23 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 26 Sep 2003 10:10:10 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Sep 2003 10:10:10 -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(6.0.3790.0); Fri, 26 Sep 2003 10:10:09 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 26 Sep 2003 10:10:08 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 10:10:07 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP response pre-production
Thread-Index: AcOEUK6yivQv1+BRQ8CBshjb9uZLogAACwhQ
From: "Ryan M. Hurst" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "Michael Myers" <[e-mail]>, "David Engberg" <[e-mail]>, "Ambarish Malpani" <[e-mail]>, <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Tim Polk" <[e-mail]>
X-OriginalArrivalTime: 26 Sep 2003 17:10:08.0811 (UTC) FILETIME=[09CC57B0:01C38451]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8QHACKP097233
Sender: [e-mail]
Precedence: 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 do not believe clients "SHOULD include a nonce" I believe they "MAY
include a nonce if they wish to protect the client from a replay attack,
the inclusion of a nonce precludes intermediate caching and pre-produced
responses".

Ryan

-----Original Message-----
From: Florian Oelmaier [mailto:[e-mail]] 
Sent: Friday, September 26, 2003 10:07 AM
To: 'Michael Myers'; Ryan M. Hurst; 'David Engberg'; 'Ambarish Malpani';
[e-mail]
Cc: 'Russ Housley'; 'Stephen Kent'; 'Tim Polk'
Subject: RE: OCSP response pre-production

Hello Michael,

thanks for your mail and the background story. I see your point and
knowing the history of it makes it more easy to understand the current
discussion. 

I am very fond of a clarification of the text of RfC2560 regarding
nonces. I recognize your expertise gathered during the design of OCSP.
So maybe I am not in the right position to do this, but please allow me
to present another option for a clarification regarding nonce:
 

My guidelines drafting the clarification:

- clarify nonce handling
- improve security of the protocol

- allow for the same amount of possibilities as in the published RfC
- make only recommendations, do not add a new "absolute requirement"
- good compromise between "nonces" and "caching"
 

I am not an english native speaker - so please dont judge it by
eloquence or grammar. Here it comes:



"Clients SHOULD include a request nonce to allow responders to establish
protection against replay attacks. If the client included a nonce, it
SHALL reject responses containing a mismatching nonce. If the client
included a nonce, it MAY accept  responses containing no nonce at all
based on its (security) requirements."

"As a response without nonce could be used for a replay attack against
clients accepting such responses, responders that want to ensure a
maximum level of protection against replay attacks SHOULD include a
nonce into all responses. If the request did not contain a nonce, a new
nonce SHOULD be generated by the responder and included into the
response."




Please see the attached file for a comparison between the two proposals
in terms of interoperability and possibilities. I think my proposal will
bring the same level of security in real world situations without
denying other possibilities and without being able to break any
installations or implementations out there.

Best regards,

-- 
Florian Oelmaier
SyTrust

> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]] 
> Sent: Friday, September 26, 2003 5:54 PM
> To: Ryan M. Hurst; David Engberg; [e-mail]; 
> Ambarish Malpani; [e-mail]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> Subject: RE: OCSP response pre-production
> 
> 
> David, Ryan, Florian:
> 
> Apologies for the length of this but I didn't want this 
> predictable debate to occur on the POLL: thread.
> 
> The whole point of this clarification and the poll is to 
> recognize the fact that a client sends a nonce for two very good
> reasons: protection against replay and to ensure freshness. 
> Both are relevant to high-assurance security practices.  
> There was vigorous debate on this topic during OCSP's 
> genesis, a good deal of it between myself and Carlisle Adams, 
> from which came the nonce extension and it's optional use.
> 
> It was commonly understood back then that nonces break 
> caching. Some may recall that I was an advocate for pre-produced
> responses for precisely the reasons it's now surfacing.   We
> debated the point and arrived at a constructive conclusion.  
> It went through WG, IETF and IESG last calls. No one objected 
> and it became RFC 2560.
> 
> As the poll clearly indicates, this common understanding was 
> correctly interpreted by, so far, every OCSP implementor.  
> The proposed text simply codifies that understanding in a way 
> that makes it abundantly clear what SHALL be done.
> 
> We have a responsibility and a duty, especially within the 
> Security Area, to design secure protocols.  To have a 
> client's nonce sometimes respected and sometimes not, as 
> would be the case in changing the server-side requirement to 
> SHOULD from SHALL, defeats that purpose.
> 
> I'll say it again:  nonces are optional to begin with.  If 
> your system architecture relies on caching, then don't use 
> nonces. Now, I understand that one may not have full control 
> over client-side configuration and thus be unable to cause a 
> given population of clients to not use nonces.  But that does 
> not mean we should purposefully punch a hole in the security 
> of the protocol's specification in order to accomodate a 
> particular business case.
> 
> Ryan had a useful solution to this.  Non-signing caching 
> servers relay nonced requests to whatever master server 
> they're associated with that can sign.  A fresh response, 
> including the nonce, comes back and is then forwarded to the 
> requesting client.
> 
> Sure, this impacts system-level performance.  But the answer 
> to the performance problem is straightforward:  get bigger, 
> faster boxes and bigger, faster signing engines.  I suspect 
> there's an ample number of crypto vendors out there who would 
> be willing to pitch their wares against the latter need.
> 
> It's also worth noting that among a heterogeneous population 
> of clients, perhaps only a small portion of them would nonce.  On
> the other hand, maybe most will.  I don't know.    I do know a
> security hole when I see it.  We incorporate thoughtful 
> security features into our protocols for a reason.
> 
> So, nonces break caching.  We knew that from day one. But, as 
> far as I can tell from the poll to date, NO extant signing 
> servers or clients are broken by the proposed text.
> 
> Mike
> 
> 
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QH73KP097096 for <[e-mail]>; Fri, 26 Sep 2003 10:07:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QH73us097095 for ietf-pkix-bks; Fri, 26 Sep 2003 10:07:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QH71KP097089 for <[e-mail]>; Fri, 26 Sep 2003 10:07:01 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd07.aul.t-online.de  by mailout03.sul.t-online.com with smtp  id 1A2w3Q-0006HN-05; Fri, 26 Sep 2003 19:06:52 +0200
Received: from hagen (rxZscwZc8eKBp5go6nELrsP4V0gt2tzI4zV+FUp3FrIV+hAtJASEYj@[80.128.89.200]) by fmrl07.sul.t-online.com with esmtp id 1A2w3K-1Ux5040; Fri, 26 Sep 2003 19:06:46 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, "'David Engberg'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, <[e-mail]>
Cc: "'Russ Housley'" <[e-mail]>, "'Stephen Kent'" <[e-mail]>, "'Tim Polk'" <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 19:06:44 +0200
Organization: SyTrust
Message-ID: <002701c38450$904f44b0$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_000_0028_01C38461.53D814B0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0028_01C38461.53D814B0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Michael,

thanks for your mail and the background story. I see your point and
knowing the history of it makes it more easy to understand the current
discussion. 

I am very fond of a clarification of the text of RfC2560 regarding
nonces. I recognize your expertise gathered during the design of OCSP.
So maybe I am not in the right position to do this, but please allow me
to present another option for a clarification regarding nonce:
 

My guidelines drafting the clarification:

- clarify nonce handling
- improve security of the protocol

- allow for the same amount of possibilities as in the published RfC
- make only recommendations, do not add a new "absolute requirement"
- good compromise between "nonces" and "caching"
 

I am not an english native speaker - so please dont judge it by
eloquence or grammar. Here it comes:



"Clients SHOULD include a request nonce to allow responders to establish
protection against replay attacks. If the client included a nonce, it
SHALL reject responses containing a mismatching nonce. If the client
included a nonce, it MAY accept  responses containing no nonce at all
based on its (security) requirements."

"As a response without nonce could be used for a replay attack against
clients accepting such responses, responders that want to ensure a
maximum level of protection against replay attacks SHOULD include a
nonce into all responses. If the request did not contain a nonce, a new
nonce SHOULD be generated by the responder and included into the
response."




Please see the attached file for a comparison between the two proposals
in terms of interoperability and possibilities. I think my proposal will
bring the same level of security in real world situations without
denying other possibilities and without being able to break any
installations or implementations out there.

Best regards,

-- 
Florian Oelmaier
SyTrust

> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]] 
> Sent: Friday, September 26, 2003 5:54 PM
> To: Ryan M. Hurst; David Engberg; [e-mail]; 
> Ambarish Malpani; [e-mail]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> Subject: RE: OCSP response pre-production
> 
> 
> David, Ryan, Florian:
> 
> Apologies for the length of this but I didn't want this 
> predictable debate to occur on the POLL: thread.
> 
> The whole point of this clarification and the poll is to 
> recognize the fact that a client sends a nonce for two very good
> reasons: protection against replay and to ensure freshness. 
> Both are relevant to high-assurance security practices.  
> There was vigorous debate on this topic during OCSP's 
> genesis, a good deal of it between myself and Carlisle Adams, 
> from which came the nonce extension and it's optional use.
> 
> It was commonly understood back then that nonces break 
> caching. Some may recall that I was an advocate for pre-produced
> responses for precisely the reasons it's now surfacing.   We
> debated the point and arrived at a constructive conclusion.  
> It went through WG, IETF and IESG last calls. No one objected 
> and it became RFC 2560.
> 
> As the poll clearly indicates, this common understanding was 
> correctly interpreted by, so far, every OCSP implementor.  
> The proposed text simply codifies that understanding in a way 
> that makes it abundantly clear what SHALL be done.
> 
> We have a responsibility and a duty, especially within the 
> Security Area, to design secure protocols.  To have a 
> client's nonce sometimes respected and sometimes not, as 
> would be the case in changing the server-side requirement to 
> SHOULD from SHALL, defeats that purpose.
> 
> I'll say it again:  nonces are optional to begin with.  If 
> your system architecture relies on caching, then don't use 
> nonces. Now, I understand that one may not have full control 
> over client-side configuration and thus be unable to cause a 
> given population of clients to not use nonces.  But that does 
> not mean we should purposefully punch a hole in the security 
> of the protocol's specification in order to accomodate a 
> particular business case.
> 
> Ryan had a useful solution to this.  Non-signing caching 
> servers relay nonced requests to whatever master server 
> they're associated with that can sign.  A fresh response, 
> including the nonce, comes back and is then forwarded to the 
> requesting client.
> 
> Sure, this impacts system-level performance.  But the answer 
> to the performance problem is straightforward:  get bigger, 
> faster boxes and bigger, faster signing engines.  I suspect 
> there's an ample number of crypto vendors out there who would 
> be willing to pitch their wares against the latter need.
> 
> It's also worth noting that among a heterogeneous population 
> of clients, perhaps only a small portion of them would nonce.  On
> the other hand, maybe most will.  I don't know.    I do know a
> security hole when I see it.  We incorporate thoughtful 
> security features into our protocols for a reason.
> 
> So, nonces break caching.  We knew that from day one. But, as 
> far as I can tell from the poll to date, NO extant signing 
> servers or clients are broken by the proposed text.
> 
> Mike
> 
> 
> 
> 

------=_NextPart_000_0028_01C38461.53D814B0
Content-Type: text/plain;
	name="comparison.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="comparison.txt"

The current proposal for the wording is:
>
> "Clients that elect to include a request nonce SHALL reject responses=20
> that fail to include the client's nonce from the associated request."
>
> "Correspondingly, upon receipt of a request containing a nonce, a =
responder SHALL=20
> include the value of such nonce in the production of the associated =
response."
>

This proposal prohibits some configuration that were possible before:

                           | Responder NOT capable of      Responder =
using nonce            Responder always using
                           | producing nonce               when the =
request contained one   nonce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D                =
                                                                         =
       =20
Client not including       | no replay protection          no replay =
protection             no replay protection
nonce                      |             =20
                           |        =20
Client including nonce     | (will be rejected by client   full replay =
protection           full replay protection
and not accepting answers  | and is NOT ALLOWED, as the                  =
                  =20
without nonce              | Responder MUST answer with                  =
                 =20
                           | nonce)                                   =20
                           |        =20
Client including nonce     | [**************** this Client configuration =
ist NOT ALLOWED *****************************]
but accepting answers      | (no replay protection)       (no replay =
protection)            (full replay protection)
without nonce              | [**************** this Client configuration =
ist NOT ALLOWED *****************************]
                           |=20


My proposal for the wording:

"Clients SHOULD include a request nonce, to allow responders to =
establish protection=20
against replay attacks. If the client included a nonce, it SHALL reject =
responses=20
containing a mismatching nonce. If the client included a nonce, it MAY =
accept or=20
reject responses containing no nonce at all based on its (security) =
requirements."

"As a response without nonce could be used for a replay attack against =
clients accepting
such responses, responders that want to ensure a maximum level of =
protection=20
against replay attacks SHOULD include a nonce into all responses. If the =
request did=20
not contain a nonce, a new nonce SHOULD be generated."


Result:

                           | Responder NOT capable of      Responder =
using nonce            Responder always using
                           | producing nonce               when the =
request contained one   nonce
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D                      =
                                                                         =
 =20
Client not inclunding      | no replay protection,         no replay =
protection,            no replay protection,
nonce                      | allowed but against           allowed but =
against              allowed but against
                           | the recommendation            the =
recommendation               the recommendation
                           | =20
Client including nonce     | allowed, but will             full replay =
protection           full replay protection
and not accepting answers  | be rejected by client         allowed but =
against
without nonce              | due to its requirements       =
recommendation for maximum
                           |                               security
                           |   =20
Client including nonce     | no replay protection          no replay =
protection             full replay protection
but accepting answers      |                               allowed, but =
against
without nonce              |                               =
recommendation for maximum
                           |                               security


Advantage: Client CAN and SHOULD ask for replay protection. If the =
responder is capable of giving one - it will.=20
If not, the client can decide to accept or reject the response.

------=_NextPart_000_0028_01C38461.53D814B0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QH63KP097042 for <[e-mail]>; Fri, 26 Sep 2003 10:06:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QH63mY097041 for ietf-pkix-bks; Fri, 26 Sep 2003 10:06:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QH62KP097034 for <[e-mail]>; Fri, 26 Sep 2003 10:06:02 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Sep 2003 10:05:58 -0700
Received: from 157.54.8.23 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 26 Sep 2003 10:05:58 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Sep 2003 10:05:58 -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(6.0.3790.0); Fri, 26 Sep 2003 10:05:20 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 26 Sep 2003 10:05:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 10:05:56 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP response pre-production
Thread-Index: AcOETnnom0BzK/KPQQuFJeXpSJk8ogAAeVKQ
From: "Ryan M. Hurst" <[e-mail]>
To: "David Engberg" <[e-mail]>, "Michael Myers" <[e-mail]>
Cc: <[e-mail]>, "Ambarish Malpani" <[e-mail]>, <[e-mail]>, "Russ Housley" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Tim Polk" <[e-mail]>
X-OriginalArrivalTime: 26 Sep 2003 17:05:57.0061 (UTC) FILETIME=[73BE5750:01C38450]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8QH62KP097036
Sender: [e-mail]
Precedence: 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 don't believe the proposal requires a server to support the
mixed mode behavior, I think it simply clarifies that this is how that
environment would be served.

Ryan

-----Original Message-----
From: David Engberg [mailto:[e-mail]] 
Sent: Friday, September 26, 2003 9:49 AM
To: Michael Myers
Cc: Ryan M. Hurst; [e-mail]; Ambarish Malpani;
[e-mail]; Russ Housley; Stephen Kent; Tim Polk
Subject: Re: OCSP response pre-production


Michael -

I should have clarified in my poll response that an extant signing 
server (CoreStreet's RTC Responder, part of the RTC VA) is broken by the

change unless the responder SHALL is changed to SHOULD.  With this 
modification, the clients are allowed to enforce your stated nonce 
requirements without breaking any servers.

I do not believe that Ryan's solution fits the needs of a large scale, 
high security deployment.  By forcing OCSP deployments to leave a 
key-bearing master server online, you are exposing your infrastructure 
to the risks of remote compromise (e.g. 
http://www.cert.org/advisories/CA-2002-29.html) and denial-of-service. 
Both of these attacks are more common and catastrophic in the real world

than any sort of man-in-the-middle replay of short-lived responses.

The proposed mixed-mode compromise would be similar to requiring the 
root DNS servers to perform RSA signatures whenever requested by a 
client.  An attacker on a 56kbps dial-up line could send enough requests

to saturate even a top-of-the-line $25k HSM.  One buffer overflow would 
allow an attacker to create responses that reinstate any revoked 
credential.

Is there any reason not to change the responder language to SHOULD while

maintaing the client language as SHALL?

Thanks,
David


Michael Myers wrote:
 > ...
> Ryan had a useful solution to this.  Non-signing caching servers
> relay nonced requests to whatever master server they're
> associated with that can sign.  A fresh response, including the
> nonce, comes back and is then forwarded to the requesting
> client.
> 
> Sure, this impacts system-level performance.  But the answer to
> the performance problem is straightforward:  get bigger, faster
> boxes and bigger, faster signing engines.  I suspect there's an
> ample number of crypto vendors out there who would be willing to
> pitch their wares against the latter need.
> 
> It's also worth noting that among a heterogeneous population of
> clients, perhaps only a small portion of them would nonce.  On
> the other hand, maybe most will.  I don't know.    I do know a
> security hole when I see it.  We incorporate thoughtful security
> features into our protocols for a reason.
> 
> So, nonces break caching.  We knew that from day one. But, as
> far as I can tell from the poll to date, NO extant signing
> servers or clients are broken by the proposed text.






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QH0oKP096830 for <[e-mail]>; Fri, 26 Sep 2003 10:00:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QH0oCw096829 for ietf-pkix-bks; Fri, 26 Sep 2003 10:00:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QH0nKP096822; Fri, 26 Sep 2003 10:00:49 -0700 (PDT) (envelope-from [e-mail])
Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Sep 2003 10:00:45 -0700
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Fri, 26 Sep 2003 10:00:34 -0700
Received: from 157.54.5.25 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 26 Sep 2003 10:00:44 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 26 Sep 2003 10:00:47 -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(6.0.3790.0); Fri, 26 Sep 2003 10:00:42 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Fri, 26 Sep 2003 10:00:42 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 10:00:39 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: OCSP response pre-production
Thread-Index: AcOETJZ2c+hveLpbQmudawHuz5x3AgAAxcUQ
From: "Ryan M. Hurst" <[e-mail]>
To: "Paul Hoffman / IMC" <[e-mail]>, "Michael Myers" <[e-mail]>, "David Engberg" <[e-mail]>, <[e-mail]>, "Ambarish Malpani" <[e-mail]>, <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Tim Polk" <[e-mail]>
X-OriginalArrivalTime: 26 Sep 2003 17:00:42.0670 (UTC) FILETIME=[B85A14E0:01C3844F]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8QH0nKP096823
Sender: [e-mail]
Precedence: 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 concur with this, er "me too" :)

Ryan

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[e-mail]] 
Sent: Friday, September 26, 2003 9:40 AM
To: Michael Myers; Ryan M. Hurst; David Engberg; [e-mail];
Ambarish Malpani; [e-mail]
Cc: Russ Housley; Stephen Kent; Tim Polk
Subject: RE: OCSP response pre-production

I hate to send "me too" responses, but everything Mike says in his 
extended discussion is exactly right. My summary would be:

- If you can't sign, you must reject requests with nonces.

- Caching servers can ask a different server to sign. They can 
respond to all requests that don't ahve nonces, and they (probably 
selectively) send back the requests that have nonces to a server 
willing to sign them.

- If you control the OCSP clients and you don't want to sign the 
responses, inhibit the clients from sending requests with nonces.


--Paul Hoffman, Director
--Internet Mail Consortium





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QGo4KP096400 for <[e-mail]>; Fri, 26 Sep 2003 09:50:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QGo43q096399 for ietf-pkix-bks; Fri, 26 Sep 2003 09:50:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QGo3KP096376 for <[e-mail]>; Fri, 26 Sep 2003 09:50:04 -0700 (PDT) (envelope-from [e-mail])
Received: from corestreet.com (engberg.corestreet.com [192.168.2.87]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id h8QGnZxh007980; Fri, 26 Sep 2003 12:49:35 -0400
Message-ID: <[e-mail]>
Date: Fri, 26 Sep 2003 12:49:00 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet, Ltd.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: "Ryan M. Hurst" <[e-mail]>, [e-mail], Ambarish Malpani <[e-mail]>, [e-mail], Russ Housley <[e-mail]>, Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>
Subject: Re: OCSP response pre-production
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Michael -

I should have clarified in my poll response that an extant signing 
server (CoreStreet's RTC Responder, part of the RTC VA) is broken by the 
change unless the responder SHALL is changed to SHOULD.  With this 
modification, the clients are allowed to enforce your stated nonce 
requirements without breaking any servers.

I do not believe that Ryan's solution fits the needs of a large scale, 
high security deployment.  By forcing OCSP deployments to leave a 
key-bearing master server online, you are exposing your infrastructure 
to the risks of remote compromise (e.g. 
http://www.cert.org/advisories/CA-2002-29.html) and denial-of-service. 
Both of these attacks are more common and catastrophic in the real world 
than any sort of man-in-the-middle replay of short-lived responses.

The proposed mixed-mode compromise would be similar to requiring the 
root DNS servers to perform RSA signatures whenever requested by a 
client.  An attacker on a 56kbps dial-up line could send enough requests 
to saturate even a top-of-the-line $25k HSM.  One buffer overflow would 
allow an attacker to create responses that reinstate any revoked 
credential.

Is there any reason not to change the responder language to SHOULD while 
maintaing the client language as SHALL?

Thanks,
David


Michael Myers wrote:
 > ...
> Ryan had a useful solution to this.  Non-signing caching servers
> relay nonced requests to whatever master server they're
> associated with that can sign.  A fresh response, including the
> nonce, comes back and is then forwarded to the requesting
> client.
> 
> Sure, this impacts system-level performance.  But the answer to
> the performance problem is straightforward:  get bigger, faster
> boxes and bigger, faster signing engines.  I suspect there's an
> ample number of crypto vendors out there who would be willing to
> pitch their wares against the latter need.
> 
> It's also worth noting that among a heterogeneous population of
> clients, perhaps only a small portion of them would nonce.  On
> the other hand, maybe most will.  I don't know.    I do know a
> security hole when I see it.  We incorporate thoughtful security
> features into our protocols for a reason.
> 
> So, nonces break caching.  We knew that from day one. But, as
> far as I can tell from the poll to date, NO extant signing
> servers or clients are broken by the proposed text.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QGcQKP096099 for <[e-mail]>; Fri, 26 Sep 2003 09:38:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QGcQEN096098 for ietf-pkix-bks; Fri, 26 Sep 2003 09:38:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from [63.202.92.152] (adsl-63-202-92-152.dsl.snfc21.pacbell.net [63.202.92.152]) (authenticated bits=0) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QGc0KQ096081; Fri, 26 Sep 2003 09:38:01 -0700 (PDT) (envelope-from [e-mail])
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002082bb9a1bcb12da@[63.202.92.152]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Habeas-SWE-1: winter into spring
X-Habeas-SWE-2: brightly anticipated
X-Habeas-SWE-3: like Habeas SWE (tm)
X-Habeas-SWE-4: Copyright 2002 Habeas (tm)
X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this
X-Habeas-SWE-6: email in exchange for a license for this Habeas
X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant
X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this
X-Habeas-SWE-9: mark in spam to <http://www.habeas.com/report>.
Date: Fri, 26 Sep 2003 09:40:15 -0700
To: "Michael Myers" <[e-mail]>, "Ryan M. Hurst" <[e-mail]>, "David Engberg" <[e-mail]>, <[e-mail]>, "Ambarish Malpani" <[e-mail]>, <[e-mail]>
From: Paul Hoffman / IMC <[e-mail]>
Subject: RE: OCSP response pre-production
Cc: "Russ Housley" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Tim Polk" <[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>

I hate to send "me too" responses, but everything Mike says in his 
extended discussion is exactly right. My summary would be:

- If you can't sign, you must reject requests with nonces.

- Caching servers can ask a different server to sign. They can 
respond to all requests that don't ahve nonces, and they (probably 
selectively) send back the requests that have nonces to a server 
willing to sign them.

- If you control the OCSP clients and you don't want to sign the 
responses, inhibit the clients from sending requests with nonces.


--Paul Hoffman, Director
--Internet Mail Consortium


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QGUwKP095329 for <[e-mail]>; Fri, 26 Sep 2003 09:30:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QGUwAe095328 for ietf-pkix-bks; Fri, 26 Sep 2003 09:30:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8QGUvKP095323 for <[e-mail]>; Fri, 26 Sep 2003 09:30:57 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 31261 invoked by uid 0); 26 Sep 2003 16:30:55 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.188.142) by woodstock.binhost.com with SMTP; 26 Sep 2003 16:30:55 -0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Fri, 26 Sep 2003 12:30:55 -0400
To: "Deacon, Alex" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: POLL:  Use of nonces in OCSP
Cc: [e-mail]
In-Reply-To: <[e-mail] .ad.vrsn.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>

Alex:

To support such an environment, the client should not include a nonce in 
the request.  Do you have control over the clients?  If so, then the change 
will not cause you a problem.

Russ

At 05:12 PM 9/25/2003 -0700, Deacon, Alex wrote:


>Hi Mike,
>
>Although this new text would not break the existing VeriSign OCSP code base,
>it will break the (soon to be deployed) next generation of our OCSP
>services.  These services are designed to serve PKI's with a high volume of
>RP's (such as TLS server and code signing CA's) and rely on response
>pre-production, distribution and caching through out the network.
>
>In such a deployment it is not possible for a responder to include a nonce
>in the response.
>
>Regards,
>Alex
>
>
>
>
> > -----Original Message-----
> > From: Michael Myers [mailto:[e-mail]]
> > Sent: Wednesday, September 24, 2003 7:38 AM
> > To: [e-mail]
> > Cc: Stephen Kent; Ambarish Malpani
> > Subject: POLL: Use of nonces in OCSP
> >
> >
> >
> > All,
> >
> > Recent list traffic indicates there might be some confusion out
> > there regarding the use of nonces in OCSP.  This is
> > understandable since RFC 2560 is regrettably silent on the
> > point.  It seems that most folks correctly inferred our original
> > intent but absent normative language there's a possibility that
> > some may not.
> >
> > After some discussion with the Chairs and the AD, we will take
> > action to clarify our original intent in one fashion or another
> > but first need to poll IMPLEMENTORS to determine how many, if
> > any, implementations of OCSP would break as a consequence of the
> > following normative language:
> >
> >     "Clients that elect to include a request nonce
> >      SHALL reject responses that fail to include
> >      the client's nonce from the associated request."
> >
> >     "Correspondingly, upon receipt of a request
> >      containing a nonce, a responder SHALL include
> >      the value of such nonce in the production of
> >      the associated response."
> >
> > IMPLEMENTORS ONLY, please, and just yes/no or equivalent.
> >
> > Mike
> >
> >



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QFoqKP093465 for <[e-mail]>; Fri, 26 Sep 2003 08:50:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8QFoqn3093464 for ietf-pkix-bks; Fri, 26 Sep 2003 08:50:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8QFooKP093459 for <[e-mail]>; Fri, 26 Sep 2003 08:50:50 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8QFog753094; Fri, 26 Sep 2003 08:50:42 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Ryan M. Hurst" <[e-mail]>, "David Engberg" <[e-mail]>, <[e-mail]>, "Ambarish Malpani" <[e-mail]>, <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Tim Polk" <[e-mail]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 08:54: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)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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, Ryan, Florian:

Apologies for the length of this but I didn't want this
predictable debate to occur on the POLL: thread.

The whole point of this clarification and the poll is to
recognize the fact that a client sends a nonce for two very good
reasons: protection against replay and to ensure freshness.
Both are relevant to high-assurance security practices.  There
was vigorous debate on this topic during OCSP's genesis, a good
deal of it between myself and Carlisle Adams, from which came
the nonce extension and it's optional use.

It was commonly understood back then that nonces break caching.
Some may recall that I was an advocate for pre-produced
responses for precisely the reasons it's now surfacing.   We
debated the point and arrived at a constructive conclusion.  It
went through WG, IETF and IESG last calls. No one objected and
it became RFC 2560.

As the poll clearly indicates, this common understanding was
correctly interpreted by, so far, every OCSP implementor.  The
proposed text simply codifies that understanding in a way that
makes it abundantly clear what SHALL be done.

We have a responsibility and a duty, especially within the
Security Area, to design secure protocols.  To have a client's
nonce sometimes respected and sometimes not, as would be the
case in changing the server-side requirement to SHOULD from
SHALL, defeats that purpose.

I'll say it again:  nonces are optional to begin with.  If your
system architecture relies on caching, then don't use nonces.
Now, I understand that one may not have full control over
client-side configuration and thus be unable to cause a given
population of clients to not use nonces.  But that does not mean
we should purposefully punch a hole in the security of the
protocol's specification in order to accomodate a particular
business case.

Ryan had a useful solution to this.  Non-signing caching servers
relay nonced requests to whatever master server they're
associated with that can sign.  A fresh response, including the
nonce, comes back and is then forwarded to the requesting
client.

Sure, this impacts system-level performance.  But the answer to
the performance problem is straightforward:  get bigger, faster
boxes and bigger, faster signing engines.  I suspect there's an
ample number of crypto vendors out there who would be willing to
pitch their wares against the latter need.

It's also worth noting that among a heterogeneous population of
clients, perhaps only a small portion of them would nonce.  On
the other hand, maybe most will.  I don't know.    I do know a
security hole when I see it.  We incorporate thoughtful security
features into our protocols for a reason.

So, nonces break caching.  We knew that from day one. But, as
far as I can tell from the poll to date, NO extant signing
servers or clients are broken by the proposed text.

Mike





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q6oUKP049655 for <[e-mail]>; Thu, 25 Sep 2003 23:50:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8Q6oUsf049654 for ietf-pkix-bks; Thu, 25 Sep 2003 23:50:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from polito.it (anacreon.polito.it [130.192.3.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q6oSKP049633 for <[e-mail]>; Thu, 25 Sep 2003 23:50:29 -0700 (PDT) (envelope-from [e-mail])
Received: from [130.192.1.27] (HELO polito.it) by polito.it (CommuniGate Pro SMTP 4.1.3) with ESMTP-TLS id 12892006 for [e-mail]; Fri, 26 Sep 2003 08:49:21 +0200
Message-ID: <[e-mail]>
Date: Fri, 26 Sep 2003 08:49:16 +0200
From: Marius Marian <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: POLL:  Use of nonces in OCSP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; 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>

Michael Myers wrote:

>After some discussion with the Chairs and the AD, we will take
>action to clarify our original intent in one fashion or another
>but first need to poll IMPLEMENTORS to determine how many, if
>any, implementations of OCSP would break as a consequence of the
>following normative language:
>
>    "Clients that elect to include a request nonce
>     SHALL reject responses that fail to include
>     the client's nonce from the associated request."
>
>    "Correspondingly, upon receipt of a request
>     containing a nonce, a responder SHALL include
>     the value of such nonce in the production of
>     the associated response."
>
>IMPLEMENTORS ONLY, please, and just yes/no or equivalent.
>  
>

Our implementation (here at Politecnico di Torino) will not break as a 
consequence of
the above mentioned statements.

Regards,
    Marius Marian.





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q4VdKP008686 for <[e-mail]>; Thu, 25 Sep 2003 21:31:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8Q4VddX008685 for ietf-pkix-bks; Thu, 25 Sep 2003 21:31:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from localhost ([e-mail] [66.31.43.88]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q4VcKP008680 for <[e-mail]>; Thu, 25 Sep 2003 21:31:38 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1A2jGY-0007R0-00; Thu, 25 Sep 2003 23:27:34 -0400
Message-ID: <[e-mail]>
Date: Thu, 25 Sep 2003 23:27:33 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: POLL: Use of nonces in OCSP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The only word I would change was in your second paragraph:

     "Correspondingly, upon receipt of a request
      containing a nonce, a responder SHALL include
      the value of such nonce in the production of
      the associated response."

I would recommend changing SHALL to SHOULD or MAY so that a compliant 
OCSP infrastructure can be deployed which has no signing keys on the 
responders.  If a request with a nonce is received, the responder can 
return a pre-generated response without the nonce, and the client can be 
configured to accept or reject this based on its local policies (as 
allowed by most current OCSP clients).  I believe that "SHALL" makes any 
responder without a signing key automatically uncompliant, since it will 
be unable to meet this requirement.

Thanks,
Dave



Michael Myers wrote:
> David,
> 
> The proposed text does not mandate use of nonces but rather
> clarifies existing text regarding this optional OCSP extension.
> Does that help?
> 
> Mike
> 
> 
>>-----Original Message-----
>>From: [e-mail]
>>[mailto:[e-mail]]On Behalf Of
>>David Engberg
>>Sent: Thursday, September 25, 2003 2:45 PM
>>To: [e-mail]
>>Subject: RE: POLL: Use of nonces in OCSP
>>
>>
>>
>>
>>No, we would not like to see the language change.
>>Yes, it would break
>>existing deployments based on caching-only responders.
>>
>>
>>Explanation:
>>
>>There is a (strong) case to be made that a large OCSP
>>deployment based
>>around caching-only responders with no private keys
>>to protect can be
>>more secure against real-world attacks than one based
>>entirely on
>>live-signing responders using nonces:
>>
>>     http://www.corestreet.com/whitepapers/nonce-sense.pdf
>>
>>It would be undesirable to change the specification
>>to break existing
>>implementations and deployments that chose this route.
>>
>>
>>
> 
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q4MGKP008436 for <[e-mail]>; Thu, 25 Sep 2003 21:22:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8Q4MGUH008435 for ietf-pkix-bks; Thu, 25 Sep 2003 21:22:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q4MFKP008430 for <[e-mail]>; Thu, 25 Sep 2003 21:22:16 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (h005008001124.ne.client2.attbi.com[66.31.43.88]) by comcast.net (rwcrmhc11) with ESMTP id <2003092604221201300bk5c4e>; Fri, 26 Sep 2003 04:22:12 +0000
Received: from localhost ([127.0.0.1] helo=corestreet.com ident=dave) by localhost with esmtp (Exim 3.35 #1 (Debian)) id 1A2jQE-0007RW-00; Thu, 25 Sep 2003 23:37:34 -0400
Message-ID: <[e-mail]>
Date: Thu, 25 Sep 2003 23:37:33 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: POLL: Use of nonces in OCSP
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have worked with several clients (for example, Alacris's OCSP client) 
that have independent configuration options for "Send a nonce with the 
request" and "Require the nonce in the response."

There may be reasons to remove this client flexibility ... to say that 
any client that sends a nonce MUST reject any response that does not 
contain that response.  But this new requirement may be unnecessarily 
restrictive, since it removes a potentially useful deployment alternative.

I was more concerned on the responder side ... I don't want a 
caching-only responder to be considered "out of compliance" if it cannot 
(or will not) return a nonce.

Thanks,
Dave


[e-mail] wrote:
> David,
>  
> David Engberg wrote on 09/25/2003, 14:44:
> 
>> There is a (strong) case to be made that a large OCSP deployment based
>> around caching-only responders with no private keys to protect can be
>> more secure against real-world attacks than one based entirely on
>> live-signing responders using nonces:
>>
>>      http://www.corestreet.com/whitepapers/nonce-sense.pdf
>>
>> It would be undesirable to change the specification to break existing
>> implementations and deployments that chose this route.
>>
>>
> Interesting paper.
>  
> Are you saying that you have an OCSP client that sends a nonce in the 
> OCSP request, and you have a caching OCSP responder that ignores that 
> nonce, and sends a cached OCSP response without that nonce, and your 
> OCSP client subsequently accepts that cached OCSP response even though 
> the nonce doesn't match ?
>  
> To me it sounds like the client should not be sending the nonce. Then 
> the cached OCSP responses will work fine.
> Perhaps there should be a hint for the client not to send the nonce, eg. 
> something in the AIA extension of the certificate being verified.
>  
> -- 
> I am the dog in dogfood
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q1PNKP000958 for <[e-mail]>; Thu, 25 Sep 2003 18:25:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8Q1PN6Y000957 for ietf-pkix-bks; Thu, 25 Sep 2003 18:25:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q1PLKP000952 for <[e-mail]>; Thu, 25 Sep 2003 18:25:21 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8Q1PL735475; Thu, 25 Sep 2003 18:25:21 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Ryan M. Hurst" <[e-mail]>, "David Engberg" <[e-mail]>, <[e-mail]>
Subject: Re: OCSP response pre-production
Date: Thu, 25 Sep 2003 18:28: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)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Ryan M. Hurst
> Sent: Thursday, September 25, 2003 5:28 PM
>
>. . .
>
> I wouldn't have a problem with changing the SHALL to 
> a SHOULD



I will.

Mike



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q0bpKP099208 for <[e-mail]>; Thu, 25 Sep 2003 17:37:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8Q0bp4m099207 for ietf-pkix-bks; Thu, 25 Sep 2003 17:37:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q0boKP099201 for <[e-mail]>; Thu, 25 Sep 2003 17:37:50 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8Q0bq734139; Thu, 25 Sep 2003 17:37:52 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "Alex Deacon" <[e-mail]>
Subject: OCSP response pre-production
Date: Thu, 25 Sep 2003 17:41:26 -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 V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 recent OCSP poll on the use of nonces has surfaced concerns
regarding OCSP response pre-production.

Let's use this thread to discuss the issue and so keep the POLL:
thread clear for break/no-break responses.

The text proposed in the poll does not mandate use of nonces.
It clarifies text that has been there from day one.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q0RoKP098885 for <[e-mail]>; Thu, 25 Sep 2003 17:27:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8Q0Ro63098884 for ietf-pkix-bks; Thu, 25 Sep 2003 17:27:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q0RnKP098874 for <[e-mail]>; Thu, 25 Sep 2003 17:27:49 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Sep 2003 17:27:51 -0700
Received: from 157.54.6.150 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 25 Sep 2003 17:27:46 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-05.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Sep 2003 17:27:57 -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(6.0.3790.1060); Thu, 25 Sep 2003 17:27:45 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 25 Sep 2003 17:27:45 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: POLL: Use of nonces in OCSP
Date: Thu, 25 Sep 2003 17:27:41 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: POLL: Use of nonces in OCSP
Thread-Index: AcODvzaQqxdCfkxdSOiB3Tk5i4PxHgABNM/g
From: "Ryan M. Hurst" <[e-mail]>
To: "David Engberg" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 26 Sep 2003 00:27:45.0725 (UTC) FILETIME=[01B9B6D0:01C383C5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8Q0RnKP098879
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dave - I agree that pre-produced responses are important, but I don't
think this wording prevents that behavior; the text proposed was:

"Clients that elect to include a request nonce SHALL reject responses
that fail to include the client's nonce from the associated request."

In other words if you include a nonce in your request you should compare
it to the nonce in the response you get back; This does mean that
clients should include a nonce, so clients that do not include a nonce
(like ours) are not negatively effected by this statement.
 
"Correspondingly, upon receipt of a request containing a nonce, a
responder SHALL include the value of such nonce in the production of the
associated response."

In other words if a client sends you a nonce generate a fresh response
and copy the nonce from the request into it. This does have the
potential to cause problems for clients that are sending a nonce, but if
their client is sending the nonce they are saying "hey help protect me
from replay attacks".

I wouldn't have a problem with changing the SHALL to a SHOULD, but if we
were to do that we should qualify why so that people understand the
distinction.

My personal opinion is that if a responder that distributes pre-produced
responses gets a request with a nonce in it, it should proxy the request
to the master to get a fresh response and replay it.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of David Engberg
Sent: Thursday, September 25, 2003 2:45 PM
To: [e-mail]
Subject: RE: POLL: Use of nonces in OCSP



No, we would not like to see the language change.  Yes, it would break 
existing deployments based on caching-only responders.


Explanation:

There is a (strong) case to be made that a large OCSP deployment based 
around caching-only responders with no private keys to protect can be 
more secure against real-world attacks than one based entirely on 
live-signing responders using nonces:

     http://www.corestreet.com/whitepapers/nonce-sense.pdf

It would be undesirable to change the specification to break existing 
implementations and deployments that chose this route.







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q0DAKP098578 for <[e-mail]>; Thu, 25 Sep 2003 17:13:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8Q0DAiY098577 for ietf-pkix-bks; Thu, 25 Sep 2003 17:13:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from pigeon.verisign.com (pigeon.verisign.com [65.205.251.71]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8Q0D9KP098571 for <[e-mail]>; Thu, 25 Sep 2003 17:13:09 -0700 (PDT) (envelope-from [e-mail])
Received: from mou1wnexc01.vcorp.ad.vrsn.com (verisign.com [65.205.251.53]) by pigeon.verisign.com (8.12.10/) with ESMTP id h8Q0CqpR024951; Thu, 25 Sep 2003 17:12:52 -0700 (PDT)
Received: by mou1wnexc01.vcorp.ad.vrsn.com with Internet Mail Service (5.5.2653.19) id <TK16RLR3>; Thu, 25 Sep 2003 17:12:52 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, [e-mail]
Cc: Stephen Kent <[e-mail]>, Ambarish Malpani <[e-mail]>
Subject: RE: POLL:  Use of nonces in OCSP
Date: Thu, 25 Sep 2003 17:12:48 -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>

Hi Mike,

Although this new text would not break the existing VeriSign OCSP code base,
it will break the (soon to be deployed) next generation of our OCSP
services.  These services are designed to serve PKI's with a high volume of
RP's (such as TLS server and code signing CA's) and rely on response
pre-production, distribution and caching through out the network.  

In such a deployment it is not possible for a responder to include a nonce
in the response.

Regards,
Alex




> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, September 24, 2003 7:38 AM
> To: [e-mail]
> Cc: Stephen Kent; Ambarish Malpani
> Subject: POLL: Use of nonces in OCSP
> 
> 
> 
> All,
> 
> Recent list traffic indicates there might be some confusion out
> there regarding the use of nonces in OCSP.  This is
> understandable since RFC 2560 is regrettably silent on the
> point.  It seems that most folks correctly inferred our original
> intent but absent normative language there's a possibility that
> some may not.
> 
> After some discussion with the Chairs and the AD, we will take
> action to clarify our original intent in one fashion or another
> but first need to poll IMPLEMENTORS to determine how many, if
> any, implementations of OCSP would break as a consequence of the
> following normative language:
> 
>     "Clients that elect to include a request nonce
>      SHALL reject responses that fail to include
>      the client's nonce from the associated request."
> 
>     "Correspondingly, upon receipt of a request
>      containing a nonce, a responder SHALL include
>      the value of such nonce in the production of
>      the associated response."
> 
> IMPLEMENTORS ONLY, please, and just yes/no or equivalent.
> 
> Mike
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PNduKP097796 for <[e-mail]>; Thu, 25 Sep 2003 16:39:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8PNduOP097795 for ietf-pkix-bks; Thu, 25 Sep 2003 16:39:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PNdsKP097790 for <[e-mail]>; Thu, 25 Sep 2003 16:39:54 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8PNdt732207; Thu, 25 Sep 2003 16:39:55 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "David Engberg" <[e-mail]>, <[e-mail]>
Subject: RE: POLL: Use of nonces in OCSP
Date: Thu, 25 Sep 2003 16:43: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
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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,

The proposed text does not mandate use of nonces but rather
clarifies existing text regarding this optional OCSP extension.
Does that help?

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of
> David Engberg
> Sent: Thursday, September 25, 2003 2:45 PM
> To: [e-mail]
> Subject: RE: POLL: Use of nonces in OCSP
>
>
>
>
> No, we would not like to see the language change.
> Yes, it would break
> existing deployments based on caching-only responders.
>
>
> Explanation:
>
> There is a (strong) case to be made that a large OCSP
> deployment based
> around caching-only responders with no private keys
> to protect can be
> more secure against real-world attacks than one based
> entirely on
> live-signing responders using nonces:
>
>      http://www.corestreet.com/whitepapers/nonce-sense.pdf
>
> It would be undesirable to change the specification
> to break existing
> implementations and deployments that chose this route.
>
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PLjaKP094847 for <[e-mail]>; Thu, 25 Sep 2003 14:45:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8PLjahn094846 for ietf-pkix-bks; Thu, 25 Sep 2003 14:45:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from the-humungus.corestreet.com ([68.162.232.130]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PLjTKP094841 for <[e-mail]>; Thu, 25 Sep 2003 14:45:35 -0700 (PDT) (envelope-from [e-mail])
Received: from corestreet.com (engberg.corestreet.com [192.168.2.87]) by the-humungus.corestreet.com (8.12.8/8.12.8) with ESMTP id h8PLjQxh028747 for <[e-mail]>; Thu, 25 Sep 2003 17:45:26 -0400
Message-ID: <[e-mail]>
Date: Thu, 25 Sep 2003 17:44:53 -0400
From: David Engberg <[e-mail]>
Organization: CoreStreet, Ltd.
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: [e-mail]
Subject: RE: POLL: Use of nonces in OCSP
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>

No, we would not like to see the language change.  Yes, it would break 
existing deployments based on caching-only responders.


Explanation:

There is a (strong) case to be made that a large OCSP deployment based 
around caching-only responders with no private keys to protect can be 
more secure against real-world attacks than one based entirely on 
live-signing responders using nonces:

     http://www.corestreet.com/whitepapers/nonce-sense.pdf

It would be undesirable to change the specification to break existing 
implementations and deployments that chose this route.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PHoqKP086108 for <[e-mail]>; Thu, 25 Sep 2003 10:50:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8PHoqrN086107 for ietf-pkix-bks; Thu, 25 Sep 2003 10:50:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PHooKP086102 for <[e-mail]>; Thu, 25 Sep 2003 10:50:50 -0700 (PDT) (envelope-from [e-mail])
Received: from mail5.microsoft.com ([157.54.6.156]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 25 Sep 2003 10:50:48 -0700
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Thu, 25 Sep 2003 10:50:46 -0700
Received: from 157.54.8.155 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 25 Sep 2003 10:50:46 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 25 Sep 2003 10:50:46 -0700
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(6.0.3790.1060); Thu, 25 Sep 2003 10:50:45 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 25 Sep 2003 10:50:45 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: POLL:  Use of nonces in OCSP
Date: Thu, 25 Sep 2003 10:50:51 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: POLL:  Use of nonces in OCSP
Thread-Index: AcODjWoPr6ppov5VRDmWLDTHv2V7ugAABzAQ
From: "Ryan M. Hurst" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, "Ambarish Malpani" <[e-mail]>
X-OriginalArrivalTime: 25 Sep 2003 17:50:45.0113 (UTC) FILETIME=[8B88C690:01C3838D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8PHopKP086103
Sender: [e-mail]
Precedence: 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, that is what I meant :)

-----Original Message-----
From: Michael Myers [mailto:[e-mail]] 
Sent: Thursday, September 25, 2003 10:53 AM
To: Ryan M. Hurst; [e-mail]
Cc: Stephen Kent; Ambarish Malpani
Subject: RE: POLL: Use of nonces in OCSP

Ryan,

I take that as "yes, that's what our code does."

Let's identify another thread to address pre-produced responses
and so keep the POLL: thread focused on gathering break/no-break
responses.  Thanks.

Mike

> -----Original Message-----
> From: Ryan M. Hurst [mailto:[e-mail]]
> Sent: Thursday, September 25, 2003 10:39 AM
> To: Michael Myers; [e-mail]
> Cc: Stephen Kent; Ambarish Malpani
> Subject: RE: POLL: Use of nonces in OCSP
>
>
> Yes
>
> I would also like to see text indicating the intent
> of leaving a nonce
> out of the request, namely its OK for a server to
> provide a pre-produced
> response.
>
> Ryan
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> On Behalf Of Michael Myers
> Sent: Wednesday, September 24, 2003 7:38 AM
> To: [e-mail]
> Cc: Stephen Kent; Ambarish Malpani
> Subject: POLL: Use of nonces in OCSP
>
>
> All,
>
> Recent list traffic indicates there might be some
> confusion out
> there regarding the use of nonces in OCSP.  This is
> understandable since RFC 2560 is regrettably silent on the
> point.  It seems that most folks correctly inferred
> our original
> intent but absent normative language there's a
> possibility that
> some may not.
>
> After some discussion with the Chairs and the AD, we will take
> action to clarify our original intent in one fashion
> or another
> but first need to poll IMPLEMENTORS to determine how many, if
> any, implementations of OCSP would break as a
> consequence of the
> following normative language:
>
>     "Clients that elect to include a request nonce
>      SHALL reject responses that fail to include
>      the client's nonce from the associated request."
>
>     "Correspondingly, upon receipt of a request
>      containing a nonce, a responder SHALL include
>      the value of such nonce in the production of
>      the associated response."
>
> IMPLEMENTORS ONLY, please, and just yes/no or equivalent.
>
> Mike
>
>
>
>
>
>







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PHnYKP086078 for <[e-mail]>; Thu, 25 Sep 2003 10:49:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8PHnYKn086077 for ietf-pkix-bks; Thu, 25 Sep 2003 10:49:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PHnXKP086071 for <[e-mail]>; Thu, 25 Sep 2003 10:49:33 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8PHnT716224; Thu, 25 Sep 2003 10:49:29 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Ryan M. Hurst" <[e-mail]>, <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, "Ambarish Malpani" <[e-mail]>
Subject: RE: POLL:  Use of nonces in OCSP
Date: Thu, 25 Sep 2003 10:53: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 V6.00.2800.1106
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>

Ryan,

I take that as "yes, that's what our code does."

Let's identify another thread to address pre-produced responses
and so keep the POLL: thread focused on gathering break/no-break
responses.  Thanks.

Mike

> -----Original Message-----
> From: Ryan M. Hurst [mailto:[e-mail]]
> Sent: Thursday, September 25, 2003 10:39 AM
> To: Michael Myers; [e-mail]
> Cc: Stephen Kent; Ambarish Malpani
> Subject: RE: POLL: Use of nonces in OCSP
>
>
> Yes
>
> I would also like to see text indicating the intent
> of leaving a nonce
> out of the request, namely its OK for a server to
> provide a pre-produced
> response.
>
> Ryan
>
> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> On Behalf Of Michael Myers
> Sent: Wednesday, September 24, 2003 7:38 AM
> To: [e-mail]
> Cc: Stephen Kent; Ambarish Malpani
> Subject: POLL: Use of nonces in OCSP
>
>
> All,
>
> Recent list traffic indicates there might be some
> confusion out
> there regarding the use of nonces in OCSP.  This is
> understandable since RFC 2560 is regrettably silent on the
> point.  It seems that most folks correctly inferred
> our original
> intent but absent normative language there's a
> possibility that
> some may not.
>
> After some discussion with the Chairs and the AD, we will take
> action to clarify our original intent in one fashion
> or another
> but first need to poll IMPLEMENTORS to determine how many, if
> any, implementations of OCSP would break as a
> consequence of the
> following normative language:
>
>     "Clients that elect to include a request nonce
>      SHALL reject responses that fail to include
>      the client's nonce from the associated request."
>
>     "Correspondingly, upon receipt of a request
>      containing a nonce, a responder SHALL include
>      the value of such nonce in the production of
>      the associated response."
>
> IMPLEMENTORS ONLY, please, and just yes/no or equivalent.
>
> Mike
>
>
>
>
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PHcjKP085807 for <[e-mail]>; Thu, 25 Sep 2003 10:38:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8PHch3D085799 for ietf-pkix-bks; Thu, 25 Sep 2003 10:38:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PHcgKP085793 for <[e-mail]>; Thu, 25 Sep 2003 10:38:42 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 25 Sep 2003 10:38:44 -0700
Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 25 Sep 2003 10:38:38 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Thu, 25 Sep 2003 10:38:41 -0700
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(6.0.3790.1060); Thu, 25 Sep 2003 10:38:37 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1069); Thu, 25 Sep 2003 10:38:37 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: POLL:  Use of nonces in OCSP
Date: Thu, 25 Sep 2003 10:38:42 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: POLL:  Use of nonces in OCSP
Thread-Index: AcOCwM8/VDs8HL2ATXawguoqE47CaQAyucBg
From: "Ryan M. Hurst" <[e-mail]>
To: "Michael Myers" <[e-mail]>, <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, "Ambarish Malpani" <[e-mail]>
X-OriginalArrivalTime: 25 Sep 2003 17:38:37.0576 (UTC) FILETIME=[D9E37080:01C3838B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8PHcgKP085795
Sender: [e-mail]
Precedence: 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

I would also like to see text indicating the intent of leaving a nonce
out of the request, namely its OK for a server to provide a pre-produced
response.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Michael Myers
Sent: Wednesday, September 24, 2003 7:38 AM
To: [e-mail]
Cc: Stephen Kent; Ambarish Malpani
Subject: POLL: Use of nonces in OCSP


All,

Recent list traffic indicates there might be some confusion out
there regarding the use of nonces in OCSP.  This is
understandable since RFC 2560 is regrettably silent on the
point.  It seems that most folks correctly inferred our original
intent but absent normative language there's a possibility that
some may not.

After some discussion with the Chairs and the AD, we will take
action to clarify our original intent in one fashion or another
but first need to poll IMPLEMENTORS to determine how many, if
any, implementations of OCSP would break as a consequence of the
following normative language:

    "Clients that elect to include a request nonce
     SHALL reject responses that fail to include
     the client's nonce from the associated request."

    "Correspondingly, upon receipt of a request
     containing a nonce, a responder SHALL include
     the value of such nonce in the production of
     the associated response."

IMPLEMENTORS ONLY, please, and just yes/no or equivalent.

Mike







Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PG6DKP081997 for <[e-mail]>; Thu, 25 Sep 2003 09:06:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8PG6D9R081996 for ietf-pkix-bks; Thu, 25 Sep 2003 09:06:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ascertia.com.pk ([203.81.196.124]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8PG68KP081976 for <[e-mail]>; Thu, 25 Sep 2003 09:06:10 -0700 (PDT) (envelope-from [e-mail])
Received: From ascertia3 (unverified [192.168.0.21]) by SMTP Server [192.168.0.1] (WinGate SMTP Receiver v5.0.4) with SMTP id <[e-mail]>; Thu, 25 Sep 2003 21:09:35 +0500
Message-ID: <000801c3837e$d68dc8c0$[e-mail]>
Reply-To: "Yasir Khan" <[e-mail]>
From: "Yasir Khan" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: POLL:  Use of nonces in OCSP
Date: Thu, 25 Sep 2003 21:05:28 +0500
Organization: Ascertia Limited.
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.4807.1700
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>

NO, not broken:

Ascertia Revocation Provider (ARP) OCSP client
TrustFinder OCSP Server
SignEzee
PDF Signer

Regards,

Yasir Khan
Software Engineer
Ascertia Limited.
www.ascertia.com 


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Michael Myers
Sent: 24 September 2003 15:38
To: [e-mail]
Cc: Stephen Kent; Ambarish Malpani
Subject: POLL: Use of nonces in OCSP


All,

Recent list traffic indicates there might be some confusion out
there regarding the use of nonces in OCSP.  This is
understandable since RFC 2560 is regrettably silent on the
point.  It seems that most folks correctly inferred our original
intent but absent normative language there's a possibility that
some may not.

After some discussion with the Chairs and the AD, we will take
action to clarify our original intent in one fashion or another
but first need to poll IMPLEMENTORS to determine how many, if
any, implementations of OCSP would break as a consequence of the
following normative language:

    "Clients that elect to include a request nonce
     SHALL reject responses that fail to include
     the client's nonce from the associated request."

    "Correspondingly, upon receipt of a request
     containing a nonce, a responder SHALL include
     the value of such nonce in the production of
     the associated response."

IMPLEMENTORS ONLY, please, and just yes/no or equivalent.

Mike






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PFhHKP080801 for <[e-mail]>; Thu, 25 Sep 2003 08:43:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8PFhH14080800 for ietf-pkix-bks; Thu, 25 Sep 2003 08:43:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from postmark.nist.gov (pushme.nist.gov [129.6.16.92]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PFh1KP080783 for <[e-mail]>; Thu, 25 Sep 2003 08:43:01 -0700 (PDT) (envelope-from [e-mail])
Received: from krdp8.nist.gov (krdp8.ncsl.nist.gov [129.6.54.113]) by postmark.nist.gov (8.12.5/8.12.5) with ESMTP id h8PFgG7o011472; Thu, 25 Sep 2003 11:42:16 -0400 (EDT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 25 Sep 2003 11:46:59 -0400
To: Stephen Kent <[e-mail]>, "Ryan M. Hurst" <[e-mail]>
From: Tim Polk <[e-mail]>
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID  matching)
Cc: <[e-mail]>
In-Reply-To: <p0600201cbb97c7099ffc@[128.89.89.75]>
References: <A883CA84-4DEC-4FF7-A4A4-9726EAFBAAB9@mimectl> <[e-mail].n t dev.microsoft.com> <p05210601bb74568e9933@[10.1.71.45]> <A883CA84-4DEC-4FF7-A4A4-9726EAFBAAB9@mimectl>
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>
Ryan,<br><br>
I meant to respond to this message some time ago.&nbsp; Steve's message
has reminded me to get my two cents worth in as well!<br><br>
At 06:54 PM 9/24/2003 -0400, Stephen Kent wrote:<br>
<blockquote type=cite class=cite cite>Ryan,<br><br>
Sorry for being late responding to your message on this topic. It slipped
through the cracks at my end.<br><br>
<blockquote type=cite class=cite cite><font size=2>Depends on your
definition Steve :)<br>
</font>&nbsp;<br>
<font size=2>We have run the latest NIST conformance tests and with very
few exceptions (namely things we didn't implement because it was
ambiguous or not practical) we pass, I know this doesn't exactly mean we
are conformant with 3280 but its the most complete test of that I am
aware of :)</font></blockquote><br>
Maybe Tim can fix this oversight :-)</blockquote><br>
We thought the tests were pretty comprehensive... and I know for a fact
that we test name chaining in our tests!&nbsp; Those must be in the tests
you determined to be impractical... <br><br>
We (NIST) are very interested in knowing more these about
ambiguities.&nbsp; Are these ambiguities in RFC 3280?&nbsp; Ambiguities
in the tests or test documents?<br><br>
We are trying very hard to complete interoperability testing so that 3280
can progress to Draft.&nbsp; If there are ambiguities in 3280 we would
like to expunge as many ambiguities as possible at that time.&nbsp; That
would suggest imperfections in the editors of 3280, so I find that
unlikely! :)<br><br>
If the ambiguities are in the test or test documents, we would like to
fix those as well.&nbsp; If the tests are wrong, we are not achieving an
accurate view of 3280 conformance.&nbsp; I am also working on protection
profiles for PKI clients that reference these tests.&nbsp; I don't want
to enshrine incorrect tests in a government &quot;standard&quot;.&nbsp;
(Just an aside: Note the little 's' - no FIPS is planned at this
time.)<br><br>
Either way, we would love to get the list of ambiguities as you see
them.<br><br>
<br>
<blockquote type=cite class=cite cite><blockquote type=cite class=cite cite>&nbsp;<br>
<font size=2>As for the specifics on name vs. key based chaining, the
algorithm described in 3280 section 6.1 effectively through out valid
chains as a policy if the name does not match.&nbsp; Its basically the
last check, we know the chain cryptographically validates, we know the
policy intersections and are happy with them, we know and trust the
issuer and despite all of this&nbsp; (and a bunch of other things) it
says lets throughs it out anyways.</font></blockquote><br>
failure to ensure matching between the Subject/Issuer name in a cert
chain, especially for the last two certs, creates additional
opportunities for human users to be fooled. Specifically, a user
examining an EE cert (that might be displayed by an application) may make
a value judgement based on the Issuer name, which in this case would not
necessarily be the same name as what an administrator examined and used
in his/her value judgement.&nbsp; So, failign to perform this check seems
to create a vulnerability that could otherwise be avoided.&nbsp; That, by
itself, seems to justify following the standard.<br><br>
Steve</blockquote><br>
The standard is quite clear that it is *not* name vs. key based chaining,
but name *and* key based chaining.&nbsp; (The key identifiers are not
required to chain, but will do so if the CAs are conformant with RFC
3280.&nbsp; If the key identifiers don't chain, that would clearly cause
interoperability problems!)<br><br>
Thanks,<br><br>
Tim<br><br>
</html>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PF1jKP078597 for <[e-mail]>; Thu, 25 Sep 2003 08:01:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8PF1jLV078596 for ietf-pkix-bks; Thu, 25 Sep 2003 08:01:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8PF1hKP078590 for <[e-mail]>; Thu, 25 Sep 2003 08:01:43 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Thu, 25 Sep 2003 10:02:48 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: POLL:  Use of nonces in OCSP
Date: Thu, 25 Sep 2003 10:00:26 -0500
Message-ID: <000101c38375$c4559060$[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, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-OriginalArrivalTime: 25 Sep 2003 15:02:48.0265 (UTC) FILETIME=[1543CB90:01C38376]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

After reviewing carefully your statement, my definitive answer is NO,
our implementation will not break.

Miguel A Rodriguez
SeguriDATA
Mexico

> -----Original Message-----
> From: Michael Myers [mailto:[e-mail]]
> Sent: Wednesday, September 24, 2003 2:13 PM
> To: Miguel Rodriguez
> Subject: RE: POLL: Use of nonces in OCSP
> 
> Miguel,
> 
> May I call you to understand why?  Else you can call me at
> [phone].
> 
> Michael Myers
> 
> > -----Original Message-----
> > From: Miguel Rodriguez [mailto:[e-mail]]
> > Sent: Wednesday, September 24, 2003 12:02 PM
> > To: 'Michael Myers'
> > Subject: RE: POLL: Use of nonces in OCSP
> >
> >
> > Yes
> >
> > Miguel A Rodriguez
> > SeguriDATA
> > Mexico
> >
> > > -----Original Message-----
> > > From: [e-mail]
> > [mailto:[e-mail]]
> > > On Behalf Of Michael Myers
> > > Sent: Wednesday, September 24, 2003 9:38 AM
> > > To: [e-mail]
> > > Cc: Stephen Kent; Ambarish Malpani
> > > Subject: POLL: Use of nonces in OCSP
> > >
> > >
> > > All,
> > >
> > > Recent list traffic indicates there might be some
> > confusion out
> > > there regarding the use of nonces in OCSP.  This is
> > > understandable since RFC 2560 is regrettably silent on the
> > > point.  It seems that most folks correctly inferred
> > our original
> > > intent but absent normative language there's a
> > possibility that
> > > some may not.
> > >
> > > After some discussion with the Chairs and the AD,
> > we will take
> > > action to clarify our original intent in one
> > fashion or another
> > > but first need to poll IMPLEMENTORS to determine
> > how many, if
> > > any, implementations of OCSP would break as a
> > consequence of the
> > > following normative language:
> > >
> > >     "Clients that elect to include a request nonce
> > >      SHALL reject responses that fail to include
> > >      the client's nonce from the associated request."
> > >
> > >     "Correspondingly, upon receipt of a request
> > >      containing a nonce, a responder SHALL include
> > >      the value of such nonce in the production of
> > >      the associated response."
> > >
> > > IMPLEMENTORS ONLY, please, and just yes/no or equivalent.
> > >
> > > Mike
> >
> >
> >
> >
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OMsXKP043112 for <[e-mail]>; Wed, 24 Sep 2003 15:54:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8OMsXss043111 for ietf-pkix-bks; Wed, 24 Sep 2003 15:54:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OMsWKP043086 for <[e-mail]>; Wed, 24 Sep 2003 15:54:32 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h8OMsS0w004741; Wed, 24 Sep 2003 18:54:28 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0600201cbb97c7099ffc@[128.89.89.75]>
In-Reply-To: <A883CA84-4DEC-4FF7-A4A4-9726EAFBAAB9@mimectl>
References:  <[e-mail].n t dev.microsoft.com>, <p05210601bb74568e9933@[10.1.71.45]> <A883CA84-4DEC-4FF7-A4A4-9726EAFBAAB9@mimectl>
Date: Wed, 24 Sep 2003 18:54:11 -0400
To: "Ryan M. Hurst" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID  matching)
Cc: <[e-mail]>
Content-Type: multipart/alternative; boundary="============_-1147678438==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1147678438==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

Ryan,

Sorry for being late responding to your message on this topic. It 
slipped through the cracks at my end.

>Depends on your definition Steve :)
>
>We have run the latest NIST conformance tests and with very few 
>exceptions (namely things we didn't implement because it was 
>ambiguous or not practical) we pass, I know this doesn't exactly 
>mean we are conformant with 3280 but its the most complete test of 
>that I am aware of :)

Maybe Tim can fix this oversight :-)

>
>As for the specifics on name vs. key based chaining, the algorithm 
>described in 3280 section 6.1 effectively through out valid chains 
>as a policy if the name does not match.  Its basically the last 
>check, we know the chain cryptographically validates, we know the 
>policy intersections and are happy with them, we know and trust the 
>issuer and despite all of this  (and a bunch of other things) it 
>says lets throughs it out anyways.

failure to ensure matching between the Subject/Issuer name in a cert 
chain, especially for the last two certs, creates additional 
opportunities for human users to be fooled. Specifically, a user 
examining an EE cert (that might be displayed by an application) may 
make a value judgement based on the Issuer name, which in this case 
would not necessarily be the same name as what an administrator 
examined and used in his/her value judgement.  So, failign to perform 
this check seems to create a vulnerability that could otherwise be 
avoided.  That, by itself, seems to justify following the standard.

Steve
--============_-1147678438==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>RE: Making more of Key IDs (was RE: 3280 Question
WRT SKID</title></head><body>
<div>Ryan,</div>
<div><br></div>
<div>Sorry for being late responding to your message on this topic. It
slipped through the cracks at my end.</div>
<div><br></div>
<blockquote type="cite" cite><font face="Arial" size="-1"
color="#000000">Depends on your definition Steve
:)</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">We have run
the latest NIST conformance tests and with very few exceptions (namely
things we didn't implement because it was ambiguous or not practical)
we pass, I know this doesn't exactly mean we are conformant with 3280
but its the most complete test of that I am aware of
:)</font></blockquote>
<div><br>
Maybe Tim can fix this oversight :-)<br>
</div>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Arial" size="-1">As for the
specifics on name vs. key based chaining, the algorithm described in
3280 section 6.1 effectively through out valid chains as a policy if
the name does not match.&nbsp;&nbsp;Its basically the last check, we
know the chain cryptographically validates, we know the policy
intersections and are happy with them, we know and trust the
issuer&nbsp;and despite all of this&nbsp; (and a bunch of other
things) it says lets throughs it out anyways.</font></blockquote>
<div><br></div>
<div>failure to ensure matching between the Subject/Issuer name in a
cert chain, especially for the last two certs, creates additional
opportunities for human users to be fooled. Specifically, a user
examining an EE cert (that might be displayed by an application) may
make a value judgement based on the Issuer name, which in this case
would not necessarily be the same name as what an administrator
examined and used in his/her value judgement.&nbsp; So, failign to
perform this check seems to create a vulnerability that could
otherwise be avoided.&nbsp; That, by itself, seems to justify
following the standard.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1147678438==_ma============--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OM5sKP035891 for <[e-mail]>; Wed, 24 Sep 2003 15:05:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8OM5sCd035889 for ietf-pkix-bks; Wed, 24 Sep 2003 15:05:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.aauckland.ac.nz [130.216.33.151] (may be forged)) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OM5qKP035877 for <[e-mail]>; Wed, 24 Sep 2003 15:05:52 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9-20030924/8.12.9) with ESMTP id h8OM5LVS004904; Thu, 25 Sep 2003 10:05:27 +1200
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h8OLcsM13801; Thu, 25 Sep 2003 09:38:54 +1200
Date: Thu, 25 Sep 2003 09:38:54 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: POLL:  Use of nonces in OCSP
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>

>    "Clients that elect to include a request nonce
>     SHALL reject responses that fail to include
>     the client's nonce from the associated request."
>
>    "Correspondingly, upon receipt of a request
>     containing a nonce, a responder SHALL include
>     the value of such nonce in the production of
>     the associated response."
>
>IMPLEMENTORS ONLY, please, and just yes/no or equivalent.

Yes (as in "Yes, that's what my code does").

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OLx4KP035110 for <[e-mail]>; Wed, 24 Sep 2003 14:59:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8OLx3Es035108 for ietf-pkix-bks; Wed, 24 Sep 2003 14:59:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from vulcan.rsasecurity.com (vulcan.rsasecurity.com [204.167.114.130]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8OLx0KP035097 for <[e-mail]>; Wed, 24 Sep 2003 14:59:03 -0700 (PDT) (envelope-from [e-mail])
Received: from ebola.securitydynamics.com by vulcan.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 24 Sep 2003 21:59:03 UT
Received: from exrsa01.rsa.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.12.10/NULL) with ESMTP id h8OLsAu5000437; Wed, 24 Sep 2003 17:54:11 -0400 (EDT)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <SW4ZGMKY>; Wed, 24 Sep 2003 14:58:42 -0700
Message-ID: <[e-mail]>
From: "Wertz, Eric" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, [e-mail]
Cc: Stephen Kent <[e-mail]>, Ambarish Malpani <[e-mail]>
Subject: RE: POLL:  Use of nonces in OCSP
Date: Wed, 24 Sep 2003 14:58:41 -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>

Neither RSA Cert-C or Cert-J would be affected/broken by this clarification
to the nonce-handling text.

-e


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OLTMKP032646 for <[e-mail]>; Wed, 24 Sep 2003 14:29:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8OLTMp4032645 for ietf-pkix-bks; Wed, 24 Sep 2003 14:29:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OLTKKP032630 for <[e-mail]>; Wed, 24 Sep 2003 14:29:20 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd08.aul.t-online.de  by mailout01.sul.t-online.com with smtp  id 1A2G8L-0007Uz-02; Wed, 24 Sep 2003 22:21:09 +0200
Received: from hagen (GzNECmZpQe6rAbfnyuQt5hLwyiJCpJ5T1pXxKkBGw4kbUrIORXOUEg@[217.228.226.72]) by fmrl08.sul.t-online.com with esmtp id 1A2G8I-0zrS9w0; Wed, 24 Sep 2003 22:21:06 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, <[e-mail]>
Cc: "'Stephen Kent'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>
Subject: RE: POLL:  Use of nonces in OCSP
Date: Wed, 24 Sep 2003 22:21:05 +0200
Organization: SyTrust
Message-ID: <000501c382d9$62529800$4228a8c0@hagen>
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
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-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>

Short answer for the POLL:

No, our client will not break
No, our responder will not break




Detailed answer for the interested:

>     "Clients that elect to include a request nonce
>      SHALL reject responses that fail to include
>      the client's nonce from the associated request."

No. Our client will not break - as its behaviour is configurable
(accept/warning/reject). The behaviour described is NOT the default. Our
default is to issue a warning to the user and not reject it. This can be
changed easily.

>     "Correspondingly, upon receipt of a request
>      containing a nonce, a responder SHALL include
>      the value of such nonce in the production of
>      the associated response."

No. Our responder will not break - as its behaviour is configurable
(always nonce, nonce on request, never nonce). Due to security reasons
the current default behaviour is to send a nonce for every request. As
far as I can see this would be in compliance with the new wording. On
the other hand, taking the new client requirement into account, there is
no reason for the "always" setting anymore and we will change our
default to "nonce on request" once all clients have adopted the changes.


With this change, the user / client can determine what "assurance" level
regarding the OCSP response it needs. This also means, that the users /
clients dictate to what amount an OCSP-Responder is allowed to use
pre-produced responses. We should discuss if this is pratical in real
world installations / services. Maybe the other way round will meet
todays requirements easier: the PKI operator / responder tells the user
what "assurance" level regarding the validity he is willing to give. But
this is up to you - from a technical point of view I wholeheartly
welcome the proposed clarifications.

Thanks for your work,

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OI2WKP059660 for <[e-mail]>; Wed, 24 Sep 2003 11:02:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8OI2Vpd059658 for ietf-pkix-bks; Wed, 24 Sep 2003 11:02:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from imo-m06.mx.aol.com (imo-m06.mx.aol.com [64.12.136.161]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OI2UKP059608 for <[e-mail]>; Wed, 24 Sep 2003 11:02:30 -0700 (PDT) (envelope-from [e-mail])
Received: from [e-mail] by imo-m06.mx.aol.com (mail_out_v36_r1.1.) id 7.177.204216f9 (16099) for <[e-mail]>; Wed, 24 Sep 2003 14:02:18 -0400 (EDT)
Received: from  pc655301.nscp.aoltw.net (h-10-169-25-113.nscp.aoltw.net [10.169.25.113]) by air-id11.mx.aol.com (v96.6) with ESMTP id MAILINID113-3ee33f71dc291eb; Wed, 24 Sep 2003 14:02:17 -0400
Date: Wed, 24 Sep 2003 11:02:16 -0700
From: "Terry Hayes" <[e-mail]>
Subject: Re: POLL:  Use of nonces in OCSP
To: [e-mail]
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
References:  <[e-mail]>
X-Mailer: AOL Communicator (20030917.2 Win)
Organization: AOL
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=us-ascii
X-AOL-IP: 10.169.25.113
Sender: [e-mail]
Precedence: 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 Netscape security library (NSS) includes an OCSP client, and the 
Netscape Certificate Management product includes an OCSP responder. 
Neither of these implementations will break as a result of the new language.

Terry Hayes




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OHDvKP050364 for <[e-mail]>; Wed, 24 Sep 2003 10:13:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8OHDvD0050363 for ietf-pkix-bks; Wed, 24 Sep 2003 10:13:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OHDtKP050348 for <[e-mail]>; Wed, 24 Sep 2003 10:13:55 -0700 (PDT) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=drh-consultancy.co.uk) by anchor-post-32.mail.demon.net with esmtp (Exim 3.35 #1) id 1A2DD7-0003sp-0W; Wed, 24 Sep 2003 18:13:53 +0100
Message-ID: <[e-mail]>
Date: Wed, 24 Sep 2003 18:16:20 +0100
From: Dr Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Dr Stephen Henson <[e-mail]>
CC: Michael Myers <[e-mail]>, [e-mail], Stephen Kent <[e-mail]>, Ambarish Malpani <[e-mail]>
Subject: Re: POLL:  Use of nonces in OCSP
References: <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.76.7.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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>

Dr Stephen Henson wrote:

> 
> No.
> 

I'd better clarify that: I mean "It wont break".

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OHAOKP050089 for <[e-mail]>; Wed, 24 Sep 2003 10:10:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8OHAO9i050088 for ietf-pkix-bks; Wed, 24 Sep 2003 10:10:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OHANKP050076 for <[e-mail]>; Wed, 24 Sep 2003 10:10:23 -0700 (PDT) (envelope-from [e-mail])
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.9/8.12.9) with SMTP id h8OHA64c019141; Wed, 24 Sep 2003 10:10:06 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "Richard Levitte - VMS Whacker" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Subject: RE: POLL: Use of nonces in OCSP
Date: Wed, 24 Sep 2003 10:13: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 V6.00.2800.1165
Sender: [e-mail]
Precedence: 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,
    Neither will the Valicert one.

A

> -----Original Message-----
> From: Richard Levitte - VMS Whacker [mailto:[e-mail]]
> Sent: Wednesday, September 24, 2003 9:47 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Re: POLL: Use of nonces in OCSP
> 
> 
> In message <[e-mail]> on 
> Wed, 24 Sep 2003 07:38:09 -0700, "Michael Myers" <[e-mail]> said:
> 
> mmyers> After some discussion with the Chairs and the AD, we will take
> mmyers> action to clarify our original intent in one fashion or another
> mmyers> but first need to poll IMPLEMENTORS to determine how many, if
> mmyers> any, implementations of OCSP would break as a consequence of the
> mmyers> following normative language:
> mmyers> 
> mmyers>     "Clients that elect to include a request nonce
> mmyers>      SHALL reject responses that fail to include
> mmyers>      the client's nonce from the associated request."
> mmyers> 
> mmyers>     "Correspondingly, upon receipt of a request
> mmyers>      containing a nonce, a responder SHALL include
> mmyers>      the value of such nonce in the production of
> mmyers>      the associated response."
> 
> For OpenSSL, the answer is no, as far as I can tell.
> 
> -- 
> Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
> Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
> T: [phone] |                             | SWEDEN
>      "Price, performance, quality...  choose the two you like"
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OGldKP049010 for <[e-mail]>; Wed, 24 Sep 2003 09:47:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8OGldvl049009 for ietf-pkix-bks; Wed, 24 Sep 2003 09:47:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from nic.lp.se (nic.lp.se [213.212.3.208]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OGlbKP048996 for <[e-mail]>; Wed, 24 Sep 2003 09:47:38 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (127.0.0.1) by nic.lp.se (MX V5.3 VnHj) with ESMTP; Wed, 24 Sep 2003 18:47:19 +0200
Date: Wed, 24 Sep 2003 18:47:16 +0200 (CEST)
Message-ID: <[e-mail]>
To: [e-mail]
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: POLL: Use of nonces in OCSP
From: Richard Levitte - VMS Whacker <[e-mail]>
In-Reply-To: <[e-mail]>
References: <p06002000bb90b4869722@[128.89.89.75]> <[e-mail]>
X-URL: http://www.lp.se/
X-Waved: dead chicken, GNU emacs 21.2.1, Mew version 4.0.58
X-Mew: See http://www.mew.org/
X-Mailer: Mew version 4.0.58 on Emacs 21.2 / Mule 5.0 (SAKAKI)
MIME-Version: 1.0
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>

In message <[e-mail]> on Wed, 24 Sep 2003 07:38:09 -0700, "Michael Myers" <[e-mail]> said:

mmyers> After some discussion with the Chairs and the AD, we will take
mmyers> action to clarify our original intent in one fashion or another
mmyers> but first need to poll IMPLEMENTORS to determine how many, if
mmyers> any, implementations of OCSP would break as a consequence of the
mmyers> following normative language:
mmyers> 
mmyers>     "Clients that elect to include a request nonce
mmyers>      SHALL reject responses that fail to include
mmyers>      the client's nonce from the associated request."
mmyers> 
mmyers>     "Correspondingly, upon receipt of a request
mmyers>      containing a nonce, a responder SHALL include
mmyers>      the value of such nonce in the production of
mmyers>      the associated response."

For OpenSSL, the answer is no, as far as I can tell.

-- 
Richard Levitte     | http://richard.levitte.org/ | Tunnlandsv. 3
Levitte Programming | http://www.lp.se/           | S-168 36 Bromma
T: [phone] |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OFiTKP044637 for <[e-mail]>; Wed, 24 Sep 2003 08:44:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8OFiTRE044636 for ietf-pkix-bks; Wed, 24 Sep 2003 08:44:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OFiRKP044619 for <[e-mail]>; Wed, 24 Sep 2003 08:44:28 -0700 (PDT) (envelope-from [e-mail])
Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=drh-consultancy.co.uk) by anchor-post-32.mail.demon.net with esmtp (Exim 3.35 #1) id 1A2BoW-000E84-0W; Wed, 24 Sep 2003 16:44:24 +0100
Message-ID: <[e-mail]>
Date: Wed, 24 Sep 2003 16:46:28 +0100
From: Dr Stephen Henson <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail], Stephen Kent <[e-mail]>, Ambarish Malpani <[e-mail]>
Subject: Re: POLL:  Use of nonces in OCSP
References: <[e-mail]>
In-Reply-To: <[e-mail]>
X-Enigmail-Version: 0.76.7.0
X-Enigmail-Supports: pgp-inline, pgp-mime
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>

No.

(OpenSSL OCSP 0.9.7 and later)

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [e-mail], PGP key: via homepage.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OEYYKP038463 for <[e-mail]>; Wed, 24 Sep 2003 07:34:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8OEYYto038462 for ietf-pkix-bks; Wed, 24 Sep 2003 07:34:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8OEYXKP038457 for <[e-mail]>; Wed, 24 Sep 2003 07:34:33 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.99]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id h8OEYY748319; Wed, 24 Sep 2003 07:34:34 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, "Ambarish Malpani" <[e-mail]>
Subject: POLL:  Use of nonces in OCSP
Date: Wed, 24 Sep 2003 07:38: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)
In-Reply-To: <p06002000bb90b4869722@[128.89.89.75]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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,

Recent list traffic indicates there might be some confusion out
there regarding the use of nonces in OCSP.  This is
understandable since RFC 2560 is regrettably silent on the
point.  It seems that most folks correctly inferred our original
intent but absent normative language there's a possibility that
some may not.

After some discussion with the Chairs and the AD, we will take
action to clarify our original intent in one fashion or another
but first need to poll IMPLEMENTORS to determine how many, if
any, implementations of OCSP would break as a consequence of the
following normative language:

    "Clients that elect to include a request nonce
     SHALL reject responses that fail to include
     the client's nonce from the associated request."

    "Correspondingly, upon receipt of a request
     containing a nonce, a responder SHALL include
     the value of such nonce in the production of
     the associated response."

IMPLEMENTORS ONLY, please, and just yes/no or equivalent.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8JDUkKP004489 for <[e-mail]>; Fri, 19 Sep 2003 06:30:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8JDUkhL004488 for ietf-pkix-bks; Fri, 19 Sep 2003 06:30:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8JDUjKP004479 for <[e-mail]>; Fri, 19 Sep 2003 06:30:45 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h8JDUd0w002412; Fri, 19 Sep 2003 09:30:39 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p06002000bb90b4869722@[128.89.89.75]>
In-Reply-To:  <[e-mail] dev.microsoft.com>
References:  <[e-mail] dev.microsoft.com>
Date: Fri, 19 Sep 2003 09:26:38 -0400
To: "Trevor Freeman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SCVP additions
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 16:18 -0700 9/18/03, Trevor Freeman wrote:
>Hi Steve,
>Sounds like a good idea. I am about to go on vacation for a couple of
>weeks, but I will start this on my return.
>Trevor
>

Thanks,

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8J713KP038484 for <[e-mail]>; Fri, 19 Sep 2003 00:01:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8J713Nt038483 for ietf-pkix-bks; Fri, 19 Sep 2003 00:01:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8J711KP038463 for <[e-mail]>; Fri, 19 Sep 2003 00:01:02 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA33682; Fri, 19 Sep 2003 09:06:37 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA15161; Fri, 19 Sep 2003 09:02:12 +0200
Message-ID: <[e-mail]>
Date: Fri, 19 Sep 2003 09:00:59 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: SCVP additions
References: <p0600200bbb8fe2331008@[128.89.89.75]>
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>

Steve,

> Folks,

> Based on the discussions of the last 2 weeks, I think there is a need to 
> augment the SCVP text to specify what an SCVP client does in terms of 
> validating responses from an SCVP server. Long ago we discussed the need 
> for a FSM-style description, when we were developing rules for 
> evaluating candidate DPD/DPV protocols, and it seems to be absent from 
> the SCVP spec.
> 
> Several different cases have been identified: dumb client using SCVP for 
> DPV, smart client using SCVP for DPD, 

Please add to this list: smart client using SCVP for DPV,

Denis

 > and SCVP server acting as a client
> for DPV or DPD. The requirements may be different for each of these 
> cases, in terms of what data must be configured in a client, how the 
> user knows what the client will do based on the config, etc. This sort 
> of requirement is analogous to what IPsec mandates re administrative 
> capabilities for SPDs, to allow a user to know what the IPsec 
> implementation will do based on the SPD configuration. Note that in 
> IPsec there are different requirements imposed on hosts vs. security 
> gateways, so the idea of different requirements for different classes of 
> implementation is not new.
> 
> Trevor, please think about how this can be accommodated in the next rev 
> of the document.  You may want to post text for this topic as you and 
> your co-authors develop proposed requirements for the different cases, 
> so the WG can discuss them separate from the rest of the document.
> 
> Steve
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8INIlKP074749 for <[e-mail]>; Thu, 18 Sep 2003 16:18:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8INIlXa074748 for ietf-pkix-bks; Thu, 18 Sep 2003 16:18:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8INIhKP074738 for <[e-mail]>; Thu, 18 Sep 2003 16:18:45 -0700 (PDT) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Sep 2003 16:18:40 -0700
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Thu, 18 Sep 2003 16:18:14 -0700
Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 18 Sep 2003 16:18:39 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 18 Sep 2003 16:17:15 -0700
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(6.0.3790.1060); Thu, 18 Sep 2003 16:18:40 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Thu, 18 Sep 2003 16:18:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP additions
Date: Thu, 18 Sep 2003 16:18:36 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP additions
Thread-Index: AcN+NfJZY5/DmQpvRJCFGG+ZTvUgkwABOuaQ
From: "Trevor Freeman" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 18 Sep 2003 23:18:57.0712 (UTC) FILETIME=[3C58AB00:01C37E3B]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8INIjKP074743
Sender: [e-mail]
Precedence: 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,
Sounds like a good idea. I am about to go on vacation for a couple of
weeks, but I will start this on my return.
Trevor

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Thursday, September 18, 2003 3:40 PM
To: [e-mail]
Subject: SCVP additions

Folks,

Based on the discussions of the last 2 weeks, I think there is a need 
to augment the SCVP text to specify what an SCVP client does in terms 
of validating responses from an SCVP server. Long ago we discussed 
the need for a FSM-style description, when we were developing rules 
for evaluating candidate DPD/DPV protocols, and it seems to be absent 
from the SCVP spec.

Several different cases have been identified: dumb client using SCVP 
for DPV, smart client using SCVP for DPD, and SCVP server acting as a 
client for DPV or DPD. The requirements may be different for each of 
these cases, in terms of what data must be configured in a client, 
how the user knows what the client will do based on the config, etc. 
This sort of requirement is analogous to what IPsec mandates re 
administrative capabilities for SPDs, to allow a user to know what 
the IPsec implementation will do based on the SPD configuration. Note 
that in IPsec there are different requirements imposed on hosts vs. 
security gateways, so the idea of different requirements for 
different classes of implementation is not new.

Trevor, please think about how this can be accommodated in the next 
rev of the document.  You may want to post text for this topic as you 
and your co-authors develop proposed requirements for the different 
cases, so the WG can discuss them separate from the rest of the 
document.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8IMeaKP072964 for <[e-mail]>; Thu, 18 Sep 2003 15:40:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8IMea50072963 for ietf-pkix-bks; Thu, 18 Sep 2003 15:40:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8IMeZKP072956 for <[e-mail]>; Thu, 18 Sep 2003 15:40:35 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h8IMeV0w007061; Thu, 18 Sep 2003 18:40:31 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0600200bbb8fe2331008@[128.89.89.75]>
Date: Thu, 18 Sep 2003 18:40:17 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: SCVP additions
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

Based on the discussions of the last 2 weeks, I think there is a need 
to augment the SCVP text to specify what an SCVP client does in terms 
of validating responses from an SCVP server. Long ago we discussed 
the need for a FSM-style description, when we were developing rules 
for evaluating candidate DPD/DPV protocols, and it seems to be absent 
from the SCVP spec.

Several different cases have been identified: dumb client using SCVP 
for DPV, smart client using SCVP for DPD, and SCVP server acting as a 
client for DPV or DPD. The requirements may be different for each of 
these cases, in terms of what data must be configured in a client, 
how the user knows what the client will do based on the config, etc. 
This sort of requirement is analogous to what IPsec mandates re 
administrative capabilities for SPDs, to allow a user to know what 
the IPsec implementation will do based on the SPD configuration. Note 
that in IPsec there are different requirements imposed on hosts vs. 
security gateways, so the idea of different requirements for 
different classes of implementation is not new.

Trevor, please think about how this can be accommodated in the next 
rev of the document.  You may want to post text for this topic as you 
and your co-authors develop proposed requirements for the different 
cases, so the WG can discuss them separate from the rest of the 
document.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8IJMCKP064495 for <[e-mail]>; Thu, 18 Sep 2003 12:22:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8IJMCcI064494 for ietf-pkix-bks; Thu, 18 Sep 2003 12:22:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8IJMAKP064480 for <[e-mail]>; Thu, 18 Sep 2003 12:22:11 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h8IJM10w027800 for <[e-mail]>; Thu, 18 Sep 2003 15:22:02 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p06002001bb8f6665c4e7@[12.159.173.165]>
Date: Thu, 18 Sep 2003 09:44:31 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: WG last call re draft-pkix-acpolicies-extn-03.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

This document seems to be stable and I've seen no discussion on it 
for a while, so let's begin a WG last call that will terminate on 
10/3.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8IH7mKP056875 for <[e-mail]>; Thu, 18 Sep 2003 10:07:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8IH7mJd056874 for ietf-pkix-bks; Thu, 18 Sep 2003 10:07:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.173]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8IH7kKP056865 for <[e-mail]>; Thu, 18 Sep 2003 10:07:47 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp3.pacifier.net (Postfix) with ESMTP id 7401E6DD6F; Thu, 18 Sep 2003 10:07:47 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, <[e-mail]>
Subject: RE: draft-ietf-pkix-x509-ipaddr-as-extn-02.txt
Date: Thu, 18 Sep 2003 10:09:20 -0700
Message-ID: <007c01c37e07$9dbdac30$[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, Build 10.0.2627
Importance: Normal
In-Reply-To: <p06002001bb8e70376b82@[128.89.89.82]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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 don't consider an ASN.1 module that does not compile to be just
neatness.   However I do think that after the new module is vetted that
it can be progressed.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Stephen Kent
> Sent: Wednesday, September 17, 2003 1:59 PM
> To: [e-mail]
> Subject: draft-ietf-pkix-x509-ipaddr-as-extn-02.txt
> 
> 
> 
> The new version of this document addressed all the comments posted 
> during the WG last call, to the satisfaction of the folks who made 
> the comments. Jim noted a couple of minor changes that should be made 
> to the ASN.1 module, for neatness, but he indicated that these are 
> very minor.
> 
> Thus the WG last call is closed now. I will asl Charlie Lynn to 
> generate a new rev of the ID with the changes Jim suggested, and then 
> forward this version of the ID to the IESG.
> 
> Steve
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HKxVej017488 for <[e-mail]>; Wed, 17 Sep 2003 13:59:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8HKxVt4017487 for ietf-pkix-bks; Wed, 17 Sep 2003 13:59:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HKxUej017476 for <[e-mail]>; Wed, 17 Sep 2003 13:59:30 -0700 (PDT) (envelope-from [e-mail])
Received: from [12.159.173.165] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h8HKxG14003959 for <[e-mail]>; Wed, 17 Sep 2003 16:59:26 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p06002001bb8e70376b82@[128.89.89.82]>
Date: Wed, 17 Sep 2003 16:59:07 -0400
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: draft-ietf-pkix-x509-ipaddr-as-extn-02.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The new version of this document addressed all the comments posted 
during the WG last call, to the satisfaction of the folks who made 
the comments. Jim noted a couple of minor changes that should be made 
to the ASN.1 module, for neatness, but he indicated that these are 
very minor.

Thus the WG last call is closed now. I will asl Charlie Lynn to 
generate a new rev of the ID with the changes Jim suggested, and then 
forward this version of the ID to the IESG.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HD84eo098976 for <[e-mail]>; Wed, 17 Sep 2003 06:08:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8HD84rk098975 for ietf-pkix-bks; Wed, 17 Sep 2003 06:08:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8HD81eo098968 for <[e-mail]>; Wed, 17 Sep 2003 06:08:02 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 4189 invoked by uid 1649); 17 Sep 2003 13:07:56 -0000
Date: 17 Sep 2003 13:07:56 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: [e-mail] (Peter Gutmann), [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
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>

The text below was meant as a proposal to change the RfC and NOT as a hint for an OCSP-client developer!

Sorry for not being clear on that one, Peter.

On Thu, 18 Sep 2003 01:01:00 +1200, [e-mail] (Peter Gutmann) wrote :

> "Florian Oelmaier" <[e-mail]> writes:
> 
> >If we want the OCSP responder to know beforehand, if the client will 
> >accept a pre-produced response or not, add a CRITICAL flag to the
> >extension. This way the client can indicate in the request if it is 
> > willing to accept a response without nonce.
> 
> Uhh, except that the RFC says the critical flag can't be set for this.
> 
> Peter.
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HCwdeo098720 for <[e-mail]>; Wed, 17 Sep 2003 05:58:39 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8HCwdYl098719 for ietf-pkix-bks; Wed, 17 Sep 2003 05:58:39 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8HCwbeo098710 for <[e-mail]>; Wed, 17 Sep 2003 05:58:37 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h8HCwVQA006625; Thu, 18 Sep 2003 00:58:31 +1200
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h8HD10f11746; Thu, 18 Sep 2003 01:01:00 +1200
Date: Thu, 18 Sep 2003 01:01:00 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Florian Oelmaier" <[e-mail]> writes:

>If we want the OCSP responder to know beforehand, if the client will accept a
>pre-produced response or not, add a CRITICAL flag to the extension. This way
>the client can indicate in the request if it is willing to accept a response
>without nonce.

Uhh, except that the RFC says the critical flag can't be set for this.

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GEKUeo085985 for <[e-mail]>; Tue, 16 Sep 2003 07:20:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8GEKUav085984 for ietf-pkix-bks; Tue, 16 Sep 2003 07:20:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GEKTeo085978 for <[e-mail]>; Tue, 16 Sep 2003 07:20:30 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16396; Tue, 16 Sep 2003 10:20:24 -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-x509-ipaddr-as-extn-02.txt
Date: Tue, 16 Sep 2003 10:20:24 -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		: X.509 Extensions for IP Addresses and AS Identifiers
	Author(s)	: C. Lynn et al.
	Filename	: draft-ietf-pkix-x509-ipaddr-as-extn-02.txt
	Pages		: 24
	Date		: 2003-9-16
	
This document defines two X.509 v3 certificate extensions.  The first
binds a list of IP address blocks, or prefixes, to the subject of a
certificate.  The second binds a list of autonomous system
identifiers to the subject of a certificate.  These extensions may be
used to convey the authorization of the subject to use the IP
addresses and autonomous system identifiers contained in the
extensions.
Please send comments on this draft to the [e-mail] mail
list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-x509-ipaddr-as-extn-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-x509-ipaddr-as-extn-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-x509-ipaddr-as-extn-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-x509-ipaddr-as-extn-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-pkix-x509-ipaddr-as-extn-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GEKQeo085976 for <[e-mail]>; Tue, 16 Sep 2003 07:20:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8GEKQ0X085975 for ietf-pkix-bks; Tue, 16 Sep 2003 07:20:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8GEKPeo085970 for <[e-mail]>; Tue, 16 Sep 2003 07:20:25 -0700 (PDT) (envelope-from [e-mail])
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16377; Tue, 16 Sep 2003 10:20:19 -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-pkixrep-02.txt
Date: Tue, 16 Sep 2003 10:20:19 -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 Repository 
                          Locator Service
	Author(s)	: S. Boeyen, P. Hallam-Baker
	Filename	: draft-ietf-pkix-pkixrep-02.txt
	Pages		: 3
	Date		: 2003-9-16
	
This document defines a PKI repository locator service. The service
makes use of DNS SRV records defined in accordance with RFC 2782. The
service enables certificate using systems to locate PKI repositories 
based on a domain name, identify the protocols that can be used to 
access the repository, and obtain addresses for the servers that host 
the repository service.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-pkixrep-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-pkixrep-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-pkixrep-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-pkixrep-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G6oleo042231 for <[e-mail]>; Mon, 15 Sep 2003 23:50:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G6olUl042229 for ietf-pkix-bks; Mon, 15 Sep 2003 23:50:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G6okeo042216 for <[e-mail]>; Mon, 15 Sep 2003 23:50:46 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id IAA03046; Tue, 16 Sep 2003 08:56:20 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id IAA09914; Tue, 16 Sep 2003 08:51:51 +0200
Message-ID: <[e-mail]>
Date: Tue, 16 Sep 2003 08:50:40 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Wen-Cheng Wang <[e-mail]>
CC: [e-mail]
Subject: Re: How a SCVP client authenticates the SCVP server?
References: <[e-mail]> <[e-mail]> <01ac01c37b71$6d358210$4f85900a@wcwang> <[e-mail]> <00d801c37c16$ddb383c0$4f85900a@wcwang>
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>

Wen-Cheng,

> Denis,
> 
> 
>>A "normal client" knows trust anchors (i.e. root CAs) and can query SCVP 
>>servers that are certified by one of these trust anchors (plus other 
>>conditions like CP OIDs for example or a given name). He will check the 
>>revocation status of the SCVP in the normal way, i.e. using CRLs or OCSP 
>>responses.must 
>>
>>Normal = "fat" client. :-)
>>
> 
> That sounds to me that a "normal client" has to have its own path
> construction/validation module, which might be a restircted (less capable)
> version, so that it can validate any SCVP server certificate that
> can be reached by one or more certification paths, which must
> start from one of its trust anchors and must can be constructed and
> validated by its own (less capable) path construction/validation module.
> If so, "normal clients" indeed represent a class between "simple clients"
> and "SCVP servers as clients" (SCVP server relays).
> 
> BTW, I note that you said 'a "normal client" .... can query SCVP servers
> that are certified by one of these trust anchors'. Do you mean that only
> trust anchors can issue SCVP server certificates? Or, again, is this just one
> possible case, but not the only one? For example, in a hierarchical PKI, can
> a lower-level subordinate CA issue SCVP server certificates? At least , I do
> not see any restriction imposed in the current SCVP draft on who can issue
> SCVP server certificates.

Any CA can indeed issue an SCVP certificate. There may be a hierarchy.
We are in agreement.

Denis

> Wen-Cheng
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G5vqeo022984 for <[e-mail]>; Mon, 15 Sep 2003 22:57:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G5vqQA022982 for ietf-pkix-bks; Mon, 15 Sep 2003 22:57:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gate.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G5tIeo021990 for <[e-mail]>; Mon, 15 Sep 2003 22:57:49 -0700 (PDT) (envelope-from [e-mail])
Received: from ms7.chttl.com.tw (ms7 [10.144.2.117]) by gate.chttl.com.tw (8.12.9/8.12.9) with ESMTP id h8G5se3K002452; Tue, 16 Sep 2003 13:54:40 +0800
Received: (from root@localhost) by ms7.chttl.com.tw (8.12.3/8.12.1) id h8G5sd0b003140; Tue, 16 Sep 2003 13:54:39 +0800
Received: from wcwang ([10.144.133.79]) by ms7.chttl.com.tw (8.12.3/8.12.1) with SMTP id h8G5sb7M003096; Tue, 16 Sep 2003 13:54:38 +0800
Message-ID: <00d801c37c16$ddb383c0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]> <01ac01c37b71$6d358210$4f85900a@wcwang> <[e-mail]>
Subject: Re: How a SCVP client authenticates the SCVP server?
Date: Tue, 16 Sep 2003 13:53:33 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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,

> 
> A "normal client" knows trust anchors (i.e. root CAs) and can query SCVP 
> servers that are certified by one of these trust anchors (plus other 
> conditions like CP OIDs for example or a given name). He will check the 
> revocation status of the SCVP in the normal way, i.e. using CRLs or OCSP 
> responses.must 
> 
> Normal = "fat" client. :-)
> 
That sounds to me that a "normal client" has to have its own path
construction/validation module, which might be a restircted (less capable)
version, so that it can validate any SCVP server certificate that
can be reached by one or more certification paths, which must
start from one of its trust anchors and must can be constructed and
validated by its own (less capable) path construction/validation module.
If so, "normal clients" indeed represent a class between "simple clients"
and "SCVP servers as clients" (SCVP server relays).

BTW, I note that you said 'a "normal client" .... can query SCVP servers
that are certified by one of these trust anchors'. Do you mean that only
trust anchors can issue SCVP server certificates? Or, again, is this just one
possible case, but not the only one? For example, in a hierarchical PKI, can
a lower-level subordinate CA issue SCVP server certificates? At least , I do
not see any restriction imposed in the current SCVP draft on who can issue
SCVP server certificates.

Wen-Cheng



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G5qQeo021017 for <[e-mail]>; Mon, 15 Sep 2003 22:53:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G5qQXB021016 for ietf-pkix-bks; Mon, 15 Sep 2003 22:52:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G5oGeo019669 for <[e-mail]>; Mon, 15 Sep 2003 22:52:25 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id CFF406F1E6; Mon, 15 Sep 2003 22:50:18 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Charles Lynn'" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: WG last call
Date: Mon, 15 Sep 2003 22:51:56 -0700
Message-ID: <001001c37c16$a4651ac0$[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, Build 10.0.2627
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Charlie,

The text looks fine and I can now confirm that I understand how to
encode the fields in question.

The ASN.1 module has a couple of problems.


1.  The module should start as follows:

   id-mod-ip-addr-and-as-ident { iso(1)
            identified-organization(3) dod(6) internet(1) security(5)
            mechanisms(5) pkix(7) mod(0) 30 }
   DEFINITIONS ::=

2.  By convention the module name SHOULD start with an uppercase
character and is normally a simple text string that describes what the
module is for (i.e. PKIXAttributeCertificate).  You might wish to change
to module name something like IPAddressBlocks.

3.  You have imported the symbol ip-pkix, but the symbol is never
referenced in the module.  I would suggest removing it.

4.  You might wish to remove the line "-- IMPORTS --" since this is
uncommented immeadiately below.

5.  Optional change is to use "DEFINITIONS EXPLICIT TAGS" and remove the
two occuraces of EXPLICIT.  This is not important and would not change
anything.

Jim



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G5Jheo005500 for <[e-mail]>; Mon, 15 Sep 2003 22:19:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G5JgSk005498 for ietf-pkix-bks; Mon, 15 Sep 2003 22:19:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailo.ntcif.telstra.com.au ([202.12.233.17]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G5Jeeo005448 for <[e-mail]>; Mon, 15 Sep 2003 22:19:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from uucp@localhost) by mailo.ntcif.telstra.com.au (8.8.2/8.6.9) id PAA21289; Tue, 16 Sep 2003 15:19:12 +1000 (EST)
Received: from maili.ntcif.telstra.com.au(202.12.162.17) via SMTP by mailo.ntcif.telstra.com.au, id smtpdelaa0H; Tue Sep 16 15:12:54 2003
Received: (from uucp@localhost) by maili.ntcif.telstra.com.au (8.8.2/8.6.9) id PAA08310; Tue, 16 Sep 2003 15:12:34 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdphaGRo; Tue Sep 16 15:11:22 2003
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id PAA16255; Tue, 16 Sep 2003 15:11:20 +1000 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: IP addr: 01: WG last call
Date: Tue, 16 Sep 2003 15:11:06 +1000
Message-ID: <[e-mail]>
Thread-Topic: IP addr: 01: WG last call
Thread-Index: AcN8CgDnqrR0+Il6R4uNDXOnTztaSwAAaKzg
From: "Manger, James H" <[e-mail]>
To: "Charles Lynn" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8G5Jgeo005491
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks for addressing my comments.


3.
A while ago people wanted to sort CRL entries with ideas of faster searching and one-pass processing.  It was a poor idea as everything had to be processed anyway (to verify the signature) and hash tables (that ignored sorting) were more efficient for lookups.

I have not looked at the best algorithms for the required operations on the address range extensions, but I wanted to know that someone else had and that sorting really did help.  It looks like you (and the 3 coders you mention) have done this.




----------
From: Charles Lynn [mailto:[e-mail]]
Sent: Tuesday, 16 September 2003 2:21 PM

James,

Thanks for your comments on our draft.

Do the following address your concerns?

>1. Instead of a BOOLEAN type for which TRUE is required and FALSE is 
>   forbidden, simply use a NULL type.

Thanks for suggesting the improvement.
(Now to get the CA and other software to use it ... :-)

>2. [previously answered]

>3. Why does everything have to be sorted?  Does it really make it 
>   easier or faster for CAs

If by CAs you mean the generation code, not really.  The CAs need to
do the sorting and handle/eliminate the boundary cases (adjacent,
overlapping, or subsumed allocations).

>   and relying parties,

Yes.  The following text has been added...

   Sections 2 and 3 specify several rules about the encoding of the
   extensions defined in this specification that MUST be followed.
   These encoding rules serve the following purposes.  First, they
   result in a unique encoding of the extension's value; two instances
   of an extension can be compared for equality octet-by-octet.  Second,
   they achieve the minimal size encoding of the information.  Third,
   they allow relying parties to use one-pass algorithms when performing
   certification path validation; in particular, the reply parties do
   not need either to sort the information, or to implement extra code
   in the subset checking algorithms to handle several boundary cases
   (adjacent, overlapping, or subsumed allocations).

Should some other point be addressed?

For the case that the extensions were written, the CAs sign each of the
~ 200,000 certificate on the order of once a year.  The 15,000 relying
parties validate each certificate about once a day (less caching).

>   or just harder to implement & more fragile to interoperate?

Harder for the CA, easier for all the relying parties.  The boundary cases
are easy to code incorrectly (having observed three people doing it).
Since the intended use is to help secure Internet routing, we would like
to fail-safe rather than fail-unprotected.

>4. Section 2.3 says delegations in a certificate must be a subset of 
>   the delegations in its issuer's certificate.  What does this mean 
>   for certificate path processing inputs and self-signed trust anchor 
>   certificates?  If a trust anchor is provided in the form of a 
>   self-signed certificate must it contain the delegation extension for 
>   the path to be valid?

Yes.

>   Is some sort of "initial-delegation-set" 
>   required as a path processing input (or, perhaps, a boolean flag 
>   indicating if each sort of delegation is allowed or disallowed)?

No.  The initial set comes directly from the set of trust anchor
certificates.  The follwing text (|) has been added.  Is it sufficient?
Should there be explicit text a la Section 6 of RFC 3280 that specifies
there is a working set of ranges, that is initialized from the trust
anchor certificate?  Do you think a description of the subset algorithm
is necessary to make it easier for folks to correctly implement the checks?

2.3.  IP Address Delegation Extension Certification Path Validation

   Certification path validation of a certificate containing the IP
   address delegation extension requires additional processing.  As each
   certificate in a path is validated, the IP addresses in the IP
   address delegation extension of that certificate MUST be subsumed by
   IP addresses in the IP address delegation extension in the issuer's
   certificate.  Validation MUST fail when this is not the case.  A
   certificate that is a trust anchor for certification path validation   |
   of certificates containing the IP address delegation extension, as     |
   well as all certificates along the path, MUST each contain the IP      |
   address delegation extension.  The initial set of allowed address      |
   ranges is taken from the trust anchor certificate.                     |

Charlie



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G4RFeo001528 for <[e-mail]>; Mon, 15 Sep 2003 21:27:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G4RFON001527 for ietf-pkix-bks; Mon, 15 Sep 2003 21:27:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from wolfe.bbn.com (wolfe.bbn.com [128.89.80.22]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G4REeo001518 for <[e-mail]>; Mon, 15 Sep 2003 21:27:14 -0700 (PDT) (envelope-from [e-mail])
Received: by wolfe.bbn.com (Postfix, from userid 13538) id 8E4FC16506; Tue, 16 Sep 2003 00:27:12 -0400 (EDT)
From: Charles Lynn <[e-mail]>
To: [e-mail], [e-mail]
Cc: [e-mail], [e-mail], [e-mail]
Subject: new version of draft-ietf-pkix-x509-ipaddr-as-extn-02.txt
Message-Id: <[e-mail]>
Date: Tue, 16 Sep 2003 00:27:12 -0400 (EDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

A revised version of the draft addressing the comments that were
received has been submitted.

Thanks for your feedback,
Charlie


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G4Mkeo001404 for <[e-mail]>; Mon, 15 Sep 2003 21:22:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G4Mksh001403 for ietf-pkix-bks; Mon, 15 Sep 2003 21:22:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from wolfe.bbn.com (wolfe.bbn.com [128.89.80.22]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G4Mjeo001397 for <[e-mail]>; Mon, 15 Sep 2003 21:22:45 -0700 (PDT) (envelope-from [e-mail])
Received: by wolfe.bbn.com (Postfix, from userid 13538) id 5A7FE16506; Tue, 16 Sep 2003 00:22:43 -0400 (EDT)
From: Charles Lynn <[e-mail]>
To: "Jim Schaad" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: WG last call
Message-Id: <[e-mail]>
Date: Tue, 16 Sep 2003 00:22:43 -0400 (EDT)
Sender: [e-mail]
Precedence: 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,

Thanks for your comments on our draft.

Do the following address your concerns?

> 1. I don't understand doing a draft to define private extensions.
>    This is the phrase used in the abstract.used in the message.

We removed the "private" modifier.
(FYI, note that the PKIX arc under which the extensions are defined is
 id-pe- ... "private extensions")

> 2. I have a complete lack of understanding on how the IP adresses are
>    to be encoded.  Either a section on this needs to be added or a
>    reference to this needs to be place in the document.

A literal interpretation is that we only talk about ranges of IP
addresses, not an individual address as one might put into a host's
certificate.  We added text covering individual addresses and give
an example.

A more general interpretation is that the current text is not clear.
To cover the case where the comment is about the encoding of the
IPAddress and IPAddressRange types, introductory text has been added.
Does the following address your concerns?

   2.1.1.  Encoding of an IP Address or Prefix

   There are two families of IP addresses: IPv4 and IPv6.

   An IPv4 address is a 32-bit quantity that is written as four decimal
   numbers, each in the range 0 through 255, separated by a dot (".");
   10.5.0.5 is an example of an IPv4 address.

   An IPv6 address is a 128-bit quantity that is written as eight
   hexadecimal numbers, each in the range 0 through ffff, separated by a
   semicolon (":"); 2001:0:200:3:0:0:0:1 is an example of an IPv6
   address.  IPv6 addresses frequently have adjacent fields whose value
   is 0.  One such group of 0 fields may be abbreviated by two
   semicolons ("::").  The previous example may thus be represented by
   2001:0:200:3::1.

   An address prefix is a set of 2^k continuous addresses whose more-
   significant bits are identical.  For example, the set of 512 IPv4
   addresses from 10.5.0.0 through 10.5.1.255 all have the same 23 most-
   significant bits.  The set of addresses is written by appending a
   slash ("/") and the number of constant bits to the lowest address in
   the set.  The prefix for the example set is 10.5.0.0/23, and contains
   2^(32-23) = 2^9 addresses.  The set of IPv6 addresses
   2001:0:200:0:0:0:0:0 through 2001:0:3ff:ffff:ffff:ffff:ffff:ffff
   (2^89 addresses) is represented by 2001:0:200:0:0:0:0:0/39 or
   equivalently 2001:0:200::/39.  A prefix may be abbreviated by
   omitting the less-significant zero fields, but there should be enough
   fields to contain the indicated number of constant bits.  The
   abbreviated forms of the example IPv4 prefix is 10.5.0/23 and of the
   example IPv6 prefix is 2001:0:200/39.

   An IP address or prefix is encoded in the IP address delegation
   extension as a DER-encoded ASN.1 BIT STRING containing the constant
   most-significant bits.  Recall [X.690] that the DER encoding of a BIT
   STRING consists of the BIT STRING type (0x03), followed by (an
   encoding of) the number of value octets, followed by the value.  The
   value consists of an "initial octet" that specifies the number of
   unused bits in the last value octet, followed by the "subsequent
   octets" that contain the octets of the bit string.  (For IP
   addresses, the encoding of the length will be just the length.)

   In the case of a single address, all the bits are constant, so the
   bit string for an IPv4 address contains 32 bits.  The subsequent
   octets in the DER-encoding of the address 10.5.0.4 are 0x0a 0x05 0x00
   0x04.  Since all the bits in the last octet are used, the initial
   octet is 0x00.  The octets in the DER-encoded BIT STRING is thus:

        Type Len  Unused Bits ...
        0x03 0x05  0x00  0x0a 0x05 0x00 0x04

   Similarly, the DER-encoding of the prefix 10.5.0/23 is:

        Type Len  Unused Bits ...
        0x03 0x04  0x01  0x0a 0x05 0x00

   In this case the three subsequent octets contain 24 bits, but the
   prefix only uses 23, so there is one unused bit in the last octet,
   thus the initial octet is 1 (the DER require that all unused bits
   MUST be set to zero-bits).

   The DER-encoding of the IPv6 address 2001:0:200:3:0:0:0:1 is:

        Type Len  Unused Bits ...
        0x03 0x11  0x00  0x20 0x01 0x00 0x00 0x02 0x00 0x00 0x03
                         0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x01

   and the DER-encoding of the prefix 2001:0:200/39, which has one
   unused bit in the last octet, is:

        Type Len  Unused Bits ...
        0x03 0x06  0x01  0x20 0x01 0x00 0x00 0x02


   2.1.2.  Encoding of a Range of IP Addresses

   While any contiguous range of IP addresses can be represented by a
   set of contiguous prefixes, a more concise representation is achieved
   by encoding the range as a SEQUENCE containing the lowest address and
   the highest address, where each address is encoded as a BIT STRING.
   Within the SEQUENCE, the bit string representing the lowest address
   in the range is formed by removing all the least-significant zero-
   bits from the address, and the bit string representing the highest
   address in the range is formed by removing all the least-significant
   one-bits.  The DER BIT STRING encoding requires that all the unused
   bits in the last octet MUST be set to zero-bits.  Note that a prefix
   can always be expressed as a range, but a range cannot always be
   expressed as a prefix.

   The range of addresses represented by the prefix 10.5.0/23 is
   10.5.0.0 through 10.5.1.255.  The lowest address ends in sixteen
   zero-bits that are removed.  The DER-encoding of the resulting
   sixteen-bit string is:

        Type Len  Unused Bits ...
        0x03 0x03  0x00  0x0a 0x05

   The highest address ends in nine one-bits that are removed.  The DER-
   encoding of the resulting twenty-three-bit string is:

        Type Len  Unused Bits ...
        0x03 0x04  0x01  0x0a 0x05 0x00

   The prefix 2001:0:200/39 can be encoded as a range where the DER-
   encoding of the lowest address (2001:0:200::) is:

        Type Len  Unused Bits ...
        0x03 0x06  0x01  0x20 0x01 0x00 0x00 0x02

   and the largest address (2001:0:3ff:ffff:ffff:ffff:ffff:ffff), which,
   after removal of the ninety least-significant one-bits leaves a
   thirty-eight bit string, is encoded as:

        Type Len  Unused Bits ...
        0x03 0x06  0x02  0x20 0x01 0x00 0x00 0x00

   The special case of all IP address blocks, i.e., a prefix of all
   zero-bits -- "0/0", MUST be encoded per the DER with a length octet
   of one, an initial octet of zero, and no subsequent octets:

        Type Len  Unused Bits ...
        0x03 0x01  0x00

   Note that for IP addresses the number of trailing zero-bits is
   significant.  For example, the DER-encoding of 10.64/12:

        Type Len  Unused Bits ...
        0x03 0x03  0x04  0x0a 0x40

   is different than the DER-encoding of 10.64.0/20:

        Type Len  Unused Bits ...
        0x03 0x04  0x04  0x0a 0x40 0x00
...
   2.2.3.8.  Element addressPrefix and Type IPAddress
...
   An IP address prefix is encoded as a BIT STRING.  The DER encoding of
   a BIT STRING uses the initial octet of the string to specify how many
   of the least-significant bits of the last subsequent octet are
   unused.  The DER encoding specifies that these unused bits MUST be
   set to zero-bits.

   Example:
             128.0.0.0       = 1000 0000.0000 0000.0000 0000.0000 0000
          to 143.255 255 255 = 1000 1111.1111 1111.1111 1111.1111 1111
        bit string to encode = 1000
              Type Len  Unused Bits ...
   Encoding = 0x03 0x02  0x04  0x80
...
   2.2.3.9.  Element addressRange and Type IPAddressRange

   The addressRange element is of type IPAddressRange.  The
   IPAddressRange type consists of a SEQUENCE containing a minimum
   (element min) and maximum (element max) IP address.  Each IP address
   is encoded as a BIT STRING.  The semantic interpretation of the
   minimum address in an IPAddressRange is that all the unspecified bits
   (for the full length of the IP address) are zero-bits.  The semantic
   interpretation of the maximum address is that all the unspecified
   bits are one-bits.  The BIT STRING for the minimum address results
   from removing all the least-significant zero-bits from the minimum
   address.  The BIT STRING for the maximum address results from
   removing all the least-significant one-bits from the maximum address.

   Example:
             129.64.0.0       = 1000 0001.0100 0000.0000 0000.0000 0000
          to 143.255.255.255  = 1000 1111.1111 1111.1111 1111.1111 1111
           minimum bit string = 1000 0001.01
           maximum bit string = 1000
   Encoding = SEQUENCE {
               Type Len  Unused Bits ...
        min    0x03 0x03  0x06  0x81      0x40
        max    0x03 0x02  0x04  0x80
              }

To cover the case where the comment is about the criteria used to
select which CHOICE is to be used, pseudo code has been added.

   2.2.3.7.  Type IPAddressOrRange

   The IPAddressOrRange type is a CHOICE of either an addressPrefix (an
   IP prefix or address) or an addressRange (an IP address range)
   element.

   This specification requires that any range of addresses that can be
   encoded as prefix MUST be encoded using an IPAddress element (a BIT
   STRING), and any range that cannot be encoded as a prefix MUST be
   encoded using an IPAddressRange (a SEQUENCE containing two BIT
   STRINGs).  The following pseudo code illustrates how to select the
   encoding of a given range of addresses.

        LET  N = the number of matching most-significant bits in the
                 lowest and highest addresses of the range
        IF   all the remaining bits in the lowest address are zero-bits
         AND all the remaining bits in the highest address are one-bits
        THEN the range MUST be encoded as an N-bit IPAddress
        ELSE the range MUST be encoded as an IPAddressRange

Are there other places where the text needs to be improved?

> 3. There is no ASN.1 module but this document defines new items.  (At
>    least there is no tagging so I don't need to know explicit vs implicit.)

Russ has assiged a module id, and an appendix has been added...

   Appendix A -- ASN.1 Module

   This normative appendix describes the IP address and AS identifiers
   extensions used by conforming PKI components in ASN.1 syntax.

   id-mod-ip-addr-and-as-ident  OBJECT IDENTIFIER ::= { iso(1)
            identified-organization(3) dod(6) internet(1) security(5)
            mechanisms(5) pkix(7) mod(0) 30 }
   DEFINITIONS ::=
   BEGIN
   -- EXPORTS ALL --
   -- IMPORTS --
   IMPORTS
   -- PKIX specific OIDs and arcs --
   id-pkix, id-pe FROM PKIX1Explicit88 { iso(1)
            identified-organization(3) dod(6) internet(1) security(5)
            mechanisms(5) pkix(7) id-mod(0) id-pkix1-explicit(18) };

   -- IP Address Delegation Extension OID --
   id-pe-ipAddrBlock  OBJECT IDENTIFIER ::= { id-pe 7 }
   -- IP Address Delegation Extension Syntax --
   IPAddrBlocks        ::= SEQUENCE OF IPAddressFamily
   IPAddressFamily     ::= SEQUENCE { -- AFI & opt SAFI --
      addressFamily        OCTET STRING (SIZE (2..3)),
      ipAddressChoice      IPAddressChoice }
   IPAddressChoice     ::= CHOICE {
      inherit              NULL, -- inherit from issuer --
      addressesOrRanges    SEQUENCE OF IPAddressOrRange }
   IPAddressOrRange    ::= CHOICE {
      addressPrefix        IPAddress,
      addressRange         IPAddressRange }
   IPAddressRange      ::= SEQUENCE {
      min                  IPAddress,
      max                  IPAddress }
   IPAddress           ::= BIT STRING

   -- Autonomous System Identifier Delegation Extension OID --
   id-pe-autonomousSysId  OBJECT IDENTIFIER ::= { id-pe 8 }
   -- Autonomous System Identifier Delegation Extension Syntax --
   ASIdentifiers       ::= SEQUENCE {
       asnum               [0] EXPLICIT ASIdentifierChoice OPTIONAL,
       rdi                 [1] EXPLICIT ASIdentifierChoice OPTIONAL }
   ASIdentifierChoice  ::= CHOICE {
      inherit              NULL, -- inherit from issuer --
      asIdsOrRanges        SEQUENCE OF ASIdOrRange }
   ASIdOrRange         ::= CHOICE {
       id                  ASId,
       range               ASRange }
   ASRange             ::= SEQUENCE {
       min                 ASId,
       max                 ASId }
   ASId                ::= INTEGER

   END

Charlie


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G4L4eo001356 for <[e-mail]>; Mon, 15 Sep 2003 21:21:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8G4L4UJ001353 for ietf-pkix-bks; Mon, 15 Sep 2003 21:21:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from wolfe.bbn.com (wolfe.bbn.com [128.89.80.22]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8G4L0eo001334 for <[e-mail]>; Mon, 15 Sep 2003 21:21:02 -0700 (PDT) (envelope-from [e-mail])
Received: by wolfe.bbn.com (Postfix, from userid 13538) id B38A116506; Tue, 16 Sep 2003 00:20:53 -0400 (EDT)
From: Charles Lynn <[e-mail]>
To: "Manger, James H" <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: IP addr: 01: WG last call
Message-Id: <[e-mail]>
Date: Tue, 16 Sep 2003 00:20:53 -0400 (EDT)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

James,

Thanks for your comments on our draft.

Do the following address your concerns?

>1. Instead of a BOOLEAN type for which TRUE is required and FALSE is 
>   forbidden, simply use a NULL type.
>
>Change the type of the inherit fields in IPAddressChoice (2.2.3) and 
>ASIdentifierChoice (3.2.3) to the following:
>
>    IPAddressChoice     ::= CHOICE {
>       inherit              NULL, -- Inherit from Issuer
>       addressesOrRanges    SEQUENCE OF IPAddressOrRange }
>
>    ASIdentifierChoice ::= CHOICE {
>       inherit             NULL, -- Inherit from Issuer
>       asIdsOrRanges       SEQUENCE OF ASIdOrRange }
>
>The associated text describing the inherit fields (2.2.3.5 & 
>3.2.3.3) can be simplified as follows:
>
>"2.2.3.5.  Element inherit
>
>    If the IPAddressChoice choice contains the inherit element, then 
>the set of authorized IP addresses for the specified AFI and 
>optional SAFI is taken from the Issuer's certificate, or the 
>Issuer's Issuer's certificate, recursively, until a certificate 
>containing an IPAddressChoice containing an addressesOrRanges 
>element is located.

Thanks for suggesting the improvement.
(Now to get the CA and other software to use it ... :-)

>2. [previously answered]

>3. Why does everything have to be sorted?  Does it really make it 
>   easier or faster for CAs

If by CAs you mean the generation code, not really.  The CAs need to
do the sorting and handle/eliminate the boundary cases (adjacent,
overlapping, or subsumed allocations).

>   and relying parties,

Yes.  The following text has been added...

   Sections 2 and 3 specify several rules about the encoding of the
   extensions defined in this specification that MUST be followed.
   These encoding rules serve the following purposes.  First, they
   result in a unique encoding of the extension's value; two instances
   of an extension can be compared for equality octet-by-octet.  Second,
   they achieve the minimal size encoding of the information.  Third,
   they allow relying parties to use one-pass algorithms when performing
   certification path validation; in particular, the reply parties do
   not need either to sort the information, or to implement extra code
   in the subset checking algorithms to handle several boundary cases
   (adjacent, overlapping, or subsumed allocations).

Should some other point be addressed?

For the case that the extensions were written, the CAs sign each of the
~ 200,000 certificate on the order of once a year.  The 15,000 relying
parties validate each certificate about once a day (less caching).

>   or just harder to implement & more fragile to interoperate?

Harder for the CA, easier for all the relying parties.  The boundary cases
are easy to code incorrectly (having observed three people doing it).
Since the intended use is to help secure Internet routing, we would like
to fail-safe rather than fail-unprotected.

>4. Section 2.3 says delegations in a certificate must be a subset of 
>   the delegations in its issuer's certificate.  What does this mean 
>   for certificate path processing inputs and self-signed trust anchor 
>   certificates?  If a trust anchor is provided in the form of a 
>   self-signed certificate must it contain the delegation extension for 
>   the path to be valid?

Yes.

>   Is some sort of "initial-delegation-set" 
>   required as a path processing input (or, perhaps, a boolean flag 
>   indicating if each sort of delegation is allowed or disallowed)?

No.  The initial set comes directly from the set of trust anchor
certificates.  The follwing text (|) has been added.  Is it sufficient?
Should there be explicit text a la Section 6 of RFC 3280 that specifies
there is a working set of ranges, that is initialized from the trust
anchor certificate?  Do you think a description of the subset algorithm
is necessary to make it easier for folks to correctly implement the checks?

2.3.  IP Address Delegation Extension Certification Path Validation

   Certification path validation of a certificate containing the IP
   address delegation extension requires additional processing.  As each
   certificate in a path is validated, the IP addresses in the IP
   address delegation extension of that certificate MUST be subsumed by
   IP addresses in the IP address delegation extension in the issuer's
   certificate.  Validation MUST fail when this is not the case.  A
   certificate that is a trust anchor for certification path validation   |
   of certificates containing the IP address delegation extension, as     |
   well as all certificates along the path, MUST each contain the IP      |
   address delegation extension.  The initial set of allowed address      |
   ranges is taken from the trust anchor certificate.                     |

Charlie


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FNVxeo090368 for <[e-mail]>; Mon, 15 Sep 2003 16:31:59 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FNVxBa090367 for ietf-pkix-bks; Mon, 15 Sep 2003 16:31:59 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FNVteo090360 for <[e-mail]>; Mon, 15 Sep 2003 16:31:57 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd02.aul.t-online.de  by mailout10.sul.t-online.com with smtp  id 19z2om-000151-02; Tue, 16 Sep 2003 01:31:40 +0200
Received: from hagen (S95A30ZCwel+kghkURgJA4YVsOBaf5p9eCXPUdTN3qPpTDBpg92wQc@[217.80.253.38]) by fmrl02.sul.t-online.com with esmtp id 19z2oi-0WEqVU0; Tue, 16 Sep 2003 01:31:36 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Tue, 16 Sep 2003 01:31:34 +0200
Organization: SyTrust
Message-ID: <000001c37be1$80e400f0$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C37BF2.446CD0F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <000a01c37bb0$71d7bb50$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C37BF2.446CD0F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

I agree with Ryan statement, too - but I see a difference in the way
Ambarish rephrases it:
 
A nonce in the request indicates:
Ryan: "I want a fresh response"
Ambarish: I am not willing to accept a response without a nonce
 
I think the first way adds a lot of flexibility to the protocol: The
responder detects that the client would like to have a fresh response
(who would not like that!) and can then decide to produce a new one or
to present a pre-produced response (without nonce). In the case of  the
pre-produced response the client can decide wether to accept it or not.
 
I dont see the reason to limit the functionality of the protocol by
going down the second road - without any benefit attached to it.
 
If we want the OCSP responder to know beforehand, if the client will
accept a pre-produced response or not, add a CRITICAL flag to the
extension. This way the client can indicate in the request if it is
willing to accept a response without nonce.
 
For me the inclusion of a nonce into a request indicates: "I want a
fresh response, I will check the nonce if you give me one back, if not I
will decide on my own if I will accept the response or not".
 
-- 
Florian Oelmaier
SyTrust
 

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Monday, September 15, 2003 7:40 PM
To: 'Ryan M. Hurst'; 'Florian Oelmaier'; 'Peter Gutmann';
[e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?


 
Hi Ryan,
    I agree with your statement below. If a client has a nonce in the
request, it MUST NOT accept
a response without a nonce. If you are willing to accept a response
without a nonce, don't include
one in the request.
 
The main problem of not having a nonce in the request is you might be
open to a replay attack and
you should have a decently accurate clock.
 
If you know how accurate your clock is, you can bound the time during
which you are open to
a reply attack by accepting pre-produced responses that were produced
acceptably recently
(NOTE: I am not addressing the following 2 questions:
    -how you know how accurate your clock is
    - how recently you should require the response to have been produced
(depends on your policy))
If the pre-produced response is too old for your purposes, you can
always include a nonce to
force a new response.
 
 
Regards,
Ambarish

-----Original Message-----
From: Ryan M. Hurst [mailto:[e-mail]] 
Sent: Monday, September 15, 2003 8:55 AM
To: Florian Oelmaier; Peter Gutmann; [e-mail];
[e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?


Florian - I will see about getting a option to disable support for
pre-produced responses, but I beleive the correct interpretation of the
nonce on the server side is "I want a fresh response", given this
including a nonce when we don't care if we get one back removes a way
for us to communicate with servers out there so I don't think we will do
that.
 
Ryan

  _____  

From: Florian Oelmaier
Sent: Mon 9/15/2003 8:47 AM
To: Ryan M. Hurst; Peter Gutmann; [e-mail];
[e-mail]; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?


> Florian - We will be fine with your server generated nonce, but I
still 

> hold to my original statement that this does not protect your server 

> from anything, and as for your client expecting a nonce in a reply,  

> it should simply make sure the nonce in the request matches the nonce
in 

> the received reply as thats the only way to truly protect against a 

> replay attack on the client side.



An alternate proposal for you client:

1) your client always generates a nonce in its request.

2) your client accepts responses not containing a nonce at all as valid,
if the response contains a nonce, it has to be the correct one.



What will happen?



When sending a request to a responder that preproduces responses, your
client will receive a response without nonce. Your client will accept
it. Security is not worse than your original proposal. 



When sending a request to a responder that ALWAYS! uses nonces in his
responses, you WILL get a nonce back (even when it was replay attack, as
an attacker cannot obtain a response without nonce). Your client will
check it and accept it when it matches. With such a responder the nonces
protection works as designed.



When sending a request to a responder that uses nonces only when the
request contained one, you may get a correct nonce back or (in case of a
replay attack) a response without nonce. Either way you will accept it
(as your client does not know if that responder sends nonces or not).
Security is not worse than your original proposal.



With this proposal your client lets the responder decide wether it wants
to make use of nonce-security or not. So it seems to be an improvement
without any disadvantages.



-- 

Florian Oelmaier

SyTrust




------=_NextPart_000_0001_01C37BF2.446CD0F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Nachricht</TITLE>

<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial size=3D2>I =
agree with Ryan=20
statement, too - but I see a difference in the way Ambarish rephrases=20
it:</FONT></SPAN></DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial size=3D2>A =
nonce in the=20
request indicates:</FONT></SPAN></DIV>
<DIV><SPAN class=3D189201723-15092003><FONT size=3D2><FONT =
face=3DArial>Ryan: "I want=20
a fresh response"</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial =
size=3D2>Ambarish: I am not=20
willing to accept a response without a nonce</FONT></SPAN></DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial size=3D2>I =
think the first=20
way adds a lot of flexibility to the protocol: The=20
responder&nbsp;detects&nbsp;that the client would like to have a fresh =
response=20
(who would not like that!) and can then decide to produce a new one or =
to=20
present a pre-produced response (without nonce). In the case of =
&nbsp;the=20
pre-produced response the client can decide wether to accept it or=20
not.</FONT></SPAN></DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial size=3D2>I dont =
see the=20
reason to limit the functionality of the protocol by going down the =
second=20
road&nbsp;- without any benefit attached to it.</FONT></SPAN></DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial size=3D2>If we =
want the OCSP=20
responder to know beforehand, if the client will accept a pre-produced =
response=20
or not, add a CRITICAL flag to the extension. This way the client can=20
indicate&nbsp;in the request&nbsp;if it is willing to accept a response =
without=20
nonce.</FONT></SPAN></DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial size=3D2>For me =
the inclusion=20
of a nonce into a request indicates: "I want a fresh response, I will =
check the=20
nonce if you give me one back, if not I will decide on my own if I will =
accept=20
the response or not".</FONT></SPAN></DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial size=3D2>--=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial =
size=3D2>Florian=20
Oelmaier</FONT></SPAN></DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial=20
size=3D2>SyTrust</FONT></SPAN></DIV>
<DIV><SPAN class=3D189201723-15092003><FONT face=3DArial=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></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr =
align=3Dleft><FONT face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ambarish Malpani=20
  [mailto:[e-mail]] <BR><B>Sent:</B> Monday, September 15, =
2003 7:40=20
  PM<BR><B>To:</B> 'Ryan M. Hurst'; 'Florian Oelmaier'; 'Peter Gutmann'; =

  [e-mail]; [e-mail]<BR><B>Subject:</B> RE: [OCSP] are =
several=20
  requests for different CAs at once valid ?<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
  Ryan,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp; I agree with your statement below. If a =
client has a=20
  nonce in the request, it MUST NOT accept</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff size=3D2>a=20
  response without a nonce. If you are willing to accept a response =
without a=20
  nonce, don't include</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff size=3D2>one=20
  in the request.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff size=3D2>The=20
  main problem of not having a nonce in the request is you might be open =
to a=20
  replay attack and</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff size=3D2>you=20
  should have a decently accurate clock.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff size=3D2>If=20
  you know how accurate your clock is, you can bound the time during =
which you=20
  are open to</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff size=3D2>a=20
  reply attack by accepting pre-produced responses that were produced =
acceptably=20
  recently</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>(NOTE: I am not addressing the following 2=20
  questions:</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp; -how you know how accurate your clock=20
  is</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp; - how recently you should require the =
response to=20
  have been produced (depends on your policy))</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff size=3D2>If=20
  the pre-produced response is too old for your purposes, you can always =
include=20
  a nonce to</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>force a new response.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Regards,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D380143417-15092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Ambarish</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
    face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> =
Ryan M. Hurst=20
    [mailto:[e-mail]] <BR><B>Sent:</B> Monday, =
September 15,=20
    2003 8:55 AM<BR><B>To:</B> Florian Oelmaier; Peter Gutmann;=20
    [e-mail]; [e-mail]; =
[e-mail]<BR><B>Subject:</B> RE:=20
    [OCSP] are several requests for different CAs at once valid=20
    ?<BR><BR></FONT></DIV>
    <DIV id=3DidOWAReplyText33286 dir=3Dltr>
    <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Florian - =
I will see=20
    about getting a option to disable support for pre-produced =
responses, but I=20
    beleive the correct interpretation of the nonce on the server side =
is "I=20
    want a fresh response", given this including a nonce when we don't =
care if=20
    we get one back removes a way for us to communicate with servers out =
there=20
    so I don't think we will do that.</FONT></DIV>
    <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
    <DIV dir=3Dltr><BR>
    <HR tabIndex=3D-1>
    <FONT face=3DTahoma size=3D2><B>From:</B> Florian =
Oelmaier<BR><B>Sent:</B> Mon=20
    9/15/2003 8:47 AM<BR><B>To:</B> Ryan M. Hurst; Peter Gutmann;=20
    [e-mail]; [e-mail]; [e-mail];=20
    [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests for=20
    different CAs at once valid ?<BR></FONT><BR></DIV>
    <DIV><PRE style=3D"WORD-WRAP: break-word">&gt; Florian - We will be =
fine with your server generated nonce, but I still=20
&gt; hold to my original statement that this does not protect your =
server=20
&gt; from anything, and as for your client expecting a nonce in a reply, =
=20
&gt; it should simply make sure the nonce in the request matches the =
nonce in=20
&gt; the received reply as thats the only way to truly protect against a =

&gt; replay attack on the client side.

An alternate proposal for you client:
1) your client always generates a nonce in its request.
2) your client accepts responses not containing a nonce at all as valid, =
if the response contains a nonce, it has to be the correct one.

What will happen?

When sending a request to a responder that preproduces responses, your =
client will receive a response without nonce. Your client will accept =
it. Security is not worse than your original proposal.=20

When sending a request to a responder that ALWAYS! uses nonces in his =
responses, you WILL get a nonce back (even when it was replay attack, as =
an attacker cannot obtain a response without nonce). Your client will =
check it and accept it when it matches. With such a responder the nonces =
protection works as designed.

When sending a request to a responder that uses nonces only when the =
request contained one, you may get a correct nonce back or (in case of a =
replay attack) a response without nonce. Either way you will accept it =
(as your client does not know if that responder sends nonces or not). =
Security is not worse than your original proposal.

With this proposal your client lets the responder decide wether it wants =
to make use of nonce-security or not. So it seems to be an improvement =
without any disadvantages.

--=20
Florian Oelmaier
SyTrust

</PRE></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0001_01C37BF2.446CD0F0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FMKXeo087544 for <[e-mail]>; Mon, 15 Sep 2003 15:20:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FMKXBu087543 for ietf-pkix-bks; Mon, 15 Sep 2003 15:20:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FMKVeo087538 for <[e-mail]>; Mon, 15 Sep 2003 15:20:31 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h8FMKE0w011159; Mon, 15 Sep 2003 18:20:14 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521060fbb8be84d0fdb@[128.89.89.75]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Mon, 15 Sep 2003 18:19:46 -0400
To: "Deacon, Alex" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Cc: "'Ryan M. Hurst'" <[e-mail]>, Peter Gutmann	 <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: multipart/alternative; boundary="============_-1148458086==_ma============"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--============_-1148458086==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 14:37 -0700 9/15/03, Deacon, Alex wrote:
>
>I have to agree with Ryan on this one.  Online does not necessarily 
>mean real time.  For example, there are many OCSP responders on the 
>market that get the revocation information from CRL's.  These 
>responders are online, but not real-time.
>
>Anyway, the bottom line is this:  In order to provide OCSP services 
>for very large scale internet pki's (e.g. SSL and code signing CA's) 
>in a *cost effective* way, OCSP responses must be pregenerated, 
>distributed and finally cached through out the network (on clients, 
>proxy's, server's, etc).  
>
>Alex
>

There are two separable issues here.

The first is the source of the revocation status info. OCSP does not 
guarantee that the source of this data is other than CRL-based, as 
noted above. The RFC makes clear that pre-production of responses is 
a legitimate mode of operation.

The second issue is whether the response from the OCSP server is 
current.  Use of nonces in a request-response format is an easy way 
to ensure liveness, but the nonce is an extension, not a part of the 
base protocol. So, obviously, one ought not rely on the presence of a 
nonce in the request or response.

So long as the response contains the producedAt value or the 
thisUpdate value, a client can determine how "current" the response 
is. The RFC requires that thisUpdate appear in pre-generated 
responses, and the producedAt value is a mandatory part of the 
BasicOSCPResponseresponse.

Steve

--============_-1148458086==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>RE: [OCSP] are several requests for different CAs
at o</title></head><body>
<div>At 14:37 -0700 9/15/03, Deacon, Alex wrote:</div>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Courier New" size="-1">I have
to agree with Ryan on this one.&nbsp; Online does not necessarily mean
real time.&nbsp; For example, there are many OCSP responders on the
market that get the revocation information from CRL's.&nbsp; These
responders are online, but not real-time.</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">Anyway, the bottom line is this: &nbsp;In order to provide
OCSP services for very large scale internet pki's (e.g. SSL and code
signing CA's) in a *cost effective* way, OCSP responses must be
pregenerated, distributed and finally cached through out the network
(on clients, proxy's, server's, etc).&nbsp;&nbsp;</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<blockquote type="cite" cite><font face="Courier New"
size="-1">Alex</font></blockquote>
<blockquote type="cite" cite>&nbsp;</blockquote>
<div><br></div>
<div>There are two separable issues here.</div>
<div><br></div>
<div>The first is the source of the revocation status info. OCSP does
not guarantee that the source of this data is other than CRL-based, as
noted above. The RFC makes clear that pre-production of responses is a
legitimate mode of operation.</div>
<div><br></div>
<div>The second issue is whether the response from the OCSP server is
current.&nbsp; Use of nonces in a request-response format is an easy
way to ensure liveness, but the nonce is an extension, not a part of
the base protocol. So, obviously, one ought not rely on the presence
of a nonce in the request or response.</div>
<div><br></div>
<div>So long as the response contains the producedAt value or the
thisUpdate value, a client can determine how &quot;current&quot; the
response is. The RFC requires that thisUpdate appear in pre-generated
responses, and the producedAt value is a mandatory part of the
BasicOSCPResponseresponse.</div>
<div><br></div>
<div>Steve</div>
<div><br></div>
</body>
</html>
--============_-1148458086==_ma============--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FLxgeo086706 for <[e-mail]>; Mon, 15 Sep 2003 14:59:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FLxgr7086705 for ietf-pkix-bks; Mon, 15 Sep 2003 14:59:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FLxeeo086698 for <[e-mail]>; Mon, 15 Sep 2003 14:59:41 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h8FLxb1h014326; Tue, 16 Sep 2003 09:59:37 +1200
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h8FM1uB22576; Tue, 16 Sep 2003 10:01:56 +1200
Date: Tue, 16 Sep 2003 10:01:56 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Ryan M. Hurst" <[e-mail]> writes:

>More sillyness, The response has a thisUpdate, nextUpdate and ProducedAt;
>these values are adequare for communicating the freshness necessary to
>comminicate publication policy to the user.

That assumes perfectly synchronised clocks, which has been known for at least
20 years to be a weak point in security protocols, because now you're
including something that most users don't regard as security-relevant in your
TCB.  I've seen machines with clocks that were out by decades, and the users
didn't notice (see my paper at Usenix Security '02 on common security
pitfalls).  PCs with clocks that are out by hours or tens of minutes are
extremely common... hmm, to save me re-typing a pile of stuff, see the design
details for RTCS for more on this.  In fact some of the issues raised during
this debate have been almost a checklist of the design requirements for RTCS
(and yes, I do agree with the people who have pointed out that the only way to
get OCSP to scale in any useful way is to pre-generate responses, and by
extension allow for replay attacks :-).

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FLbCeo085898 for <[e-mail]>; Mon, 15 Sep 2003 14:37:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FLbCWT085897 for ietf-pkix-bks; Mon, 15 Sep 2003 14:37:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FLbAeo085891 for <[e-mail]>; Mon, 15 Sep 2003 14:37:10 -0700 (PDT) (envelope-from [e-mail])
Received: from MOU1WNEXC03.vcorp.ad.vrsn.com (verisign.com [65.205.251.57]) by peacock.verisign.com (8.12.9/) with ESMTP id h8FLb5fd016436; Mon, 15 Sep 2003 14:37:05 -0700 (PDT)
Received: by mou1wnexc03.verisign.com with Internet Mail Service (5.5.2653.19) id <SJRJV3HD>; Mon, 15 Sep 2003 14:37:05 -0700
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>, Peter Gutmann <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 14:37:05 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C37BD1.81F404A0"
Sender: [e-mail]
Precedence: 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_01C37BD1.81F404A0
Content-Type: text/plain;
	charset="iso-8859-1"

 
I have to agree with Ryan on this one.  Online does not necessarily mean
real time.  For example, there are many OCSP responders on the market that
get the revocation information from CRL's.  These responders are online, but
not real-time.
 
Anyway, the bottom line is this:  In order to provide OCSP services for very
large scale internet pki's (e.g. SSL and code signing CA's) in a *cost
effective* way, OCSP responses must be pregenerated, distributed and finally
cached through out the network (on clients, proxy's, server's, etc).  
 
Alex
 

-----Original Message-----
From: Ryan M. Hurst [mailto:[e-mail]]
Sent: Monday, September 15, 2003 8:49 AM
To: Peter Gutmann; [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?


In-line


  _____  

From: Peter Gutmann
Sent: Mon 9/15/2003 8:29 AM
To: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?


"Ryan M. Hurst" <[e-mail]> writes:



>Now your just being silly Peter, using pre-produced OCSP responses is no

>worse that using CRLs and it is a cocept explicitly supported by the RFC
for

>the very reasons we implemented it that way.



I agree that technically it's no worse than a CRL.  However, the "O" in
"OCSP"

stands for "Online", not "Offline", which is what the nonceless responder

design is doing to it.  The fact that the name of the protocol is "Online

Certificate Status Protocol" will no doubt lead some poor misguided users to

believe that they're actually getting some sort of live, online check, not

just a query of last week's CRL data.

[rmh] I actualy think its better than CRLs, with the use of OCSP it become
possible to do revocation checking by default on 56k connections for things
like SSL, its also possible to make more frequent updates, etc. As for your
definition your quibling on symmantics, The Online in OCSP does not
necessarily mean the response was dynamically generated, afterall its a
protocol that will only work when its online. Also the fact that responses
are pre-produced does not mean they were issued off of stale data, it simply
means that caching of responses is possible. 
Maybe the RFC title needs to be changed.  Or there could be two variants,
the

"Offline CRL Query Protocol" (OCQP) and OCSP.  The problem at the moment is

that users have no idea what they're getting, presumably all are expecting

OCSP while many are only getting OCQP.  This is at best misleading, and at

worst deceptive if someone's truly relying on it for real, live cert status

info.

[rmh] More sillyness, The response has a thisUpdate, nextUpdate and
ProducedAt; these values are adequare for communicating the freshness
necessary to comminicate publication policy to the user.
Peter.


------_=_NextPart_001_01C37BD1.81F404A0
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>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">


<META content=3D"MSHTML 6.00.2800.1141" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D941482921-15092003><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D941482921-15092003><FONT face=3D"Courier New" =
size=3D2>I have to=20
agree with Ryan on this one.&nbsp; Online does not necessarily mean =
real=20
time.&nbsp; For example, there are many OCSP responders on the market =
that get=20
the revocation information from CRL's.&nbsp; These responders are =
online, but=20
not real-time.</FONT></SPAN></DIV>
<DIV><SPAN class=3D941482921-15092003><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D941482921-15092003><FONT face=3D"Courier New" =
size=3D2>Anyway, the=20
bottom line is this: &nbsp;In order to provide OCSP services for very =
large=20
scale internet pki's (e.g. SSL and code signing CA's) in a *cost =
effective* way,=20
OCSP responses must be pregenerated, distributed and finally cached =
through out=20
the network (on clients, proxy's, server's,=20
etc).&nbsp;&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=3D941482921-15092003><FONT face=3D"Courier New"=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D941482921-15092003><FONT face=3D"Courier New"=20
size=3D2>Alex</FONT></SPAN></DIV>
<DIV><SPAN class=3D941482921-15092003></SPAN><SPAN=20
class=3D941482921-15092003></SPAN><SPAN =
class=3D941482921-15092003><FONT=20
face=3D"Courier New" size=3D2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ryan M. Hurst=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Monday, September =
15, 2003=20
  8:49 AM<BR><B>To:</B> Peter Gutmann; [e-mail]; =
[e-mail];=20
  [e-mail]; [e-mail]<BR><B>Subject:</B> RE: [OCSP] are =
several=20
  requests for different CAs at once valid ?<BR><BR></FONT></DIV>
  <DIV id=3DidOWAReplyText63047 dir=3Dltr>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>In-line</FONT></DIV></DIV>
  <DIV dir=3Dltr><PRE style=3D"WORD-WRAP: break-word"></PRE><BR>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Peter =
Gutmann<BR><B>Sent:</B> Mon=20
  9/15/2003 8:29 AM<BR><B>To:</B> [e-mail]; =
[e-mail];=20
  [e-mail]; [e-mail]; =
[e-mail];=20
  [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests for =
different=20
  CAs at once valid ?<BR></FONT><BR></DIV>
  <DIV><PRE style=3D"WORD-WRAP: break-word">"Ryan M. Hurst" =
&lt;[e-mail]&gt; writes:

&gt;Now your just being silly Peter, using pre-produced OCSP responses =
is no
&gt;worse that using CRLs and it is a cocept explicitly supported by =
the RFC for
&gt;the very reasons we implemented it that way.

I agree that technically it's no worse than a CRL.  However, the "O" in =
"OCSP"
stands for "Online", not "Offline", which is what the nonceless =
responder
design is doing to it.  The fact that the name of the protocol is =
"Online
Certificate Status Protocol" will no doubt lead some poor misguided =
users to
believe that they're actually getting some sort of live, online check, =
not
just a query of last week's CRL data.
[rmh] I actualy think its better than CRLs, with the use of OCSP it =
become possible to do revocation checking by default on 56k connections =
for things like SSL, its also possible to make more frequent updates, =
etc. As for your definition your quibling on symmantics, The Online in =
OCSP does not necessarily mean the response was dynamically generated, =
afterall its a protocol that will only work when its online. Also the =
fact that responses are pre-produced does not mean they were issued off =
of stale data, it simply means that caching of responses is possible. =
</PRE><PRE style=3D"WORD-WRAP: break-word">Maybe the RFC title needs to =
be changed.  Or there could be two variants, the
"Offline CRL Query Protocol" (OCQP) and OCSP.  The problem at the =
moment is
that users have no idea what they're getting, presumably all are =
expecting
OCSP while many are only getting OCQP.  This is at best misleading, and =
at
worst deceptive if someone's truly relying on it for real, live cert =
status
info.
[rmh] More sillyness, The response has a thisUpdate, nextUpdate and =
ProducedAt; these values are adequare for communicating the freshness =
necessary to comminicate publication policy to the user.</PRE><PRE =
style=3D"WORD-WRAP: break-word">Peter.
</PRE></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C37BD1.81F404A0--


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FHeZeo073216 for <[e-mail]>; Mon, 15 Sep 2003 10:40:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FHeZoY073215 for ietf-pkix-bks; Mon, 15 Sep 2003 10:40:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FHeYeo073210 for <[e-mail]>; Mon, 15 Sep 2003 10:40:34 -0700 (PDT) (envelope-from [e-mail])
Received: from AMBARISHW2K (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id h8FHeHPo016280; Mon, 15 Sep 2003 10:40:22 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>, "'Florian Oelmaier'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 10:40:18 -0700
Message-ID: <000a01c37bb0$71d7bb50$[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000B_01C37B75.C57A69F0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <14615E97-F1AF-4FE6-BF55-553823CED1BE@mimectl>
Importance: Normal
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_000B_01C37B75.C57A69F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

=20
Hi Ryan,
    I agree with your statement below. If a client has a nonce in the
request, it MUST NOT accept
a response without a nonce. If you are willing to accept a response =
without
a nonce, don't include
one in the request.
=20
The main problem of not having a nonce in the request is you might be =
open
to a replay attack and
you should have a decently accurate clock.
=20
If you know how accurate your clock is, you can bound the time during =
which
you are open to
a reply attack by accepting pre-produced responses that were produced
acceptably recently
(NOTE: I am not addressing the following 2 questions:
    -how you know how accurate your clock is
    - how recently you should require the response to have been produced
(depends on your policy))
If the pre-produced response is too old for your purposes, you can =
always
include a nonce to
force a new response.
=20
=20
Regards,
Ambarish

-----Original Message-----
From: Ryan M. Hurst [mailto:[e-mail]]=20
Sent: Monday, September 15, 2003 8:55 AM
To: Florian Oelmaier; Peter Gutmann; [e-mail];
[e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid =
?


Florian - I will see about getting a option to disable support for
pre-produced responses, but I beleive the correct interpretation of the
nonce on the server side is "I want a fresh response", given this =
including
a nonce when we don't care if we get one back removes a way for us to
communicate with servers out there so I don't think we will do that.
=20
Ryan

  _____ =20

From: Florian Oelmaier
Sent: Mon 9/15/2003 8:47 AM
To: Ryan M. Hurst; Peter Gutmann; [e-mail]; =
[e-mail];
[e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid =
?


> Florian - We will be fine with your server generated nonce, but I =
still=20

> hold to my original statement that this does not protect your server=20

> from anything, and as for your client expecting a nonce in a reply, =20

> it should simply make sure the nonce in the request matches the nonce =
in=20

> the received reply as thats the only way to truly protect against a=20

> replay attack on the client side.



An alternate proposal for you client:

1) your client always generates a nonce in its request.

2) your client accepts responses not containing a nonce at all as valid, =
if
the response contains a nonce, it has to be the correct one.



What will happen?



When sending a request to a responder that preproduces responses, your
client will receive a response without nonce. Your client will accept =
it.
Security is not worse than your original proposal.=20



When sending a request to a responder that ALWAYS! uses nonces in his
responses, you WILL get a nonce back (even when it was replay attack, as =
an
attacker cannot obtain a response without nonce). Your client will check =
it
and accept it when it matches. With such a responder the nonces =
protection
works as designed.



When sending a request to a responder that uses nonces only when the =
request
contained one, you may get a correct nonce back or (in case of a replay
attack) a response without nonce. Either way you will accept it (as your
client does not know if that responder sends nonces or not). Security is =
not
worse than your original proposal.



With this proposal your client lets the responder decide wether it wants =
to
make use of nonce-security or not. So it seems to be an improvement =
without
any disadvantages.



--=20

Florian Oelmaier

SyTrust




------=_NextPart_000_000B_01C37B75.C57A69F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Message</TITLE>

<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Ryan,</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;&nbsp;&nbsp; I agree with your statement below. If a =
client has a=20
nonce in the request, it MUST NOT accept</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>a=20
response without a nonce. If you are willing to accept a response =
without a=20
nonce, don't include</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>one in=20
the request.</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>The=20
main problem of not having a nonce in the request is you might be open =
to a=20
replay attack and</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>you=20
should have a decently accurate clock.</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>If you=20
know how accurate your clock is, you can bound the time during which you =
are=20
open to</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>a=20
reply attack by accepting pre-produced responses that were produced =
acceptably=20
recently</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>(NOTE:=20
I am not addressing the following 2 questions:</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;&nbsp;&nbsp; -how you know how accurate your clock=20
is</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;&nbsp;&nbsp; - how recently you should require the =
response to have=20
been produced (depends on your policy))</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>If the=20
pre-produced response is too old for your purposes, you can always =
include a=20
nonce to</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>force=20
a new response.</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D380143417-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2>Ambarish</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr =
align=3Dleft><FONT=20
  face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B> Ryan =
M. Hurst=20
  [mailto:[e-mail]] <BR><B>Sent:</B> Monday, September =
15, 2003=20
  8:55 AM<BR><B>To:</B> Florian Oelmaier; Peter Gutmann; =
[e-mail];=20
  [e-mail]; [e-mail]<BR><B>Subject:</B> RE: [OCSP] are =
several=20
  requests for different CAs at once valid ?<BR><BR></FONT></DIV>
  <DIV id=3DidOWAReplyText33286 dir=3Dltr>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Florian - I =
will see about=20
  getting a option to disable support for pre-produced responses, but I =
beleive=20
  the correct interpretation of the nonce on the server side is "I want =
a fresh=20
  response", given this including a nonce when we don't care if we get =
one back=20
  removes a way for us to communicate with servers out there so I don't =
think we=20
  will do that.</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
  <DIV dir=3Dltr><BR>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> Florian =
Oelmaier<BR><B>Sent:</B> Mon=20
  9/15/2003 8:47 AM<BR><B>To:</B> Ryan M. Hurst; Peter Gutmann;=20
  [e-mail]; [e-mail]; [e-mail];=20
  [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests for =
different=20
  CAs at once valid ?<BR></FONT><BR></DIV>
  <DIV><PRE style=3D"WORD-WRAP: break-word">&gt; Florian - We will be =
fine with your server generated nonce, but I still=20
&gt; hold to my original statement that this does not protect your =
server=20
&gt; from anything, and as for your client expecting a nonce in a reply, =
=20
&gt; it should simply make sure the nonce in the request matches the =
nonce in=20
&gt; the received reply as thats the only way to truly protect against a =

&gt; replay attack on the client side.

An alternate proposal for you client:
1) your client always generates a nonce in its request.
2) your client accepts responses not containing a nonce at all as valid, =
if the response contains a nonce, it has to be the correct one.

What will happen?

When sending a request to a responder that preproduces responses, your =
client will receive a response without nonce. Your client will accept =
it. Security is not worse than your original proposal.=20

When sending a request to a responder that ALWAYS! uses nonces in his =
responses, you WILL get a nonce back (even when it was replay attack, as =
an attacker cannot obtain a response without nonce). Your client will =
check it and accept it when it matches. With such a responder the nonces =
protection works as designed.

When sending a request to a responder that uses nonces only when the =
request contained one, you may get a correct nonce back or (in case of a =
replay attack) a response without nonce. Either way you will accept it =
(as your client does not know if that responder sends nonces or not). =
Security is not worse than your original proposal.

With this proposal your client lets the responder decide wether it wants =
to make use of nonce-security or not. So it seems to be an improvement =
without any disadvantages.

--=20
Florian Oelmaier
SyTrust

</PRE></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000B_01C37B75.C57A69F0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FFsbeo064772 for <[e-mail]>; Mon, 15 Sep 2003 08:54:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FFsbVc064771 for ietf-pkix-bks; Mon, 15 Sep 2003 08:54:37 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FFsYeo064739 for <[e-mail]>; Mon, 15 Sep 2003 08:54:36 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Sep 2003 08:54:44 -0700
Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Sep 2003 08:54:30 -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(6.0.3790.0); Mon, 15 Sep 2003 08:54:37 -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(6.0.3790.0); Mon, 15 Sep 2003 08:54:41 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Mon, 15 Sep 2003 08:54:28 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.6944
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <>, <[e-mail]>
To: Florian Oelmaier <[e-mail]>, Peter Gutmann <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN7oaewvZ/DKlomQ+uAX2T6tNq0EA==
Message-ID: <14615E97-F1AF-4FE6-BF55-553823CED1BE@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
Date: Mon, 15 Sep 2003 08:54:33 -0700
X-OriginalArrivalTime: 15 Sep 2003 15:54:28.0835 (UTC) FILETIME=[A537BB30:01C37BA1]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_45624FE8-9BE7-4B76-BA3D-C80988DA609B_"

--_45624FE8-9BE7-4B76-BA3D-C80988DA609B_
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Florian - I will see about getting a option to disable support for pre-prod=
uced responses, but I beleive the correct interpretation of the nonce on th=
e server side is "I want a fresh response", given this including a nonce wh=
en we don't care if we get one back removes a way for us to communicate wit=
h servers out there so I don't think we will do that.

Ryan



From: Florian Oelmaier
Sent: Mon 9/15/2003 8:47 AM
To: Ryan M. Hurst; Peter Gutmann; [e-mail]; [e-mail]; =
[e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?


> Florian - We will be fine with your server generated nonce, but I still=20
> hold to my original statement that this does not protect your server=20
> from anything, and as for your client expecting a nonce in a reply, =20
> it should simply make sure the nonce in the request matches the nonce in=
=20
> the received reply as thats the only way to truly protect against a=20
> replay attack on the client side.

An alternate proposal for you client:
1) your client always generates a nonce in its request.
2) your client accepts responses not containing a nonce at all as valid, if=
 the response contains a nonce, it has to be the correct one.

What will happen?

When sending a request to a responder that preproduces responses, your clie=
nt will receive a response without nonce. Your client will accept it. Secur=
ity is not worse than your original proposal.=20

When sending a request to a responder that ALWAYS! uses nonces in his respo=
nses, you WILL get a nonce back (even when it was replay attack, as an atta=
cker cannot obtain a response without nonce). Your client will check it and=
 accept it when it matches. With such a responder the nonces protection wor=
ks as designed.

When sending a request to a responder that uses nonces only when the reques=
t contained one, you may get a correct nonce back or (in case of a replay a=
ttack) a response without nonce. Either way you will accept it (as your cli=
ent does not know if that responder sends nonces or not). Security is not w=
orse than your original proposal.

With this proposal your client lets the responder decide wether it wants to=
 make use of nonce-security or not. So it seems to be an improvement withou=
t any disadvantages.

--=20
Florian Oelmaier
SyTrust

--_45624FE8-9BE7-4B76-BA3D-C80988DA609B_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText33286 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Florian - I will=
 see about getting a option to disable support for pre-produced responses, =
but I beleive the correct interpretation of the nonce on the server side is=
 "I want a fresh response", given this including a nonce when we don't care=
 if we get one back removes a way for us to communicate with servers out th=
ere so I don't think we will do that.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Florian Oelmaier<BR><B>Sent:</B> =
Mon 9/15/2003 8:47 AM<BR><B>To:</B> Ryan M. Hurst; Peter Gutmann; ambarish@=
malpani.biz; [e-mail]; [e-mail]; [e-mail]<BR><B>Su=
bject:</B> RE: [OCSP] are several requests for different CAs at once valid =
?<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">&gt; Florian - We will be fine wi=
th your server generated nonce, but I still=20
&gt; hold to my original statement that this does not protect your server=20
&gt; from anything, and as for your client expecting a nonce in a reply, =20
&gt; it should simply make sure the nonce in the request matches the nonce =
in=20
&gt; the received reply as thats the only way to truly protect against a=20
&gt; replay attack on the client side.

An alternate proposal for you client:
1) your client always generates a nonce in its request.
2) your client accepts responses not containing a nonce at all as valid, if=
 the response contains a nonce, it has to be the correct one.

What will happen?

When sending a request to a responder that preproduces responses, your clie=
nt will receive a response without nonce. Your client will accept it. Secur=
ity is not worse than your original proposal.=20

When sending a request to a responder that ALWAYS! uses nonces in his respo=
nses, you WILL get a nonce back (even when it was replay attack, as an atta=
cker cannot obtain a response without nonce). Your client will check it and=
 accept it when it matches. With such a responder the nonces protection wor=
ks as designed.

When sending a request to a responder that uses nonces only when the reques=
t contained one, you may get a correct nonce back or (in case of a replay a=
ttack) a response without nonce. Either way you will accept it (as your cli=
ent does not know if that responder sends nonces or not). Security is not w=
orse than your original proposal.

With this proposal your client lets the responder decide wether it wants to=
 make use of nonce-security or not. So it seems to be an improvement withou=
t any disadvantages.

--=20
Florian Oelmaier
SyTrust

</PRE></DIV></BODY></HTML>

--_45624FE8-9BE7-4B76-BA3D-C80988DA609B_--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FFnOeo063861 for <[e-mail]>; Mon, 15 Sep 2003 08:49:24 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FFnOEm063860 for ietf-pkix-bks; Mon, 15 Sep 2003 08:49:24 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FFnMeo063843 for <[e-mail]>; Mon, 15 Sep 2003 08:49:22 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Sep 2003 08:49:07 -0700
Received: from 157.54.6.197 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Sep 2003 08:49:18 -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(6.0.3790.1060); Mon, 15 Sep 2003 08:49:13 -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(6.0.3790.0); Mon, 15 Sep 2003 08:49:06 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Mon, 15 Sep 2003 08:49:17 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.6944
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: Peter Gutmann <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN7oO4TH7PbjpooRuKIOx3VHgRVRQ==
Message-ID: <90C3EB39-1319-4967-A8A5-65EECC5CC70D@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
Date: Mon, 15 Sep 2003 08:49:21 -0700
X-OriginalArrivalTime: 15 Sep 2003 15:49:17.0239 (UTC) FILETIME=[EB7DF470:01C37BA0]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_869CB0DB-6DEE-425C-A278-084F2A4A83E3_"

--_869CB0DB-6DEE-425C-A278-084F2A4A83E3_
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In-line




From: Peter Gutmann
Sent: Mon 9/15/2003 8:29 AM
To: [e-mail]; [e-mail]; [e-mail]; pgut001@=
cs.auckland.ac.nz; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?


"Ryan M. Hurst" <[e-mail]> writes:

>Now your just being silly Peter, using pre-produced OCSP responses is no
>worse that using CRLs and it is a cocept explicitly supported by the RFC f=
or
>the very reasons we implemented it that way.

I agree that technically it's no worse than a CRL.  However, the "O" in "OC=
SP"
stands for "Online", not "Offline", which is what the nonceless responder
design is doing to it.  The fact that the name of the protocol is "Online
Certificate Status Protocol" will no doubt lead some poor misguided users t=
o
believe that they're actually getting some sort of live, online check, not
just a query of last week's CRL data.
[rmh] I actualy think its better than CRLs, with the use of OCSP it become =
possible to do revocation checking by default on 56k connections for things=
 like SSL, its also possible to make more frequent updates, etc. As for you=
r definition your quibling on symmantics, The Online in OCSP does not neces=
sarily mean the response was dynamically generated, afterall its a protocol=
 that will only work when its online. Also the fact that responses are pre-=
produced does not mean they were issued off of stale data, it simply means =
that caching of responses is possible.=20
Maybe the RFC title needs to be changed.  Or there could be two variants, t=
he
"Offline CRL Query Protocol" (OCQP) and OCSP.  The problem at the moment is
that users have no idea what they're getting, presumably all are expecting
OCSP while many are only getting OCQP.  This is at best misleading, and at
worst deceptive if someone's truly relying on it for real, live cert status
info.
[rmh] More sillyness, The response has a thisUpdate, nextUpdate and Produce=
dAt; these values are adequare for communicating the freshness necessary to=
 comminicate publication policy to the user.
Peter.

--_869CB0DB-6DEE-425C-A278-084F2A4A83E3_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText63047 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>In-line</FONT></=
DIV></DIV>
<DIV dir=3Dltr><PRE style=3D"WORD-WRAP: break-word"></PRE><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Peter Gutmann<BR><B>Sent:</B> Mon=
 9/15/2003 8:29 AM<BR><B>To:</B> [e-mail]; [e-mail]; o=
[e-mail]; [e-mail]; [e-mail]; =
[e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests for differe=
nt CAs at once valid ?<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">"Ryan M. Hurst" &lt;rmh@windows.m=
icrosoft.com&gt; writes:

&gt;Now your just being silly Peter, using pre-produced OCSP responses is n=
o
&gt;worse that using CRLs and it is a cocept explicitly supported by the RF=
C for
&gt;the very reasons we implemented it that way.

I agree that technically it's no worse than a CRL.  However, the "O" in "OC=
SP"
stands for "Online", not "Offline", which is what the nonceless responder
design is doing to it.  The fact that the name of the protocol is "Online
Certificate Status Protocol" will no doubt lead some poor misguided users t=
o
believe that they're actually getting some sort of live, online check, not
just a query of last week's CRL data.
[rmh] I actualy think its better than CRLs, with the use of OCSP it become =
possible to do revocation checking by default on 56k connections for things=
 like SSL, its also possible to make more frequent updates, etc. As for you=
r definition your quibling on symmantics, The Online in OCSP does not neces=
sarily mean the response was dynamically generated, afterall its a protocol=
 that will only work when its online. Also the fact that responses are pre-=
produced does not mean they were issued off of stale data, it simply means =
that caching of responses is possible. </PRE><PRE style=3D"WORD-WRAP: break=
-word">Maybe the RFC title needs to be changed.  Or there could be two vari=
ants, the
"Offline CRL Query Protocol" (OCQP) and OCSP.  The problem at the moment is
that users have no idea what they're getting, presumably all are expecting
OCSP while many are only getting OCQP.  This is at best misleading, and at
worst deceptive if someone's truly relying on it for real, live cert status
info.
[rmh] More sillyness, The response has a thisUpdate, nextUpdate and Produce=
dAt; these values are adequare for communicating the freshness necessary to=
 comminicate publication policy to the user.</PRE><PRE style=3D"WORD-WRAP: =
break-word">Peter.
</PRE></DIV></BODY></HTML>

--_869CB0DB-6DEE-425C-A278-084F2A4A83E3_--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FFlteo063372 for <[e-mail]>; Mon, 15 Sep 2003 08:47:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FFltnN063371 for ietf-pkix-bks; Mon, 15 Sep 2003 08:47:55 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8FFlpeo063348 for <[e-mail]>; Mon, 15 Sep 2003 08:47:51 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 21569 invoked by uid 1649); 15 Sep 2003 15:47:52 -0000
Date: 15 Sep 2003 15:47:52 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: "Ryan M. Hurst" <[e-mail]>, Peter Gutmann <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
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>

> Florian - We will be fine with your server generated nonce, but I still 
> hold to my original statement that this does not protect your server 
> from anything, and as for your client expecting a nonce in a reply,  
> it should simply make sure the nonce in the request matches the nonce in 
> the received reply as thats the only way to truly protect against a 
> replay attack on the client side.

An alternate proposal for you client:
1) your client always generates a nonce in its request.
2) your client accepts responses not containing a nonce at all as valid, if the response contains a nonce, it has to be the correct one.

What will happen?

When sending a request to a responder that preproduces responses, your client will receive a response without nonce. Your client will accept it. Security is not worse than your original proposal. 

When sending a request to a responder that ALWAYS! uses nonces in his responses, you WILL get a nonce back (even when it was replay attack, as an attacker cannot obtain a response without nonce). Your client will check it and accept it when it matches. With such a responder the nonces protection works as designed.

When sending a request to a responder that uses nonces only when the request contained one, you may get a correct nonce back or (in case of a replay attack) a response without nonce. Either way you will accept it (as your client does not know if that responder sends nonces or not). Security is not worse than your original proposal.

With this proposal your client lets the responder decide wether it wants to make use of nonce-security or not. So it seems to be an improvement without any disadvantages.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FFRXeo061839 for <[e-mail]>; Mon, 15 Sep 2003 08:27:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FFRXfo061838 for ietf-pkix-bks; Mon, 15 Sep 2003 08:27:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FFRTeo061815 for <[e-mail]>; Mon, 15 Sep 2003 08:27:32 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h8FFRP1h006537; Tue, 16 Sep 2003 03:27:25 +1200
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h8FFTgT20653; Tue, 16 Sep 2003 03:29:42 +1200
Date: Tue, 16 Sep 2003 03:29:42 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Ryan M. Hurst" <[e-mail]> writes:

>Now your just being silly Peter, using pre-produced OCSP responses is no
>worse that using CRLs and it is a cocept explicitly supported by the RFC for
>the very reasons we implemented it that way.

I agree that technically it's no worse than a CRL.  However, the "O" in "OCSP"
stands for "Online", not "Offline", which is what the nonceless responder
design is doing to it.  The fact that the name of the protocol is "Online
Certificate Status Protocol" will no doubt lead some poor misguided users to
believe that they're actually getting some sort of live, online check, not
just a query of last week's CRL data.

Maybe the RFC title needs to be changed.  Or there could be two variants, the
"Offline CRL Query Protocol" (OCQP) and OCSP.  The problem at the moment is
that users have no idea what they're getting, presumably all are expecting
OCSP while many are only getting OCQP.  This is at best misleading, and at
worst deceptive if someone's truly relying on it for real, live cert status
info.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FFEpeo061094 for <[e-mail]>; Mon, 15 Sep 2003 08:14:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FFEp6V061093 for ietf-pkix-bks; Mon, 15 Sep 2003 08:14:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FFEoeo061085 for <[e-mail]>; Mon, 15 Sep 2003 08:14:50 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Sep 2003 08:14:54 -0700
Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Sep 2003 08:14:34 -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(6.0.3790.0); Mon, 15 Sep 2003 08:14:43 -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(6.0.3790.0); Mon, 15 Sep 2003 08:14:35 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Mon, 15 Sep 2003 08:14:44 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.6944
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <>, <[e-mail]>
To: Florian Oelmaier <[e-mail]>, Ambarish Malpani <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN7nBl8cO4J7HG5TPqEdVGSR3rYKQ==
Message-ID: <80F94401-56FE-4BE2-B5DF-96F7CB59652C@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
Date: Mon, 15 Sep 2003 08:14:47 -0700
X-OriginalArrivalTime: 15 Sep 2003 15:14:44.0711 (UTC) FILETIME=[182B4770:01C37B9C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_8526FF15-D029-44C3-ADC8-41B3D5EB6FA6_"

--_8526FF15-D029-44C3-ADC8-41B3D5EB6FA6_
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Since were talking changes ;) I have provided some suggested text for one o=
f the comments bellow. Also if changes are going to be made further clarifi=
cations should be made:

1. HTTP GET vs. POST: Additional text is needed to indicate that GET is mos=
t appropriate for environments where response pre-production and network in=
frastructure caching is to be used.
2. HTTP headers: Additional text is needed to indicate that the HTTP cache =
related headers should be used so that network infrastructure can deal with=
 these responses appropriately; e.g. servers that do not include a nonce an=
d do not wish their responses to be cached should add the no-cache header, =
and that implementations that accept that their responses be cached should =
set the cache expiration to be in accordance with the response expiration.
3. Responder Identification: Additional text is needed to indicate why byKe=
y is the better choice, specifically when making responses for certificates=
 issued by more than one issuing authority.
4. Nonce: Additional text is needed on when to include a nonce, in addition=
 to the bellow text its a good idea to say something along the lines of "in=
 environments that support pre-produced responses clients can include a non=
ce to indicate that they want a freshly generated response, servers should =
assume that if the client includes a nonce that a new request should be gen=
erated.

Ryan =20




From: Florian Oelmaier
Sent: Mon 9/15/2003 7:33 AM
To: Ambarish Malpani; Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann'; i=
[e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?


Hello Ambarish,

that was your change note I am referring:

- Section 4.4.1 - Clarified that a nonce in the request MUST be included in=
 the response for the response to be trusted.
[rmh] How about "Clients that require protection from re-play attacks MUST =
include a response in their request and MUST require the resulting response=
 contains the same nonce."
Additionally you added a requirement 8 to 3.2:
   8. If the request contained a nonce, the response must contain the
      same nonce (see section 4.4.1).

These changes would have instructed the clients what to do with nonceless r=
esponses where the request contains one. Right now the standard does not in=
struct the clients what to do in this case.

--=20
Florian Oelmaier
SyTrust

On Mon, 15 Sep 2003 07:25:01 -0700, "Ambarish Malpani" <[e-mail]=
z> wrote :

> This is a multi-part message in MIME format.
>=20
>=20
> Nachricht
> Hi Florian,
>     I believe the change with regards to nonces that isn't reflected in
> current
> version is that we didn't require nonces to be DER encoded (as an OCTET
> STRING).
>=20
> Is this the change you are talking about? If so, I don't think that has a=
ny
> impact
> on the issue of a responder sending a nonce if the requestor doesn't incl=
ude
> one.
>=20
> Regards,
> Ambarish
>   -----Original Message-----
>   From: Florian Oelmaier [mailto:[e-mail]]
>   Sent: Sunday, September 14, 2003 6:06 PM
>   To: 'Ambarish Malpani'; 'Ryan M. Hurst'; 'Peter Gutmann';
> [e-mail]; [e-mail]
>   Subject: RE: [OCSP] are several requests for different CAs at once vali=
d ?
>=20
>=20
>   Hello Ambarish,
>=20
>   that depends on the client handling the nonce (see my message to Ryan).=
 I
> know you proposed some changes to the RfC to solve these problems back in
> January 2002 (http://www.imc.org/ietf-pkix/mail-archive/msg02983.html) - =
yet
> I cant find your changes in the RfC at http://www.ietf.org/rfc/rfc2560.tx=
t.
> So currently the published RfC does not instruct a client what to do when
> the requests contained a nonce but the response didnt. For me that means =
we
> can expect all kinds of behaviour out there.
>=20
>   Best regards,
>   Florian
>     -----Original Message-----
>     From: Ambarish Malpani [mailto:[e-mail]]
>     Sent: Monday, September 15, 2003 1:58 AM
>     To: Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann';
> [e-mail]; [e-mail]
>     Subject: RE: [OCSP] are several requests for different CAs at once va=
lid
> ?
>=20
>=20
>=20
>     Hi Florian,
>         Including a nonce in the response where there isn't one in the
> request
>     doesn't buy you any additional security (unless the nonce has some
> different
>     semantics in your environment and isn't just a nonce).
>=20
>     Regards,
>     Ambarish
>       -----Original Message-----
>       From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Florian Oelmaier
>       Sent: Sunday, September 14, 2003 3:14 PM
>       To: 'Ryan M. Hurst'; 'Peter Gutmann'; [e-mail]; vf@unity.n=
et
>       Subject: RE: [OCSP] are several requests for different CAs at once
> valid ?
>=20
>=20
>       Hello Ryan,
>=20
>       please note: although you are not sending a nonce, some
> OCSP-Responders will answer with one. To allow an responder to use nonce =
for
> replay attack protection, it must include the nonce into ALL his response=
s -
> otherwise this particular response could be used in a replay. On a sideno=
te:
> the inclusion of a nonce would surely benefit the security - perhaps you =
can
> make it a configuration setting?
>=20
>       --
>       Florian Oelmaier
>       SyTrust
>=20
>       -----Original Message-----
>       From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Ryan M. Hurst
>       Sent: Sunday, September 14, 2003 8:55 PM
>       To: Peter Gutmann; [e-mail]; [e-mail]
>       Subject: RE: [OCSP] are several requests for different CAs at once
> valid ?
>=20
>=20
>         Peter - I really don't think what we are doing is breaking OCSP's
> security, after all nonce is a optional value in 2560 and the standard
> already specifically supports response pre-production:
>=20
>              2.5  Response Pre-production
>=20
>                 OCSP responders MAY pre-produce signed responses specifyi=
ng
> the
>                 status of certificates at a specified time. The time at
> which the
>                 status was known to be correct SHALL be reflected in the
> thisUpdate
>                 field of the response. The time at or before which newer
> information
>                 will be available is reflected in the nextUpdate field,
> while the
>                 time at which the response was produced will appear in th=
e
> producedAt
>                 field of the response.
>=20
>         And the only way to support this concept within OCSP would be to
> have the described behavior in regards to nonce handling.
>=20
>         As for why OCSP was chosen over RTCS or a propietary solution, th=
e
> goal is to work with exiting public infrastrucutres and other third-party
> solutions; given this OCSP was the obvious solution.
>=20
>         Ryan
>=20
>=20
> ------------------------------------------------------------------------
>=20
>         From: Peter Gutmann
>         Sent: Sun 9/14/2003 5:26 AM
>         To: [e-mail]; [e-mail]; [e-mail]
>         Subject: RE: [OCSP] are several requests for different CAs at onc=
e
> valid ?
>=20
>=20
> "Ryan M. Hurst" <[e-mail]> writes:
>=20
> >Traditionally OCSP responders generate and sign responses on-demand
> >(dynamically), this requires the responders to scale their infrastructur=
e
> to
> >handle very high peak volumes.
>=20
> Hmm, biting back my immediate response (that breaking OCSP's security
> doesn't
> seem like a good way to try and get usable performance out of it), why no=
t
> use
> a protocol like RTCS, which was designed from the outset to allow for hig=
h-
> performance, highly scalable implementations?  It's not called real-time
> cert
> status for nothing (there's one organisation using it for exactly that, t=
hey
> do a real-time verification of cert validity using live validity data bef=
ore
> each and every use of the cert).
>=20
> Peter.
>=20
>=20

--_8526FF15-D029-44C3-ADC8-41B3D5EB6FA6_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText67375 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Since were talki=
ng changes ;) I have provided some suggested text for one of the comments b=
ellow. Also if changes are going to be made further clarifications should b=
e made:</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>1. HTTP GET vs. POST: Additional=
 text is needed to indicate that GET is most appropriate for environments w=
here response pre-production and network infrastructure caching is to be us=
ed.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>2. HTTP headers: Additional text=
 is needed to indicate that the HTTP cache related headers should be used s=
o that network infrastructure can deal with these responses appropriately; =
e.g. servers that do not include a nonce and do not wish their responses to=
 be cached should add the no-cache header, and that implementations that ac=
cept that their responses be cached should set the cache expiration to be i=
n accordance with the response expiration.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>3. Responder Identification: Add=
itional text is needed to indicate why byKey is the better choice, specific=
ally when making responses for certificates issued by more than one issuing=
 authority.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>4. Nonce: Additional text is nee=
ded on when to include a nonce, in addition to the bellow text its a good i=
dea to say something along the lines of "in environments that support pre-p=
roduced responses clients can include a nonce to indicate that they want a =
freshly generated response, servers should assume that if the client includ=
es a nonce that a new request should be generated.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan&nbsp;&nbsp;</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Florian Oelmaier<BR><B>Sent:</B> =
Mon 9/15/2003 7:33 AM<BR><B>To:</B> Ambarish Malpani; Florian Oelmaier; 'Ry=
an M. Hurst'; 'Peter Gutmann'; [e-mail]; [e-mail]<BR><B>Subjec=
t:</B> RE: [OCSP] are several requests for different CAs at once valid ?<BR=
></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">Hello Ambarish,

that was your change note I am referring:

- Section 4.4.1 - Clarified that a nonce in the request MUST be included in=
 the response for the response to be trusted.
[rmh] How about "Clients that require protection from re-play attacks MUST =
include a response in their request and MUST require the resulting response=
 contains the same nonce."</PRE><PRE style=3D"WORD-WRAP: break-word">Additi=
onally you added a requirement 8 to 3.2:
   8. If the request contained a nonce, the response must contain the
      same nonce (see section 4.4.1).

These changes would have instructed the clients what to do with nonceless r=
esponses where the request contains one. Right now the standard does not in=
struct the clients what to do in this case.

--=20
Florian Oelmaier
SyTrust

On Mon, 15 Sep 2003 07:25:01 -0700, "Ambarish Malpani" &lt;ambarish@malpani=
.biz&gt; wrote :

&gt; This is a multi-part message in MIME format.
&gt;=20
&gt;=20
&gt; Nachricht
&gt; Hi Florian,
&gt;     I believe the change with regards to nonces that isn't reflected i=
n
&gt; current
&gt; version is that we didn't require nonces to be DER encoded (as an OCTE=
T
&gt; STRING).
&gt;=20
&gt; Is this the change you are talking about? If so, I don't think that ha=
s any
&gt; impact
&gt; on the issue of a responder sending a nonce if the requestor doesn't i=
nclude
&gt; one.
&gt;=20
&gt; Regards,
&gt; Ambarish
&gt;   -----Original Message-----
&gt;   From: Florian Oelmaier [mailto:[e-mail]]
&gt;   Sent: Sunday, September 14, 2003 6:06 PM
&gt;   To: 'Ambarish Malpani'; 'Ryan M. Hurst'; 'Peter Gutmann';
&gt; [e-mail]; [e-mail]
&gt;   Subject: RE: [OCSP] are several requests for different CAs at once v=
alid ?
&gt;=20
&gt;=20
&gt;   Hello Ambarish,
&gt;=20
&gt;   that depends on the client handling the nonce (see my message to Rya=
n). I
&gt; know you proposed some changes to the RfC to solve these problems back=
 in
&gt; January 2002 (http://www.imc.org/ietf-pkix/mail-archive/msg02983.html)=
 - yet
&gt; I cant find your changes in the RfC at http://www.ietf.org/rfc/rfc2560=
.txt.
&gt; So currently the published RfC does not instruct a client what to do w=
hen
&gt; the requests contained a nonce but the response didnt. For me that mea=
ns we
&gt; can expect all kinds of behaviour out there.
&gt;=20
&gt;   Best regards,
&gt;   Florian
&gt;     -----Original Message-----
&gt;     From: Ambarish Malpani [mailto:[e-mail]]
&gt;     Sent: Monday, September 15, 2003 1:58 AM
&gt;     To: Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann';
&gt; [e-mail]; [e-mail]
&gt;     Subject: RE: [OCSP] are several requests for different CAs at once=
 valid
&gt; ?
&gt;=20
&gt;=20
&gt;=20
&gt;     Hi Florian,
&gt;         Including a nonce in the response where there isn't one in the
&gt; request
&gt;     doesn't buy you any additional security (unless the nonce has some
&gt; different
&gt;     semantics in your environment and isn't just a nonce).
&gt;=20
&gt;     Regards,
&gt;     Ambarish
&gt;       -----Original Message-----
&gt;       From: [e-mail]
&gt; [mailto:[e-mail]]On Behalf Of Florian Oelmaier
&gt;       Sent: Sunday, September 14, 2003 3:14 PM
&gt;       To: 'Ryan M. Hurst'; 'Peter Gutmann'; [e-mail]; vf@unit=
y.net
&gt;       Subject: RE: [OCSP] are several requests for different CAs at on=
ce
&gt; valid ?
&gt;=20
&gt;=20
&gt;       Hello Ryan,
&gt;=20
&gt;       please note: although you are not sending a nonce, some
&gt; OCSP-Responders will answer with one. To allow an responder to use non=
ce for
&gt; replay attack protection, it must include the nonce into ALL his respo=
nses -
&gt; otherwise this particular response could be used in a replay. On a sid=
enote:
&gt; the inclusion of a nonce would surely benefit the security - perhaps y=
ou can
&gt; make it a configuration setting?
&gt;=20
&gt;       --
&gt;       Florian Oelmaier
&gt;       SyTrust
&gt;=20
&gt;       -----Original Message-----
&gt;       From: [e-mail]
&gt; [mailto:[e-mail]] On Behalf Of Ryan M. Hurst
&gt;       Sent: Sunday, September 14, 2003 8:55 PM
&gt;       To: Peter Gutmann; [e-mail]; [e-mail]
&gt;       Subject: RE: [OCSP] are several requests for different CAs at on=
ce
&gt; valid ?
&gt;=20
&gt;=20
&gt;         Peter - I really don't think what we are doing is breaking OCS=
P's
&gt; security, after all nonce is a optional value in 2560 and the standard
&gt; already specifically supports response pre-production:
&gt;=20
&gt;              2.5  Response Pre-production
&gt;=20
&gt;                 OCSP responders MAY pre-produce signed responses speci=
fying
&gt; the
&gt;                 status of certificates at a specified time. The time a=
t
&gt; which the
&gt;                 status was known to be correct SHALL be reflected in t=
he
&gt; thisUpdate
&gt;                 field of the response. The time at or before which new=
er
&gt; information
&gt;                 will be available is reflected in the nextUpdate field=
,
&gt; while the
&gt;                 time at which the response was produced will appear in=
 the
&gt; producedAt
&gt;                 field of the response.
&gt;=20
&gt;         And the only way to support this concept within OCSP would be =
to
&gt; have the described behavior in regards to nonce handling.
&gt;=20
&gt;         As for why OCSP was chosen over RTCS or a propietary solution,=
 the
&gt; goal is to work with exiting public infrastrucutres and other third-pa=
rty
&gt; solutions; given this OCSP was the obvious solution.
&gt;=20
&gt;         Ryan
&gt;=20
&gt;=20
&gt; ----------------------------------------------------------------------=
--
&gt;=20
&gt;         From: Peter Gutmann
&gt;         Sent: Sun 9/14/2003 5:26 AM
&gt;         To: [e-mail]; [e-mail]; [e-mail]
&gt;         Subject: RE: [OCSP] are several requests for different CAs at =
once
&gt; valid ?
&gt;=20
&gt;=20
&gt; "Ryan M. Hurst" &lt;[e-mail]&gt; writes:
&gt;=20
&gt; &gt;Traditionally OCSP responders generate and sign responses on-deman=
d
&gt; &gt;(dynamically), this requires the responders to scale their infrast=
ructure
&gt; to
&gt; &gt;handle very high peak volumes.
&gt;=20
&gt; Hmm, biting back my immediate response (that breaking OCSP's security
&gt; doesn't
&gt; seem like a good way to try and get usable performance out of it), why=
 not
&gt; use
&gt; a protocol like RTCS, which was designed from the outset to allow for =
high-
&gt; performance, highly scalable implementations?  It's not called real-ti=
me
&gt; cert
&gt; status for nothing (there's one organisation using it for exactly that=
, they
&gt; do a real-time verification of cert validity using live validity data =
before
&gt; each and every use of the cert).
&gt;=20
&gt; Peter.
&gt;=20
&gt;=20
</PRE></DIV></BODY></HTML>

--_8526FF15-D029-44C3-ADC8-41B3D5EB6FA6_--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FEqIeo059541 for <[e-mail]>; Mon, 15 Sep 2003 07:52:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FEqIJE059540 for ietf-pkix-bks; Mon, 15 Sep 2003 07:52:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FEqGeo059528 for <[e-mail]>; Mon, 15 Sep 2003 07:52:16 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Sep 2003 07:52:11 -0700
Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 15 Sep 2003 07:52:12 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 15 Sep 2003 07:52:21 -0700
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(6.0.3790.1060); Mon, 15 Sep 2003 07:52:10 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Mon, 15 Sep 2003 07:52:11 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.6944
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: Peter Gutmann <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN7mPQu0SxC1EMiShar0T033q5x2g==
Message-ID: <ED3FD277-05E7-48C8-8CB4-047C24621BF7@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
Date: Mon, 15 Sep 2003 07:52:15 -0700
X-OriginalArrivalTime: 15 Sep 2003 14:52:11.0468 (UTC) FILETIME=[F192C8C0:01C37B98]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_736CCC93-1A71-4311-9769-AD055C89A1DD_"

--_736CCC93-1A71-4311-9769-AD055C89A1DD_
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Now your just being silly Peter, using pre-produced OCSP responses is no wo=
rse that using CRLs and it is a cocept explicitly supported by the RFC for =
the very reasons we implemented it that way.=20

Florian - We will be fine with your server generated nonce, but I still hol=
d to my original statement that this does not protect your server from anyt=
hing, and as for your client expecting a nonce in a reply,  it should simpl=
y make sure the nonce in the request matches the nonce in the received repl=
y as thats the only way to truly protect against a replay attack on the cli=
ent side.

Ryanb


From: Peter Gutmann
Sent: Mon 9/15/2003 6:48 AM
To: [e-mail]; [e-mail]; [e-mail]; pgut001@=
cs.auckland.ac.nz; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?


"Florian Oelmaier" <[e-mail]> writes:

>So currently the published RfC does not instruct a client what to do when =
the
>requests contained a nonce but the response didnt. For me that means we ca=
n
>expect all kinds of behaviour out there.

My code treats a nonceless response as pretty much worthless (it could be a
replay, there's no way to tell) and rejects it.  I've heard from a few othe=
r
vendors out there, and there's a mixture of implementations rejecting
nonceless messages as insecure, and "performance-tuned" implementations
deliberately sending them to make replays possible.

I do think that if you're going to use nonceless messages for performance
reasons you may as well optimise things a step further and just pop up a
dialog that says "Everything seems to be OK as far as I can tell", avoiding
the overhead of submitting a query at all.  If everything's OK then you get=
 a
nice fast response, and if everything's not OK (there's an attacker spoofin=
g
responses) you wouldn't know anyway, so why bother even pretending?  As a
side-benefit, you can advertise your product as a high-performance OCSP
responder...

Peter.

--_736CCC93-1A71-4311-9769-AD055C89A1DD_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText87386 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Now your just be=
ing silly Peter, using pre-produced OCSP responses is no worse that using C=
RLs and it is a cocept explicitly supported by the RFC for the very reasons=
 we implemented it that way.&nbsp;</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Florian - We will be fine with y=
our server generated nonce, but I still hold to my original statement that =
this does not protect your server from anything, and as for your client exp=
ecting a nonce in&nbsp;a reply, &nbsp;it should simply make sure the nonce =
in the request matches the nonce in the received reply as thats the only wa=
y to truly protect against a replay attack on the client side.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryanb</FONT><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Peter Gutmann<BR><B>Sent:</B> Mon=
 9/15/2003 6:48 AM<BR><B>To:</B> [e-mail]; [e-mail]; o=
[e-mail]; [e-mail]; [e-mail]; =
[e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests for differe=
nt CAs at once valid ?<BR></FONT><BR></DIV></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">"Florian Oelmaier" &lt;oelmaier@s=
ytrust.com&gt; writes:

&gt;So currently the published RfC does not instruct a client what to do wh=
en the
&gt;requests contained a nonce but the response didnt. For me that means we=
 can
&gt;expect all kinds of behaviour out there.

My code treats a nonceless response as pretty much worthless (it could be a
replay, there's no way to tell) and rejects it.  I've heard from a few othe=
r
vendors out there, and there's a mixture of implementations rejecting
nonceless messages as insecure, and "performance-tuned" implementations
deliberately sending them to make replays possible.

I do think that if you're going to use nonceless messages for performance
reasons you may as well optimise things a step further and just pop up a
dialog that says "Everything seems to be OK as far as I can tell", avoiding
the overhead of submitting a query at all.  If everything's OK then you get=
 a
nice fast response, and if everything's not OK (there's an attacker spoofin=
g
responses) you wouldn't know anyway, so why bother even pretending?  As a
side-benefit, you can advertise your product as a high-performance OCSP
responder...

Peter.
</PRE></DIV></BODY></HTML>

--_736CCC93-1A71-4311-9769-AD055C89A1DD_--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FEXVeo057902 for <[e-mail]>; Mon, 15 Sep 2003 07:33:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FEXVIE057901 for ietf-pkix-bks; Mon, 15 Sep 2003 07:33:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8FEXTeo057893 for <[e-mail]>; Mon, 15 Sep 2003 07:33:29 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 12473 invoked by uid 1649); 15 Sep 2003 14:33:29 -0000
Date: 15 Sep 2003 14:33:29 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>, "Florian Oelmaier" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
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>

Hello Ambarish,

that was your change note I am referring:

- Section 4.4.1 - Clarified that a nonce in the request MUST be included in the response for the response to be trusted.

Additionally you added a requirement 8 to 3.2:
   8. If the request contained a nonce, the response must contain the
      same nonce (see section 4.4.1).

These changes would have instructed the clients what to do with nonceless responses where the request contains one. Right now the standard does not instruct the clients what to do in this case.

-- 
Florian Oelmaier
SyTrust

On Mon, 15 Sep 2003 07:25:01 -0700, "Ambarish Malpani" <[e-mail]> wrote :

> This is a multi-part message in MIME format.
> 
> 
> Nachricht
> Hi Florian,
>     I believe the change with regards to nonces that isn't reflected in
> current
> version is that we didn't require nonces to be DER encoded (as an OCTET
> STRING).
> 
> Is this the change you are talking about? If so, I don't think that has any
> impact
> on the issue of a responder sending a nonce if the requestor doesn't include
> one.
> 
> Regards,
> Ambarish
>   -----Original Message-----
>   From: Florian Oelmaier [mailto:[e-mail]]
>   Sent: Sunday, September 14, 2003 6:06 PM
>   To: 'Ambarish Malpani'; 'Ryan M. Hurst'; 'Peter Gutmann';
> [e-mail]; [e-mail]
>   Subject: RE: [OCSP] are several requests for different CAs at once valid ?
> 
> 
>   Hello Ambarish,
> 
>   that depends on the client handling the nonce (see my message to Ryan). I
> know you proposed some changes to the RfC to solve these problems back in
> January 2002 (http://www.imc.org/ietf-pkix/mail-archive/msg02983.html) - yet
> I cant find your changes in the RfC at http://www.ietf.org/rfc/rfc2560.txt.
> So currently the published RfC does not instruct a client what to do when
> the requests contained a nonce but the response didnt. For me that means we
> can expect all kinds of behaviour out there.
> 
>   Best regards,
>   Florian
>     -----Original Message-----
>     From: Ambarish Malpani [mailto:[e-mail]]
>     Sent: Monday, September 15, 2003 1:58 AM
>     To: Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann';
> [e-mail]; [e-mail]
>     Subject: RE: [OCSP] are several requests for different CAs at once valid
> ?
> 
> 
> 
>     Hi Florian,
>         Including a nonce in the response where there isn't one in the
> request
>     doesn't buy you any additional security (unless the nonce has some
> different
>     semantics in your environment and isn't just a nonce).
> 
>     Regards,
>     Ambarish
>       -----Original Message-----
>       From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Florian Oelmaier
>       Sent: Sunday, September 14, 2003 3:14 PM
>       To: 'Ryan M. Hurst'; 'Peter Gutmann'; [e-mail]; [e-mail]
>       Subject: RE: [OCSP] are several requests for different CAs at once
> valid ?
> 
> 
>       Hello Ryan,
> 
>       please note: although you are not sending a nonce, some
> OCSP-Responders will answer with one. To allow an responder to use nonce for
> replay attack protection, it must include the nonce into ALL his responses -
> otherwise this particular response could be used in a replay. On a sidenote:
> the inclusion of a nonce would surely benefit the security - perhaps you can
> make it a configuration setting?
> 
>       --
>       Florian Oelmaier
>       SyTrust
> 
>       -----Original Message-----
>       From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Ryan M. Hurst
>       Sent: Sunday, September 14, 2003 8:55 PM
>       To: Peter Gutmann; [e-mail]; [e-mail]
>       Subject: RE: [OCSP] are several requests for different CAs at once
> valid ?
> 
> 
>         Peter - I really don't think what we are doing is breaking OCSP's
> security, after all nonce is a optional value in 2560 and the standard
> already specifically supports response pre-production:
> 
>              2.5  Response Pre-production
> 
>                 OCSP responders MAY pre-produce signed responses specifying
> the
>                 status of certificates at a specified time. The time at
> which the
>                 status was known to be correct SHALL be reflected in the
> thisUpdate
>                 field of the response. The time at or before which newer
> information
>                 will be available is reflected in the nextUpdate field,
> while the
>                 time at which the response was produced will appear in the
> producedAt
>                 field of the response.
> 
>         And the only way to support this concept within OCSP would be to
> have the described behavior in regards to nonce handling.
> 
>         As for why OCSP was chosen over RTCS or a propietary solution, the
> goal is to work with exiting public infrastrucutres and other third-party
> solutions; given this OCSP was the obvious solution.
> 
>         Ryan
> 
> 
> ------------------------------------------------------------------------
> 
>         From: Peter Gutmann
>         Sent: Sun 9/14/2003 5:26 AM
>         To: [e-mail]; [e-mail]; [e-mail]
>         Subject: RE: [OCSP] are several requests for different CAs at once
> valid ?
> 
> 
> "Ryan M. Hurst" <[e-mail]> writes:
> 
> >Traditionally OCSP responders generate and sign responses on-demand
> >(dynamically), this requires the responders to scale their infrastructure
> to
> >handle very high peak volumes.
> 
> Hmm, biting back my immediate response (that breaking OCSP's security
> doesn't
> seem like a good way to try and get usable performance out of it), why not
> use
> a protocol like RTCS, which was designed from the outset to allow for high-
> performance, highly scalable implementations?  It's not called real-time
> cert
> status for nothing (there's one organisation using it for exactly that, they
> do a real-time verification of cert validity using live validity data before
> each and every use of the cert).
> 
> Peter.
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FESNeo057595 for <[e-mail]>; Mon, 15 Sep 2003 07:28:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FESNAi057594 for ietf-pkix-bks; Mon, 15 Sep 2003 07:28:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8FESLeo057578 for <[e-mail]>; Mon, 15 Sep 2003 07:28:21 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 6629 invoked by uid 1649); 15 Sep 2003 14:28:14 -0000
Date: 15 Sep 2003 14:28:14 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: [e-mail] (Peter Gutmann), [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
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>

> My code treats a nonceless response as pretty much worthless (it could be > a replay, there's no way to tell) and rejects it.  I've heard from a 
> few other vendors out there, and there's a mixture of implementations 
> rejecting nonceless messages as insecure, and "performance-tuned" 
> implementations deliberately sending them to make replays possible.

Our client is configurable. The standard is to issue a warning ("no replay protection"), but it can be configured to reject or accept it. On the other hand our client always includes a nonce into his requests (Why not? Even if the responder cannot answer it due to preproduced responses, I do not loose anything by asking for one - and on the client a nonce has nothing to do with performance).

> [...]  As a side-benefit, you can advertise your product as a 
> high-performance OCSP responder...

LOL. We do that :) And in the standard config our responder always uses fresh responses and always! includes a nonce into it. 

Just to clarify for the casual reader: including a nonce is not a performance issue by itself. If one wants to include a nonce, it is not possible to use pre-produced responses anymore.

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FEM1eo057377 for <[e-mail]>; Mon, 15 Sep 2003 07:22:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FEM1VK057376 for ietf-pkix-bks; Mon, 15 Sep 2003 07:22:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FELxeo057359 for <[e-mail]>; Mon, 15 Sep 2003 07:21:59 -0700 (PDT) (envelope-from [e-mail])
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.9/8.12.9) with SMTP id h8FELmPo016134; Mon, 15 Sep 2003 07:21:51 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 07:25:01 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01C37B5A.7A3AE8E0"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <000001c37b25$8cf94a60$4228a8c0@hagen>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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_0026_01C37B5A.7A3AE8E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Nachricht
Hi Florian,
    I believe the change with regards to nonces that isn't reflected in
current
version is that we didn't require nonces to be DER encoded (as an OCTET
STRING).

Is this the change you are talking about? If so, I don't think that has any
impact
on the issue of a responder sending a nonce if the requestor doesn't include
one.

Regards,
Ambarish
  -----Original Message-----
  From: Florian Oelmaier [mailto:[e-mail]]
  Sent: Sunday, September 14, 2003 6:06 PM
  To: 'Ambarish Malpani'; 'Ryan M. Hurst'; 'Peter Gutmann';
[e-mail]; [e-mail]
  Subject: RE: [OCSP] are several requests for different CAs at once valid ?


  Hello Ambarish,

  that depends on the client handling the nonce (see my message to Ryan). I
know you proposed some changes to the RfC to solve these problems back in
January 2002 (http://www.imc.org/ietf-pkix/mail-archive/msg02983.html) - yet
I cant find your changes in the RfC at http://www.ietf.org/rfc/rfc2560.txt.
So currently the published RfC does not instruct a client what to do when
the requests contained a nonce but the response didnt. For me that means we
can expect all kinds of behaviour out there.

  Best regards,
  Florian
    -----Original Message-----
    From: Ambarish Malpani [mailto:[e-mail]]
    Sent: Monday, September 15, 2003 1:58 AM
    To: Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann';
[e-mail]; [e-mail]
    Subject: RE: [OCSP] are several requests for different CAs at once valid
?



    Hi Florian,
        Including a nonce in the response where there isn't one in the
request
    doesn't buy you any additional security (unless the nonce has some
different
    semantics in your environment and isn't just a nonce).

    Regards,
    Ambarish
      -----Original Message-----
      From: [e-mail]
[mailto:[e-mail]]On Behalf Of Florian Oelmaier
      Sent: Sunday, September 14, 2003 3:14 PM
      To: 'Ryan M. Hurst'; 'Peter Gutmann'; [e-mail]; [e-mail]
      Subject: RE: [OCSP] are several requests for different CAs at once
valid ?


      Hello Ryan,

      please note: although you are not sending a nonce, some
OCSP-Responders will answer with one. To allow an responder to use nonce for
replay attack protection, it must include the nonce into ALL his responses -
otherwise this particular response could be used in a replay. On a sidenote:
the inclusion of a nonce would surely benefit the security - perhaps you can
make it a configuration setting?

      --
      Florian Oelmaier
      SyTrust

      -----Original Message-----
      From: [e-mail]
[mailto:[e-mail]] On Behalf Of Ryan M. Hurst
      Sent: Sunday, September 14, 2003 8:55 PM
      To: Peter Gutmann; [e-mail]; [e-mail]
      Subject: RE: [OCSP] are several requests for different CAs at once
valid ?


        Peter - I really don't think what we are doing is breaking OCSP's
security, after all nonce is a optional value in 2560 and the standard
already specifically supports response pre-production:

             2.5  Response Pre-production

                OCSP responders MAY pre-produce signed responses specifying
the
                status of certificates at a specified time. The time at
which the
                status was known to be correct SHALL be reflected in the
thisUpdate
                field of the response. The time at or before which newer
information
                will be available is reflected in the nextUpdate field,
while the
                time at which the response was produced will appear in the
producedAt
                field of the response.

        And the only way to support this concept within OCSP would be to
have the described behavior in regards to nonce handling.

        As for why OCSP was chosen over RTCS or a propietary solution, the
goal is to work with exiting public infrastrucutres and other third-party
solutions; given this OCSP was the obvious solution.

        Ryan


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

        From: Peter Gutmann
        Sent: Sun 9/14/2003 5:26 AM
        To: [e-mail]; [e-mail]; [e-mail]
        Subject: RE: [OCSP] are several requests for different CAs at once
valid ?


"Ryan M. Hurst" <[e-mail]> writes:

>Traditionally OCSP responders generate and sign responses on-demand
>(dynamically), this requires the responders to scale their infrastructure
to
>handle very high peak volumes.

Hmm, biting back my immediate response (that breaking OCSP's security
doesn't
seem like a good way to try and get usable performance out of it), why not
use
a protocol like RTCS, which was designed from the outset to allow for high-
performance, highly scalable implementations?  It's not called real-time
cert
status for nothing (there's one organisation using it for exactly that, they
do a real-time verification of cert validity using live validity data before
each and every use of the cert).

Peter.

------=_NextPart_000_0026_01C37B5A.7A3AE8E0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Nachricht</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D264233405-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Florian,</FONT></SPAN></DIV>
<DIV><SPAN class=3D264233405-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;&nbsp;&nbsp; I believe the change with regards to nonces =
that isn't=20
reflected in current</FONT></SPAN></DIV>
<DIV><SPAN class=3D264233405-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2>version is that we didn't require nonces to be DER encoded (as =
an OCTET=20
STRING).</FONT></SPAN></DIV>
<DIV><SPAN class=3D264233405-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D264233405-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>Is=20
this the change you are talking about? If so, I don't think that has any =

impact</FONT></SPAN></DIV>
<DIV><SPAN class=3D264233405-15092003><FONT face=3DArial color=3D#0000ff =
size=3D2>on the=20
issue of a responder sending a nonce if the requestor doesn't include=20
one.</FONT></SPAN></DIV>
<DIV><SPAN class=3D264233405-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D264233405-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D264233405-15092003><FONT face=3DArial color=3D#0000ff =

size=3D2>Ambarish</FONT></SPAN></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>-----Original Message-----<BR><B>From:</B> Florian Oelmaier=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Sunday, September 14, =
2003 6:06=20
  PM<BR><B>To:</B> 'Ambarish Malpani'; 'Ryan M. Hurst'; 'Peter Gutmann'; =

  [e-mail]; [e-mail]<BR><B>Subject:</B> RE: [OCSP] are =
several=20
  requests for different CAs at once valid ?<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D665403500-15092003>Hello Ambarish,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D665403500-15092003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D665403500-15092003>that=20
  depends on the client handling the nonce (see my message to Ryan). I =
know you=20
  proposed some changes to the RfC to solve these problems back in =
January 2002=20
  (<A=20
  =
href=3D"http://www.imc.org/ietf-pkix/mail-archive/msg02983.html">http://w=
ww.imc.org/ietf-pkix/mail-archive/msg02983.html</A>)&nbsp;-=20
  yet I cant find your changes in the RfC at <A=20
  =
href=3D"http://www.ietf.org/rfc/rfc2560.txt">http://www.ietf.org/rfc/rfc2=
560.txt</A>.=20
  So currently the published RfC does not instruct a client what to do =
when the=20
  requests contained a nonce but the response didnt.&nbsp;For me that =
means we=20
  can expect all kinds of behaviour out there.</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D665403500-15092003></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2><SPAN class=3D665403500-15092003></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D665403500-15092003>Best=20
  regards,</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D665403500-15092003>Florian</SPAN></FONT></DIV>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV></DIV>
    <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr =
align=3Dleft><FONT face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Ambarish Malpani =

    [mailto:[e-mail]] <BR><B>Sent:</B> Monday, September 15, =
2003=20
    1:58 AM<BR><B>To:</B> Florian Oelmaier; 'Ryan M. Hurst'; 'Peter =
Gutmann';=20
    [e-mail]; [e-mail]<BR><B>Subject:</B> RE: [OCSP] are =
several=20
    requests for different CAs at once valid ?<BR><BR></FONT></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
    <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
    Florian,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>&nbsp;&nbsp;&nbsp; Including a nonce in the response where =
there=20
    isn't one in the request</FONT></SPAN></DIV>
    <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>doesn't buy you any additional security (unless the nonce =
has some=20
    different</FONT></SPAN></DIV>
    <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>semantics in your environment and isn't just a=20
    nonce).</FONT></SPAN></DIV>
    <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Regards,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Ambarish</FONT></SPAN></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>-----Original Message-----<BR><B>From:</B>=20
      [e-mail] =
[mailto:[e-mail]]<B>On=20
      Behalf Of </B>Florian Oelmaier<BR><B>Sent:</B> Sunday, September =
14, 2003=20
      3:14 PM<BR><B>To:</B> 'Ryan M. Hurst'; 'Peter Gutmann'; =
[e-mail];=20
      [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests =
for=20
      different CAs at once valid ?<BR><BR></FONT></DIV>
      <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
      size=3D2>Hello Ryan,</FONT></SPAN></DIV>
      <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
      size=3D2></FONT></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
      size=3D2>please note: although you are not sending a =
nonce,&nbsp;some=20
      OCSP-Responders will answer with one. To allow an responder to use =
nonce=20
      for&nbsp;replay attack protection,&nbsp;it must include the nonce =
into ALL=20
      his responses - otherwise this particular response could be used =
in a=20
      replay. On a sidenote: the inclusion of a nonce would surely =
benefit the=20
      security - perhaps you can make it a configuration=20
      setting?</FONT></SPAN></DIV>
      <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
      size=3D2></FONT></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
      size=3D2>-- </FONT></SPAN></DIV>
      <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
      size=3D2>Florian Oelmaier</FONT></SPAN></DIV>
      <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
      size=3D2>SyTrust</FONT></SPAN></DIV>
      <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
      size=3D2></FONT></SPAN>&nbsp;</DIV>
      <DIV></DIV>
      <DIV><FONT face=3DTahoma size=3D2>-----Original =
Message-----<BR><B>From:</B>=20
      [e-mail] [mailto:[e-mail]] =
<B>On=20
      Behalf Of </B>Ryan M. Hurst<BR><B>Sent:</B> Sunday, September 14, =
2003=20
      8:55 PM<BR><B>To:</B> Peter Gutmann; [e-mail];=20
      [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests =
for=20
      different CAs at once valid ?<BR><BR></DIV></FONT>
      <BLOCKQUOTE dir=3Dltr=20
      style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
        <DIV id=3DidOWAReplyText27203 dir=3Dltr>
        <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Peter =
- I really=20
        don't think what we are doing is breaking OCSP's security, after =
all=20
        nonce is a optional value in 2560 and the standard already =
specifically=20
        supports response pre-production:</FONT></DIV>
        <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
        <DIV dir=3Dltr>&nbsp;&nbsp;&nbsp;&nbsp; 2.5&nbsp; Response=20
        Pre-production<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OCSP=20
        responders MAY pre-produce signed responses specifying=20
        the<BR>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; status of =
certificates at a=20
        specified time. The time at which=20
        the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; status was =
known to be=20
        correct SHALL be reflected in the=20
        thisUpdate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field =
of the=20
        response. The time at or before which newer=20
        information<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will =
be=20
        available is reflected in the nextUpdate field, while=20
        the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; time at which =
the=20
        response was produced will appear in the=20
        producedAt<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field =
of the=20
        response.<BR></DIV></DIV>
        <DIV dir=3Dltr>And the only way to support this concept within =
OCSP would=20
        be to have the described behavior in regards to nonce =
handling.</DIV>
        <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
        <DIV dir=3Dltr>As for why OCSP was chosen over RTCS or a =
propietary=20
        solution, the goal is to work with exiting public =
infrastrucutres and=20
        other third-party solutions; given this OCSP was the obvious=20
        solution.</DIV>
        <DIV dir=3Dltr>&nbsp;</DIV>
        <DIV dir=3Dltr>Ryan<BR></DIV>
        <DIV dir=3Dltr>
        <HR tabIndex=3D-1>
        </DIV>
        <DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Peter=20
        Gutmann<BR><B>Sent:</B> Sun 9/14/2003 5:26 AM<BR><B>To:</B>=20
        [e-mail]; [e-mail];=20
        [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests =
for=20
        different CAs at once valid ?<BR></FONT><BR></DIV>
        <DIV><PRE style=3D"WORD-WRAP: break-word">"Ryan M. Hurst" =
&lt;[e-mail]&gt; writes:

&gt;Traditionally OCSP responders generate and sign responses on-demand
&gt;(dynamically), this requires the responders to scale their =
infrastructure to
&gt;handle very high peak volumes.=20

Hmm, biting back my immediate response (that breaking OCSP's security =
doesn't
seem like a good way to try and get usable performance out of it), why =
not use
a protocol like RTCS, which was designed from the outset to allow for =
high-
performance, highly scalable implementations?  It's not called real-time =
cert
status for nothing (there's one organisation using it for exactly that, =
they
do a real-time verification of cert validity using live validity data =
before
each and every use of the cert).

Peter.
</PRE></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></=
HTML>

------=_NextPart_000_0026_01C37B5A.7A3AE8E0--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FEJheo057282 for <[e-mail]>; Mon, 15 Sep 2003 07:19:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FEJh63057281 for ietf-pkix-bks; Mon, 15 Sep 2003 07:19:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smarthost2.mail.uk.easynet.net (smarthost2.mail.uk.easynet.net [212.135.6.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FEJfeo057272 for <[e-mail]>; Mon, 15 Sep 2003 07:19:42 -0700 (PDT) (envelope-from [e-mail])
Received: from [217.205.5.135] (helo=laptoplk) by smarthost2.mail.uk.easynet.net with esmtp (Exim 4.10) id 19yuCV-000JTS-00 for [e-mail]; Mon, 15 Sep 2003 15:19:35 +0100
From: "Liaquat Khan" <[e-mail]>
To: <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 15:21:28 +0100
Message-ID: <007201c37b94$a77736d0$3101a8c0@laptoplk>
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 V6.00.2800.1106
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>

:-) I like it!

Our OCSP responder by default requires a nonce to be present in OCSP
requests.  If it is missing, it rejects the request.  This requirement
can be switched off by the administrator, in which case OCSP requests
without a nonce will also be processed. 

Our Windows-based OCSP client by default sends a nonce in all OCSP
requests and then compares this with nonce sent back the server.  If the
nonce comparison fails then the OCSP response is rejected.  However, in
our OCSP client, it is possible to change the default setting so that a
nonce is not included in OCSP requests.   

Regard,
LK

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Peter Gutmann
Sent: 15 September 2003 14:49
To: [e-mail]; [e-mail]; [e-mail];
[e-mail]; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?


"Florian Oelmaier" <[e-mail]> writes:

>So currently the published RfC does not instruct a client what to do
when the
>requests contained a nonce but the response didnt. For me that means we
can
>expect all kinds of behaviour out there.

My code treats a nonceless response as pretty much worthless (it could
be a
replay, there's no way to tell) and rejects it.  I've heard from a few
other
vendors out there, and there's a mixture of implementations rejecting
nonceless messages as insecure, and "performance-tuned" implementations
deliberately sending them to make replays possible.

I do think that if you're going to use nonceless messages for
performance
reasons you may as well optimise things a step further and just pop up a
dialog that says "Everything seems to be OK as far as I can tell",
avoiding
the overhead of submitting a query at all.  If everything's OK then you
get a
nice fast response, and if everything's not OK (there's an attacker
spoofing
responses) you wouldn't know anyway, so why bother even pretending?  As
a
side-benefit, you can advertise your product as a high-performance OCSP
responder...

Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FDkjeo055900 for <[e-mail]>; Mon, 15 Sep 2003 06:46:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FDkjFS055895 for ietf-pkix-bks; Mon, 15 Sep 2003 06:46:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FDkfeo055875 for <[e-mail]>; Mon, 15 Sep 2003 06:46:43 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h8FDkU1h005108; Tue, 16 Sep 2003 01:46:30 +1200
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h8FDmdD20210; Tue, 16 Sep 2003 01:48:39 +1200
Date: Tue, 16 Sep 2003 01:48:39 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Florian Oelmaier" <[e-mail]> writes:

>So currently the published RfC does not instruct a client what to do when the
>requests contained a nonce but the response didnt. For me that means we can
>expect all kinds of behaviour out there.

My code treats a nonceless response as pretty much worthless (it could be a
replay, there's no way to tell) and rejects it.  I've heard from a few other
vendors out there, and there's a mixture of implementations rejecting
nonceless messages as insecure, and "performance-tuned" implementations
deliberately sending them to make replays possible.

I do think that if you're going to use nonceless messages for performance
reasons you may as well optimise things a step further and just pop up a
dialog that says "Everything seems to be OK as far as I can tell", avoiding
the overhead of submitting a query at all.  If everything's OK then you get a
nice fast response, and if everything's not OK (there's an attacker spoofing
responses) you wouldn't know anyway, so why bother even pretending?  As a
side-benefit, you can advertise your product as a high-performance OCSP
responder...

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FDKZeo051302 for <[e-mail]>; Mon, 15 Sep 2003 06:20:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FDKZ3k051300 for ietf-pkix-bks; Mon, 15 Sep 2003 06:20:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FDKXeo051183 for <[e-mail]>; Mon, 15 Sep 2003 06:20:33 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h8FDKQ0w010055; Mon, 15 Sep 2003 09:20:26 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210600bb8b6cb5186d@[128.89.89.82]>
In-Reply-To: <00c701c379b1$c0bba0c0$[e-mail]>
References: <00c701c379b1$c0bba0c0$[e-mail]>
Date: Mon, 15 Sep 2003 09:19:25 -0400
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: WG last call - DER-encoded BIT STRING for IPAddress
Cc: "'Manger, James H'" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 21:44 -0700 9/12/03, Jim Schaad wrote:
>I withdraw my objection on this issue.  I still think that some
>clarification language on how IPAddresses are encoded makes sense.
>
>jim
>

Jim,

Right.  We're adding the ASN.1 module and will provide more 
discussion of address encoding.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FCCYeo031272 for <[e-mail]>; Mon, 15 Sep 2003 05:12:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FCCY8W031271 for ietf-pkix-bks; Mon, 15 Sep 2003 05:12:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FCCJeo031265 for <[e-mail]>; Mon, 15 Sep 2003 05:12:30 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA25072; Mon, 15 Sep 2003 14:17:47 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id OAA32078; Mon, 15 Sep 2003 14:13:21 +0200
Message-ID: <[e-mail]>
Date: Mon, 15 Sep 2003 14:12:11 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Wen-Cheng Wang <[e-mail]>
CC: [e-mail]
Subject: Re: How a SCVP client authenticates the SCVP server?
References: <[e-mail]> <[e-mail]> <01ac01c37b71$6d358210$4f85900a@wcwang>
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>

Wen-Cheng,

>>Trevor,
>>
>>
>>>Hi Wen-Cheng,
>>
>>>First off consider there are two classes of SCVP clients. 
>>>* Simple clients who only originate SCVP request and 
>>>* SCVP servers who can both service requests and originate their own
>>>requests to other SCVP servers(relay).
>>
>>There is a third class, as well :
>>
>>   * Normal clients (as opposed to simple clients) which can directly query 
>>different SCVP servers, e.g. because they support different validation 
>>policies and which are using trust anchors and some local conditions. The 
>>advantage is that the keys of the SCVP servers may easily be changed, 
>>without the need for a local re-configuration. The local configuration is 
>>close to the SCVP server class.
> 
> 
> It seems that you belong to a different taxonomy school :-)


> The main difference between "Simple clients" and "SCVP servers as clients"
> (SCVP Srver relays) is that a SCVP server has its own path construction/validation
> modules while a simple client might have no its own path construction/validation
> modules (that is why the simple client need to delegate that job to a SCVP server).

> I do not see why a simple client can not directly query different servers. Cann't a
> simple client query any SCVP server listed in its trusted list?

This is one possible case, but not the only one.

> Therefore, I do not understand the difference between your definition of normal
> clients and the definition of simple clients. Does a "normal client" you definied
> has its own path construction/validation modules?

A "normal client" knows trust anchors (i.e. root CAs) and can query SCVP 
servers that are certified by one of these trust anchors (plus other 
conditions like CP OIDs for example or a given name). He will check the 
revocation status of the SCVP in the normal way, i.e. using CRLs or OCSP 
responses.

Normal = "fat" client. :-)

A simple client does not know what a trust anchor is and directly trusts the 
public key(s) of the servers(s).

Denis

>>IF the SCVP server has no certificate, THEN it can only be accessed by 
>>simple clients.
>>
>>IF the SCVP server has a certificate, THEN it can always be accessed: by 
>>simple clients, normal clients and SCVP servers.
>>
>>Thus I see advantages to always include the SCVP certificate, even if simple 
>>clients are free to ignore it when validating the response.
>>
>>Denis
>>
>>
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FABCeo026934 for <[e-mail]>; Mon, 15 Sep 2003 03:11:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8FABBlY026933 for ietf-pkix-bks; Mon, 15 Sep 2003 03:11:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gate.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8FAB7eo026928 for <[e-mail]>; Mon, 15 Sep 2003 03:11:09 -0700 (PDT) (envelope-from [e-mail])
Received: from ms7.chttl.com.tw (ms7 [10.144.2.117]) by gate.chttl.com.tw (8.12.9/8.12.9) with ESMTP id h8FAAP3K031202; Mon, 15 Sep 2003 18:10:26 +0800
Received: (from root@localhost) by ms7.chttl.com.tw (8.12.3/8.12.1) id h8FAAOWi008428; Mon, 15 Sep 2003 18:10:24 +0800
Received: from wcwang ([10.144.133.79]) by ms7.chttl.com.tw (8.12.3/8.12.1) with SMTP id h8FAAN7M008332; Mon, 15 Sep 2003 18:10:23 +0800
Message-ID: <01ac01c37b71$6d358210$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Trevor Freeman" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: How a SCVP client authenticates the SCVP server?
Date: Mon, 15 Sep 2003 18:09:18 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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,
> 
> > Hi Wen-Cheng,
> 
> > First off consider there are two classes of SCVP clients. 
> > * Simple clients who only originate SCVP request and 
> > * SCVP servers who can both service requests and originate their own
> > requests to other SCVP servers(relay).
> 
> There is a third class, as well :
> 
>    * Normal clients (as opposed to simple clients) which can directly query 
> different SCVP servers, e.g. because they support different validation 
> policies and which are using trust anchors and some local conditions. The 
> advantage is that the keys of the SCVP servers may easily be changed, 
> without the need for a local re-configuration. The local configuration is 
> close to the SCVP server class.

It seems that you belong to a different taxonomy school :-)
The main difference between "Simple clients" and "SCVP servers as clients"
(SCVP Srver relays) is that a SCVP server has its own path construction/validation
modules while a simple client might have no its own path construction/validation
modules (that is why the simple client need to delegate that job to a SCVP server).
I do not see why a simple client can not directly query different servers. Cann't a
simple client query any SCVP server listed in its trusted list?
Therefore, I do not understand the difference between your definition of normal
clients and the definition of simple clients. Does a "normal client" you definied
has its own path construction/validation modules?

> 
> IF the SCVP server has no certificate, THEN it can only be accessed by 
> simple clients.
> 
> IF the SCVP server has a certificate, THEN it can always be accessed: by 
> simple clients, normal clients and SCVP servers.
> 
> Thus I see advantages to always include the SCVP certificate, even if simple 
> clients are free to ignore it when validating the response.
> 
> Denis
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8F9Qseo024533 for <[e-mail]>; Mon, 15 Sep 2003 02:26:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8F9QsNM024532 for ietf-pkix-bks; Mon, 15 Sep 2003 02:26:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gate.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8F9Qpeo024515 for <[e-mail]>; Mon, 15 Sep 2003 02:26:52 -0700 (PDT) (envelope-from [e-mail])
Received: from ms5.chttl.com.tw (ms5 [10.144.2.115]) by gate.chttl.com.tw (8.12.9/8.12.9) with ESMTP id h8F9QZ3K028453; Mon, 15 Sep 2003 17:26:36 +0800
Received: (from root@localhost) by ms5.chttl.com.tw (8.11.6/8.11.6) id h8F9QY307260; Mon, 15 Sep 2003 17:26:34 +0800
Received: from wcwang ([10.144.133.79]) by ms5.chttl.com.tw (8.11.6/8.11.6) with SMTP id h8F9QXb07217; Mon, 15 Sep 2003 17:26:34 +0800
Message-ID: <018e01c37b6b$4d8bcab0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Trevor Freeman" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: How a SCVP client authenticates the SCVP server?
Date: Mon, 15 Sep 2003 17:25:28 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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,

Thank you for the clarification. I think now I understand the
philosophy of the current SCVP ID that "the SCVP server
MUST include its own certificate in the certificates field within
SignedData", although I am still not 100% agreed with that.
Especially, I don't think "the simple client does not need to do
anything else just because the information was conveyed in a
certificate". I believe that

1. at least the client should validate (NOTE: maybe by using an
    out-of-band and restricted version of certificate validation
    software) the SCVP server certificate at the first time it
    receives the certificate (NOTE: maybe via an out-of-band
    channel) so that it does not blindly trust the server cert ; and
2. the client should periodically re-validate and check the status
    of the SCVP server certificate, or alternatively there should
    be an out-of-band notification mechanism to notify the client
    in case that the SCVP server certificate is revoked.

I must clarify that I never worry about the need of supporting
certificate parsing in the client at all. What I concerned
are security issues related to validating the SCVP server
certificate. Anyway, since you will elaborate "how the client
validates the signature" in draft 13, I guess those security issues
will also be clarified then. Hopefully.

Best Regards,
Wen-Cheng

----- Original Message ----- 
From: "Trevor Freeman" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>
Cc: <[e-mail]>
Sent: Sunday, September 14, 2003 7:27 AM
Subject: RE: How a SCVP client authenticates the SCVP server?


> 
> Hi Wen,
> Yes the SCVP server MUST have a CA issued certificate conformant to 3280
> and use it when signing signed data responses. It is a matter of local
> policy and capability how the client validates the signature which is a
> subject I will elaborate on in draft 13. I see no benefit in using raw
> keys as you suggest. All you save is some data on the wire and
> complicate the server who now has to support more mechanisms to do
> signed data signatures. The client is already parsing ASN CMS data so
> the impact of supporting parsing the ASN certificate is negligible. The
> simple client does not need to do anything else just because the
> information was conveyed in a certificate. If you really want to
> distribute the public key of the server, since that is a mater of local
> policy, then you can ignore the cert totally. Alternatively use
> authenticated data with a pre-shraed key.
> 
> Trevor 
> 
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 11:14 PM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: RE: How a SCVP client authenticates the SCVP server?
> 
> Hi, Trevor,
> 
> Do you mean that the SCVP server still needs to apply a server 
> cetificate from a CA even in the case where all its intended clients are
> simple clients? (Note: I am talking about the case where
> SignedData is used. Let the AuthenticatedData case be
> temporary out of the scope of our discussion.)
> However, in your last mail, you tell us that "for simple clients, the
> trust mechanism cannot rely on any form of certificate
> validation...". I do not understand if the SCVP server certificate is 
> no use in the case where all the intended clients are simple clients,
> why does the SCVP server still need to have a server certificate?
> Why not let th SCVP server directly distribute its own public-key
> to all its clients via an out-of-band trusted channel?
> 
> It does not make sense to me if you require the SCVP server to
> apply a server certificate from a CA but tell the client that it does
> not to validate the server certificate and does not need to check
> whether the server certificate is revoked by its issuer.
> 
> Wen-Cheng 
> 
> 
> Trevor Freeman wrote:
> > Hi Wen,
> > I would not make that strict interpretation. In all non error cases
> the
> > SCVP is signed. The signature is either a signed data signature using
> a
> > 3280 cert or authenticated data MAC which may contain a 3280 cert.  I
> do
> > not see you mode 1 or 2 as fitting at description. Mode 3 is closer
> > except the simple client simply needs a key hash and to be able to
> parse
> > the cert to find the public key and do a comparison. The intent of the
> > MAC is to allow client the simplest of validations modes possible. 
> > Trevor
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On Behalf Of Wen-Cheng Wang
> > Sent: Friday, September 12, 2003 7:35 PM
> > To: Trevor Freeman
> > Cc: [e-mail]
> > Subject: RE: How a SCVP client authenticates the SCVP server?
> > Hi, Trevor,
> > It seems that you are trying to tell us:
> > 1. For simple clients, they must authenticate the SCVP server
> >    in the fashion of either mode 1 or mode 2 I metntioned.
> > 2. For SCVP servers who act as a SCVP client (a SCVP relay),
> >    they can authenticate the SCVP server in the fashion of mode 3
> >    I mentioned.
> > Is my interpretation correct?
> > If so, don't you think the text of the current SCVP ID need to be
> > changed to support mode 1?
> > Best Reagrds,
> > Wen-Cheng
> > Trevor Freeman wrote:
> > > Hi Wen-Cheng,
> > > First off consider there are two classes of SCVP clients. 
> > > * Simple clients who only originate SCVP request and 
> > > * SCVP servers who can both service requests and originate their own
> > > requests to other SCVP servers(relay).
> > > The validation requirements are quite different between the two. For
> > > simple clients the trust mechanism cannot rely on any form of
> > > certificate validation, but will be achieved by out-of-band
> > > configuration of the SCVP server's public signing\authentication key
> > or
> > > a symmetric shared key. For SCVP server making request of other SCVP
> > > servers, then chain validation is legitimate option since the
> > discovery
> > > and use model is quite different as are the constraints - or
> relative
> > > lack of them- on the servers capabilities. Beyond having
> certificates
> > > conformant to 3280 and having a specific key purpose, I don't think
> we
> > > need to be more prescriptive.
> > > Trevor
> > > -----Original Message-----
> > > From: [e-mail]
> > [mailto:[e-mail]]
> > > On Behalf Of Wen-Cheng Wang
> > > Sent: Friday, September 12, 2003 5:00 AM
> > > To: [e-mail]
> > > Subject: How a SCVP client authenticates the SCVP server?
> > > Folks,
> > > After the past [SCVP-AIA] discussions and reviewing
> > > the current SCVP ID, I feel that it seems to be
> > > unclear that how a SCVP client validates the
> > > signature on the SCVP response signed by the SCVP
> > > server. Since this topic is not directly related to
> > > SCVP-AIA, I would like to discuss it in another thread
> > > and hope to get some feedbacks from this WG. Especailly,
> > > I hope the editors of SCVP ID can tell us what is
> > > in their mind when designing the protocol and the
> > > message format.
> > > When asked how a SCVP client validates the signature
> > > on the SCVP response, I believe that the most intuitive
> > > answer will be "Use the public-key of the SCVP server
> > > to verify the signature." However, the truth is that
> > > things might not be as simple as they are looked like.
> > > Before a SCVP client using the public-key of the SCVP
> > > server, the client MUST make sure the public-key is
> > > trustworthy. The question how can the client trust the
> > > public-key of the SCVP server? During the [SCVP-AIA]
> > > discussions, at least three possibilities are mentioned:
> > > 1. The SCVP server first delivered its own public-key to SCVP
> > >    clients via an out-of-band trusted channel. A SCVP client
> > >    must securely stored the public-key of the SCVP server in its
> > >    local environment in advance and then it can use the public-key
> > >    to verify the signature of the SCVP server.
> > > In this mode, the SCVP server need not to have its own
> > > certificate and of course does not need to include its own
> > > certificate in the certificates field within the signed SCVP
> > > response (i.e., a CMS SignedData). (Note: the current SCVP ID
> > > does not allow this mode because it says "The SCVP server MUST
> > > include its own certificate in the certificates field within
> > > SignedData" in its section 4.
> > > Note that, in this mode, the public-key of the SCVP server
> > > must be delivered to SCVP clients via an out-of-band
> > > trusted channel. (Similar to the way to deliver root key to
> > > relying parties.)
> > > There is one issue need to be discussed for this mode. Since
> > > the SCVP server does not have its own certificate, how can it
> > > identify itself in the signed SCVP response? Because the signed
> > > response is actually a CMS SignedData, the SCVP server must
> > > try to identify itself by using a SignerIdentifier structure,
> > > which is
> > >   SignerIdentifier ::= CHOICE {
> > >           issuerAndSerialNumber IssuerAndSerialNumber,
> > >           subjectKeyIdentifier [0] SubjectKeyIdentifier }
> > > IMO, the SubjectKeyIdentifier field might be the only choice
> > > since IssuerAndSerialNumber makes no sense in this case. The
> > > problem is there is currently no unique way for generating
> > > Key Identifier. For example, if the server side calculates
> > > its own key identifier as 160-bit SHA-1 hash value of its
> > > public-key while the client side uses 0100 + the least
> > > significant 60 bits of the SHA-1 hash value, there will be
> > > an interoperability problem.
> > > Therefore, if the SCVP is going to support this mode, the protocol
> > > might need to define an unique way for generating key identifier.
> > > (At least, within the scope of SCVP.)
> > > 2. The SCVP server first signed itw own certificate (i.e., a
> > >    self-signed certificate) and delivered the self-signed
> certificate
> > >    to SCVP clients via an out-of-band trusted channel. A SCVP client
> > >    must securely stored the self-signed certificate of the SCVP
> server
> > >    in its local environment in advance and it can use the public-key
> > >    in the self-signed certificate of the SCVP server to verify
> > >    the signature of the SCVP server.
> > > Note that, as the same reason why a self-signed certificate of a
> > > root CA must be deliverd to relying parties via an out-of-band
> > > trusted channel, the self-signed certificate of the SCVP server
> > > must be delivered to SCVP clients via an out-of-band trusted
> > > channel. Also, a SCVP client must securely stores the self-signed
> > > certificate of the SCVP server in its local environment and then
> > > use the public-key within the certificate to verify the signature
> > > of the SCVP server.
> > > My opinion is mode 2 is actually equal to mode 1 except that
> > > the OCSP server can now identify itself by using either
> > > IssuerAndSerialNumber field or SubjectKeyIdentifier field
> > > in a SignerIdentifier structure and it burdens the SCVP server
> > > with the overhead of creating its own self-signed certificate.
> > > Personally, I am not in favor of mode 2 because I believe that
> > > a SCVP server is simply an EE from the viewpoint of the PKI and
> > > I doubt whether a self-signed EE certificate is a legal X.509
> > > certificate and I also doubt whether PKIX should encourge an EE
> > > to create its own self-signed certificate.
> > > 3. The SCVP server certificate should be signed by a CA. The SCVP
> > >    server can then include its own certificate in the signed SCVP
> > >    response. After receiving the signed response, a SCVP client
> > >    must validate the SCVP server certificate first to determine
> > >    whether it is a trusted SCVP server. And then the SCVP client
> > >    can use the public-key in the SCVP server certificate to verify
> > >    the signature of the SCVP server.
> > >    
> > > It seems that the procedure describe in mode 3 is very reasonable
> > > and straightforward. Believe me, it is not that simple. Please
> > > note that a SCVP client must validate the SCVP server certificate
> > > first after receiving the signed response and before can use the
> > > public-key in the SCVP server certificate to verify the signature
> > > of the SCVP server. That is sort of similar to ask an OCSP
> > > client to check the status of the OCSP server certificate before
> > > it can use the public-key in that certificate to verify the
> > > signature of the OCSP server. It is a chicken-and-egg problem.
> > > Let's think about why a RP (a certificate-using application) wants
> > > to delegate the job of certification path construction/validation
> > > to a SCVP Server. I believe that one possibile reason is the
> > > implementator of the certificate-using application is not capable
> > > of implementing the complex certification path
> > > construction/validation algorithm and therefore decide to delegate
> > > that job to a SCVP server because he/she heard of the SCVP is the
> > > savior of the certificate-using application implementator.
> > > Unfortunately, the application implementator will eventually find
> > > that he/she still need to implementing the complex certification
> > > path construction/validation algorithm because the SCVP client
> > > side must validate the SCVP server certificate first and that
> > > might invloves constructing a certification path from the SCVP
> > > server certificate to the RP's trust anchor and the validating
> > > the certification path. Therefore, I do not know how mode 3 works
> > > if every certificate-using application does not have its own
> > > certification path construction/validation module. Ironically, isn't
> > > the original idea of SCVP is to eliminate application
> implementators'
> > > burden for implementing the complex certification path
> > > construction/validation.
> > > I believe that mode 3 is what in the SCVP ID editors' minds when
> > > they design the protocol. Unfortunately, the current SCVP ID does
> > > not tell us how a SCVP client can authenticate the SCVP server.
> > > At least, the following issues should be discussed.
> > > 1. Who should sign the SCVP server certificate?
> > > 2. What is the format of the SCVP server certificate?
> > >    (Is there any special requirements for the format of
> > >     the SCVP server certificate? or is it just a normal EE
> > >     signing certificate?)
> > > 3. How a SCVP client can validate the SCVP server certificate
> > >    without its own certification path construction/validation
> > >    module?
> > > Can anyone clarify these issues?
> > > Best Regards,
> > > Wen-Cheng Wang
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8F7lWeo007282 for <[e-mail]>; Mon, 15 Sep 2003 00:47:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8F7lWgp007281 for ietf-pkix-bks; Mon, 15 Sep 2003 00:47:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8F7lUeo007262 for <[e-mail]>; Mon, 15 Sep 2003 00:47:31 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA54710; Mon, 15 Sep 2003 09:53:01 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA30374; Mon, 15 Sep 2003 09:48:36 +0200
Message-ID: <[e-mail]>
Date: Mon, 15 Sep 2003 09:47:26 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: How a SCVP client authenticates the SCVP server?
References: <007401c3794c$b4305e50$[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>

Santosh,

> Well put.

> I always assumed that option 3 is not viable for the reasons cited.

> I always assumed that if the client relies on SCVP for path validation, it
> will have one or more SCVP servers as it trust anchor(s) as opposed to
> having Certification Authority(s) as its trust anchor(s).

As you know, ISO is currently attempting to provide a definition for what is 
a trust anchor in a PDAM. Although not finally approved, it is along the 
following lines:

"trust anchor: The public key of a CA that is trusted by a certificate using 
system and used as the starting trusted public key for validating signatures 
on certificates and/or CRLs in a certificate chain."

Since the definition clearly mentions a CA, the wording "SCVP servers as it 
trust anchor(s)" is not appropriate. Since an SCVP server is not a CA, its 
public key cannot be considered to be a "trust anchor".

Call it "directly trusted key", if you wish, but do not use the wording 
"trust anchor".

Denis.



> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 8:00 AM
> To: [e-mail]
> Subject: How a SCVP client authenticates the SCVP server?
> 
> 
> 
> Folks,
> 
> After the past [SCVP-AIA] discussions and reviewing
> the current SCVP ID, I feel that it seems to be
> unclear that how a SCVP client validates the
> signature on the SCVP response signed by the SCVP
> server. Since this topic is not directly related to
> SCVP-AIA, I would like to discuss it in another thread
> and hope to get some feedbacks from this WG. Especailly,
> I hope the editors of SCVP ID can tell us what is
> in their mind when designing the protocol and the
> message format.
> 
> When asked how a SCVP client validates the signature
> on the SCVP response, I believe that the most intuitive
> answer will be "Use the public-key of the SCVP server
> to verify the signature." However, the truth is that
> things might not be as simple as they are looked like.
> Before a SCVP client using the public-key of the SCVP
> server, the client MUST make sure the public-key is trustworthy. The
> question how can the client trust the public-key of the SCVP server? During
> the [SCVP-AIA] discussions, at least three possibilities are mentioned:
> 
> 1. The SCVP server first delivered its own public-key to SCVP
>    clients via an out-of-band trusted channel. A SCVP client
>    must securely stored the public-key of the SCVP server in its
>    local environment in advance and then it can use the public-key
>    to verify the signature of the SCVP server.
> 
> In this mode, the SCVP server need not to have its own certificate and of
> course does not need to include its own certificate in the certificates
> field within the signed SCVP response (i.e., a CMS SignedData). (Note: the
> current SCVP ID does not allow this mode because it says "The SCVP server
> MUST include its own certificate in the certificates field within
> SignedData" in its section 4.
> 
> Note that, in this mode, the public-key of the SCVP server
> must be delivered to SCVP clients via an out-of-band
> trusted channel. (Similar to the way to deliver root key to relying
> parties.)
> 
> There is one issue need to be discussed for this mode. Since the SCVP server
> does not have its own certificate, how can it identify itself in the signed
> SCVP response? Because the signed response is actually a CMS SignedData, the
> SCVP server must try to identify itself by using a SignerIdentifier
> structure, which is
> 
>   SignerIdentifier ::= CHOICE {
>           issuerAndSerialNumber IssuerAndSerialNumber,
>           subjectKeyIdentifier [0] SubjectKeyIdentifier }
> 
> IMO, the SubjectKeyIdentifier field might be the only choice since
> IssuerAndSerialNumber makes no sense in this case. The problem is there is
> currently no unique way for generating Key Identifier. For example, if the
> server side calculates its own key identifier as 160-bit SHA-1 hash value of
> its public-key while the client side uses 0100 + the least significant 60
> bits of the SHA-1 hash value, there will be an interoperability problem.
> 
> Therefore, if the SCVP is going to support this mode, the protocol might
> need to define an unique way for generating key identifier. (At least,
> within the scope of SCVP.)
> 
> 2. The SCVP server first signed itw own certificate (i.e., a
>    self-signed certificate) and delivered the self-signed certificate
>    to SCVP clients via an out-of-band trusted channel. A SCVP client
>    must securely stored the self-signed certificate of the SCVP server
>    in its local environment in advance and it can use the public-key
>    in the self-signed certificate of the SCVP server to verify
>    the signature of the SCVP server.
> 
> Note that, as the same reason why a self-signed certificate of a root CA
> must be deliverd to relying parties via an out-of-band trusted channel, the
> self-signed certificate of the SCVP server must be delivered to SCVP clients
> via an out-of-band trusted channel. Also, a SCVP client must securely stores
> the self-signed certificate of the SCVP server in its local environment and
> then use the public-key within the certificate to verify the signature of
> the SCVP server.
> 
> My opinion is mode 2 is actually equal to mode 1 except that the OCSP server
> can now identify itself by using either IssuerAndSerialNumber field or
> SubjectKeyIdentifier field in a SignerIdentifier structure and it burdens
> the SCVP server with the overhead of creating its own self-signed
> certificate.
> 
> Personally, I am not in favor of mode 2 because I believe that a SCVP server
> is simply an EE from the viewpoint of the PKI and I doubt whether a
> self-signed EE certificate is a legal X.509 certificate and I also doubt
> whether PKIX should encourge an EE to create its own self-signed
> certificate.
> 
> 3. The SCVP server certificate should be signed by a CA. The SCVP
>    server can then include its own certificate in the signed SCVP
>    response. After receiving the signed response, a SCVP client
>    must validate the SCVP server certificate first to determine
>    whether it is a trusted SCVP server. And then the SCVP client
>    can use the public-key in the SCVP server certificate to verify
>    the signature of the SCVP server.
>    
> It seems that the procedure describe in mode 3 is very reasonable and
> straightforward. Believe me, it is not that simple. Please note that a SCVP
> client must validate the SCVP server certificate first after receiving the
> signed response and before can use the public-key in the SCVP server
> certificate to verify the signature of the SCVP server. That is sort of
> similar to ask an OCSP client to check the status of the OCSP server
> certificate before it can use the public-key in that certificate to verify
> the signature of the OCSP server. It is a chicken-and-egg problem.
> 
> Let's think about why a RP (a certificate-using application) wants to
> delegate the job of certification path construction/validation to a SCVP
> Server. I believe that one possibile reason is the implementator of the
> certificate-using application is not capable of implementing the complex
> certification path construction/validation algorithm and therefore decide to
> delegate that job to a SCVP server because he/she heard of the SCVP is the
> savior of the certificate-using application implementator. Unfortunately,
> the application implementator will eventually find that he/she still need to
> implementing the complex certification path construction/validation
> algorithm because the SCVP client side must validate the SCVP server
> certificate first and that might invloves constructing a certification path
> from the SCVP server certificate to the RP's trust anchor and the validating
> the certification path. Therefore, I do not know how mode 3 works if every
> certificate-using application does not have its own certification path
> construction/validation module. Ironically, isn't the original idea of SCVP
> is to eliminate application implementators' burden for implementing the
> complex certification path construction/validation.
> 
> I believe that mode 3 is what in the SCVP ID editors' minds when they design
> the protocol. Unfortunately, the current SCVP ID does not tell us how a SCVP
> client can authenticate the SCVP server. At least, the following issues
> should be discussed.
> 
> 1. Who should sign the SCVP server certificate?
> 2. What is the format of the SCVP server certificate?
>    (Is there any special requirements for the format of
>     the SCVP server certificate? or is it just a normal EE
>     signing certificate?)
> 3. How a SCVP client can validate the SCVP server certificate
>    without its own certification path construction/validation
>    module?
> 
> Can anyone clarify these issues?
> 
> Best Regards,
> Wen-Cheng Wang
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8F7Neeo099793 for <[e-mail]>; Mon, 15 Sep 2003 00:23:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8F7NehZ099792 for ietf-pkix-bks; Mon, 15 Sep 2003 00:23:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8F7NZeo099737 for <[e-mail]>; Mon, 15 Sep 2003 00:23:36 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA60636; Mon, 15 Sep 2003 09:28:59 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA30222; Mon, 15 Sep 2003 09:24:33 +0200
Message-ID: <[e-mail]>
Date: Mon, 15 Sep 2003 09:23:23 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: How a SCVP client authenticates the SCVP server?
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>

Trevor,

> Hi Wen-Cheng,

> First off consider there are two classes of SCVP clients. 
> * Simple clients who only originate SCVP request and 
> * SCVP servers who can both service requests and originate their own
> requests to other SCVP servers(relay).

There is a third class, as well :

   * Normal clients (as opposed to simple clients) which can directly query 
different SCVP servers, e.g. because they support different validation 
policies and which are using trust anchors and some local conditions. The 
advantage is that the keys of the SCVP servers may easily be changed, 
without the need for a local re-configuration. The local configuration is 
close to the SCVP server class.

IF the SCVP server has no certificate, THEN it can only be accessed by 
simple clients.

IF the SCVP server has a certificate, THEN it can always be accessed: by 
simple clients, normal clients and SCVP servers.

Thus I see advantages to always include the SCVP certificate, even if simple 
clients are free to ignore it when validating the response.

Denis


> The validation requirements are quite different between the two. For
> simple clients the trust mechanism cannot rely on any form of
> certificate validation, but will be achieved by out-of-band
> configuration of the SCVP server's public signing\authentication key or
> a symmetric shared key. For SCVP server making request of other SCVP
> servers, then chain validation is legitimate option since the discovery
> and use model is quite different as are the constraints - or relative
> lack of them- on the servers capabilities. Beyond having certificates
> conformant to 3280 and having a specific key purpose, I don't think we
> need to be more prescriptive.
> 
> Trevor
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 5:00 AM
> To: [e-mail]
> Subject: How a SCVP client authenticates the SCVP server?
> 
> 
> Folks,
> 
> After the past [SCVP-AIA] discussions and reviewing
> the current SCVP ID, I feel that it seems to be
> unclear that how a SCVP client validates the
> signature on the SCVP response signed by the SCVP
> server. Since this topic is not directly related to
> SCVP-AIA, I would like to discuss it in another thread
> and hope to get some feedbacks from this WG. Especailly,
> I hope the editors of SCVP ID can tell us what is
> in their mind when designing the protocol and the
> message format.
> 
> When asked how a SCVP client validates the signature
> on the SCVP response, I believe that the most intuitive
> answer will be "Use the public-key of the SCVP server
> to verify the signature." However, the truth is that
> things might not be as simple as they are looked like.
> Before a SCVP client using the public-key of the SCVP
> server, the client MUST make sure the public-key is
> trustworthy. The question how can the client trust the
> public-key of the SCVP server? During the [SCVP-AIA]
> discussions, at least three possibilities are mentioned:
> 
> 1. The SCVP server first delivered its own public-key to SCVP
>    clients via an out-of-band trusted channel. A SCVP client
>    must securely stored the public-key of the SCVP server in its
>    local environment in advance and then it can use the public-key
>    to verify the signature of the SCVP server.
> 
> In this mode, the SCVP server need not to have its own
> certificate and of course does not need to include its own
> certificate in the certificates field within the signed SCVP
> response (i.e., a CMS SignedData). (Note: the current SCVP ID
> does not allow this mode because it says "The SCVP server MUST
> include its own certificate in the certificates field within
> SignedData" in its section 4.
> 
> Note that, in this mode, the public-key of the SCVP server
> must be delivered to SCVP clients via an out-of-band
> trusted channel. (Similar to the way to deliver root key to
> relying parties.)
> 
> There is one issue need to be discussed for this mode. Since
> the SCVP server does not have its own certificate, how can it
> identify itself in the signed SCVP response? Because the signed
> response is actually a CMS SignedData, the SCVP server must
> try to identify itself by using a SignerIdentifier structure,
> which is
> 
>   SignerIdentifier ::= CHOICE {
>           issuerAndSerialNumber IssuerAndSerialNumber,
>           subjectKeyIdentifier [0] SubjectKeyIdentifier }
> 
> IMO, the SubjectKeyIdentifier field might be the only choice
> since IssuerAndSerialNumber makes no sense in this case. The
> problem is there is currently no unique way for generating
> Key Identifier. For example, if the server side calculates
> its own key identifier as 160-bit SHA-1 hash value of its
> public-key while the client side uses 0100 + the least
> significant 60 bits of the SHA-1 hash value, there will be
> an interoperability problem.
> 
> Therefore, if the SCVP is going to support this mode, the protocol
> might need to define an unique way for generating key identifier.
> (At least, within the scope of SCVP.)
> 
> 2. The SCVP server first signed itw own certificate (i.e., a
>    self-signed certificate) and delivered the self-signed certificate
>    to SCVP clients via an out-of-band trusted channel. A SCVP client
>    must securely stored the self-signed certificate of the SCVP server
>    in its local environment in advance and it can use the public-key
>    in the self-signed certificate of the SCVP server to verify
>    the signature of the SCVP server.
> 
> Note that, as the same reason why a self-signed certificate of a
> root CA must be deliverd to relying parties via an out-of-band
> trusted channel, the self-signed certificate of the SCVP server
> must be delivered to SCVP clients via an out-of-band trusted
> channel. Also, a SCVP client must securely stores the self-signed
> certificate of the SCVP server in its local environment and then
> use the public-key within the certificate to verify the signature
> of the SCVP server.
> 
> My opinion is mode 2 is actually equal to mode 1 except that
> the OCSP server can now identify itself by using either
> IssuerAndSerialNumber field or SubjectKeyIdentifier field
> in a SignerIdentifier structure and it burdens the SCVP server
> with the overhead of creating its own self-signed certificate.
> 
> Personally, I am not in favor of mode 2 because I believe that
> a SCVP server is simply an EE from the viewpoint of the PKI and
> I doubt whether a self-signed EE certificate is a legal X.509
> certificate and I also doubt whether PKIX should encourge an EE
> to create its own self-signed certificate.
> 
> 3. The SCVP server certificate should be signed by a CA. The SCVP
>    server can then include its own certificate in the signed SCVP
>    response. After receiving the signed response, a SCVP client
>    must validate the SCVP server certificate first to determine
>    whether it is a trusted SCVP server. And then the SCVP client
>    can use the public-key in the SCVP server certificate to verify
>    the signature of the SCVP server.
>    
> It seems that the procedure describe in mode 3 is very reasonable
> and straightforward. Believe me, it is not that simple. Please
> note that a SCVP client must validate the SCVP server certificate
> first after receiving the signed response and before can use the
> public-key in the SCVP server certificate to verify the signature
> of the SCVP server. That is sort of similar to ask an OCSP
> client to check the status of the OCSP server certificate before
> it can use the public-key in that certificate to verify the
> signature of the OCSP server. It is a chicken-and-egg problem.
> 
> Let's think about why a RP (a certificate-using application) wants
> to delegate the job of certification path construction/validation
> to a SCVP Server. I believe that one possibile reason is the
> implementator of the certificate-using application is not capable
> of implementing the complex certification path
> construction/validation algorithm and therefore decide to delegate
> that job to a SCVP server because he/she heard of the SCVP is the
> savior of the certificate-using application implementator.
> Unfortunately, the application implementator will eventually find
> that he/she still need to implementing the complex certification
> path construction/validation algorithm because the SCVP client
> side must validate the SCVP server certificate first and that
> might invloves constructing a certification path from the SCVP
> server certificate to the RP's trust anchor and the validating
> the certification path. Therefore, I do not know how mode 3 works
> if every certificate-using application does not have its own
> certification path construction/validation module. Ironically, isn't
> the original idea of SCVP is to eliminate application implementators'
> burden for implementing the complex certification path
> construction/validation.
> 
> I believe that mode 3 is what in the SCVP ID editors' minds when
> they design the protocol. Unfortunately, the current SCVP ID does
> not tell us how a SCVP client can authenticate the SCVP server.
> At least, the following issues should be discussed.
> 
> 1. Who should sign the SCVP server certificate?
> 2. What is the format of the SCVP server certificate?
>    (Is there any special requirements for the format of
>     the SCVP server certificate? or is it just a normal EE
>     signing certificate?)
> 3. How a SCVP client can validate the SCVP server certificate
>    without its own certification path construction/validation
>    module?
> 
> Can anyone clarify these issues?
> 
> Best Regards,
> Wen-Cheng Wang
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8F4Xgeo056099 for <[e-mail]>; Sun, 14 Sep 2003 21:33:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8F4Xgd7056098 for ietf-pkix-bks; Sun, 14 Sep 2003 21:33:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8F4Xfeo056090 for <[e-mail]>; Sun, 14 Sep 2003 21:33:41 -0700 (PDT) (envelope-from [e-mail])
Received: from mail5.microsoft.com ([157.54.6.156]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 14 Sep 2003 21:33:37 -0700
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Sun, 14 Sep 2003 21:33:42 -0700
Received: from 157.54.6.150 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 14 Sep 2003 21:33:38 -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(6.0.3790.0); Sun, 14 Sep 2003 21:33:44 -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(6.0.3790.0); Sun, 14 Sep 2003 21:33:41 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Sun, 14 Sep 2003 21:33:37 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.6944
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <000001c37b16$be0b1480$4228a8c0@hagen>
References: <DDB24CCE-A58B-479F-BDEF-92F1F1045FFC@mimectl>, <000001c37b16$be0b1480$4228a8c0@hagen>
To: Florian Oelmaier <[e-mail]>
Cc: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN7QonXwBbn/pCYQvmf345g5Pt4bg==
Message-ID: <2F65A0D4-4CCA-488C-BB08-17043415ABCB@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
Date: Sun, 14 Sep 2003 21:33:40 -0700
X-OriginalArrivalTime: 15 Sep 2003 04:33:37.0363 (UTC) FILETIME=[87D7CA30:01C37B42]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_6DF4ED85-8E8C-49D0-924C-C381A9D86430_"

--_6DF4ED85-8E8C-49D0-924C-C381A9D86430_
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Florian - I think there are two scenarios nonce's provide value in OCSP:

1. The server has a chance at knowing the request is unique.
2. The client can know the response he has been given was generated specifi=
cally for him.

#1 has the potential of adding some level of security on the server side (a=
suming several implementation details arround tracking the nonces) but sinc=
e getting at the nonce still requires a decode, and likley a signature veri=
fy so the benefit is likley to be limited policy control and audit only.

#2 on the other hand is what I think the intention of the nonce in OCSP was=
 intended for, specifically this is a way that a client can ensure he has a=
 response that was generated just for him. This is particularly important i=
n high value transation systems based on OCSP for work flow, these same sys=
tems also tend to require signed requests for the same fundematal reasons.

The scenario you outline bellow sounds like you are trying to protect the c=
lient from replay attacks by including the nonce, this however does not mak=
e sense since the client would just see a nonsensical 16byte value it would=
 have nothing to compare to to ensure it is unique; the best it could do wo=
uld be to see if it was one it had seen before but that would likley be acc=
omplished through other means such as a hash of the response for quick inde=
xing without the cost of a decode.=20

I beleive the protection from this threat is to have the client require uni=
que, dynamically generated responses.

Ryan

=20



From: Florian Oelmaier
Sent: Sun 9/14/2003 4:20 PM
To: 'Ryan M. Hurst'
Cc: 'Peter Gutmann'; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?


Ryan M.Hurst wrote:
"On a side note, I don't think your buying yourself any security if you
server is generating a nonce if the request didn't contain one. After
all the idea of the nonce is to cryptographically bind a unique request
to a unique response and since the client doesn't have anything to
compare the nonce to I think you hurt your servers performance without
adding any  value."

Let us assume a responder produces responses with nonce only when the
request contains one. Thus it is easy for an attacker to obtain a valid
response of the responder without nonce (he only needs to send a request
without one). The attacker now replays this response to another client
using a nonce in his request.=20

What does this other client see?
He sends a request with a nonce. The responder does not answer with a
nonce. According to the RfC, nonces are optional. Maybe the responder is
not capable of producing nonces. So it depends on the client - I saw
clients out there accepting the response, I also saw clients not
accepting it.=20

Conclusion:
If the responder wants to protect itself against replay attacks, it
should include a nonce into every response it ever constructs. This way,
an attacker can never replay one of its responses to a client using
nonce (because the nonces would most probably mismatch).

About performance:
If the server does not preproduce responses, the nonce generation (16
random bytes) does not have any performance hit. I agree with you, when
preproducing responses, including a nonce does not make sense. From my
point of view, one could go without nonce in closed environments where
time synchronization is not an issue (meaning time is secure and
correct).

--=20
Florian Oelmaier
SyTrust

--_6DF4ED85-8E8C-49D0-924C-C381A9D86430_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText39827 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Florian - I thin=
k there are&nbsp;two scenarios nonce's provide value in OCSP:</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>1. The server has a chance at kn=
owing the request is unique.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>2. The client can know the respo=
nse he has been given was generated specifically for him.</FONT></DIV></DIV=
>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>#1 has the potential of adding some level of security on the=
 server side (asuming several implementation details arround tracking the n=
onces) but since getting at the nonce still requires a decode, and likley a=
 signature verify so the benefit is likley to be limited policy control and=
 audit only.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>#2 on the other hand is what I think the intention of the no=
nce in OCSP was intended for, specifically this is a way that a client can =
ensure he has a response that was generated just for him. This is particula=
rly important in high value transation systems based on OCSP for work flow,=
 these same systems also tend to require signed requests for the same funde=
matal reasons.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>The scenario you outline bellow sounds like you are trying t=
o protect the client from replay attacks by including the nonce, this howev=
er does not make sense since the client would just see a nonsensical 16byte=
 value it would have nothing to compare to to ensure it is unique; the best=
 it could do would be to see if it was one it had seen before but that woul=
d likley be accomplished through other means such as a hash of the response=
 for quick indexing without the cost of a decode. </DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>I beleive the protection from this threat is to have the cli=
ent require unique, dynamically generated responses.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>Ryan</DIV>
<DIV dir=3Dltr><BR>&nbsp;</DIV>
<DIV dir=3Dltr>
<HR tabIndex=3D-1>
</DIV>
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Florian Oelmaier<B=
R><B>Sent:</B> Sun 9/14/2003 4:20 PM<BR><B>To:</B> 'Ryan M. Hurst'<BR><B>Cc=
:</B> 'Peter Gutmann'; [e-mail]; [e-mail]<BR><B>Subject:</B> R=
E: [OCSP] are several requests for different CAs at once valid ?<BR></FONT>=
<BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">Ryan M.Hurst wrote:
"On a side note, I don't think your buying yourself any security if you
server is generating a nonce if the request didn't contain one. After
all the idea of the nonce is to cryptographically bind a unique request
to a unique response and since the client doesn't have anything to
compare the nonce to I think you hurt your servers performance without
adding any  value."

Let us assume a responder produces responses with nonce only when the
request contains one. Thus it is easy for an attacker to obtain a valid
response of the responder without nonce (he only needs to send a request
without one). The attacker now replays this response to another client
using a nonce in his request.=20

What does this other client see?
He sends a request with a nonce. The responder does not answer with a
nonce. According to the RfC, nonces are optional. Maybe the responder is
not capable of producing nonces. So it depends on the client - I saw
clients out there accepting the response, I also saw clients not
accepting it.=20

Conclusion:
If the responder wants to protect itself against replay attacks, it
should include a nonce into every response it ever constructs. This way,
an attacker can never replay one of its responses to a client using
nonce (because the nonces would most probably mismatch).

About performance:
If the server does not preproduce responses, the nonce generation (16
random bytes) does not have any performance hit. I agree with you, when
preproducing responses, including a nonce does not make sense. From my
point of view, one could go without nonce in closed environments where
time synchronization is not an issue (meaning time is secure and
correct).

--=20
Florian Oelmaier
SyTrust

</PRE></DIV></BODY></HTML>

--_6DF4ED85-8E8C-49D0-924C-C381A9D86430_--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8F16Geo049103 for <[e-mail]>; Sun, 14 Sep 2003 18:06:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8F16Geg049102 for ietf-pkix-bks; Sun, 14 Sep 2003 18:06:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8F16Eeo049097 for <[e-mail]>; Sun, 14 Sep 2003 18:06:14 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd02.aul.t-online.de  by mailout05.sul.t-online.com with smtp  id 19yhoh-0002Cg-00; Mon, 15 Sep 2003 03:06:11 +0200
Received: from hagen (Vm-F82ZE8eDsQVaiYSoEAX41PHqR+FX1SHVY5YUwb25yqtyzretEko@[80.128.83.54]) by fmrl02.sul.t-online.com with esmtp id 19yhoe-2GQlYO0; Mon, 15 Sep 2003 03:06:08 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 03:06:09 +0200
Organization: SyTrust
Message-ID: <000001c37b25$8cf94a60$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01C37B36.5083A100"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C37B36.5083A100
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Ambarish,
 
that depends on the client handling the nonce (see my message to Ryan).
I know you proposed some changes to the RfC to solve these problems back
in January 2002
(http://www.imc.org/ietf-pkix/mail-archive/msg02983.html) - yet I cant
find your changes in the RfC at http://www.ietf.org/rfc/rfc2560.txt. So
currently the published RfC does not instruct a client what to do when
the requests contained a nonce but the response didnt. For me that means
we can expect all kinds of behaviour out there.
 
Best regards,
Florian

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Monday, September 15, 2003 1:58 AM
To: Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann';
[e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?


 
Hi Florian,
    Including a nonce in the response where there isn't one in the
request
doesn't buy you any additional security (unless the nonce has some
different
semantics in your environment and isn't just a nonce).
 
Regards,
Ambarish

-----Original Message-----
From: [e-mail]
[mailto:[e-mail]]On Behalf Of Florian Oelmaier
Sent: Sunday, September 14, 2003 3:14 PM
To: 'Ryan M. Hurst'; 'Peter Gutmann'; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?


Hello Ryan,
 
please note: although you are not sending a nonce, some OCSP-Responders
will answer with one. To allow an responder to use nonce for replay
attack protection, it must include the nonce into ALL his responses -
otherwise this particular response could be used in a replay. On a
sidenote: the inclusion of a nonce would surely benefit the security -
perhaps you can make it a configuration setting?
 
-- 
Florian Oelmaier
SyTrust
 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ryan M. Hurst
Sent: Sunday, September 14, 2003 8:55 PM
To: Peter Gutmann; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?



Peter - I really don't think what we are doing is breaking OCSP's
security, after all nonce is a optional value in 2560 and the standard
already specifically supports response pre-production:
 
     2.5  Response Pre-production

        OCSP responders MAY pre-produce signed responses specifying the
        status of certificates at a specified time. The time at which
the
        status was known to be correct SHALL be reflected in the
thisUpdate
        field of the response. The time at or before which newer
information
        will be available is reflected in the nextUpdate field, while
the
        time at which the response was produced will appear in the
producedAt
        field of the response.

And the only way to support this concept within OCSP would be to have
the described behavior in regards to nonce handling.
 
As for why OCSP was chosen over RTCS or a propietary solution, the goal
is to work with exiting public infrastrucutres and other third-party
solutions; given this OCSP was the obvious solution.
 
Ryan

  _____  

From: Peter Gutmann
Sent: Sun 9/14/2003 5:26 AM
To: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?


"Ryan M. Hurst" <[e-mail]> writes:



>Traditionally OCSP responders generate and sign responses on-demand

>(dynamically), this requires the responders to scale their
infrastructure to

>handle very high peak volumes. 



Hmm, biting back my immediate response (that breaking OCSP's security
doesn't

seem like a good way to try and get usable performance out of it), why
not use

a protocol like RTCS, which was designed from the outset to allow for
high-

performance, highly scalable implementations?  It's not called real-time
cert

status for nothing (there's one organisation using it for exactly that,
they

do a real-time verification of cert validity using live validity data
before

each and every use of the cert).



Peter.


------=_NextPart_000_0001_01C37B36.5083A100
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Nachricht</TITLE>

<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D665403500-15092003>Hello=20
Ambarish,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D665403500-15092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D665403500-15092003>that=20
depends on the client handling the nonce (see my message to Ryan). I =
know you=20
proposed some changes to the RfC to solve these problems back in January =
2002=20
(<A=20
href=3D"http://www.imc.org/ietf-pkix/mail-archive/msg02983.html">http://w=
ww.imc.org/ietf-pkix/mail-archive/msg02983.html</A>)&nbsp;-=20
yet I cant find your changes in the RfC at <A=20
href=3D"http://www.ietf.org/rfc/rfc2560.txt">http://www.ietf.org/rfc/rfc2=
560.txt</A>.=20
So currently the published RfC does not instruct a client what to do =
when the=20
requests contained a nonce but the response didnt.&nbsp;For me that =
means we can=20
expect all kinds of behaviour out there.</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D665403500-15092003></SPAN></FONT><FONT face=3DArial =
color=3D#0000ff=20
size=3D2><SPAN class=3D665403500-15092003></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN =
class=3D665403500-15092003>Best=20
regards,</SPAN></FONT></DIV>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
class=3D665403500-15092003>Florian</SPAN></FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr =
align=3Dleft><FONT face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ambarish Malpani=20
  [mailto:[e-mail]] <BR><B>Sent:</B> Monday, September 15, =
2003 1:58=20
  AM<BR><B>To:</B> Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann';=20
  [e-mail]; [e-mail]<BR><B>Subject:</B> RE: [OCSP] are =
several=20
  requests for different CAs at once valid ?<BR><BR></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
  <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff size=3D2>Hi=20
  Florian,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>&nbsp;&nbsp;&nbsp; Including a nonce in the response where =
there isn't=20
  one in the request</FONT></SPAN></DIV>
  <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>doesn't buy you any additional security (unless the nonce has =
some=20
  different</FONT></SPAN></DIV>
  <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>semantics in your environment and isn't just a=20
  nonce).</FONT></SPAN></DIV>
  <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Regards,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D002165623-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Ambarish</FONT></SPAN></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>-----Original Message-----<BR><B>From:</B>=20
    [e-mail] =
[mailto:[e-mail]]<B>On=20
    Behalf Of </B>Florian Oelmaier<BR><B>Sent:</B> Sunday, September 14, =
2003=20
    3:14 PM<BR><B>To:</B> 'Ryan M. Hurst'; 'Peter Gutmann'; =
[e-mail];=20
    [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests for=20
    different CAs at once valid ?<BR><BR></FONT></DIV>
    <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Hello Ryan,</FONT></SPAN></DIV>
    <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>please note: although you are not sending a =
nonce,&nbsp;some=20
    OCSP-Responders will answer with one. To allow an responder to use =
nonce=20
    for&nbsp;replay attack protection,&nbsp;it must include the nonce =
into ALL=20
    his responses - otherwise this particular response could be used in =
a=20
    replay. On a sidenote: the inclusion of a nonce would surely benefit =
the=20
    security - perhaps you can make it a configuration=20
    setting?</FONT></SPAN></DIV>
    <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff size=3D2>--=20
    </FONT></SPAN></DIV>
    <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>Florian Oelmaier</FONT></SPAN></DIV>
    <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2>SyTrust</FONT></SPAN></DIV>
    <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
    size=3D2></FONT></SPAN>&nbsp;</DIV>
    <DIV></DIV>
    <DIV><FONT face=3DTahoma size=3D2>-----Original =
Message-----<BR><B>From:</B>=20
    [e-mail] [mailto:[e-mail]] =
<B>On=20
    Behalf Of </B>Ryan M. Hurst<BR><B>Sent:</B> Sunday, September 14, =
2003 8:55=20
    PM<BR><B>To:</B> Peter Gutmann; [e-mail];=20
    [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests for=20
    different CAs at once valid ?<BR><BR></DIV></FONT>
    <BLOCKQUOTE dir=3Dltr=20
    style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff =
2px solid; MARGIN-RIGHT: 0px">
      <DIV id=3DidOWAReplyText27203 dir=3Dltr>
      <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Peter - =
I really don't=20
      think what we are doing is breaking OCSP's security, after all =
nonce is a=20
      optional value in 2560 and the standard already specifically =
supports=20
      response pre-production:</FONT></DIV>
      <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
      <DIV dir=3Dltr>&nbsp;&nbsp;&nbsp;&nbsp; 2.5&nbsp; Response=20
      Pre-production<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OCSP=20
      responders MAY pre-produce signed responses specifying=20
      the<BR>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; status of =
certificates at a=20
      specified time. The time at which=20
      the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; status was known =
to be=20
      correct SHALL be reflected in the=20
      thisUpdate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field of =
the=20
      response. The time at or before which newer=20
      information<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will be=20
      available is reflected in the nextUpdate field, while=20
      the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; time at which =
the=20
      response was produced will appear in the=20
      producedAt<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field of =
the=20
      response.<BR></DIV></DIV>
      <DIV dir=3Dltr>And the only way to support this concept within =
OCSP would be=20
      to have the described behavior in regards to nonce handling.</DIV>
      <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
      <DIV dir=3Dltr>As for why OCSP was chosen over RTCS or a =
propietary=20
      solution, the goal is to work with exiting public infrastrucutres =
and=20
      other third-party solutions; given this OCSP was the obvious=20
      solution.</DIV>
      <DIV dir=3Dltr>&nbsp;</DIV>
      <DIV dir=3Dltr>Ryan<BR></DIV>
      <DIV dir=3Dltr>
      <HR tabIndex=3D-1>
      </DIV>
      <DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Peter=20
      Gutmann<BR><B>Sent:</B> Sun 9/14/2003 5:26 AM<BR><B>To:</B>=20
      [e-mail]; [e-mail];=20
      [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests =
for=20
      different CAs at once valid ?<BR></FONT><BR></DIV>
      <DIV><PRE style=3D"WORD-WRAP: break-word">"Ryan M. Hurst" =
&lt;[e-mail]&gt; writes:

&gt;Traditionally OCSP responders generate and sign responses on-demand
&gt;(dynamically), this requires the responders to scale their =
infrastructure to
&gt;handle very high peak volumes.=20

Hmm, biting back my immediate response (that breaking OCSP's security =
doesn't
seem like a good way to try and get usable performance out of it), why =
not use
a protocol like RTCS, which was designed from the outset to allow for =
high-
performance, highly scalable implementations?  It's not called real-time =
cert
status for nothing (there's one organisation using it for exactly that, =
they
do a real-time verification of cert validity using live validity data =
before
each and every use of the cert).

Peter.
</PRE></DIV></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0001_01C37B36.5083A100--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ENsieo047102 for <[e-mail]>; Sun, 14 Sep 2003 16:54:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8ENsi3H047101 for ietf-pkix-bks; Sun, 14 Sep 2003 16:54:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ENsfeo047096 for <[e-mail]>; Sun, 14 Sep 2003 16:54:43 -0700 (PDT) (envelope-from [e-mail])
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.9/8.12.9) with SMTP id h8ENsYPo015572; Sun, 14 Sep 2003 16:54:35 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Sun, 14 Sep 2003 16:57:45 -0700
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01C37AE1.51D5EB30"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <000201c37b0d$7879b7e0$4228a8c0@hagen>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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_0002_01C37AE1.51D5EB30
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Nachricht
Hi Florian,
    Including a nonce in the response where there isn't one in the request
doesn't buy you any additional security (unless the nonce has some different
semantics in your environment and isn't just a nonce).

Regards,
Ambarish
  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]On
Behalf Of Florian Oelmaier
  Sent: Sunday, September 14, 2003 3:14 PM
  To: 'Ryan M. Hurst'; 'Peter Gutmann'; [e-mail]; [e-mail]
  Subject: RE: [OCSP] are several requests for different CAs at once valid ?


  Hello Ryan,

  please note: although you are not sending a nonce, some OCSP-Responders
will answer with one. To allow an responder to use nonce for replay attack
protection, it must include the nonce into ALL his responses - otherwise
this particular response could be used in a replay. On a sidenote: the
inclusion of a nonce would surely benefit the security - perhaps you can
make it a configuration setting?

  --
  Florian Oelmaier
  SyTrust

  -----Original Message-----
  From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ryan M. Hurst
  Sent: Sunday, September 14, 2003 8:55 PM
  To: Peter Gutmann; [e-mail]; [e-mail]
  Subject: RE: [OCSP] are several requests for different CAs at once valid ?


    Peter - I really don't think what we are doing is breaking OCSP's
security, after all nonce is a optional value in 2560 and the standard
already specifically supports response pre-production:

         2.5  Response Pre-production

            OCSP responders MAY pre-produce signed responses specifying the
            status of certificates at a specified time. The time at which
the
            status was known to be correct SHALL be reflected in the
thisUpdate
            field of the response. The time at or before which newer
information
            will be available is reflected in the nextUpdate field, while
the
            time at which the response was produced will appear in the
producedAt
            field of the response.

    And the only way to support this concept within OCSP would be to have
the described behavior in regards to nonce handling.

    As for why OCSP was chosen over RTCS or a propietary solution, the goal
is to work with exiting public infrastrucutres and other third-party
solutions; given this OCSP was the obvious solution.

    Ryan


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

    From: Peter Gutmann
    Sent: Sun 9/14/2003 5:26 AM
    To: [e-mail]; [e-mail]; [e-mail]
    Subject: RE: [OCSP] are several requests for different CAs at once valid
?


"Ryan M. Hurst" <[e-mail]> writes:

>Traditionally OCSP responders generate and sign responses on-demand
>(dynamically), this requires the responders to scale their infrastructure
to
>handle very high peak volumes.

Hmm, biting back my immediate response (that breaking OCSP's security
doesn't
seem like a good way to try and get usable performance out of it), why not
use
a protocol like RTCS, which was designed from the outset to allow for high-
performance, highly scalable implementations?  It's not called real-time
cert
status for nothing (there's one organisation using it for exactly that, they
do a real-time verification of cert validity using live validity data before
each and every use of the cert).

Peter.

------=_NextPart_000_0002_01C37AE1.51D5EB30
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Nachricht</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</DIV>
<DIV><SPAN class=3D002165623-14092003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hi=20
Florian,</FONT></SPAN></DIV>
<DIV><SPAN class=3D002165623-14092003><FONT face=3DArial color=3D#0000ff =

size=3D2>&nbsp;&nbsp;&nbsp; Including a nonce in the response where =
there isn't=20
one in the request</FONT></SPAN></DIV>
<DIV><SPAN class=3D002165623-14092003><FONT face=3DArial color=3D#0000ff =

size=3D2>doesn't buy you any additional security (unless the nonce has =
some=20
different</FONT></SPAN></DIV>
<DIV><SPAN class=3D002165623-14092003><FONT face=3DArial color=3D#0000ff =

size=3D2>semantics in your environment and isn't just a=20
nonce).</FONT></SPAN></DIV>
<DIV><SPAN class=3D002165623-14092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D002165623-14092003><FONT face=3DArial color=3D#0000ff =

size=3D2>Regards,</FONT></SPAN></DIV>
<DIV><SPAN class=3D002165623-14092003><FONT face=3DArial color=3D#0000ff =

size=3D2>Ambarish</FONT></SPAN></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>-----Original Message-----<BR><B>From:</B> =
[e-mail]=20
  [mailto:[e-mail]]<B>On Behalf Of </B>Florian=20
  Oelmaier<BR><B>Sent:</B> Sunday, September 14, 2003 3:14 =
PM<BR><B>To:</B>=20
  'Ryan M. Hurst'; 'Peter Gutmann'; [e-mail];=20
  [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests for =
different=20
  CAs at once valid ?<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Hello Ryan,</FONT></SPAN></DIV>
  <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>please note: although you are not sending a nonce,&nbsp;some=20
  OCSP-Responders will answer with one. To allow an responder to use =
nonce=20
  for&nbsp;replay attack protection,&nbsp;it must include the nonce into =
ALL his=20
  responses - otherwise this particular response could be used in a =
replay. On a=20
  sidenote: the inclusion of a nonce would surely benefit the security - =
perhaps=20
  you can make it a configuration setting?</FONT></SPAN></DIV>
  <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff size=3D2>--=20
  </FONT></SPAN></DIV>
  <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Florian Oelmaier</FONT></SPAN></DIV>
  <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>SyTrust</FONT></SPAN></DIV>
  <DIV><SPAN class=3D569120622-14092003><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV></DIV>
  <DIV><FONT face=3DTahoma size=3D2>-----Original =
Message-----<BR><B>From:</B>=20
  [e-mail] [mailto:[e-mail]] =
<B>On=20
  Behalf Of </B>Ryan M. Hurst<BR><B>Sent:</B> Sunday, September 14, 2003 =
8:55=20
  PM<BR><B>To:</B> Peter Gutmann; [e-mail];=20
  [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests for =
different=20
  CAs at once valid ?<BR><BR></DIV></FONT>
  <BLOCKQUOTE dir=3Dltr=20
  style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
    <DIV id=3DidOWAReplyText27203 dir=3Dltr>
    <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Peter - I =
really don't=20
    think what we are doing is breaking OCSP's security, after all nonce =
is a=20
    optional value in 2560 and the standard already specifically =
supports=20
    response pre-production:</FONT></DIV>
    <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr>&nbsp;&nbsp;&nbsp;&nbsp; 2.5&nbsp; Response=20
    Pre-production<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
OCSP=20
    responders MAY pre-produce signed responses specifying=20
    the<BR>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; status of certificates =
at a=20
    specified time. The time at which=20
    the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; status was known =
to be=20
    correct SHALL be reflected in the=20
    thisUpdate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field of =
the=20
    response. The time at or before which newer=20
    information<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will be =
available=20
    is reflected in the nextUpdate field, while=20
    the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; time at which the =
response=20
    was produced will appear in the=20
    producedAt<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field of =
the=20
    response.<BR></DIV></DIV>
    <DIV dir=3Dltr>And the only way to support this concept within OCSP =
would be=20
    to have the described behavior in regards to nonce handling.</DIV>
    <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
    <DIV dir=3Dltr>As for why OCSP was chosen over RTCS or a propietary =
solution,=20
    the goal is to work with exiting public infrastrucutres and other=20
    third-party solutions; given this OCSP was the obvious =
solution.</DIV>
    <DIV dir=3Dltr>&nbsp;</DIV>
    <DIV dir=3Dltr>Ryan<BR></DIV>
    <DIV dir=3Dltr>
    <HR tabIndex=3D-1>
    </DIV>
    <DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Peter=20
    Gutmann<BR><B>Sent:</B> Sun 9/14/2003 5:26 AM<BR><B>To:</B>=20
    [e-mail]; [e-mail];=20
    [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests for=20
    different CAs at once valid ?<BR></FONT><BR></DIV>
    <DIV><PRE style=3D"WORD-WRAP: break-word">"Ryan M. Hurst" =
&lt;[e-mail]&gt; writes:

&gt;Traditionally OCSP responders generate and sign responses on-demand
&gt;(dynamically), this requires the responders to scale their =
infrastructure to
&gt;handle very high peak volumes.=20

Hmm, biting back my immediate response (that breaking OCSP's security =
doesn't
seem like a good way to try and get usable performance out of it), why =
not use
a protocol like RTCS, which was designed from the outset to allow for =
high-
performance, highly scalable implementations?  It's not called real-time =
cert
status for nothing (there's one organisation using it for exactly that, =
they
do a real-time verification of cert validity using live validity data =
before
each and every use of the cert).

Peter.
</PRE></DIV></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0002_01C37AE1.51D5EB30--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ENKNeo045991 for <[e-mail]>; Sun, 14 Sep 2003 16:20:23 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8ENKN9s045990 for ietf-pkix-bks; Sun, 14 Sep 2003 16:20:23 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ENKLeo045985 for <[e-mail]>; Sun, 14 Sep 2003 16:20:21 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd02.aul.t-online.de  by mailout10.sul.t-online.com with smtp  id 19ygAC-0002Rg-00; Mon, 15 Sep 2003 01:20:16 +0200
Received: from hagen (XHmpVUZ1weZNm4lSkkI+c4tCNOEigasT4XgySLwtRbyGDfkY0LYCsB@[80.128.83.54]) by fmrl02.sul.t-online.com with esmtp id 19ygA4-1UnSHw0; Mon, 15 Sep 2003 01:20:08 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>
Cc: "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 01:20:09 +0200
Organization: SyTrust
Message-ID: <000001c37b16$be0b1480$4228a8c0@hagen>
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
Importance: Normal
In-Reply-To: <DDB24CCE-A58B-479F-BDEF-92F1F1045FFC@mimectl>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-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>

Ryan M.Hurst wrote:
"On a side note, I don't think your buying yourself any security if you
server is generating a nonce if the request didn't contain one. After
all the idea of the nonce is to cryptographically bind a unique request
to a unique response and since the client doesn't have anything to
compare the nonce to I think you hurt your servers performance without
adding any  value."

Let us assume a responder produces responses with nonce only when the
request contains one. Thus it is easy for an attacker to obtain a valid
response of the responder without nonce (he only needs to send a request
without one). The attacker now replays this response to another client
using a nonce in his request. 

What does this other client see?
He sends a request with a nonce. The responder does not answer with a
nonce. According to the RfC, nonces are optional. Maybe the responder is
not capable of producing nonces. So it depends on the client - I saw
clients out there accepting the response, I also saw clients not
accepting it. 

Conclusion:
If the responder wants to protect itself against replay attacks, it
should include a nonce into every response it ever constructs. This way,
an attacker can never replay one of its responses to a client using
nonce (because the nonces would most probably mismatch).

About performance:
If the server does not preproduce responses, the nonce generation (16
random bytes) does not have any performance hit. I agree with you, when
preproducing responses, including a nonce does not make sense. From my
point of view, one could go without nonce in closed environments where
time synchronization is not an issue (meaning time is secure and
correct).

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8EMWceo044243 for <[e-mail]>; Sun, 14 Sep 2003 15:32:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8EMWcbB044242 for ietf-pkix-bks; Sun, 14 Sep 2003 15:32:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8EMWbeo044237 for <[e-mail]>; Sun, 14 Sep 2003 15:32:37 -0700 (PDT) (envelope-from [e-mail])
Received: from mail5.microsoft.com ([157.54.6.156]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 14 Sep 2003 15:32:39 -0700
Received: from inet-vrs-05.redmond.corp.microsoft.com ([157.54.6.157]) by mail5.microsoft.com with Microsoft SMTPSVC(6.0.3790.1039); Sun, 14 Sep 2003 15:32:22 -0700
Received: from 157.54.6.197 by inet-vrs-05.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 14 Sep 2003 15:32:32 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by INET-HUB-06.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Sun, 14 Sep 2003 15:32:25 -0700
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(6.0.3790.1060); Sun, 14 Sep 2003 15:32:47 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Sun, 14 Sep 2003 15:32:32 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.6944
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <000201c37b0d$7879b7e0$4228a8c0@hagen>
References: <7056754D-7F42-4707-B335-DD36154C8031@mimectl>, <000201c37b0d$7879b7e0$4228a8c0@hagen>
To: Florian Oelmaier <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN7EBgMumGunBk8RZ6LfdJY/5Nm3Q==
Message-ID: <DDB24CCE-A58B-479F-BDEF-92F1F1045FFC@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
Date: Sun, 14 Sep 2003 15:32:35 -0700
X-OriginalArrivalTime: 14 Sep 2003 22:32:32.0603 (UTC) FILETIME=[16A3C2B0:01C37B10]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0003_01C37B1E.3C040E80"

------=_NextPart_000_0003_01C37B1E.3C040E80
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Florian - We certainly recognize the value of a nonce when protecting again=
st replay attacks, but our goal is to support high volume transactions for =
all of our consumers in the context of the internet transactions and public=
 certification authorities. As such the ability to deal with pre-produced O=
CSP responses that can be cached and/or distributed to generalized network =
load distribution centers becomes very important.

As for your request to not require this behavior, this is absolutely what w=
e do; we can validate responses that include a nonce but since our requests=
 won't include one we have nothing to verify them against.

On a side note, I don't think your buying yourself any security if you serv=
er is generating a nonce if the request didn't contain one. After all the i=
dea of the nonce is to cryptographically bind a unique request to a unique =
response and since the client doesn't have anything to compare the nonce to=
 I think you hurt your servers performance without adding any  value.=20

As for making this behavior configurable, we can certanly consider this how=
ever since we also don't support signed request I don't expect our client t=
o be the client of choice in enviroments that don't allow for such caching =
schemes.

Ryan





From: Florian Oelmaier
Sent: Sun 9/14/2003 3:13 PM
To: 'Ryan M. Hurst'; 'Peter Gutmann'; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?


Hello Ryan,

please note: although you are not sending a nonce, some OCSP-Responders wil=
l answer with one. To allow an responder to use nonce for replay attack pro=
tection, it must include the nonce into ALL his responses - otherwise this =
particular response could be used in a replay. On a sidenote: the inclusion=
 of a nonce would surely benefit the security - perhaps you can make it a c=
onfiguration setting?

--=20
Florian Oelmaier
SyTrust

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Ryan M. Hurst
Sent: Sunday, September 14, 2003 8:55 PM
To: Peter Gutmann; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?


Peter - I really don't think what we are doing is breaking OCSP's security,=
 after all nonce is a optional value in 2560 and the standard already speci=
fically supports response pre-production:

     2.5  Response Pre-production

        OCSP responders MAY pre-produce signed responses specifying the
        status of certificates at a specified time. The time at which the
        status was known to be correct SHALL be reflected in the thisUpdate
        field of the response. The time at or before which newer informatio=
n
        will be available is reflected in the nextUpdate field, while the
        time at which the response was produced will appear in the produced=
At
        field of the response.

And the only way to support this concept within OCSP would be to have the d=
escribed behavior in regards to nonce handling.

As for why OCSP was chosen over RTCS or a propietary solution, the goal is =
to work with exiting public infrastrucutres and other third-party solutions=
; given this OCSP was the obvious solution.

Ryan




From: Peter Gutmann
Sent: Sun 9/14/2003 5:26 AM
To: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?


"Ryan M. Hurst" <[e-mail]> writes:

>Traditionally OCSP responders generate and sign responses on-demand
>(dynamically), this requires the responders to scale their infrastructure =
to
>handle very high peak volumes.=20

Hmm, biting back my immediate response (that breaking OCSP's security doesn=
't
seem like a good way to try and get usable performance out of it), why not =
use
a protocol like RTCS, which was designed from the outset to allow for high-
performance, highly scalable implementations?  It's not called real-time ce=
rt
status for nothing (there's one organisation using it for exactly that, the=
y
do a real-time verification of cert validity using live validity data befor=
e
each and every use of the cert).

Peter.

------=_NextPart_000_0003_01C37B1E.3C040E80
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD><TITLE>Nachricht</TITLE></HEAD>
<BODY>
<DIV id=3DidOWAReplyText24102 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Florian - We cer=
tainly recognize the value of a nonce when protecting against replay attack=
s, but our goal is to support high volume transactions for all of our consu=
mers in the context of the internet transactions and public certification a=
uthorities. As such the ability to deal with pre-produced OCSP responses th=
at can be cached and/or distributed to generalized network load distributio=
n centers becomes very important.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2></FONT>&nbsp;</D=
IV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>As for your request to not requi=
re this behavior, this is absolutely what we do; we can validate responses =
that include a nonce but since our requests won't include one we have nothi=
ng to verify them against.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>On a side note, I don't think yo=
ur buying yourself any security if you server is generating a nonce if the =
request didn't contain one. After all the idea of the nonce is to cryptogra=
phically bind&nbsp;a unique&nbsp;request to a unique response and since the=
 client doesn't have&nbsp;anything to compare the nonce to I think you hurt=
 your servers performance without&nbsp;adding&nbsp;any&nbsp;&nbsp;value.&nb=
sp;</FONT></DIV><FONT face=3DArial size=3D2></FONT></DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>As for making this behavior conf=
igurable, we can certanly consider this however since we also don't support=
 signed request I don't expect our client to be the client of choice in env=
iroments that don't allow for such caching schemes.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV>
<DIV dir=3Dltr><BR></DIV>
<DIV dir=3Dltr>
<HR tabIndex=3D-1>
</DIV>
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Florian Oelmaier<B=
R><B>Sent:</B> Sun 9/14/2003 3:13 PM<BR><B>To:</B> 'Ryan M. Hurst'; 'Peter =
Gutmann'; [e-mail]; [e-mail]<BR><B>Subject:</B> RE: [OCSP] are=
 several requests for different CAs at once valid ?<BR></FONT><BR></DIV>
<DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff si=
ze=3D2>Hello Ryan,</FONT></SPAN></DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff si=
ze=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff si=
ze=3D2>please note: although you are not sending a nonce,&nbsp;some OCSP-Re=
sponders will answer with one. To allow an responder to use nonce for&nbsp;=
replay attack protection,&nbsp;it must include the nonce into ALL his respo=
nses - otherwise this particular response could be used in a replay. On a s=
idenote: the inclusion of a nonce would surely benefit the security - perha=
ps you can make it a configuration setting?</FONT></SPAN></DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff si=
ze=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff si=
ze=3D2>-- </FONT></SPAN></DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff si=
ze=3D2>Florian Oelmaier</FONT></SPAN></DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff si=
ze=3D2>SyTrust</FONT></SPAN></DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff si=
ze=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV></DIV>
<DIV><FONT face=3DTahoma size=3D2>-----Original Message-----<BR><B>From:</B=
> [e-mail] [mailto:[e-mail]] <B>On =
Behalf Of </B>Ryan M. Hurst<BR><B>Sent:</B> Sunday, September 14, 2003 8:55=
 PM<BR><B>To:</B> Peter Gutmann; [e-mail]; [e-mail]<BR><B>Subj=
ect:</B> RE: [OCSP] are several requests for different CAs at once valid ?<=
BR><BR></DIV></FONT>
<BLOCKQUOTE dir=3Dltr style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-=
LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV id=3DidOWAReplyText27203 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Peter - I really=
 don't think what we are doing is breaking OCSP's security, after all nonce=
 is a optional value in 2560 and the standard already specifically supports=
 response pre-production:</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr>&nbsp;&nbsp;&nbsp;&nbsp; 2.5&nbsp; Response Pre-production<B=
R><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OCSP responders MAY pre-pr=
oduce signed responses specifying the<BR>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nb=
sp; status of certificates at a specified time. The time at which the<BR>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; status was known to be correct SHA=
LL be reflected in the thisUpdate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; field of the response. The time at or before which newer information<B=
R>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will be available is reflected=
 in the nextUpdate field, while the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; time at which the response was produced will appear in the producedA=
t<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field of the response.<BR><=
/DIV></DIV>
<DIV dir=3Dltr>And the only way to support this concept within OCSP would b=
e to have the described behavior in regards to nonce handling.</DIV>
<DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff size=3D2></FONT>&nbsp;</D=
IV>
<DIV dir=3Dltr>As for why OCSP was chosen over RTCS or a propietary solutio=
n, the goal is to work with exiting public infrastrucutres and other third-=
party solutions; given this OCSP was the obvious solution.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>Ryan<BR></DIV>
<DIV dir=3Dltr>
<HR tabIndex=3D-1>
</DIV>
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Peter Gutmann<BR><=
B>Sent:</B> Sun 9/14/2003 5:26 AM<BR><B>To:</B> [e-mail]; rmh@wind=
ows.microsoft.com; [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several r=
equests for different CAs at once valid ?<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">"Ryan M. Hurst" &lt;rmh@windows.m=
icrosoft.com&gt; writes:

&gt;Traditionally OCSP responders generate and sign responses on-demand
&gt;(dynamically), this requires the responders to scale their infrastructu=
re to
&gt;handle very high peak volumes.=20

Hmm, biting back my immediate response (that breaking OCSP's security doesn=
't
seem like a good way to try and get usable performance out of it), why not =
use
a protocol like RTCS, which was designed from the outset to allow for high-
performance, highly scalable implementations?  It's not called real-time ce=
rt
status for nothing (there's one organisation using it for exactly that, the=
y
do a real-time verification of cert validity using live validity data befor=
e
each and every use of the cert).

Peter.
</PRE></DIV></BLOCKQUOTE></DIV></BODY></HTML>

------=_NextPart_000_0003_01C37B1E.3C040E80--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8EMEEeo043581 for <[e-mail]>; Sun, 14 Sep 2003 15:14:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8EMEE0l043580 for ietf-pkix-bks; Sun, 14 Sep 2003 15:14:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8EMECeo043559 for <[e-mail]>; Sun, 14 Sep 2003 15:14:12 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd02.aul.t-online.de  by mailout04.sul.t-online.com with smtp  id 19yf84-0001zX-04; Mon, 15 Sep 2003 00:14:00 +0200
Received: from hagen (VsCz4sZXwe0OmYjcgyXpb5bWjuU7TXdZDUYxEzpn4KasHhqzzqyvr1@[80.128.83.54]) by fmrl02.sul.t-online.com with esmtp id 19yf7q-1r5W640; Mon, 15 Sep 2003 00:13:46 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>, "'Peter Gutmann'" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 00:13:47 +0200
Organization: SyTrust
Message-ID: <000201c37b0d$7879b7e0$4228a8c0@hagen>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0003_01C37B1E.3C040E80"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.3416
In-Reply-To: <7056754D-7F42-4707-B335-DD36154C8031@mimectl>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a multi-part message in MIME format.

------=_NextPart_000_0003_01C37B1E.3C040E80
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hello Ryan,
 
please note: although you are not sending a nonce, some OCSP-Responders
will answer with one. To allow an responder to use nonce for replay
attack protection, it must include the nonce into ALL his responses -
otherwise this particular response could be used in a replay. On a
sidenote: the inclusion of a nonce would surely benefit the security -
perhaps you can make it a configuration setting?
 
-- 
Florian Oelmaier
SyTrust
 
-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ryan M. Hurst
Sent: Sunday, September 14, 2003 8:55 PM
To: Peter Gutmann; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?



Peter - I really don't think what we are doing is breaking OCSP's
security, after all nonce is a optional value in 2560 and the standard
already specifically supports response pre-production:
 
     2.5  Response Pre-production

        OCSP responders MAY pre-produce signed responses specifying the
        status of certificates at a specified time. The time at which
the
        status was known to be correct SHALL be reflected in the
thisUpdate
        field of the response. The time at or before which newer
information
        will be available is reflected in the nextUpdate field, while
the
        time at which the response was produced will appear in the
producedAt
        field of the response.

And the only way to support this concept within OCSP would be to have
the described behavior in regards to nonce handling.
 
As for why OCSP was chosen over RTCS or a propietary solution, the goal
is to work with exiting public infrastrucutres and other third-party
solutions; given this OCSP was the obvious solution.
 
Ryan

  _____  

From: Peter Gutmann
Sent: Sun 9/14/2003 5:26 AM
To: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?


"Ryan M. Hurst" <[e-mail]> writes:



>Traditionally OCSP responders generate and sign responses on-demand

>(dynamically), this requires the responders to scale their
infrastructure to

>handle very high peak volumes. 



Hmm, biting back my immediate response (that breaking OCSP's security
doesn't

seem like a good way to try and get usable performance out of it), why
not use

a protocol like RTCS, which was designed from the outset to allow for
high-

performance, highly scalable implementations?  It's not called real-time
cert

status for nothing (there's one organisation using it for exactly that,
they

do a real-time verification of cert validity using live validity data
before

each and every use of the cert).



Peter.


------=_NextPart_000_0003_01C37B1E.3C040E80
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>Nachricht</TITLE>

<META content=3D"MSHTML 6.00.2800.1226" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff =
size=3D2>Hello=20
Ryan,</FONT></SPAN></DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff =
size=3D2>please=20
note: although you are not sending a nonce,&nbsp;some OCSP-Responders =
will=20
answer with one. To allow an responder to use nonce for&nbsp;replay =
attack=20
protection,&nbsp;it must include the nonce into ALL his responses - =
otherwise=20
this particular response could be used in a replay. On a sidenote: the =
inclusion=20
of a nonce would surely benefit the security - perhaps you can make it a =

configuration setting?</FONT></SPAN></DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff =
size=3D2>--=20
</FONT></SPAN></DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff =

size=3D2>Florian Oelmaier</FONT></SPAN></DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff =

size=3D2>SyTrust</FONT></SPAN></DIV>
<DIV><SPAN class=3D569120622-14092003><FONT face=3DArial color=3D#0000ff =

size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV></DIV>
<DIV><FONT face=3DTahoma size=3D2>-----Original =
Message-----<BR><B>From:</B>=20
[e-mail] [mailto:[e-mail]] <B>On =
Behalf=20
Of </B>Ryan M. Hurst<BR><B>Sent:</B> Sunday, September 14, 2003 8:55=20
PM<BR><B>To:</B> Peter Gutmann; [e-mail];=20
[e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests for =
different=20
CAs at once valid ?<BR><BR></DIV></FONT>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV id=3DidOWAReplyText27203 dir=3Dltr>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Peter - I =
really don't=20
  think what we are doing is breaking OCSP's security, after all nonce =
is a=20
  optional value in 2560 and the standard already specifically supports =
response=20
  pre-production:</FONT></DIV>
  <DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>&nbsp;&nbsp;&nbsp;&nbsp; 2.5&nbsp; Response=20
  Pre-production<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OCSP=20
  responders MAY pre-produce signed responses specifying=20
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; status of certificates at =
a=20
  specified time. The time at which=20
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; status was known to =
be=20
  correct SHALL be reflected in the=20
  thisUpdate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field of the=20
  response. The time at or before which newer=20
  information<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will be =
available is=20
  reflected in the nextUpdate field, while=20
  the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; time at which the =
response=20
  was produced will appear in the=20
  producedAt<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field of the=20
  response.<BR></DIV></DIV>
  <DIV dir=3Dltr>And the only way to support this concept within OCSP =
would be to=20
  have the described behavior in regards to nonce handling.</DIV>
  <DIV dir=3Dltr><FONT face=3DArial color=3D#0000ff =
size=3D2></FONT>&nbsp;</DIV>
  <DIV dir=3Dltr>As for why OCSP was chosen over RTCS or a propietary =
solution,=20
  the goal is to work with exiting public infrastrucutres and other =
third-party=20
  solutions; given this OCSP was the obvious solution.</DIV>
  <DIV dir=3Dltr>&nbsp;</DIV>
  <DIV dir=3Dltr>Ryan<BR></DIV>
  <DIV dir=3Dltr>
  <HR tabIndex=3D-1>
  </DIV>
  <DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Peter=20
  Gutmann<BR><B>Sent:</B> Sun 9/14/2003 5:26 AM<BR><B>To:</B> =
[e-mail];=20
  [e-mail]; [e-mail]<BR><B>Subject:</B> RE: [OCSP] =
are=20
  several requests for different CAs at once valid =
?<BR></FONT><BR></DIV>
  <DIV><PRE style=3D"WORD-WRAP: break-word">"Ryan M. Hurst" =
&lt;[e-mail]&gt; writes:

&gt;Traditionally OCSP responders generate and sign responses on-demand
&gt;(dynamically), this requires the responders to scale their =
infrastructure to
&gt;handle very high peak volumes.=20

Hmm, biting back my immediate response (that breaking OCSP's security =
doesn't
seem like a good way to try and get usable performance out of it), why =
not use
a protocol like RTCS, which was designed from the outset to allow for =
high-
performance, highly scalable implementations?  It's not called real-time =
cert
status for nothing (there's one organisation using it for exactly that, =
they
do a real-time verification of cert validity using live validity data =
before
each and every use of the cert).

Peter.
</PRE></DIV></BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_0003_01C37B1E.3C040E80--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8EIseeo037961 for <[e-mail]>; Sun, 14 Sep 2003 11:54:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8EIseaj037960 for ietf-pkix-bks; Sun, 14 Sep 2003 11:54:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8EIsceo037943 for <[e-mail]>; Sun, 14 Sep 2003 11:54:39 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sun, 14 Sep 2003 11:54:59 -0700
Received: from 157.54.6.150 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sun, 14 Sep 2003 11:54:35 -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(6.0.3790.0); Sun, 14 Sep 2003 11:53:45 -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(6.0.3790.0); Sun, 14 Sep 2003 11:51:59 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Sun, 14 Sep 2003 11:54:33 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.6944
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: Peter Gutmann <[e-mail]>, <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN68aTJVMcZWgP2T2+cZJ5T2zTdlA==
Message-ID: <7056754D-7F42-4707-B335-DD36154C8031@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
Date: Sun, 14 Sep 2003 11:54:36 -0700
X-OriginalArrivalTime: 14 Sep 2003 18:54:33.0873 (UTC) FILETIME=[A31BF010:01C37AF1]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_2508C4EC-CCA8-480B-B19A-38C794235F63_"

--_2508C4EC-CCA8-480B-B19A-38C794235F63_
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Peter - I really don't think what we are doing is breaking OCSP's security,=
 after all nonce is a optional value in 2560 and the standard already speci=
fically supports response pre-production:

     2.5  Response Pre-production

        OCSP responders MAY pre-produce signed responses specifying the
        status of certificates at a specified time. The time at which the
        status was known to be correct SHALL be reflected in the thisUpdate
        field of the response. The time at or before which newer informatio=
n
        will be available is reflected in the nextUpdate field, while the
        time at which the response was produced will appear in the produced=
At
        field of the response.

And the only way to support this concept within OCSP would be to have the d=
escribed behavior in regards to nonce handling.

As for why OCSP was chosen over RTCS or a propietary solution, the goal is =
to work with exiting public infrastrucutres and other third-party solutions=
; given this OCSP was the obvious solution.

Ryan




From: Peter Gutmann
Sent: Sun 9/14/2003 5:26 AM
To: [e-mail]; [e-mail]; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?


"Ryan M. Hurst" <[e-mail]> writes:

>Traditionally OCSP responders generate and sign responses on-demand
>(dynamically), this requires the responders to scale their infrastructure =
to
>handle very high peak volumes.=20

Hmm, biting back my immediate response (that breaking OCSP's security doesn=
't
seem like a good way to try and get usable performance out of it), why not =
use
a protocol like RTCS, which was designed from the outset to allow for high-
performance, highly scalable implementations?  It's not called real-time ce=
rt
status for nothing (there's one organisation using it for exactly that, the=
y
do a real-time verification of cert validity using live validity data befor=
e
each and every use of the cert).

Peter.

--_2508C4EC-CCA8-480B-B19A-38C794235F63_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText27203 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Peter - I really=
 don't think what we are doing is breaking OCSP's security, after all nonce=
 is a optional value in 2560 and the standard already specifically supports=
 response pre-production:</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr>&nbsp;&nbsp;&nbsp;&nbsp; 2.5&nbsp; Response Pre-production<B=
R><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OCSP responders MAY pre-pr=
oduce signed responses specifying the<BR>&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nb=
sp; status of certificates at a specified time. The time at which the<BR>&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; status was known to be correct SHA=
LL be reflected in the thisUpdate<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp; field of the response. The time at or before which newer information<B=
R>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will be available is reflected=
 in the nextUpdate field, while the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp; time at which the response was produced will appear in the producedA=
t<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; field of the response.<BR><=
/DIV></DIV>
<DIV dir=3Dltr>And the only way to support this concept within OCSP would b=
e to have the described behavior in regards to nonce handling.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>As for why OCSP was chosen over RTCS or a propietary solutio=
n, the goal is to work with exiting public infrastrucutres and other third-=
party solutions; given this OCSP was the obvious solution.</DIV>
<DIV dir=3Dltr>&nbsp;</DIV>
<DIV dir=3Dltr>Ryan<BR></DIV>
<DIV dir=3Dltr>
<HR tabIndex=3D-1>
</DIV>
<DIV dir=3Dltr><FONT face=3DTahoma size=3D2><B>From:</B> Peter Gutmann<BR><=
B>Sent:</B> Sun 9/14/2003 5:26 AM<BR><B>To:</B> [e-mail]; rmh@wind=
ows.microsoft.com; [e-mail]<BR><B>Subject:</B> RE: [OCSP] are several r=
equests for different CAs at once valid ?<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">"Ryan M. Hurst" &lt;rmh@windows.m=
icrosoft.com&gt; writes:

&gt;Traditionally OCSP responders generate and sign responses on-demand
&gt;(dynamically), this requires the responders to scale their infrastructu=
re to
&gt;handle very high peak volumes.=20

Hmm, biting back my immediate response (that breaking OCSP's security doesn=
't
seem like a good way to try and get usable performance out of it), why not =
use
a protocol like RTCS, which was designed from the outset to allow for high-
performance, highly scalable implementations?  It's not called real-time ce=
rt
status for nothing (there's one organisation using it for exactly that, the=
y
do a real-time verification of cert validity using live validity data befor=
e
each and every use of the cert).

Peter.
</PRE></DIV></BODY></HTML>

--_2508C4EC-CCA8-480B-B19A-38C794235F63_--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8EDaTeo003465 for <[e-mail]>; Sun, 14 Sep 2003 06:36:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8EDaTXI003464 for ietf-pkix-bks; Sun, 14 Sep 2003 06:36:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8EDaQeo003437 for <[e-mail]>; Sun, 14 Sep 2003 06:36:28 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (202.washington-27rh15rt.dc.dial-access.att.net[12.91.156.202]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003091413361111300s6ru8e>; Sun, 14 Sep 2003 13:36:11 +0000
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Sun, 14 Sep 2003 09:36:08 -0400
Message-ID: <000501c37ac5$293dd550$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <p05210601bb8506da6217@[128.89.89.75]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8EDaSeo003459
Sender: [e-mail]
Precedence: 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 Kent:

To summarize the debate we are having, my position is as follows:

1.  A pointer to an SCVP Server in a target certificate can help a RP obtain
DPD services from the SCVP Server.

2.  A pointer to an SCVP Server in a target certificate can be used by a RP
(who is not another SCVP Server) to prioritize among its SCVP Servers for
DPV services.

3.  A pointer to an SCVP Server in a target certificate can be used by a RP
(who is  another SCVP Server) to obtain DPV services.

My interpretation of your e-mails to date is that you are ok with 1, but
with 2 you have concerns about security and you want to define the client
behavior.  (We have not had any discussion yet that distinguishes 2 and 3).

I do not think doing 2 and 3 impacts security and I do not think exactly how
an RP uses the pointer to prioritize should be subject of the standard.
Here are my reasons:

Absent the pointer, there is no standard that dictates in what order the
multiple SCVP Servers should be invoked.  Also, this situation is akin to a
RP which performs  certification path development and validation locally,
itself.  There is no standard as to in which order the various paths should
be developed and verified.  Thus, it is entirely possible (through accident
or design) that an RP would try the paths in the same order with or without
considering the pointer.  Since that ordering is not mandated by the
standard, it should not and will not impact security or interoperability.

In the interest of brevity, I have consolidated and redacted our multiple
e-mail threads and provided responses to your remaining concerns.  My
responses are in [].

We can discuss this on Wednesday, if you like.

Steve Kent wrote:

scope control has to be in the client, not a server, since the client 
needs to know what server is appropriate for a given class of query. 
the list of "it could be A or it could be B or it could be C" does 
not given me a warm fuzzy feeling. we know that, without suitable 
scope constraints, basing the selection purely form what is in a cert 
is dangerous for DPV.  That suggests that we need standards, or at a 
minimum, a significant security consideration discussion, or the 
implications for each option. and, if we fail to mandate support for 
any of these options in a standard, users are left wondering what the 
client software will do, and whether what it does is secure.

[Scope of control is always with the client.  I do not think the order in
which the client queries is security relevant or impacts interoperability.
Thus, I do not favor standardization in this area]

your starting point above is just what I have been saying, but I 
would like to see agreement on this from all the contributors to this 
discussion. the phrase "client trust list" is a bit too vague for me. 
we need to be more precise. the last sentence above suggests a 
particular behavior that may be appropriate, but what I would like to 
see is concrete text for the SCVP ID, to make clear what we really 
expect a client to do.  Currently we seem to lack the equivalent of a 
state machine for client behavior re SCVP (at least in the case where 
we create an extension of the sort being debated here) and that's not 
OK.

[I do not think the order in which the client queries is security relevant
or impacts interoperability.  Thus, I do not favor standardization in this
area]

The "holes" are the unspecified parts (gaps) in the processing 
description, several of which are still part of the discussion above.

[I do not think specification of order in which client does things is
required.  The clients should arrive at the same result regardless of the
ordering]

It does affect security for the client, and as a user I want to know 
how the client will behave. An attractive way for me to know that is 
if we have a standard and the vendor assures me that the client 
software complies with the standard.

[The order in which the client invokes SCVP Servers the client trusts for a
given scope should not impact security unless the SCVP Servers are doing
something wrong]

is this choice left to the implementer, or does an administrator have 
control over this?

[The client configuration should be matter of client configuration, be it
the administrator or the end user]

What I would want to know, as a user, is what algorithm the client 
software uses and how I can control it. if we don't mandate some type 
of admin controls here,  we cannot specify client processing of an 
SCVP response, and we have an incomplete spec. the trick is agreeing 
upon a set of generally useful controls that we want clients to have, 
while not imposing undue complexity on the clients (which we are 
trying to keep simple) and while still ensuring a base level of 
functionality for clients.

[There is no need to specify the order in which paths or SCVP Servers are
navigated by the client.  It should not impact security or
interoperability.] what you say here is a list of "could's." we need a state
machine for 
a client specification, and these could's can become part of that, if 
they are carefully articulated, but not putting them down in a spec 
leaves things very uncertain.

[We do not have a state machine for the order in which path development and
validation processes cooperate for a client.  This situation is akin to
that.  Think of SCVP Servers the client trusts as the extension of the
client software, trust store, and certificate and CRL store.  We do not have
and do not need standards in the areas of how the client builds paths and
how the path building works in conjunction with path validation.]

I am still confused by your text. You indicated, initially, that you 
had several certs issued to you by different CAs, corresponding to 
different clients. That's fine, but you are not an RP when you select 
the right cert to use when signing some data directed to a specific 
client. I think your most recent comment, above, refers to selecting 
the right SCVP server for a cert associated with a client, when 
encrypting some data for that client. Yes, here you are an RP, but 
this is not consistent with the words you used in your example, i.e., 
" My customers like US Government and Banks want me to use 
certificates minted by them for me using their PKI." This text refers 
to your cert, not their cert, hence the confusion.

[The way these PKIs work is that I am both the subscriber and RP.  When I
register for a certificate, they provide me with a trust anchor to be used
as an RP.  This TA will be replaced with the SCVP Server public key so that
I can validate certificates issued to other subscribers in these domains.]

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ECOVeo095053 for <[e-mail]>; Sun, 14 Sep 2003 05:24:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8ECOVcH095052 for ietf-pkix-bks; Sun, 14 Sep 2003 05:24:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8ECOTeo095038 for <[e-mail]>; Sun, 14 Sep 2003 05:24:29 -0700 (PDT) (envelope-from [e-mail])
Received: from cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h8ECOOZs004738; Mon, 15 Sep 2003 00:24:24 +1200
Received: (from pgut001@localhost) by cs.auckland.ac.nz (8.11.6/8.11.6) id h8ECQOq12843; Mon, 15 Sep 2003 00:26:24 +1200
Date: Mon, 15 Sep 2003 00:26:24 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Ryan M. Hurst" <[e-mail]> writes:

>Traditionally OCSP responders generate and sign responses on-demand
>(dynamically), this requires the responders to scale their infrastructure to
>handle very high peak volumes. 

Hmm, biting back my immediate response (that breaking OCSP's security doesn't
seem like a good way to try and get usable performance out of it), why not use
a protocol like RTCS, which was designed from the outset to allow for high-
performance, highly scalable implementations?  It's not called real-time cert
status for nothing (there's one organisation using it for exactly that, they
do a real-time verification of cert validity using live validity data before
each and every use of the cert).

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8DNSAeo091503 for <[e-mail]>; Sat, 13 Sep 2003 16:28:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8DNSARG091502 for ietf-pkix-bks; Sat, 13 Sep 2003 16:28:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8DNS2eo091456 for <[e-mail]>; Sat, 13 Sep 2003 16:28:04 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Sat, 13 Sep 2003 16:27:48 -0700
Received: from 157.54.6.197 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Sat, 13 Sep 2003 16:28:00 -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(6.0.3790.1060); Sat, 13 Sep 2003 16:27:54 -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(6.0.3790.0); Sat, 13 Sep 2003 16:28:14 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Sat, 13 Sep 2003 16:28:02 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: How a SCVP client authenticates the SCVP server?
Date: Sat, 13 Sep 2003 16:27:58 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: How a SCVP client authenticates the SCVP server?
Thread-Index: AcN5ycbipGRV0k7+R0SK71UwFp1Q7AAgymoQ
From: "Trevor Freeman" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 13 Sep 2003 23:28:02.0143 (UTC) FILETIME=[ACC97EF0:01C37A4E]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8DNS4eo091479
Sender: [e-mail]
Precedence: 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 Wen,
Yes the SCVP server MUST have a CA issued certificate conformant to 3280
and use it when signing signed data responses. It is a matter of local
policy and capability how the client validates the signature which is a
subject I will elaborate on in draft 13. I see no benefit in using raw
keys as you suggest. All you save is some data on the wire and
complicate the server who now has to support more mechanisms to do
signed data signatures. The client is already parsing ASN CMS data so
the impact of supporting parsing the ASN certificate is negligible. The
simple client does not need to do anything else just because the
information was conveyed in a certificate. If you really want to
distribute the public key of the server, since that is a mater of local
policy, then you can ignore the cert totally. Alternatively use
authenticated data with a pre-shraed key.

Trevor 


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Wen-Cheng Wang
Sent: Friday, September 12, 2003 11:14 PM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: How a SCVP client authenticates the SCVP server?

Hi, Trevor,

Do you mean that the SCVP server still needs to apply a server 
cetificate from a CA even in the case where all its intended clients are
simple clients? (Note: I am talking about the case where
SignedData is used. Let the AuthenticatedData case be
temporary out of the scope of our discussion.)
However, in your last mail, you tell us that "for simple clients, the
trust mechanism cannot rely on any form of certificate
validation...". I do not understand if the SCVP server certificate is 
no use in the case where all the intended clients are simple clients,
why does the SCVP server still need to have a server certificate?
Why not let th SCVP server directly distribute its own public-key
to all its clients via an out-of-band trusted channel?

It does not make sense to me if you require the SCVP server to
apply a server certificate from a CA but tell the client that it does
not to validate the server certificate and does not need to check
whether the server certificate is revoked by its issuer.

Wen-Cheng 


Trevor Freeman wrote:
> Hi Wen,
> I would not make that strict interpretation. In all non error cases
the
> SCVP is signed. The signature is either a signed data signature using
a
> 3280 cert or authenticated data MAC which may contain a 3280 cert.  I
do
> not see you mode 1 or 2 as fitting at description. Mode 3 is closer
> except the simple client simply needs a key hash and to be able to
parse
> the cert to find the public key and do a comparison. The intent of the
> MAC is to allow client the simplest of validations modes possible. 
> Trevor
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 7:35 PM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: RE: How a SCVP client authenticates the SCVP server?
> Hi, Trevor,
> It seems that you are trying to tell us:
> 1. For simple clients, they must authenticate the SCVP server
>    in the fashion of either mode 1 or mode 2 I metntioned.
> 2. For SCVP servers who act as a SCVP client (a SCVP relay),
>    they can authenticate the SCVP server in the fashion of mode 3
>    I mentioned.
> Is my interpretation correct?
> If so, don't you think the text of the current SCVP ID need to be
> changed to support mode 1?
> Best Reagrds,
> Wen-Cheng
> Trevor Freeman wrote:
> > Hi Wen-Cheng,
> > First off consider there are two classes of SCVP clients. 
> > * Simple clients who only originate SCVP request and 
> > * SCVP servers who can both service requests and originate their own
> > requests to other SCVP servers(relay).
> > The validation requirements are quite different between the two. For
> > simple clients the trust mechanism cannot rely on any form of
> > certificate validation, but will be achieved by out-of-band
> > configuration of the SCVP server's public signing\authentication key
> or
> > a symmetric shared key. For SCVP server making request of other SCVP
> > servers, then chain validation is legitimate option since the
> discovery
> > and use model is quite different as are the constraints - or
relative
> > lack of them- on the servers capabilities. Beyond having
certificates
> > conformant to 3280 and having a specific key purpose, I don't think
we
> > need to be more prescriptive.
> > Trevor
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On Behalf Of Wen-Cheng Wang
> > Sent: Friday, September 12, 2003 5:00 AM
> > To: [e-mail]
> > Subject: How a SCVP client authenticates the SCVP server?
> > Folks,
> > After the past [SCVP-AIA] discussions and reviewing
> > the current SCVP ID, I feel that it seems to be
> > unclear that how a SCVP client validates the
> > signature on the SCVP response signed by the SCVP
> > server. Since this topic is not directly related to
> > SCVP-AIA, I would like to discuss it in another thread
> > and hope to get some feedbacks from this WG. Especailly,
> > I hope the editors of SCVP ID can tell us what is
> > in their mind when designing the protocol and the
> > message format.
> > When asked how a SCVP client validates the signature
> > on the SCVP response, I believe that the most intuitive
> > answer will be "Use the public-key of the SCVP server
> > to verify the signature." However, the truth is that
> > things might not be as simple as they are looked like.
> > Before a SCVP client using the public-key of the SCVP
> > server, the client MUST make sure the public-key is
> > trustworthy. The question how can the client trust the
> > public-key of the SCVP server? During the [SCVP-AIA]
> > discussions, at least three possibilities are mentioned:
> > 1. The SCVP server first delivered its own public-key to SCVP
> >    clients via an out-of-band trusted channel. A SCVP client
> >    must securely stored the public-key of the SCVP server in its
> >    local environment in advance and then it can use the public-key
> >    to verify the signature of the SCVP server.
> > In this mode, the SCVP server need not to have its own
> > certificate and of course does not need to include its own
> > certificate in the certificates field within the signed SCVP
> > response (i.e., a CMS SignedData). (Note: the current SCVP ID
> > does not allow this mode because it says "The SCVP server MUST
> > include its own certificate in the certificates field within
> > SignedData" in its section 4.
> > Note that, in this mode, the public-key of the SCVP server
> > must be delivered to SCVP clients via an out-of-band
> > trusted channel. (Similar to the way to deliver root key to
> > relying parties.)
> > There is one issue need to be discussed for this mode. Since
> > the SCVP server does not have its own certificate, how can it
> > identify itself in the signed SCVP response? Because the signed
> > response is actually a CMS SignedData, the SCVP server must
> > try to identify itself by using a SignerIdentifier structure,
> > which is
> >   SignerIdentifier ::= CHOICE {
> >           issuerAndSerialNumber IssuerAndSerialNumber,
> >           subjectKeyIdentifier [0] SubjectKeyIdentifier }
> > IMO, the SubjectKeyIdentifier field might be the only choice
> > since IssuerAndSerialNumber makes no sense in this case. The
> > problem is there is currently no unique way for generating
> > Key Identifier. For example, if the server side calculates
> > its own key identifier as 160-bit SHA-1 hash value of its
> > public-key while the client side uses 0100 + the least
> > significant 60 bits of the SHA-1 hash value, there will be
> > an interoperability problem.
> > Therefore, if the SCVP is going to support this mode, the protocol
> > might need to define an unique way for generating key identifier.
> > (At least, within the scope of SCVP.)
> > 2. The SCVP server first signed itw own certificate (i.e., a
> >    self-signed certificate) and delivered the self-signed
certificate
> >    to SCVP clients via an out-of-band trusted channel. A SCVP client
> >    must securely stored the self-signed certificate of the SCVP
server
> >    in its local environment in advance and it can use the public-key
> >    in the self-signed certificate of the SCVP server to verify
> >    the signature of the SCVP server.
> > Note that, as the same reason why a self-signed certificate of a
> > root CA must be deliverd to relying parties via an out-of-band
> > trusted channel, the self-signed certificate of the SCVP server
> > must be delivered to SCVP clients via an out-of-band trusted
> > channel. Also, a SCVP client must securely stores the self-signed
> > certificate of the SCVP server in its local environment and then
> > use the public-key within the certificate to verify the signature
> > of the SCVP server.
> > My opinion is mode 2 is actually equal to mode 1 except that
> > the OCSP server can now identify itself by using either
> > IssuerAndSerialNumber field or SubjectKeyIdentifier field
> > in a SignerIdentifier structure and it burdens the SCVP server
> > with the overhead of creating its own self-signed certificate.
> > Personally, I am not in favor of mode 2 because I believe that
> > a SCVP server is simply an EE from the viewpoint of the PKI and
> > I doubt whether a self-signed EE certificate is a legal X.509
> > certificate and I also doubt whether PKIX should encourge an EE
> > to create its own self-signed certificate.
> > 3. The SCVP server certificate should be signed by a CA. The SCVP
> >    server can then include its own certificate in the signed SCVP
> >    response. After receiving the signed response, a SCVP client
> >    must validate the SCVP server certificate first to determine
> >    whether it is a trusted SCVP server. And then the SCVP client
> >    can use the public-key in the SCVP server certificate to verify
> >    the signature of the SCVP server.
> >    
> > It seems that the procedure describe in mode 3 is very reasonable
> > and straightforward. Believe me, it is not that simple. Please
> > note that a SCVP client must validate the SCVP server certificate
> > first after receiving the signed response and before can use the
> > public-key in the SCVP server certificate to verify the signature
> > of the SCVP server. That is sort of similar to ask an OCSP
> > client to check the status of the OCSP server certificate before
> > it can use the public-key in that certificate to verify the
> > signature of the OCSP server. It is a chicken-and-egg problem.
> > Let's think about why a RP (a certificate-using application) wants
> > to delegate the job of certification path construction/validation
> > to a SCVP Server. I believe that one possibile reason is the
> > implementator of the certificate-using application is not capable
> > of implementing the complex certification path
> > construction/validation algorithm and therefore decide to delegate
> > that job to a SCVP server because he/she heard of the SCVP is the
> > savior of the certificate-using application implementator.
> > Unfortunately, the application implementator will eventually find
> > that he/she still need to implementing the complex certification
> > path construction/validation algorithm because the SCVP client
> > side must validate the SCVP server certificate first and that
> > might invloves constructing a certification path from the SCVP
> > server certificate to the RP's trust anchor and the validating
> > the certification path. Therefore, I do not know how mode 3 works
> > if every certificate-using application does not have its own
> > certification path construction/validation module. Ironically, isn't
> > the original idea of SCVP is to eliminate application
implementators'
> > burden for implementing the complex certification path
> > construction/validation.
> > I believe that mode 3 is what in the SCVP ID editors' minds when
> > they design the protocol. Unfortunately, the current SCVP ID does
> > not tell us how a SCVP client can authenticate the SCVP server.
> > At least, the following issues should be discussed.
> > 1. Who should sign the SCVP server certificate?
> > 2. What is the format of the SCVP server certificate?
> >    (Is there any special requirements for the format of
> >     the SCVP server certificate? or is it just a normal EE
> >     signing certificate?)
> > 3. How a SCVP client can validate the SCVP server certificate
> >    without its own certification path construction/validation
> >    module?
> > Can anyone clarify these issues?
> > Best Regards,
> > Wen-Cheng Wang



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D6UWeo047639 for <[e-mail]>; Fri, 12 Sep 2003 23:30:32 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8D6UW5l047638 for ietf-pkix-bks; Fri, 12 Sep 2003 23:30:32 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.cht.com.tw ([202.39.162.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D6UTeo047624 for <[e-mail]>; Fri, 12 Sep 2003 23:30:30 -0700 (PDT) (envelope-from [e-mail])
Received: from mailgate.cht.com.tw ([10.1.22.7]) by fw.cht.com.tw (8.12.6/8.12.6) with ESMTP id h8D6SYjO057800; Sat, 13 Sep 2003 14:28:35 +0800 (CST) (envelope-from [e-mail])
Received: from linux01 (webmail.cht.com.tw [10.1.22.40]) by mailgate.cht.com.tw (8.11.6/8.10.2) with ESMTP id h8D6Qs318173; Sat, 13 Sep 2003 14:26:54 +0800
Message-ID: <14610109.1063433654208.JavaMail.root@10.1.22.7>
Date: Sat, 13 Sep 2003 14:14:14 +0800 (CST)
From: Wen-Cheng Wang <[e-mail]>
To: "\"Trevor Freeman\"" <[e-mail]>
Subject: RE: How a SCVP client authenticates the SCVP server?
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: multipart/mixed;  boundary="----=_Part_34_30507140.1063433654205"
X-Mailer: WebMail/Java v0.7.10, built with JDK 1.4.1, SendMessage plugin v1.8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_Part_34_30507140.1063433654205
Content-Type: text/plain; charset="Big5"
Content-Transfer-Encoding: quoted-printable

Hi, Trevor,

Do you mean that the SCVP server still needs to apply a server=20
cetificate from a CA even in the case where all its intended clients are si=
mple clients? (Note: I am talking about the case where
SignedData is used. Let the AuthenticatedData case be
temporary out of the scope of our discussion.)
However, in your last mail, you tell us that "for simple clients, the
trust mechanism cannot rely on any form of certificate
validation...". I do not understand if the SCVP server certificate is=20
no use in the case where all the intended clients are simple clients,
why does the SCVP server still need to have a server certificate?
Why not let th SCVP server directly distribute its own public-key
to all its clients via an out-of-band trusted channel?

It does not make sense to me if you require the SCVP server to
apply a server certificate from a CA but tell the client that it does
not to validate the server certificate and does not need to check
whether the server certificate is revoked by its issuer.

Wen-Cheng=20


Trevor Freeman wrote:
> Hi Wen,
> I would not make that strict interpretation. In all non error cases the
> SCVP is signed. The signature is either a signed data signature using a
> 3280 cert or authenticated data MAC which may contain a 3280 cert.  I do
> not see you mode 1 or 2 as fitting at description. Mode 3 is closer
> except the simple client simply needs a key hash and to be able to parse
> the cert to find the public key and do a comparison. The intent of the
> MAC is to allow client the simplest of validations modes possible.=20
> Trevor
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 7:35 PM
> To: Trevor Freeman
> Cc: [e-mail]
> Subject: RE: How a SCVP client authenticates the SCVP server?
> Hi, Trevor,
> It seems that you are trying to tell us:
> 1. For simple clients, they must authenticate the SCVP server
>    in the fashion of either mode 1 or mode 2 I metntioned.
> 2. For SCVP servers who act as a SCVP client (a SCVP relay),
>    they can authenticate the SCVP server in the fashion of mode 3
>    I mentioned.
> Is my interpretation correct?
> If so, don't you think the text of the current SCVP ID need to be
> changed to support mode 1?
> Best Reagrds,
> Wen-Cheng
> Trevor Freeman wrote:
> > Hi Wen-Cheng,
> > First off consider there are two classes of SCVP clients.=20
> > * Simple clients who only originate SCVP request and=20
> > * SCVP servers who can both service requests and originate their own
> > requests to other SCVP servers(relay).
> > The validation requirements are quite different between the two. For
> > simple clients the trust mechanism cannot rely on any form of
> > certificate validation, but will be achieved by out-of-band
> > configuration of the SCVP server's public signing\authentication key
> or
> > a symmetric shared key. For SCVP server making request of other SCVP
> > servers, then chain validation is legitimate option since the
> discovery
> > and use model is quite different as are the constraints - or relative
> > lack of them- on the servers capabilities. Beyond having certificates
> > conformant to 3280 and having a specific key purpose, I don't think we
> > need to be more prescriptive.
> > Trevor
> > -----Original Message-----
> > From: [e-mail]
> [mailto:[e-mail]]
> > On Behalf Of Wen-Cheng Wang
> > Sent: Friday, September 12, 2003 5:00 AM
> > To: [e-mail]
> > Subject: How a SCVP client authenticates the SCVP server?
> > Folks,
> > After the past [SCVP-AIA] discussions and reviewing
> > the current SCVP ID, I feel that it seems to be
> > unclear that how a SCVP client validates the
> > signature on the SCVP response signed by the SCVP
> > server. Since this topic is not directly related to
> > SCVP-AIA, I would like to discuss it in another thread
> > and hope to get some feedbacks from this WG. Especailly,
> > I hope the editors of SCVP ID can tell us what is
> > in their mind when designing the protocol and the
> > message format.
> > When asked how a SCVP client validates the signature
> > on the SCVP response, I believe that the most intuitive
> > answer will be "Use the public-key of the SCVP server
> > to verify the signature." However, the truth is that
> > things might not be as simple as they are looked like.
> > Before a SCVP client using the public-key of the SCVP
> > server, the client MUST make sure the public-key is
> > trustworthy. The question how can the client trust the
> > public-key of the SCVP server? During the [SCVP-AIA]
> > discussions, at least three possibilities are mentioned:
> > 1. The SCVP server first delivered its own public-key to SCVP
> >    clients via an out-of-band trusted channel. A SCVP client
> >    must securely stored the public-key of the SCVP server in its
> >    local environment in advance and then it can use the public-key
> >    to verify the signature of the SCVP server.
> > In this mode, the SCVP server need not to have its own
> > certificate and of course does not need to include its own
> > certificate in the certificates field within the signed SCVP
> > response (i.e., a CMS SignedData). (Note: the current SCVP ID
> > does not allow this mode because it says "The SCVP server MUST
> > include its own certificate in the certificates field within
> > SignedData" in its section 4.
> > Note that, in this mode, the public-key of the SCVP server
> > must be delivered to SCVP clients via an out-of-band
> > trusted channel. (Similar to the way to deliver root key to
> > relying parties.)
> > There is one issue need to be discussed for this mode. Since
> > the SCVP server does not have its own certificate, how can it
> > identify itself in the signed SCVP response? Because the signed
> > response is actually a CMS SignedData, the SCVP server must
> > try to identify itself by using a SignerIdentifier structure,
> > which is
> >   SignerIdentifier ::=3D CHOICE {
> >           issuerAndSerialNumber IssuerAndSerialNumber,
> >           subjectKeyIdentifier [0] SubjectKeyIdentifier }
> > IMO, the SubjectKeyIdentifier field might be the only choice
> > since IssuerAndSerialNumber makes no sense in this case. The
> > problem is there is currently no unique way for generating
> > Key Identifier. For example, if the server side calculates
> > its own key identifier as 160-bit SHA-1 hash value of its
> > public-key while the client side uses 0100 + the least
> > significant 60 bits of the SHA-1 hash value, there will be
> > an interoperability problem.
> > Therefore, if the SCVP is going to support this mode, the protocol
> > might need to define an unique way for generating key identifier.
> > (At least, within the scope of SCVP.)
> > 2. The SCVP server first signed itw own certificate (i.e., a
> >    self-signed certificate) and delivered the self-signed certificate
> >    to SCVP clients via an out-of-band trusted channel. A SCVP client
> >    must securely stored the self-signed certificate of the SCVP server
> >    in its local environment in advance and it can use the public-key
> >    in the self-signed certificate of the SCVP server to verify
> >    the signature of the SCVP server.
> > Note that, as the same reason why a self-signed certificate of a
> > root CA must be deliverd to relying parties via an out-of-band
> > trusted channel, the self-signed certificate of the SCVP server
> > must be delivered to SCVP clients via an out-of-band trusted
> > channel. Also, a SCVP client must securely stores the self-signed
> > certificate of the SCVP server in its local environment and then
> > use the public-key within the certificate to verify the signature
> > of the SCVP server.
> > My opinion is mode 2 is actually equal to mode 1 except that
> > the OCSP server can now identify itself by using either
> > IssuerAndSerialNumber field or SubjectKeyIdentifier field
> > in a SignerIdentifier structure and it burdens the SCVP server
> > with the overhead of creating its own self-signed certificate.
> > Personally, I am not in favor of mode 2 because I believe that
> > a SCVP server is simply an EE from the viewpoint of the PKI and
> > I doubt whether a self-signed EE certificate is a legal X.509
> > certificate and I also doubt whether PKIX should encourge an EE
> > to create its own self-signed certificate.
> > 3. The SCVP server certificate should be signed by a CA. The SCVP
> >    server can then include its own certificate in the signed SCVP
> >    response. After receiving the signed response, a SCVP client
> >    must validate the SCVP server certificate first to determine
> >    whether it is a trusted SCVP server. And then the SCVP client
> >    can use the public-key in the SCVP server certificate to verify
> >    the signature of the SCVP server.
> >   =20
> > It seems that the procedure describe in mode 3 is very reasonable
> > and straightforward. Believe me, it is not that simple. Please
> > note that a SCVP client must validate the SCVP server certificate
> > first after receiving the signed response and before can use the
> > public-key in the SCVP server certificate to verify the signature
> > of the SCVP server. That is sort of similar to ask an OCSP
> > client to check the status of the OCSP server certificate before
> > it can use the public-key in that certificate to verify the
> > signature of the OCSP server. It is a chicken-and-egg problem.
> > Let's think about why a RP (a certificate-using application) wants
> > to delegate the job of certification path construction/validation
> > to a SCVP Server. I believe that one possibile reason is the
> > implementator of the certificate-using application is not capable
> > of implementing the complex certification path
> > construction/validation algorithm and therefore decide to delegate
> > that job to a SCVP server because he/she heard of the SCVP is the
> > savior of the certificate-using application implementator.
> > Unfortunately, the application implementator will eventually find
> > that he/she still need to implementing the complex certification
> > path construction/validation algorithm because the SCVP client
> > side must validate the SCVP server certificate first and that
> > might invloves constructing a certification path from the SCVP
> > server certificate to the RP's trust anchor and the validating
> > the certification path. Therefore, I do not know how mode 3 works
> > if every certificate-using application does not have its own
> > certification path construction/validation module. Ironically, isn't
> > the original idea of SCVP is to eliminate application implementators'
> > burden for implementing the complex certification path
> > construction/validation.
> > I believe that mode 3 is what in the SCVP ID editors' minds when
> > they design the protocol. Unfortunately, the current SCVP ID does
> > not tell us how a SCVP client can authenticate the SCVP server.
> > At least, the following issues should be discussed.
> > 1. Who should sign the SCVP server certificate?
> > 2. What is the format of the SCVP server certificate?
> >    (Is there any special requirements for the format of
> >     the SCVP server certificate? or is it just a normal EE
> >     signing certificate?)
> > 3. How a SCVP client can validate the SCVP server certificate
> >    without its own certification path construction/validation
> >    module?
> > Can anyone clarify these issues?
> > Best Regards,
> > Wen-Cheng Wang

------=_Part_34_30507140.1063433654205--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D5J8eo028274 for <[e-mail]>; Fri, 12 Sep 2003 22:19:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8D5J7oo028273 for ietf-pkix-bks; Fri, 12 Sep 2003 22:19:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D5J6eo028259 for <[e-mail]>; Fri, 12 Sep 2003 22:19:06 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Sep 2003 22:19:07 -0700
Received: from 157.54.6.197 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Sep 2003 22:19:04 -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(6.0.3790.1060); Fri, 12 Sep 2003 22:18:42 -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(6.0.3790.0); Fri, 12 Sep 2003 22:18:46 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Fri, 12 Sep 2003 22:19:03 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: How a SCVP client authenticates the SCVP server?
Date: Fri, 12 Sep 2003 22:19:07 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: How a SCVP client authenticates the SCVP server?
Thread-Index: AcN5rYK0vmGhEf3TTHOt8YKE6a7mdwABtS3w
From: "Trevor Freeman" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 13 Sep 2003 05:19:03.0606 (UTC) FILETIME=[8BFBF560:01C379B6]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8D5J6eo028268
Sender: [e-mail]
Precedence: 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 Wen,
I would not make that strict interpretation. In all non error cases the
SCVP is signed. The signature is either a signed data signature using a
3280 cert or authenticated data MAC which may contain a 3280 cert.  I do
not see you mode 1 or 2 as fitting at description. Mode 3 is closer
except the simple client simply needs a key hash and to be able to parse
the cert to find the public key and do a comparison. The intent of the
MAC is to allow client the simplest of validations modes possible. 

Trevor

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Wen-Cheng Wang
Sent: Friday, September 12, 2003 7:35 PM
To: Trevor Freeman
Cc: [e-mail]
Subject: RE: How a SCVP client authenticates the SCVP server?

Hi, Trevor,

It seems that you are trying to tell us:

1. For simple clients, they must authenticate the SCVP server
   in the fashion of either mode 1 or mode 2 I metntioned.
2. For SCVP servers who act as a SCVP client (a SCVP relay),
   they can authenticate the SCVP server in the fashion of mode 3
   I mentioned.

Is my interpretation correct?

If so, don't you think the text of the current SCVP ID need to be
changed to support mode 1?

Best Reagrds,
Wen-Cheng

Trevor Freeman wrote:
> Hi Wen-Cheng,
> First off consider there are two classes of SCVP clients. 
> * Simple clients who only originate SCVP request and 
> * SCVP servers who can both service requests and originate their own
> requests to other SCVP servers(relay).
> The validation requirements are quite different between the two. For
> simple clients the trust mechanism cannot rely on any form of
> certificate validation, but will be achieved by out-of-band
> configuration of the SCVP server's public signing\authentication key
or
> a symmetric shared key. For SCVP server making request of other SCVP
> servers, then chain validation is legitimate option since the
discovery
> and use model is quite different as are the constraints - or relative
> lack of them- on the servers capabilities. Beyond having certificates
> conformant to 3280 and having a specific key purpose, I don't think we
> need to be more prescriptive.
> Trevor
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 5:00 AM
> To: [e-mail]
> Subject: How a SCVP client authenticates the SCVP server?
> Folks,
> After the past [SCVP-AIA] discussions and reviewing
> the current SCVP ID, I feel that it seems to be
> unclear that how a SCVP client validates the
> signature on the SCVP response signed by the SCVP
> server. Since this topic is not directly related to
> SCVP-AIA, I would like to discuss it in another thread
> and hope to get some feedbacks from this WG. Especailly,
> I hope the editors of SCVP ID can tell us what is
> in their mind when designing the protocol and the
> message format.
> When asked how a SCVP client validates the signature
> on the SCVP response, I believe that the most intuitive
> answer will be "Use the public-key of the SCVP server
> to verify the signature." However, the truth is that
> things might not be as simple as they are looked like.
> Before a SCVP client using the public-key of the SCVP
> server, the client MUST make sure the public-key is
> trustworthy. The question how can the client trust the
> public-key of the SCVP server? During the [SCVP-AIA]
> discussions, at least three possibilities are mentioned:
> 1. The SCVP server first delivered its own public-key to SCVP
>    clients via an out-of-band trusted channel. A SCVP client
>    must securely stored the public-key of the SCVP server in its
>    local environment in advance and then it can use the public-key
>    to verify the signature of the SCVP server.
> In this mode, the SCVP server need not to have its own
> certificate and of course does not need to include its own
> certificate in the certificates field within the signed SCVP
> response (i.e., a CMS SignedData). (Note: the current SCVP ID
> does not allow this mode because it says "The SCVP server MUST
> include its own certificate in the certificates field within
> SignedData" in its section 4.
> Note that, in this mode, the public-key of the SCVP server
> must be delivered to SCVP clients via an out-of-band
> trusted channel. (Similar to the way to deliver root key to
> relying parties.)
> There is one issue need to be discussed for this mode. Since
> the SCVP server does not have its own certificate, how can it
> identify itself in the signed SCVP response? Because the signed
> response is actually a CMS SignedData, the SCVP server must
> try to identify itself by using a SignerIdentifier structure,
> which is
>   SignerIdentifier ::= CHOICE {
>           issuerAndSerialNumber IssuerAndSerialNumber,
>           subjectKeyIdentifier [0] SubjectKeyIdentifier }
> IMO, the SubjectKeyIdentifier field might be the only choice
> since IssuerAndSerialNumber makes no sense in this case. The
> problem is there is currently no unique way for generating
> Key Identifier. For example, if the server side calculates
> its own key identifier as 160-bit SHA-1 hash value of its
> public-key while the client side uses 0100 + the least
> significant 60 bits of the SHA-1 hash value, there will be
> an interoperability problem.
> Therefore, if the SCVP is going to support this mode, the protocol
> might need to define an unique way for generating key identifier.
> (At least, within the scope of SCVP.)
> 2. The SCVP server first signed itw own certificate (i.e., a
>    self-signed certificate) and delivered the self-signed certificate
>    to SCVP clients via an out-of-band trusted channel. A SCVP client
>    must securely stored the self-signed certificate of the SCVP server
>    in its local environment in advance and it can use the public-key
>    in the self-signed certificate of the SCVP server to verify
>    the signature of the SCVP server.
> Note that, as the same reason why a self-signed certificate of a
> root CA must be deliverd to relying parties via an out-of-band
> trusted channel, the self-signed certificate of the SCVP server
> must be delivered to SCVP clients via an out-of-band trusted
> channel. Also, a SCVP client must securely stores the self-signed
> certificate of the SCVP server in its local environment and then
> use the public-key within the certificate to verify the signature
> of the SCVP server.
> My opinion is mode 2 is actually equal to mode 1 except that
> the OCSP server can now identify itself by using either
> IssuerAndSerialNumber field or SubjectKeyIdentifier field
> in a SignerIdentifier structure and it burdens the SCVP server
> with the overhead of creating its own self-signed certificate.
> Personally, I am not in favor of mode 2 because I believe that
> a SCVP server is simply an EE from the viewpoint of the PKI and
> I doubt whether a self-signed EE certificate is a legal X.509
> certificate and I also doubt whether PKIX should encourge an EE
> to create its own self-signed certificate.
> 3. The SCVP server certificate should be signed by a CA. The SCVP
>    server can then include its own certificate in the signed SCVP
>    response. After receiving the signed response, a SCVP client
>    must validate the SCVP server certificate first to determine
>    whether it is a trusted SCVP server. And then the SCVP client
>    can use the public-key in the SCVP server certificate to verify
>    the signature of the SCVP server.
>    
> It seems that the procedure describe in mode 3 is very reasonable
> and straightforward. Believe me, it is not that simple. Please
> note that a SCVP client must validate the SCVP server certificate
> first after receiving the signed response and before can use the
> public-key in the SCVP server certificate to verify the signature
> of the SCVP server. That is sort of similar to ask an OCSP
> client to check the status of the OCSP server certificate before
> it can use the public-key in that certificate to verify the
> signature of the OCSP server. It is a chicken-and-egg problem.
> Let's think about why a RP (a certificate-using application) wants
> to delegate the job of certification path construction/validation
> to a SCVP Server. I believe that one possibile reason is the
> implementator of the certificate-using application is not capable
> of implementing the complex certification path
> construction/validation algorithm and therefore decide to delegate
> that job to a SCVP server because he/she heard of the SCVP is the
> savior of the certificate-using application implementator.
> Unfortunately, the application implementator will eventually find
> that he/she still need to implementing the complex certification
> path construction/validation algorithm because the SCVP client
> side must validate the SCVP server certificate first and that
> might invloves constructing a certification path from the SCVP
> server certificate to the RP's trust anchor and the validating
> the certification path. Therefore, I do not know how mode 3 works
> if every certificate-using application does not have its own
> certification path construction/validation module. Ironically, isn't
> the original idea of SCVP is to eliminate application implementators'
> burden for implementing the complex certification path
> construction/validation.
> I believe that mode 3 is what in the SCVP ID editors' minds when
> they design the protocol. Unfortunately, the current SCVP ID does
> not tell us how a SCVP client can authenticate the SCVP server.
> At least, the following issues should be discussed.
> 1. Who should sign the SCVP server certificate?
> 2. What is the format of the SCVP server certificate?
>    (Is there any special requirements for the format of
>     the SCVP server certificate? or is it just a normal EE
>     signing certificate?)
> 3. How a SCVP client can validate the SCVP server certificate
>    without its own certification path construction/validation
>    module?
> Can anyone clarify these issues?
> Best Regards,
> Wen-Cheng Wang



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D4h4eo026784 for <[e-mail]>; Fri, 12 Sep 2003 21:43:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8D4h4nn026783 for ietf-pkix-bks; Fri, 12 Sep 2003 21:43:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.pacifier.net (smtp1.pacifier.net [64.255.237.171]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D4h3eo026778 for <[e-mail]>; Fri, 12 Sep 2003 21:43:03 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp1.pacifier.net (Postfix) with ESMTP id 21BA56F495; Fri, 12 Sep 2003 21:43:05 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Manger, James H'" <[e-mail]>, <[e-mail]>
Subject: RE: WG last call - DER-encoded BIT STRING for IPAddress
Date: Fri, 12 Sep 2003 21:44:44 -0700
Message-ID: <00c701c379b1$c0bba0c0$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

I withdraw my objection on this issue.  I still think that some
clarification language on how IPAddresses are encoded makes sense.

jim


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Manger, James H
> Sent: Sunday, September 07, 2003 5:23 PM
> To: [e-mail]
> Subject: RE: WG last call - DER-encoded BIT STRING for IPAddress
> 
> 
> 
> Jim,
> 
> Trailing zeros are NOT removed when DER-encoding a BIT 
> STRING, unless it is a "NamedBitList".  Hence they are not 
> removed when DER-encoding a value of the IPAddress type in 
> draft-ietf-pkix-x509-ipaddr-as-extn-01.txt.
> 
> 
> 
> ITU-T X.690 | ISO/IEC 8825-1 : 1994 "BER, CER & DER":
> 
> 11.2.2 Where ITU-T Rec. X.680 | ISO/IEC 8824-1 clause 19.7 
> applies, the bitstring shall have all trailing 0 bits removed 
> before it is encoded.
> 
> ITU-T X.680 | ISO/IEC 8824-1 : 1994 "ASN.1":
> 
> 19.7 When a "NamedBitList" is used in defining a bitstring 
> type ASN.1 encoding rules are free to add (or remove) 
> arbitrarily many trailing 0 bits to (or from) values that are 
> being encoded or decoded.  Application designers should 
> therefore ensure that different semantics are not associated 
> with such values which differ only in the number of trailing 0 bits.
> 
> 
> -----Original Message-----
> From: Jim Schaad [mailto:[e-mail]]
> Sent: Sunday, 7 September 2003 2:59 PM
> To: 'Stephen Kent'; [e-mail]
> Subject: RE: WG last call
> 
> 
> 
> Steve,
> 
> I have finally figured out what was lying in the back of my 
> mind and screaming at me.
> 
> The element IPAddress cannot be DER encoded.  If you take a 
> bit string and DER encode it, you will automatically remove 
> all trailing zeros as these are assumed not to contain 
> information.  However with IPAddress, the trailing zeros do 
> contain information. 
> 
> The element IPAddress cannot be BER encoded.  An 
> implemeantion can DER encode a bitstring and still claim full 
> compliance to the BER specification.
> 
> I cannot see how this draft can possibly progress without 
> changing the basic type of IPAddress.
> 
> jim
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Jim Schaad
> > Sent: Friday, September 05, 2003 5:35 PM
> > To: 'Stephen Kent'; [e-mail]
> > Subject: RE: WG last call
> > 
> > 
> > 
> > Steve,
> > 
> > Here are my comments on the draft.
> > 
> > 1.  I don't understand doing a draft to define private
> > extensions.  This is the phrase used in the abstract.used in 
> > the message.
> > 
> > 2.  I have a complete lack of understanding on how the IP
> > adresses are to be encoded.  Either a section on this needs 
> > to be added or a reference to this needs to be place in the 
> document.
> > 
> > 3.  There is no ASN.1 module but this document defines new
> > items.  (At least there is no tagging so I don't need to know 
> > explicit vs implicit.)
> > 
> > Jim
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of Stephen Kent
> > > Sent: Tuesday, August 19, 2003 7:02 PM
> > > To: [e-mail]
> > > Subject: WG last call
> > > 
> > > 
> > > 
> > > Folks,
> > > 
> > > We have a relatively old ID that was reposted in June, 
> after minor 
> > > changes in response to some previous comments. The 
> document defines 
> > > two proposed extensions, one to carry IP address prefix
> > data and one
> > > to carry Autonomous System Identifier info, in PK certs. The
> > > extension was developed to enable creation of a PKI that 
> > reflects the
> > > assignment of IP addresses and AS numbers, which happens 
> to be done
> > > in a top down, singly rooted tree fashion, starting with 
> IANA. The 
> > > document is draft-ietf-pkix-x509-ipaddr-as-extn-01.txt.
> > > 
> > > I would like to initiate a 2-week WG last call on this 
> ID. There are 
> > > now a couple of protocols that could make use of this 
> extension in 
> > > different contexts and so it would be good to have it as another, 
> > > completed PKIX item.
> > > 
> > > Since I am a co-author of the document, I will recuse
> > myself from the
> > > process of determining WG consensus in this case, and rely
> > on Tim to
> > > deal with any issues that may arise.
> > > 
> > > Steve
> > > 
> > 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D2oweo023231 for <[e-mail]>; Fri, 12 Sep 2003 19:50:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8D2owPh023230 for ietf-pkix-bks; Fri, 12 Sep 2003 19:50:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.cht.com.tw (fw.cht.com.tw [202.39.162.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8D2oueo023224 for <[e-mail]>; Fri, 12 Sep 2003 19:50:56 -0700 (PDT) (envelope-from [e-mail])
Received: from mailgate.cht.com.tw ([10.1.22.7]) by fw.cht.com.tw (8.12.6/8.12.6) with ESMTP id h8D2n4jO033880; Sat, 13 Sep 2003 10:49:05 +0800 (CST) (envelope-from [e-mail])
Received: from linux01 (webmail.cht.com.tw [10.1.22.40]) by mailgate.cht.com.tw (8.11.6/8.10.2) with ESMTP id h8D2lO315933; Sat, 13 Sep 2003 10:47:24 +0800
Message-ID: <27534070.1063420483808.JavaMail.root@10.1.22.7>
Date: Sat, 13 Sep 2003 10:34:43 +0800 (CST)
From: Wen-Cheng Wang <[e-mail]>
To: "\"Trevor Freeman\"" <[e-mail]>
Subject: RE: How a SCVP client authenticates the SCVP server?
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: multipart/mixed;  boundary="----=_Part_12_12359283.1063420483805"
X-Mailer: WebMail/Java v0.7.10, built with JDK 1.4.1, SendMessage plugin v1.8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_Part_12_12359283.1063420483805
Content-Type: text/plain; charset="Big5"
Content-Transfer-Encoding: quoted-printable

Hi, Trevor,

It seems that you are trying to tell us:

1. For simple clients, they must authenticate the SCVP server
   in the fashion of either mode 1 or mode 2 I metntioned.
2. For SCVP servers who act as a SCVP client (a SCVP relay),
   they can authenticate the SCVP server in the fashion of mode 3
   I mentioned.

Is my interpretation correct?

If so, don't you think the text of the current SCVP ID need to be
changed to support mode 1?

Best Reagrds,
Wen-Cheng

Trevor Freeman wrote:
> Hi Wen-Cheng,
> First off consider there are two classes of SCVP clients.=20
> * Simple clients who only originate SCVP request and=20
> * SCVP servers who can both service requests and originate their own
> requests to other SCVP servers(relay).
> The validation requirements are quite different between the two. For
> simple clients the trust mechanism cannot rely on any form of
> certificate validation, but will be achieved by out-of-band
> configuration of the SCVP server's public signing\authentication key or
> a symmetric shared key. For SCVP server making request of other SCVP
> servers, then chain validation is legitimate option since the discovery
> and use model is quite different as are the constraints - or relative
> lack of them- on the servers capabilities. Beyond having certificates
> conformant to 3280 and having a specific key purpose, I don't think we
> need to be more prescriptive.
> Trevor
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 5:00 AM
> To: [e-mail]
> Subject: How a SCVP client authenticates the SCVP server?
> Folks,
> After the past [SCVP-AIA] discussions and reviewing
> the current SCVP ID, I feel that it seems to be
> unclear that how a SCVP client validates the
> signature on the SCVP response signed by the SCVP
> server. Since this topic is not directly related to
> SCVP-AIA, I would like to discuss it in another thread
> and hope to get some feedbacks from this WG. Especailly,
> I hope the editors of SCVP ID can tell us what is
> in their mind when designing the protocol and the
> message format.
> When asked how a SCVP client validates the signature
> on the SCVP response, I believe that the most intuitive
> answer will be "Use the public-key of the SCVP server
> to verify the signature." However, the truth is that
> things might not be as simple as they are looked like.
> Before a SCVP client using the public-key of the SCVP
> server, the client MUST make sure the public-key is
> trustworthy. The question how can the client trust the
> public-key of the SCVP server? During the [SCVP-AIA]
> discussions, at least three possibilities are mentioned:
> 1. The SCVP server first delivered its own public-key to SCVP
>    clients via an out-of-band trusted channel. A SCVP client
>    must securely stored the public-key of the SCVP server in its
>    local environment in advance and then it can use the public-key
>    to verify the signature of the SCVP server.
> In this mode, the SCVP server need not to have its own
> certificate and of course does not need to include its own
> certificate in the certificates field within the signed SCVP
> response (i.e., a CMS SignedData). (Note: the current SCVP ID
> does not allow this mode because it says "The SCVP server MUST
> include its own certificate in the certificates field within
> SignedData" in its section 4.
> Note that, in this mode, the public-key of the SCVP server
> must be delivered to SCVP clients via an out-of-band
> trusted channel. (Similar to the way to deliver root key to
> relying parties.)
> There is one issue need to be discussed for this mode. Since
> the SCVP server does not have its own certificate, how can it
> identify itself in the signed SCVP response? Because the signed
> response is actually a CMS SignedData, the SCVP server must
> try to identify itself by using a SignerIdentifier structure,
> which is
>   SignerIdentifier ::=3D CHOICE {
>           issuerAndSerialNumber IssuerAndSerialNumber,
>           subjectKeyIdentifier [0] SubjectKeyIdentifier }
> IMO, the SubjectKeyIdentifier field might be the only choice
> since IssuerAndSerialNumber makes no sense in this case. The
> problem is there is currently no unique way for generating
> Key Identifier. For example, if the server side calculates
> its own key identifier as 160-bit SHA-1 hash value of its
> public-key while the client side uses 0100 + the least
> significant 60 bits of the SHA-1 hash value, there will be
> an interoperability problem.
> Therefore, if the SCVP is going to support this mode, the protocol
> might need to define an unique way for generating key identifier.
> (At least, within the scope of SCVP.)
> 2. The SCVP server first signed itw own certificate (i.e., a
>    self-signed certificate) and delivered the self-signed certificate
>    to SCVP clients via an out-of-band trusted channel. A SCVP client
>    must securely stored the self-signed certificate of the SCVP server
>    in its local environment in advance and it can use the public-key
>    in the self-signed certificate of the SCVP server to verify
>    the signature of the SCVP server.
> Note that, as the same reason why a self-signed certificate of a
> root CA must be deliverd to relying parties via an out-of-band
> trusted channel, the self-signed certificate of the SCVP server
> must be delivered to SCVP clients via an out-of-band trusted
> channel. Also, a SCVP client must securely stores the self-signed
> certificate of the SCVP server in its local environment and then
> use the public-key within the certificate to verify the signature
> of the SCVP server.
> My opinion is mode 2 is actually equal to mode 1 except that
> the OCSP server can now identify itself by using either
> IssuerAndSerialNumber field or SubjectKeyIdentifier field
> in a SignerIdentifier structure and it burdens the SCVP server
> with the overhead of creating its own self-signed certificate.
> Personally, I am not in favor of mode 2 because I believe that
> a SCVP server is simply an EE from the viewpoint of the PKI and
> I doubt whether a self-signed EE certificate is a legal X.509
> certificate and I also doubt whether PKIX should encourge an EE
> to create its own self-signed certificate.
> 3. The SCVP server certificate should be signed by a CA. The SCVP
>    server can then include its own certificate in the signed SCVP
>    response. After receiving the signed response, a SCVP client
>    must validate the SCVP server certificate first to determine
>    whether it is a trusted SCVP server. And then the SCVP client
>    can use the public-key in the SCVP server certificate to verify
>    the signature of the SCVP server.
>   =20
> It seems that the procedure describe in mode 3 is very reasonable
> and straightforward. Believe me, it is not that simple. Please
> note that a SCVP client must validate the SCVP server certificate
> first after receiving the signed response and before can use the
> public-key in the SCVP server certificate to verify the signature
> of the SCVP server. That is sort of similar to ask an OCSP
> client to check the status of the OCSP server certificate before
> it can use the public-key in that certificate to verify the
> signature of the OCSP server. It is a chicken-and-egg problem.
> Let's think about why a RP (a certificate-using application) wants
> to delegate the job of certification path construction/validation
> to a SCVP Server. I believe that one possibile reason is the
> implementator of the certificate-using application is not capable
> of implementing the complex certification path
> construction/validation algorithm and therefore decide to delegate
> that job to a SCVP server because he/she heard of the SCVP is the
> savior of the certificate-using application implementator.
> Unfortunately, the application implementator will eventually find
> that he/she still need to implementing the complex certification
> path construction/validation algorithm because the SCVP client
> side must validate the SCVP server certificate first and that
> might invloves constructing a certification path from the SCVP
> server certificate to the RP's trust anchor and the validating
> the certification path. Therefore, I do not know how mode 3 works
> if every certificate-using application does not have its own
> certification path construction/validation module. Ironically, isn't
> the original idea of SCVP is to eliminate application implementators'
> burden for implementing the complex certification path
> construction/validation.
> I believe that mode 3 is what in the SCVP ID editors' minds when
> they design the protocol. Unfortunately, the current SCVP ID does
> not tell us how a SCVP client can authenticate the SCVP server.
> At least, the following issues should be discussed.
> 1. Who should sign the SCVP server certificate?
> 2. What is the format of the SCVP server certificate?
>    (Is there any special requirements for the format of
>     the SCVP server certificate? or is it just a normal EE
>     signing certificate?)
> 3. How a SCVP client can validate the SCVP server certificate
>    without its own certification path construction/validation
>    module?
> Can anyone clarify these issues?
> Best Regards,
> Wen-Cheng Wang
------=_Part_12_12359283.1063420483805--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CMRDeo013762 for <[e-mail]>; Fri, 12 Sep 2003 15:27:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CMRDAe013761 for ietf-pkix-bks; Fri, 12 Sep 2003 15:27:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CMRBeo013755 for <[e-mail]>; Fri, 12 Sep 2003 15:27:12 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h8CMR80w023078; Fri, 12 Sep 2003 18:27:09 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210621bb87f82d77c6@[128.89.89.82]>
In-Reply-To:  <[e-mail] dev.microsoft.com>
References:  <[e-mail] dev.microsoft.com>
Date: Fri, 12 Sep 2003 18:26:57 -0400
To: "Trevor Freeman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: How a SCVP client authenticates the SCVP server?
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 14:49 -0700 9/12/03, Trevor Freeman wrote:
>Hi Wen-Cheng,
>First off consider there are two classes of SCVP clients.
>* Simple clients who only originate SCVP request and
>* SCVP servers who can both service requests and originate their own
>requests to other SCVP servers(relay).
>
>The validation requirements are quite different between the two. For
>simple clients the trust mechanism cannot rely on any form of
>certificate validation, but will be achieved by out-of-band
>configuration of the SCVP server's public signing\authentication key or
>a symmetric shared key. For SCVP server making request of other SCVP
>servers, then chain validation is legitimate option since the discovery
>and use model is quite different as are the constraints - or relative
>lack of them- on the servers capabilities. Beyond having certificates
>conformant to 3280 and having a specific key purpose, I don't think we
>need to be more prescriptive.

Trevor,

You are right that there are two different client types here, which 
suggest to me that we may need two different characterizations of 
what these distinct client types need to support re SCVP server 
validation, and we should further distinguish between DPD and DPV 
use, since the security implications are very different.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CLuVeo011029 for <[e-mail]>; Fri, 12 Sep 2003 14:56:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CLuVuw011028 for ietf-pkix-bks; Fri, 12 Sep 2003 14:56:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CLuTeo011022 for <[e-mail]>; Fri, 12 Sep 2003 14:56:30 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h8CLuN0w021927; Fri, 12 Sep 2003 17:56:23 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210601bb8506da6217@[128.89.89.75]>
In-Reply-To: <003701c376f4$598e4660$[e-mail]>
References: <003701c376f4$598e4660$[e-mail]>
Date: Fri, 12 Sep 2003 17:56:12 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 13:03 -0400 9/9/03, Santosh Chokhani wrote:
>Steve:
>
>The idea proposed is very simply.  Let me summarize it.  The pointer in the
>certificate is used in prioritization/weighing from zero or more choices of
>SCVP Servers.
>
>The prioritization scheme is upto the client and does not impact security or
>interoperability.  That is why it need not be defined.

It does affect security for the client, and as a user I want to know 
how the client will behave. An attractive way for me to know that is 
if we have a standard and the vendor assures me that the client 
software complies with the standard.

>  It can be left up to
>the client.  Of course, regardless of the pointer in the certificate, if the
>client is configured with constraints on an SCVP Server (e.g., in terms of
>policies, name spaces, etc.) the client must enforce those constraints for
>DPV.
>
>While the SCVP pointer in the certificate can be used for DPD, it may be
>used for DPV only if the client is configured with the corresponding SCVP
>Server and the server's public key.  Thus, for DPV, the certificate pointer
>can be used (at most) to prioritize or weigh the multiple SCVP Servers the
>client has.
>
>A compliant client may choose to ignore the SCVP pointer in the certificate
>if it chooses to.

is this choice left to the implementer, or does an administrator have 
control over this?

>See responses in {} with information redacted.
>
>>In all cases, SCVP client will be configured with the SCVP Servers and
>>>their public keys and any constraints in terms of limiting the Server
>>>for policies, name spaces etc.
>>
>>I think this would be reasonable, but where do we say this?
>>
>>[This is appropriate for DPV or trusted SCVP Service.  It should be
>>implicit from SCVP Specification that the clients need the SCVP Server
>>public keys in trusted manner.  Now, in terms of constraints, it should
>>be up to the client whether it trusts an SCVP Server for all names and
>>policies or only some. As to where we say these things, security
>>considerations section of SCVP Server may be one place.  I am sure
>>there are better places.]
>
>Implicit is dangerous! we need more precise discussions of how a
>client that uses SCVP is supposed to work, e.g., in terms of
>configuration data, etc. see my comments to Peter on this topic.
>
>{I do not see any danger in clients using their own algorithms and
>approaches to selecting the order in which SCVP Servers are queried.  We
>need not define the priority or actual algorithm a client uses to define the
>order in which it will query SCVP Servers.  We can write an informational
>RFC on how to configure the client, how to use the SCVP Server pointer.
>But, this is neither a security issue nor an interoperability issue.  If a
>client is configured to trust an SCVP Server for certain name spaces,
>policies, etc., those must be honored}

What I would want to know, as a user, is what algorithm the client 
software uses and how I can control it. if we don't mandate some type 
of admin controls here,  we cannot specify client processing of an 
SCVP response, and we have an incomplete spec. the trick is agreeing 
upon a set of generally useful controls that we want clients to have, 
while not imposing undue complexity on the clients (which we are 
trying to keep simple) and while still ensuring a base level of 
functionality for clients.

>  >>All this will do is select a proper server so that computational
>  >>complexity is reduced.
>>
>>what complexity? the selection of the right server based on the cert
>>presented?
>>
>>[If you do not have any algorithm to try, you will try all of them and
>>on the average n/2 servers, f the client is configured with n servers.
>>This will result in communication delays and needless signature
>>verifications on SCVP Server responses.  Also, whatever work the SCVP
>>server does to determine, it is clueless about the certificate you just
>>asked.]

a simple answer to my question would be "yes."  BTW, the last string 
of words above is also not a sentence :-)

>some strings of words above are not a sentence. so, if we assume N >>
>1, this might be a problem, but in the enterprise case, I would
>generally expect N = 1, right? So, we need to discuss what other
>cases give rise to bigger values for N, and we need to include a
>discussion of why we could not use the scope data for an SCVP server,
>as configured in a client, to determine which server to contact re
>the EE cert in question. I thought we already discussed the dangers
>of having a list of SCVP servers (for DPV) where we would "trust" all
>of them for any cert  we wanted to verify.
>
>{I gave an example of when n>1.  I am not sure if n>>1 to improve
>performance.  We could use the client configuration.  The SCVP pointer is
>another alternative.  A client could use SCVP server based priority only,
>ignore the SCVP Server based priority and use client configuration only, or
>use the combination of the two.}

what you say here is a list of "could's." we need a state machine for 
a client specification, and these could's can become part of that, if 
they are carefully articulated, but not putting them down in a spec 
leaves things very uncertain.

>  >  >I see situations where a person has credentials and hence trust
>>  anchors
>>>(these could be SCVP servers some day) from their employer, from one
>>>or more public sector customers, and one or more private sector
>>>customers. In this cases, none of these are "foreign" CAs.  A pointer
>>>will select the correct SCVP server.  Security and trust will still be
>>>a function of client configuration and under client control.
>>>
>>
>>What is a "public sector customer" relative to the person above. How
>>are these folks "customers" of that person? Same question for the
>>private sector analogs.
>>
>  >[For example, I am a security consultant.  My customers like US
>>Government and Banks want me to use certificates minted by them for me
>  >using their PKI]
>
>These are examples of you selecting the right cert to use when you
>sign something for one of your customers, but you are not the RP in
>that case and SCVP is a service to an RP. are you trying to say that
>when you receive a cert from one of these customers, that you want
>the customer to tell you which SCVP server to invoke for them?
>first, if that;s the intent, the whole discussion above is backwards!
>second, how do you address the issue of limiting the scope for each
>if these servers? I'm not saying that you cannot address the problem,
>but it seems to come and go as a part of the processing you have
>described.
>
>{When I have a certificate of the client for encryption r for digital
>signature verification, I need to verify that the certificate is good.
>Thus, my thin client would like to go to an SCVP Server.  As it so happens,
>my client has a few and I would like to select the correct one}

I am still confused by your text. You indicated, initially, that you 
had several certs issued to you by different CAs, corresponding to 
different clients. That's fine, but you are not an RP when you select 
the right cert to use when signing some data directed to a specific 
client. I think your most recent comment, above, refers to selecting 
the right SCVP server for a cert associated with a client, when 
encrypting some data for that client. Yes, here you are an RP, but 
this is not consistent with the words you used in your example, i.e., 
" My customers like US Government and Banks want me to use 
certificates minted by them for me using their PKI." This text refers 
to your cert, not their cert, hence the confusion.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CLmveo010154 for <[e-mail]>; Fri, 12 Sep 2003 14:48:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CLmvAu010153 for ietf-pkix-bks; Fri, 12 Sep 2003 14:48:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CLmteo010130 for <[e-mail]>; Fri, 12 Sep 2003 14:48:55 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Sep 2003 14:50:10 -0700
Received: from 157.54.8.155 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Sep 2003 14:48:52 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.6713); Fri, 12 Sep 2003 14:49:00 -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(6.0.3790.0); Fri, 12 Sep 2003 14:48:52 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Fri, 12 Sep 2003 14:48:51 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: How a SCVP client authenticates the SCVP server?
Date: Fri, 12 Sep 2003 14:49:05 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: How a SCVP client authenticates the SCVP server?
Thread-Index: AcN5McRG/jj1EpmGS06ApiqQPNMl8gAQ5G9w
From: "Trevor Freeman" <[e-mail]>
To: "Wen-Cheng Wang" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 12 Sep 2003 21:48:51.0523 (UTC) FILETIME=[A7873130:01C37977]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8CLmteo010145
Sender: [e-mail]
Precedence: 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 Wen-Cheng,
First off consider there are two classes of SCVP clients. 
* Simple clients who only originate SCVP request and 
* SCVP servers who can both service requests and originate their own
requests to other SCVP servers(relay).

The validation requirements are quite different between the two. For
simple clients the trust mechanism cannot rely on any form of
certificate validation, but will be achieved by out-of-band
configuration of the SCVP server's public signing\authentication key or
a symmetric shared key. For SCVP server making request of other SCVP
servers, then chain validation is legitimate option since the discovery
and use model is quite different as are the constraints - or relative
lack of them- on the servers capabilities. Beyond having certificates
conformant to 3280 and having a specific key purpose, I don't think we
need to be more prescriptive.

Trevor

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Wen-Cheng Wang
Sent: Friday, September 12, 2003 5:00 AM
To: [e-mail]
Subject: How a SCVP client authenticates the SCVP server?


Folks,

After the past [SCVP-AIA] discussions and reviewing
the current SCVP ID, I feel that it seems to be
unclear that how a SCVP client validates the
signature on the SCVP response signed by the SCVP
server. Since this topic is not directly related to
SCVP-AIA, I would like to discuss it in another thread
and hope to get some feedbacks from this WG. Especailly,
I hope the editors of SCVP ID can tell us what is
in their mind when designing the protocol and the
message format.

When asked how a SCVP client validates the signature
on the SCVP response, I believe that the most intuitive
answer will be "Use the public-key of the SCVP server
to verify the signature." However, the truth is that
things might not be as simple as they are looked like.
Before a SCVP client using the public-key of the SCVP
server, the client MUST make sure the public-key is
trustworthy. The question how can the client trust the
public-key of the SCVP server? During the [SCVP-AIA]
discussions, at least three possibilities are mentioned:

1. The SCVP server first delivered its own public-key to SCVP
   clients via an out-of-band trusted channel. A SCVP client
   must securely stored the public-key of the SCVP server in its
   local environment in advance and then it can use the public-key
   to verify the signature of the SCVP server.

In this mode, the SCVP server need not to have its own
certificate and of course does not need to include its own
certificate in the certificates field within the signed SCVP
response (i.e., a CMS SignedData). (Note: the current SCVP ID
does not allow this mode because it says "The SCVP server MUST
include its own certificate in the certificates field within
SignedData" in its section 4.

Note that, in this mode, the public-key of the SCVP server
must be delivered to SCVP clients via an out-of-band
trusted channel. (Similar to the way to deliver root key to
relying parties.)

There is one issue need to be discussed for this mode. Since
the SCVP server does not have its own certificate, how can it
identify itself in the signed SCVP response? Because the signed
response is actually a CMS SignedData, the SCVP server must
try to identify itself by using a SignerIdentifier structure,
which is

  SignerIdentifier ::= CHOICE {
          issuerAndSerialNumber IssuerAndSerialNumber,
          subjectKeyIdentifier [0] SubjectKeyIdentifier }

IMO, the SubjectKeyIdentifier field might be the only choice
since IssuerAndSerialNumber makes no sense in this case. The
problem is there is currently no unique way for generating
Key Identifier. For example, if the server side calculates
its own key identifier as 160-bit SHA-1 hash value of its
public-key while the client side uses 0100 + the least
significant 60 bits of the SHA-1 hash value, there will be
an interoperability problem.

Therefore, if the SCVP is going to support this mode, the protocol
might need to define an unique way for generating key identifier.
(At least, within the scope of SCVP.)

2. The SCVP server first signed itw own certificate (i.e., a
   self-signed certificate) and delivered the self-signed certificate
   to SCVP clients via an out-of-band trusted channel. A SCVP client
   must securely stored the self-signed certificate of the SCVP server
   in its local environment in advance and it can use the public-key
   in the self-signed certificate of the SCVP server to verify
   the signature of the SCVP server.

Note that, as the same reason why a self-signed certificate of a
root CA must be deliverd to relying parties via an out-of-band
trusted channel, the self-signed certificate of the SCVP server
must be delivered to SCVP clients via an out-of-band trusted
channel. Also, a SCVP client must securely stores the self-signed
certificate of the SCVP server in its local environment and then
use the public-key within the certificate to verify the signature
of the SCVP server.

My opinion is mode 2 is actually equal to mode 1 except that
the OCSP server can now identify itself by using either
IssuerAndSerialNumber field or SubjectKeyIdentifier field
in a SignerIdentifier structure and it burdens the SCVP server
with the overhead of creating its own self-signed certificate.

Personally, I am not in favor of mode 2 because I believe that
a SCVP server is simply an EE from the viewpoint of the PKI and
I doubt whether a self-signed EE certificate is a legal X.509
certificate and I also doubt whether PKIX should encourge an EE
to create its own self-signed certificate.

3. The SCVP server certificate should be signed by a CA. The SCVP
   server can then include its own certificate in the signed SCVP
   response. After receiving the signed response, a SCVP client
   must validate the SCVP server certificate first to determine
   whether it is a trusted SCVP server. And then the SCVP client
   can use the public-key in the SCVP server certificate to verify
   the signature of the SCVP server.
   
It seems that the procedure describe in mode 3 is very reasonable
and straightforward. Believe me, it is not that simple. Please
note that a SCVP client must validate the SCVP server certificate
first after receiving the signed response and before can use the
public-key in the SCVP server certificate to verify the signature
of the SCVP server. That is sort of similar to ask an OCSP
client to check the status of the OCSP server certificate before
it can use the public-key in that certificate to verify the
signature of the OCSP server. It is a chicken-and-egg problem.

Let's think about why a RP (a certificate-using application) wants
to delegate the job of certification path construction/validation
to a SCVP Server. I believe that one possibile reason is the
implementator of the certificate-using application is not capable
of implementing the complex certification path
construction/validation algorithm and therefore decide to delegate
that job to a SCVP server because he/she heard of the SCVP is the
savior of the certificate-using application implementator.
Unfortunately, the application implementator will eventually find
that he/she still need to implementing the complex certification
path construction/validation algorithm because the SCVP client
side must validate the SCVP server certificate first and that
might invloves constructing a certification path from the SCVP
server certificate to the RP's trust anchor and the validating
the certification path. Therefore, I do not know how mode 3 works
if every certificate-using application does not have its own
certification path construction/validation module. Ironically, isn't
the original idea of SCVP is to eliminate application implementators'
burden for implementing the complex certification path
construction/validation.

I believe that mode 3 is what in the SCVP ID editors' minds when
they design the protocol. Unfortunately, the current SCVP ID does
not tell us how a SCVP client can authenticate the SCVP server.
At least, the following issues should be discussed.

1. Who should sign the SCVP server certificate?
2. What is the format of the SCVP server certificate?
   (Is there any special requirements for the format of
    the SCVP server certificate? or is it just a normal EE
    signing certificate?)
3. How a SCVP client can validate the SCVP server certificate
   without its own certification path construction/validation
   module?

Can anyone clarify these issues?

Best Regards,
Wen-Cheng Wang




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CHlseo089817 for <[e-mail]>; Fri, 12 Sep 2003 10:47:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CHlsK8089816 for ietf-pkix-bks; Fri, 12 Sep 2003 10:47:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CHlreo089809 for <[e-mail]>; Fri, 12 Sep 2003 10:47:53 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Sep 2003 10:48:38 -0700
Received: from 157.54.8.109 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Sep 2003 10:47:49 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Sep 2003 10:47:59 -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(6.0.3790.0); Fri, 12 Sep 2003 10:47:37 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Fri, 12 Sep 2003 10:47:47 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Fri, 12 Sep 2003 10:47:45 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN5VDcYtqJ7aiu9R5K4nQqktUbdfQAAWZmg
From: "Ryan M. Hurst" <[e-mail]>
To: "Vadim Fedukovich" <[e-mail]>, <[e-mail]>
X-OriginalArrivalTime: 12 Sep 2003 17:47:47.0341 (UTC) FILETIME=[FA342BD0:01C37955]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8CHlreo089812
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Vadin

My definition of dynamic signing in the context of OCSP is "Signing of
responses on demand" e.g. generating a unique response and signature for
each request.

As for the "expected timeframe" that is a policy decision by the issuer
of the responses.

As for "How the client can be convinced the server supplied a fresh
enough response" the responses contain a ProducedAt value which
indicates when the response was made, this value can be used by the
client to determine if the "freshness" is adequate for their local
policy.

Ryan

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Vadim Fedukovich
Sent: Friday, September 12, 2003 8:16 AM
To: [e-mail]
Subject: Re: [OCSP] are several requests for different CAs at once valid
?


Dear Ryan,

should one read it as a definition:
dynamic signing is a set of pre-produced (or batch-generated) responses?

What is expected timeframe between a revocation request submitted
by a private key owner and availability of an updated OCSP response?

How a client can be convinced the server supplied a fresh enough
response?
..the reason for a client to check the current status is to get some
profs
instead of just trusting the server

thank you,
Vadim

On Fri, Sep 12, 2003 at 07:47:21AM -0700, Ryan M. Hurst wrote:
> Vadim - Traditionally OCSP responders generate and sign responses
on-demand (dynamically), this requires the responders to scale their
infrastructure to handle very high peak volumes. Since many clients,
ours included cache responses this results in most traffic happening at
a fixed time the use of  pre-produced (or batch generated responses)
allows for a number of intersting deployment scenarios leveraging
proxies which enable high volume deployments of OCSP.
> 
> To be clear our client doesnt require this type of deployment, we just
implemented it in such a way to allow for it as our goal is to be able
to support internet scale revocation checking with our customers.
> 
> Ryan
> 
> 
> 
> From: Vadim Fedukovich
> Sent: Fri 9/12/2003 5:33 AM
> To: [e-mail]
> Subject: Re: [OCSP] are several requests for different CAs at once
valid ?
> 
> 
> On Thu, Sep 11, 2003 at 08:57:58PM -0700, Ryan M. Hurst wrote:
> > Done in order to support pre-produced OCSP responses, our goal is to
create solution capable of being deployed in distributed enviroments and
in volumes in-practical to support dynamic signing. This is also why we
default to GET, most HTTP proxies do not support caching of POSTs.
> > 
> > Ryan
> > 
> 
> Dear Ryan,
> 
> what exactly is dynamic signing?
> 
> Vadim
> 
> > 
> > 
> > From: Peter Gutmann
> > Sent: Thu 9/11/2003 8:00 PM
> > To: [e-mail]; [e-mail];
[e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: [OCSP] are several requests for different CAs at once
valid ?
> > 
> > 
> > "Ryan M. Hurst" <[e-mail]> writes:
> > 
> > >Requests do not contain a nonce, and a nonce's in the Responses are
ignored.
> > 
> > Done in order to make replay attacks feasible?
> > 
> > Peter.






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CH99eo086154 for <[e-mail]>; Fri, 12 Sep 2003 10:09:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CH99km086152 for ietf-pkix-bks; Fri, 12 Sep 2003 10:09:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CH97eo086142 for <[e-mail]>; Fri, 12 Sep 2003 10:09:07 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h8CH8o1E007299; Fri, 12 Sep 2003 13:09:03 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210608bb879c24e5bd@[128.33.244.176]>
In-Reply-To: <007b01c37704$d698f9b0$[e-mail]>
References: <007b01c37704$d698f9b0$[e-mail]>
Date: Fri, 12 Sep 2003 11:56:33 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 15:01 -0400 9/9/03, Santosh Chokhani wrote:
>Steve:
>
>The SCVP Server is like AKID and SKID.  They are not needed for security.
>They can aid in path development.
>
>Please see responses in-line in <> with redaction.
>
>
>At 17:36 -0400 9/8/03, Santosh Chokhani wrote:
>
>>But, if an RP is dealing with multiple enterprises, the pointer does
>>help.
>
>so, we have an RP who has no "local" SCVP server; all the servers are
>"foreign" to him, and he has to choose the right one.
>
><I do not think "local", "foreign" etc. are meaningful or should be used.  A
>client has a set of SCVP Servers that it trusts.  It does not matter where
>these servers are physically or organizationally located.  The set could be
>empty and DPD will still work>

you are right that the terms "local" and "foreign" are not precise. 
they are intended to convey the notion of an authority that is 
responsible for an enterprise environment. vs. another authority.

>  >The reason the pointer in the certificate is not critical for DPV also
>>is that the RP client will require some out of band trusted means to
>>obtain the Trusted SCVP Server public key.  For the public key, RP will
>>not rely on the information in the certificate.  All the certificate
>>tells RP is which of the RP client pre-configured servers to try first.
>
>I'm confused again. You say that the client needs to get the public
>key for each server via some other means, not from the cert being
>validated. but then you say that the cert will be used to decide
>which server to "try first."  That seems to suggest that the client
>is willing to let any of these servers verify any cert for him, and
>it's just a matter of which server the cert points to. as I said
>before, this seems to have all the advantages of the browser PKI
>model :-)
>
><Ha, ha.  If the client has constraints on the SCVP Server, it can impose
>them.  Assuming more than one SCVP Servers can be used to verify a
>certificate in question, then the SCVP Server pointer information can be
>used in prioritization, if the client chooses to.>

yes, if the constraints indicate that multiple servers are equally 
acceptable, then an extension could be used for prioritization. but I 
note that you comment speaks in terms of "If the client has 
constraints on the SCVP Server" and that does, in fact, remind me of 
the browser PKI model.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CH99eo086155 for <[e-mail]>; Fri, 12 Sep 2003 10:09:09 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CH99MG086153 for ietf-pkix-bks; Fri, 12 Sep 2003 10:09:09 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CH97eo086141 for <[e-mail]>; Fri, 12 Sep 2003 10:09:07 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h8CH8o1C007299; Fri, 12 Sep 2003 13:09:02 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210607bb87999e4e67@[128.33.244.176]>
In-Reply-To: <003301c376cf$a3d1cf50$[e-mail]>
References: <003301c376cf$a3d1cf50$[e-mail]>
Date: Fri, 12 Sep 2003 11:50:42 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:41 -0400 9/9/03, Santosh Chokhani wrote:
>Steve:
>
>See responses in [] with text redacted.
>
>
>>If a certificate in question has an SCVP Server pointer that also
>>happens to be in the client's list of SCVP Servers whom it trusts, the
>>client uses that SCVP Server for DPD and for DPV.
>
>This description lacks the scope controls you seem to have suggested
>earlier, i.e., what servers are trusted for what sets of certs?
>
>[The scope control could be used in conjunction or in spite of what is in
>the Server.  The way I look at it is a client could select an SCVP Server
>purely based on its configuration, based on some combination of its
>configuration and what is on the certificate, and purely from the
>certificate.  For the DPV services, the selected SCVP Server must be in the
>trust list of the client.  For DPD, this is not needed]

scope control has to be in the client, not a server, since the client 
needs to know what server is appropriate for a given class of query. 
the list of "it could be A or it could be B or it could be C" does 
not given me a warm fuzzy feeling. we know that, without suitable 
scope constraints, basing the selection purely form what is in a cert 
is dangerous for DPV.  That suggests that we need standards, or at a 
minimum, a significant security consideration discussion, or the 
implications for each option. and, if we fail to mandate support for 
any of these options in a standard, users are left wondering what the 
client software will do, and whether what it does is secure.

>  >If the SCVP Server pointed to by the certificate is not in the client's
>>trust list, the Server can be only used for DPD and you know most
>>likely client will have some work remaining to do to find cross
>>certification from RP domain to subscriber domain.
>
>So, if the client needs the DPV service, because it is dumb, it's up
>the creek here? that may be an odd response to finding this SCVP
>extension in an EE cert. I can see instances where this might be OK,
>but in other cases why doesn't the client just contact its "home"
>SCVP server and ask it to perform the DPV service?
>
>[If the client needs a trusted service (e.g., DPV), it needs the SCVP Server
>information such as name and public key pre-configured.  It is unlikely to
>be much help having an SCVP Server pointer whose public key the client does
>not already trust.  In cases where the SCVP Server pointer in the
>certificate is not in the client trust list, the client must use its own
>trust list and any deterministic or heuristic algorithm to go through the
>trust list of SCVP Servers it has]

your starting point above is just what I have been saying, but I 
would like to see agreement on this from all the contributors to this 
discussion. the phrase "client trust list" is a bit too vague for me. 
we need to be more precise. the last sentence above suggests a 
particular behavior that may be appropriate, but what I would like to 
see is concrete text for the SCVP ID, to make clear what we really 
expect a client to do.  Currently we seem to lack the equivalent of a 
state machine for client behavior re SCVP (at least in the case where 
we create an extension of the sort being debated here) and that's not 
OK.

>
>Overall, what I see here is a start at how a client might make use of
>an extension, but with a number of holes to be addressed.
>
>[We can discuss this next time we talk.  While I have tended to be brief, I
>do not see any holes in the approach.  Your points have made the debate more
>clear and my thoughts more sharp, but they have not shown any holes in it.
>My assumption all along has been that if the client does not already trust
>an SCVP Server, a pointer in the certificate is not the right thing since
>then the client will have to do the very path development and validation it
>intended to avoid.]

The "holes" are the unspecified parts (gaps) in the processing 
description, several of which are still part of the discussion above.

steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CGfSeo084928 for <[e-mail]>; Fri, 12 Sep 2003 09:41:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CGfSHK084927 for ietf-pkix-bks; Fri, 12 Sep 2003 09:41:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CGfReo084922 for <[e-mail]>; Fri, 12 Sep 2003 09:41:27 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h8CGfOqp025887; Fri, 12 Sep 2003 12:41:24 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Wen-Cheng Wang'" <[e-mail]>, <[e-mail]>
Subject: RE: How a SCVP client authenticates the SCVP server?
Date: Fri, 12 Sep 2003 12:41:16 -0400
Message-ID: <007401c3794c$b4305e50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <01e601c37925$73b505a0$4f85900a@wcwang>
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8CGfSeo084923
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Well put.

I always assumed that option 3 is not viable for the reasons cited.

I always assumed that if the client relies on SCVP for path validation, it
will have one or more SCVP servers as it trust anchor(s) as opposed to
having Certification Authority(s) as its trust anchor(s).

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Wen-Cheng Wang
Sent: Friday, September 12, 2003 8:00 AM
To: [e-mail]
Subject: How a SCVP client authenticates the SCVP server?



Folks,

After the past [SCVP-AIA] discussions and reviewing
the current SCVP ID, I feel that it seems to be
unclear that how a SCVP client validates the
signature on the SCVP response signed by the SCVP
server. Since this topic is not directly related to
SCVP-AIA, I would like to discuss it in another thread
and hope to get some feedbacks from this WG. Especailly,
I hope the editors of SCVP ID can tell us what is
in their mind when designing the protocol and the
message format.

When asked how a SCVP client validates the signature
on the SCVP response, I believe that the most intuitive
answer will be "Use the public-key of the SCVP server
to verify the signature." However, the truth is that
things might not be as simple as they are looked like.
Before a SCVP client using the public-key of the SCVP
server, the client MUST make sure the public-key is trustworthy. The
question how can the client trust the public-key of the SCVP server? During
the [SCVP-AIA] discussions, at least three possibilities are mentioned:

1. The SCVP server first delivered its own public-key to SCVP
   clients via an out-of-band trusted channel. A SCVP client
   must securely stored the public-key of the SCVP server in its
   local environment in advance and then it can use the public-key
   to verify the signature of the SCVP server.

In this mode, the SCVP server need not to have its own certificate and of
course does not need to include its own certificate in the certificates
field within the signed SCVP response (i.e., a CMS SignedData). (Note: the
current SCVP ID does not allow this mode because it says "The SCVP server
MUST include its own certificate in the certificates field within
SignedData" in its section 4.

Note that, in this mode, the public-key of the SCVP server
must be delivered to SCVP clients via an out-of-band
trusted channel. (Similar to the way to deliver root key to relying
parties.)

There is one issue need to be discussed for this mode. Since the SCVP server
does not have its own certificate, how can it identify itself in the signed
SCVP response? Because the signed response is actually a CMS SignedData, the
SCVP server must try to identify itself by using a SignerIdentifier
structure, which is

  SignerIdentifier ::= CHOICE {
          issuerAndSerialNumber IssuerAndSerialNumber,
          subjectKeyIdentifier [0] SubjectKeyIdentifier }

IMO, the SubjectKeyIdentifier field might be the only choice since
IssuerAndSerialNumber makes no sense in this case. The problem is there is
currently no unique way for generating Key Identifier. For example, if the
server side calculates its own key identifier as 160-bit SHA-1 hash value of
its public-key while the client side uses 0100 + the least significant 60
bits of the SHA-1 hash value, there will be an interoperability problem.

Therefore, if the SCVP is going to support this mode, the protocol might
need to define an unique way for generating key identifier. (At least,
within the scope of SCVP.)

2. The SCVP server first signed itw own certificate (i.e., a
   self-signed certificate) and delivered the self-signed certificate
   to SCVP clients via an out-of-band trusted channel. A SCVP client
   must securely stored the self-signed certificate of the SCVP server
   in its local environment in advance and it can use the public-key
   in the self-signed certificate of the SCVP server to verify
   the signature of the SCVP server.

Note that, as the same reason why a self-signed certificate of a root CA
must be deliverd to relying parties via an out-of-band trusted channel, the
self-signed certificate of the SCVP server must be delivered to SCVP clients
via an out-of-band trusted channel. Also, a SCVP client must securely stores
the self-signed certificate of the SCVP server in its local environment and
then use the public-key within the certificate to verify the signature of
the SCVP server.

My opinion is mode 2 is actually equal to mode 1 except that the OCSP server
can now identify itself by using either IssuerAndSerialNumber field or
SubjectKeyIdentifier field in a SignerIdentifier structure and it burdens
the SCVP server with the overhead of creating its own self-signed
certificate.

Personally, I am not in favor of mode 2 because I believe that a SCVP server
is simply an EE from the viewpoint of the PKI and I doubt whether a
self-signed EE certificate is a legal X.509 certificate and I also doubt
whether PKIX should encourge an EE to create its own self-signed
certificate.

3. The SCVP server certificate should be signed by a CA. The SCVP
   server can then include its own certificate in the signed SCVP
   response. After receiving the signed response, a SCVP client
   must validate the SCVP server certificate first to determine
   whether it is a trusted SCVP server. And then the SCVP client
   can use the public-key in the SCVP server certificate to verify
   the signature of the SCVP server.
   
It seems that the procedure describe in mode 3 is very reasonable and
straightforward. Believe me, it is not that simple. Please note that a SCVP
client must validate the SCVP server certificate first after receiving the
signed response and before can use the public-key in the SCVP server
certificate to verify the signature of the SCVP server. That is sort of
similar to ask an OCSP client to check the status of the OCSP server
certificate before it can use the public-key in that certificate to verify
the signature of the OCSP server. It is a chicken-and-egg problem.

Let's think about why a RP (a certificate-using application) wants to
delegate the job of certification path construction/validation to a SCVP
Server. I believe that one possibile reason is the implementator of the
certificate-using application is not capable of implementing the complex
certification path construction/validation algorithm and therefore decide to
delegate that job to a SCVP server because he/she heard of the SCVP is the
savior of the certificate-using application implementator. Unfortunately,
the application implementator will eventually find that he/she still need to
implementing the complex certification path construction/validation
algorithm because the SCVP client side must validate the SCVP server
certificate first and that might invloves constructing a certification path
from the SCVP server certificate to the RP's trust anchor and the validating
the certification path. Therefore, I do not know how mode 3 works if every
certificate-using application does not have its own certification path
construction/validation module. Ironically, isn't the original idea of SCVP
is to eliminate application implementators' burden for implementing the
complex certification path construction/validation.

I believe that mode 3 is what in the SCVP ID editors' minds when they design
the protocol. Unfortunately, the current SCVP ID does not tell us how a SCVP
client can authenticate the SCVP server. At least, the following issues
should be discussed.

1. Who should sign the SCVP server certificate?
2. What is the format of the SCVP server certificate?
   (Is there any special requirements for the format of
    the SCVP server certificate? or is it just a normal EE
    signing certificate?)
3. How a SCVP client can validate the SCVP server certificate
   without its own certification path construction/validation
   module?

Can anyone clarify these issues?

Best Regards,
Wen-Cheng Wang




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CFFueo079275 for <[e-mail]>; Fri, 12 Sep 2003 08:15:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CFFuWN079274 for ietf-pkix-bks; Fri, 12 Sep 2003 08:15:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from main.giknpc.com.ua (backup.adm.dp.ua [212.86.233.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CFFpeo079246 for <[e-mail]>; Fri, 12 Sep 2003 08:15:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from vf@localhost) by main.giknpc.com.ua (8.11.6/8.11.6) id h8CFFkO16027 for [e-mail]; Fri, 12 Sep 2003 18:15:46 +0300
Date: Fri, 12 Sep 2003 18:15:46 +0300
From: Vadim Fedukovich <[e-mail]>
To: [e-mail]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <9CB9CE0D-518D-45D2-B6BA-6D01C2C9D2BA@mimectl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <9CB9CE0D-518D-45D2-B6BA-6D01C2C9D2BA@mimectl>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: 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 Ryan,

should one read it as a definition:
dynamic signing is a set of pre-produced (or batch-generated) responses?

What is expected timeframe between a revocation request submitted
by a private key owner and availability of an updated OCSP response?

How a client can be convinced the server supplied a fresh enough response?
..the reason for a client to check the current status is to get some profs
instead of just trusting the server

thank you,
Vadim

On Fri, Sep 12, 2003 at 07:47:21AM -0700, Ryan M. Hurst wrote:
> Vadim - Traditionally OCSP responders generate and sign responses on-demand (dynamically), this requires the responders to scale their infrastructure to handle very high peak volumes. Since many clients, ours included cache responses this results in most traffic happening at a fixed time the use of  pre-produced (or batch generated responses) allows for a number of intersting deployment scenarios leveraging proxies which enable high volume deployments of OCSP.
> 
> To be clear our client doesnt require this type of deployment, we just implemented it in such a way to allow for it as our goal is to be able to support internet scale revocation checking with our customers.
> 
> Ryan
> 
> 
> 
> From: Vadim Fedukovich
> Sent: Fri 9/12/2003 5:33 AM
> To: [e-mail]
> Subject: Re: [OCSP] are several requests for different CAs at once valid ?
> 
> 
> On Thu, Sep 11, 2003 at 08:57:58PM -0700, Ryan M. Hurst wrote:
> > Done in order to support pre-produced OCSP responses, our goal is to create solution capable of being deployed in distributed enviroments and in volumes in-practical to support dynamic signing. This is also why we default to GET, most HTTP proxies do not support caching of POSTs.
> > 
> > Ryan
> > 
> 
> Dear Ryan,
> 
> what exactly is dynamic signing?
> 
> Vadim
> 
> > 
> > 
> > From: Peter Gutmann
> > Sent: Thu 9/11/2003 8:00 PM
> > To: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> > Cc: [e-mail]
> > Subject: RE: [OCSP] are several requests for different CAs at once valid ?
> > 
> > 
> > "Ryan M. Hurst" <[e-mail]> writes:
> > 
> > >Requests do not contain a nonce, and a nonce's in the Responses are ignored.
> > 
> > Done in order to make replay attacks feasible?
> > 
> > Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CElSeo076667 for <[e-mail]>; Fri, 12 Sep 2003 07:47:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CElSYv076666 for ietf-pkix-bks; Fri, 12 Sep 2003 07:47:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CElReo076639 for <[e-mail]>; Fri, 12 Sep 2003 07:47:27 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 12 Sep 2003 07:46:44 -0700
Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 12 Sep 2003 07:47:22 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 12 Sep 2003 07:47:18 -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(6.0.3790.0); Fri, 12 Sep 2003 07:47:18 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Fri, 12 Sep 2003 07:47:22 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.6944
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Mime-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <958E6100-F4C6-48C5-94F2-B9D329D5872D@mimectl>, <[e-mail]>
To: Vadim Fedukovich <[e-mail]>, <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN5PMWEwFjtQ/X0Smu8LrZTURiKOA==
Message-ID: <9CB9CE0D-518D-45D2-B6BA-6D01C2C9D2BA@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
Date: Fri, 12 Sep 2003 07:47:21 -0700
X-OriginalArrivalTime: 12 Sep 2003 14:47:22.0219 (UTC) FILETIME=[C5EDA3B0:01C3793C]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_91AA6755-E178-4930-9318-9CF2E5402874_"

--_91AA6755-E178-4930-9318-9CF2E5402874_
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Vadim - Traditionally OCSP responders generate and sign responses on-demand=
 (dynamically), this requires the responders to scale their infrastructure =
to handle very high peak volumes. Since many clients, ours included cache r=
esponses this results in most traffic happening at a fixed time the use of =
 pre-produced (or batch generated responses) allows for a number of interst=
ing deployment scenarios leveraging proxies which enable high volume deploy=
ments of OCSP.

To be clear our client doesnt require this type of deployment, we just impl=
emented it in such a way to allow for it as our goal is to be able to suppo=
rt internet scale revocation checking with our customers.

Ryan



From: Vadim Fedukovich
Sent: Fri 9/12/2003 5:33 AM
To: [e-mail]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?


On Thu, Sep 11, 2003 at 08:57:58PM -0700, Ryan M. Hurst wrote:
> Done in order to support pre-produced OCSP responses, our goal is to crea=
te solution capable of being deployed in distributed enviroments and in vol=
umes in-practical to support dynamic signing. This is also why we default t=
o GET, most HTTP proxies do not support caching of POSTs.
>=20
> Ryan
>=20

Dear Ryan,

what exactly is dynamic signing?

Vadim

>=20
>=20
> From: Peter Gutmann
> Sent: Thu 9/11/2003 8:00 PM
> To: [e-mail]; [e-mail]; [e-mail]=
m; [e-mail]
> Cc: [e-mail]
> Subject: RE: [OCSP] are several requests for different CAs at once valid =
?
>=20
>=20
> "Ryan M. Hurst" <[e-mail]> writes:
>=20
> >Requests do not contain a nonce, and a nonce's in the Responses are igno=
red.
>=20
> Done in order to make replay attacks feasible?
>=20
> Peter.

--_91AA6755-E178-4930-9318-9CF2E5402874_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText59001 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Vadim - Traditio=
nally OCSP responders generate and sign responses on-demand (dynamically), =
this requires the responders to scale their infrastructure to handle very h=
igh peak volumes. Since many clients, ours included cache responses this re=
sults in most traffic happening at a fixed time the use of&nbsp; pre-produc=
ed (or batch generated responses) allows for a number of intersting deploym=
ent scenarios leveraging proxies which enable high volume deployments of OC=
SP.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>To be clear our client doesnt re=
quire this type of deployment, we just implemented it in such a way to allo=
w for it as our goal is to be able to support internet scale revocation che=
cking with our customers.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Vadim Fedukovich<BR><B>Sent:</B> =
Fri 9/12/2003 5:33 AM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> Re=
: [OCSP] are several requests for different CAs at once valid ?<BR></FONT><=
BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">On Thu, Sep 11, 2003 at 08:57:58P=
M -0700, Ryan M. Hurst wrote:
&gt; Done in order to support pre-produced OCSP responses, our goal is to c=
reate solution capable of being deployed in distributed enviroments and in =
volumes in-practical to support dynamic signing. This is also why we defaul=
t to GET, most HTTP proxies do not support caching of POSTs.
&gt;=20
&gt; Ryan
&gt;=20

Dear Ryan,

what exactly is dynamic signing?

Vadim

&gt;=20
&gt;=20
&gt; From: Peter Gutmann
&gt; Sent: Thu 9/11/2003 8:00 PM
&gt; To: [e-mail]; [e-mail]; oelmaier@sytrust=
.com; [e-mail]
&gt; Cc: [e-mail]
&gt; Subject: RE: [OCSP] are several requests for different CAs at once val=
id ?
&gt;=20
&gt;=20
&gt; "Ryan M. Hurst" &lt;[e-mail]&gt; writes:
&gt;=20
&gt; &gt;Requests do not contain a nonce, and a nonce's in the Responses ar=
e ignored.
&gt;=20
&gt; Done in order to make replay attacks feasible?
&gt;=20
&gt; Peter.

</PRE></DIV></BODY></HTML>

--_91AA6755-E178-4930-9318-9CF2E5402874_--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CCXheo062453 for <[e-mail]>; Fri, 12 Sep 2003 05:33:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CCXhZK062452 for ietf-pkix-bks; Fri, 12 Sep 2003 05:33:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from main.giknpc.com.ua (backup.adm.dp.ua [212.86.233.14]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CCXMeo062425 for <[e-mail]>; Fri, 12 Sep 2003 05:33:37 -0700 (PDT) (envelope-from [e-mail])
Received: (from vf@localhost) by main.giknpc.com.ua (8.11.6/8.11.6) id h8CCX8410386 for [e-mail]; Fri, 12 Sep 2003 15:33:08 +0300
Date: Fri, 12 Sep 2003 15:33:08 +0300
From: Vadim Fedukovich <[e-mail]>
To: [e-mail]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Message-ID: <[e-mail]>
References: <[e-mail]> <958E6100-F4C6-48C5-94F2-B9D329D5872D@mimectl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <958E6100-F4C6-48C5-94F2-B9D329D5872D@mimectl>
User-Agent: Mutt/1.4.1i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Thu, Sep 11, 2003 at 08:57:58PM -0700, Ryan M. Hurst wrote:
> Done in order to support pre-produced OCSP responses, our goal is to create solution capable of being deployed in distributed enviroments and in volumes in-practical to support dynamic signing. This is also why we default to GET, most HTTP proxies do not support caching of POSTs.
> 
> Ryan
> 

Dear Ryan,

what exactly is dynamic signing?

Vadim

> 
> 
> From: Peter Gutmann
> Sent: Thu 9/11/2003 8:00 PM
> To: [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [OCSP] are several requests for different CAs at once valid ?
> 
> 
> "Ryan M. Hurst" <[e-mail]> writes:
> 
> >Requests do not contain a nonce, and a nonce's in the Responses are ignored.
> 
> Done in order to make replay attacks feasible?
> 
> Peter.



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CC1meo059293 for <[e-mail]>; Fri, 12 Sep 2003 05:01:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CC1map059291 for ietf-pkix-bks; Fri, 12 Sep 2003 05:01:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gate.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CC1geo059274 for <[e-mail]>; Fri, 12 Sep 2003 05:01:45 -0700 (PDT) (envelope-from [e-mail])
Received: from ms7.chttl.com.tw (ms7 [10.144.2.117]) by gate.chttl.com.tw (8.12.9/8.12.9) with ESMTP id h8CC1S3K004616 for <[e-mail]>; Fri, 12 Sep 2003 20:01:29 +0800
Received: (from root@localhost) by ms7.chttl.com.tw (8.12.3/8.12.1) id h8CC1RIm009416 for [e-mail]; Fri, 12 Sep 2003 20:01:27 +0800
Received: from wcwang ([10.144.133.79]) by ms7.chttl.com.tw (8.12.3/8.12.1) with SMTP id h8CC1Q7M009372 for <[e-mail]>; Fri, 12 Sep 2003 20:01:27 +0800
Message-ID: <01e601c37925$73b505a0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>
Subject: How a SCVP client authenticates the SCVP server?
Date: Fri, 12 Sep 2003 20:00:24 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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,

After the past [SCVP-AIA] discussions and reviewing
the current SCVP ID, I feel that it seems to be
unclear that how a SCVP client validates the
signature on the SCVP response signed by the SCVP
server. Since this topic is not directly related to
SCVP-AIA, I would like to discuss it in another thread
and hope to get some feedbacks from this WG. Especailly,
I hope the editors of SCVP ID can tell us what is
in their mind when designing the protocol and the
message format.

When asked how a SCVP client validates the signature
on the SCVP response, I believe that the most intuitive
answer will be "Use the public-key of the SCVP server
to verify the signature." However, the truth is that
things might not be as simple as they are looked like.
Before a SCVP client using the public-key of the SCVP
server, the client MUST make sure the public-key is
trustworthy. The question how can the client trust the
public-key of the SCVP server? During the [SCVP-AIA]
discussions, at least three possibilities are mentioned:

1. The SCVP server first delivered its own public-key to SCVP
   clients via an out-of-band trusted channel. A SCVP client
   must securely stored the public-key of the SCVP server in its
   local environment in advance and then it can use the public-key
   to verify the signature of the SCVP server.

In this mode, the SCVP server need not to have its own
certificate and of course does not need to include its own
certificate in the certificates field within the signed SCVP
response (i.e., a CMS SignedData). (Note: the current SCVP ID
does not allow this mode because it says "The SCVP server MUST
include its own certificate in the certificates field within
SignedData" in its section 4.

Note that, in this mode, the public-key of the SCVP server
must be delivered to SCVP clients via an out-of-band
trusted channel. (Similar to the way to deliver root key to
relying parties.)

There is one issue need to be discussed for this mode. Since
the SCVP server does not have its own certificate, how can it
identify itself in the signed SCVP response? Because the signed
response is actually a CMS SignedData, the SCVP server must
try to identify itself by using a SignerIdentifier structure,
which is

  SignerIdentifier ::= CHOICE {
          issuerAndSerialNumber IssuerAndSerialNumber,
          subjectKeyIdentifier [0] SubjectKeyIdentifier }

IMO, the SubjectKeyIdentifier field might be the only choice
since IssuerAndSerialNumber makes no sense in this case. The
problem is there is currently no unique way for generating
Key Identifier. For example, if the server side calculates
its own key identifier as 160-bit SHA-1 hash value of its
public-key while the client side uses 0100 + the least
significant 60 bits of the SHA-1 hash value, there will be
an interoperability problem.

Therefore, if the SCVP is going to support this mode, the protocol
might need to define an unique way for generating key identifier.
(At least, within the scope of SCVP.)

2. The SCVP server first signed itw own certificate (i.e., a
   self-signed certificate) and delivered the self-signed certificate
   to SCVP clients via an out-of-band trusted channel. A SCVP client
   must securely stored the self-signed certificate of the SCVP server
   in its local environment in advance and it can use the public-key
   in the self-signed certificate of the SCVP server to verify
   the signature of the SCVP server.

Note that, as the same reason why a self-signed certificate of a
root CA must be deliverd to relying parties via an out-of-band
trusted channel, the self-signed certificate of the SCVP server
must be delivered to SCVP clients via an out-of-band trusted
channel. Also, a SCVP client must securely stores the self-signed
certificate of the SCVP server in its local environment and then
use the public-key within the certificate to verify the signature
of the SCVP server.

My opinion is mode 2 is actually equal to mode 1 except that
the OCSP server can now identify itself by using either
IssuerAndSerialNumber field or SubjectKeyIdentifier field
in a SignerIdentifier structure and it burdens the SCVP server
with the overhead of creating its own self-signed certificate.

Personally, I am not in favor of mode 2 because I believe that
a SCVP server is simply an EE from the viewpoint of the PKI and
I doubt whether a self-signed EE certificate is a legal X.509
certificate and I also doubt whether PKIX should encourge an EE
to create its own self-signed certificate.

3. The SCVP server certificate should be signed by a CA. The SCVP
   server can then include its own certificate in the signed SCVP
   response. After receiving the signed response, a SCVP client
   must validate the SCVP server certificate first to determine
   whether it is a trusted SCVP server. And then the SCVP client
   can use the public-key in the SCVP server certificate to verify
   the signature of the SCVP server.
   
It seems that the procedure describe in mode 3 is very reasonable
and straightforward. Believe me, it is not that simple. Please
note that a SCVP client must validate the SCVP server certificate
first after receiving the signed response and before can use the
public-key in the SCVP server certificate to verify the signature
of the SCVP server. That is sort of similar to ask an OCSP
client to check the status of the OCSP server certificate before
it can use the public-key in that certificate to verify the
signature of the OCSP server. It is a chicken-and-egg problem.

Let's think about why a RP (a certificate-using application) wants
to delegate the job of certification path construction/validation
to a SCVP Server. I believe that one possibile reason is the
implementator of the certificate-using application is not capable
of implementing the complex certification path
construction/validation algorithm and therefore decide to delegate
that job to a SCVP server because he/she heard of the SCVP is the
savior of the certificate-using application implementator.
Unfortunately, the application implementator will eventually find
that he/she still need to implementing the complex certification
path construction/validation algorithm because the SCVP client
side must validate the SCVP server certificate first and that
might invloves constructing a certification path from the SCVP
server certificate to the RP's trust anchor and the validating
the certification path. Therefore, I do not know how mode 3 works
if every certificate-using application does not have its own
certification path construction/validation module. Ironically, isn't
the original idea of SCVP is to eliminate application implementators'
burden for implementing the complex certification path
construction/validation.

I believe that mode 3 is what in the SCVP ID editors' minds when
they design the protocol. Unfortunately, the current SCVP ID does
not tell us how a SCVP client can authenticate the SCVP server.
At least, the following issues should be discussed.

1. Who should sign the SCVP server certificate?
2. What is the format of the SCVP server certificate?
   (Is there any special requirements for the format of
    the SCVP server certificate? or is it just a normal EE
    signing certificate?)
3. How a SCVP client can validate the SCVP server certificate
   without its own certification path construction/validation
   module?

Can anyone clarify these issues?

Best Regards,
Wen-Cheng Wang



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CC1meo059292 for <[e-mail]>; Fri, 12 Sep 2003 05:01:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8CC1miP059290 for ietf-pkix-bks; Fri, 12 Sep 2003 05:01:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gate.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8CC1deo059275 for <[e-mail]>; Fri, 12 Sep 2003 05:01:45 -0700 (PDT) (envelope-from [e-mail])
Received: from ms7.chttl.com.tw (ms7 [10.144.2.117]) by gate.chttl.com.tw (8.12.9/8.12.9) with ESMTP id h8CC1N3K004605; Fri, 12 Sep 2003 20:01:23 +0800
Received: (from root@localhost) by ms7.chttl.com.tw (8.12.3/8.12.1) id h8CC1Lxc009347; Fri, 12 Sep 2003 20:01:21 +0800
Received: from wcwang ([10.144.133.79]) by ms7.chttl.com.tw (8.12.3/8.12.1) with SMTP id h8CC1K7M009275; Fri, 12 Sep 2003 20:01:21 +0800
Message-ID: <01e501c37925$702ddab0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 12 Sep 2003 20:00:19 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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,

Since the discussion is not directly related to SCVP-AIA, I
think it is better to create another thread in the mailing list to
discuss them. The topic of the new thread is "How a SCVP
client authenticates the SCVP server?", please give your
comments there.

Best Regards,
Wen-Cheng

> 
> > 
> > Peter,
> > 
> > I think that the SubjectKeyIdentifier field might be the choice.
> 
> Well, at least you my try this one since the other one is not
> possible :-) And then .. even that part is only defined
> in terms of content of a certificate. 
> 
> > I anticipate that this will cause another round of debate on
> > whether the PKIX WG should define an standard way for
> > generating an unique key identifier, but I believe that at
> > least SCVP should define one if it is going to support "a SCVP
> > server without a certficate".
> 
> Well, I can understand the need to support the most simple
> type of validation for such services.
> 
> Anyway, the question is related to "waht does the client do with
> the response." Will it be consumed immediately, not logged,
> not shown to another RP, or what. In this case, all kinds
> of local authentictaion methods are useful. That's why I think
> the actual text is not optimal because IMHO it doesn't cleary 
> separate the payload from security envelope issues. 
> 
> > Well, I think I should further elaborate why the SCVP should
> > allow a SCVP client to directly trust the public-key of a SCVP
> > server without a certificate. I believe that a SCVP service is especially
> > usefull for a dumb RP. (By a dumb RP, I mean a RP which
> > is not capable of doing the complex job of certification path
> > processing by itself) The question is: if a SCVP server include its own
> > certificate within a SCVP Response as required by the current SCVP ID,
> 
> Dumb is what: Although I can see a mode of processing where the
> client code that talks SCVP is not the one that uses the certificate
> to be validated but I am not sure that the SCVP client cannot code
> decode ASN1, at least the current spec is much more difficult to
> handle than parsing an X509 cert. 
> 
> > how does the dumb RP validate the SCVP server certificate before it using
> > the certificate to validate the SCVP response? Shouldn't the RP
> > build a certificate chain from its trust anchor to the SCVP server
> > certificate first and then validate the certificate chain in according
> > with the validation policy or constraints? However, please remember
> > that it is a dumb RP and it is not capable of doing the complex path
> > processing job by itself. If it can do that job by itself, then it is not
> > a dumb RP anymore; and if it is not a dumb RP, it is not necessary
> > to delegate the path processing job to a SCVP Server. Thus if a dumb
> > RP is required to validate the SCVP Server certificate, it will be a
> > chicken-and-egg problem. Therefore, I believe it will be more
> > practical if the SCVP allows a SCVP client to directly trust the public-key
> > of a SCVP server without a certificate.
> 
> There is a difference between path validation of a target cert
> and a path validation of a server cert.  For a locally trusted
> server, the dumb client may for example just have the public key
> of the root and its identity, and then can rather easily validate
> a server cert presented. Or it has a self signed server cert,
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C6BZeo006628 for <[e-mail]>; Thu, 11 Sep 2003 23:11:35 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8C6BZJn006627 for ietf-pkix-bks; Thu, 11 Sep 2003 23:11:35 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C6BYeo006593 for <[e-mail]>; Thu, 11 Sep 2003 23:11:34 -0700 (PDT) (envelope-from [e-mail])
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.9/8.12.9) with SMTP id h8C6BOPo005288; Thu, 11 Sep 2003 23:11:24 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "'Julien Stern'" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 23:14: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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <000001c378be$ac3cc910$4228a8c0@hagen>
Sender: [e-mail]
Precedence: 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 Florian,
    What you are talking about is the VA delegation model, where
you trust an entity to provide responses for *any* CA. This
model *does not* restrict the responses to CAs that chain under
that VA, but to *any* CA. It is part of the direct trust model,
where you are, to use Steve Kent's terminology, using "indirection"
to allow a different key to be used to sign responses than the one
that is trusted.

Once again, to make it clear:

In direct trust, you trust an entity to respond for any CA. This
entity may use indirection to allow it to use a different key
to sign responses than the one that people trust directly.

For CA delegated trust, the CA needs to *directly* issue a certificate
to a responder.

Hope this helps,
Regards,
Ambarish


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Florian Oelmaier
> Sent: Thursday, September 11, 2003 4:45 PM
> To: 'Ambarish Malpani'; 'Julien Stern'; 'Ryan M. Hurst'
> Cc: [e-mail]
> Subject: RE: [OCSP] are several requests for different CAs at once valid
> ?
> 
> 
> 
> Hello Ambarish,
> 
> last time I brought this model to the attention of the list I said:
> 
> Florian Oelmaier:
> > I have seen 2 installations using a fourth model:
> > 
> > ii-a. Signed by a VA with explicit delegation by any CA in the chain.
> > 
> > Thus it is possible to use one OCSP-Responder signed by the Root-CA to
> 
> > answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.
> 
> You answered:
> 
> > Hi Florian,
> >    The model you have seen is compliant with the RFC. It is
> > basically an example of model (iii), where you explicitly
> > trust the root CA to validate all the certificates and allow
> > it to delegate that responsibity to the VA that is actually
> > responding.
> 
> Educated by your comment, I changed my mind and told people that this
> mode of operation IS RfC conform using the model (iii). Should I change
> my mind again? Is it conform or is it not?
> 
> BTW: I never said that I think this is a good idea - I just stated that
> this seems to be a fairly popular idea. And - Peter coming into my mind
> - not always do the people out there care if a special sophisticated
> configuration is RfC-conform or not. 
> 
> Ryan wrote:
> > I have to agree that this is certainly a common customer request; 
> > I have always been leery of implementing such behavior however. 
> > The main reason is that because this behavior would extend the 
> > scope of influence of an issuing CA from having control over the
> > identity of the sub ca to include direct control over the 
> > certificates issued by the sub CA. 
> 
> I see that point - but there are configurations out there where such
> deliberations are not of concern. Sometimes this direct control of the
> root CA is what the customer actually wants. Often Sub-CAs are only used
> to overcome certain compatibility problems.
> 
> Again: I am not promoting this model. I do not promote an inclusion into
> the RfC nor anything else. I am just saying people are using it out
> there. Thus our software supports it. Before the above mention
> discussion there was a disclaimer that this is not RfC conform - after
> Ambarishs comments in April this disclaimer was removed :) Perhaps I
> need to put it in again.
> 
> -- 
> Florian Oelmaier
> SyTrust
> 
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[e-mail]] 
> > Sent: Friday, September 12, 2003 12:06 AM
> > To: 'Florian Oelmaier'; 'Julien Stern'
> > Cc: [e-mail]
> > Subject: RE: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > 
> > 
> > Hi Florian,
> >     This is *not* allowed by RFC 2560. For CA delegated 
> > trust, it specifically says that the CA needs to *directly* 
> > issue  the delegation certificate to the responder.
> > 
> > 
> > Regards,
> > Ambarish
> > 
> > 
> > 2.6  OCSP Signature Authority Delegation
> > 
> >    The key that signs a certificate's status information need 
> > not be the
> >    same key that signed the certificate. A certificate's issuer
> >    explicitly delegates OCSP signing authority by issuing a 
> > certificate
> >    containing a unique value for extendedKeyUsage in the OCSP signer's
> >    certificate. This certificate MUST be issued directly to the
> >    responder by the cognizant CA.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Florian Oelmaier
> > > Sent: Thursday, September 11, 2003 4:54 AM
> > > To: Julien Stern
> > > Cc: [e-mail]
> > > Subject: Re: [OCSP] are several requests for different CAs at 
> > > once valid ?
> > > 
> > > 
> > > 
> > > > When the OCSP can answer for several CAs, I guess that attribute
> > > > certificates would be more appropriate than having different 
> > > > certificates with the same public key signed by several 
> > > CAs, but that
> > > > would clearly make the clients and the servers much more
> > > complex, so
> > > > I'm fairly happy with the way it is ...
> > > 
> > > Perhaps one thing to add here: It seems to be a fairly common
> > > requirement that an OCSP-client is configured to trust 
> > > OCSP-responses from a responder delegated by a CA that is 
> > > higher in the hierarchy than the CA in question.
> > > 
> > > So a company having some Sub-CAs and one OCSP-Responder for
> > > all of them would issue a certificate including 
> > > OCSP-delegation using the Root-CA. Now the clients trust this 
> > > OCSP-Responder for certificates issued by the Root-CA or any 
> > > of its Sub-CAs (or Sub-Sub-CAs). 
> > > 
> > > This seems to be a popular configuration. This means the
> > > OCSP-client vendors will not be surprised if you ask them to 
> > > include support into their software :)
> > > 
> > > --
> > > Florian Oelmaier
> > > SyTrust
> > > 
> > 
> > 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C3vpeo098443 for <[e-mail]>; Thu, 11 Sep 2003 20:57:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8C3vpP2098442 for ietf-pkix-bks; Thu, 11 Sep 2003 20:57:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C3vneo098433 for <[e-mail]>; Thu, 11 Sep 2003 20:57:50 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 11 Sep 2003 20:58:20 -0700
Received: from 157.54.6.197 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Sep 2003 20:57:31 -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(6.0.3790.1060); Thu, 11 Sep 2003 20:58:14 -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(6.0.3790.0); Thu, 11 Sep 2003 20:58:13 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Thu, 11 Sep 2003 20:57:53 -0700
Received: mail.windows.microsoft.com 157.54.12.84 from 157.54.0.155 157.54.0.155 via HTTP with MS-WebStorage 6.5.6944
Received: 157.54.0.155 157.54.0.155 from 157.54.1.69 157.54.1.69 via HTTP with MS-WebStorage 6.5.6944
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
MIME-Version: 1.0
From: "Ryan M. Hurst" <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
To: Peter Gutmann <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary"
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN44g2vnJIN2lFCRXye9vO0gWaRNQ==
Message-ID: <958E6100-F4C6-48C5-94F2-B9D329D5872D@mimectl>
X-Mailer: Microsoft Outlook Web Access 6.5.6944.0
X-MimeCtl: Produced By Microsoft Exchange V6.5.6944.0
Date: Thu, 11 Sep 2003 20:57:58 -0700
X-OriginalArrivalTime: 12 Sep 2003 03:57:53.0007 (UTC) FILETIME=[0A77C7F0:01C378E2]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--------------InterScan_NT_MIME_Boundary
Content-Type: multipart/alternative;
	boundary="_4B93C1E0-5E42-4F72-8BFB-271CC224186A_"

--_4B93C1E0-5E42-4F72-8BFB-271CC224186A_
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Done in order to support pre-produced OCSP responses, our goal is to create=
 solution capable of being deployed in distributed enviroments and in volum=
es in-practical to support dynamic signing. This is also why we default to =
GET, most HTTP proxies do not support caching of POSTs.

Ryan



From: Peter Gutmann
Sent: Thu 9/11/2003 8:00 PM
To: [e-mail]; [e-mail]; [e-mail];=
 [e-mail]
Cc: [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?


"Ryan M. Hurst" <[e-mail]> writes:

>Requests do not contain a nonce, and a nonce's in the Responses are ignore=
d.

Done in order to make replay attacks feasible?

Peter.

--_4B93C1E0-5E42-4F72-8BFB-271CC224186A_
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD></HEAD>
<BODY>
<DIV id=3DidOWAReplyText67776 dir=3Dltr>
<DIV dir=3Dltr><FONT face=3DArial color=3D#000000 size=3D2>Done in order to=
 support pre-produced OCSP responses, our goal is to create solution capabl=
e of being deployed in distributed enviroments and in volumes in-practical =
to support dynamic signing. This is also why we default to GET, most HTTP p=
roxies do not support caching of POSTs.</FONT></DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV dir=3Dltr><FONT face=3DArial size=3D2>Ryan</FONT></DIV></DIV>
<DIV dir=3Dltr><BR>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> Peter Gutmann<BR><B>Sent:</B> Thu=
 9/11/2003 8:00 PM<BR><B>To:</B> [e-mail]; julien.stern@cryptol=
og.com; [e-mail]; [e-mail]<BR><B>Cc:</B> ietf-=
[e-mail]<BR><B>Subject:</B> RE: [OCSP] are several requests for differe=
nt CAs at once valid ?<BR></FONT><BR></DIV>
<DIV><PRE style=3D"WORD-WRAP: break-word">"Ryan M. Hurst" &lt;rmh@windows.m=
icrosoft.com&gt; writes:

&gt;Requests do not contain a nonce, and a nonce's in the Responses are ign=
ored.

Done in order to make replay attacks feasible?

Peter.
</PRE></DIV></BODY></HTML>

--_4B93C1E0-5E42-4F72-8BFB-271CC224186A_--

--------------InterScan_NT_MIME_Boundary--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C2x8eo096188 for <[e-mail]>; Thu, 11 Sep 2003 19:59:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8C2x8PT096187 for ietf-pkix-bks; Thu, 11 Sep 2003 19:59:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C2x6eo096181 for <[e-mail]>; Thu, 11 Sep 2003 19:59:07 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h8C2wsZs019888; Fri, 12 Sep 2003 14:58:54 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h8C30Ur21701; Fri, 12 Sep 2003 15:00:30 +1200
Date: Fri, 12 Sep 2003 15:00:30 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
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>

"Ryan M. Hurst" <[e-mail]> writes:

>Requests do not contain a nonce, and a nonce's in the Responses are ignored.

Done in order to make replay attacks feasible?

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C1vFeo092981 for <[e-mail]>; Thu, 11 Sep 2003 18:57:15 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8C1vFhm092980 for ietf-pkix-bks; Thu, 11 Sep 2003 18:57:15 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C1vEeo092974 for <[e-mail]>; Thu, 11 Sep 2003 18:57:14 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Sep 2003 18:57:13 -0700
Received: from 157.54.6.150 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Sep 2003 18:57:13 -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(6.0.3790.0); Thu, 11 Sep 2003 18:57:03 -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(6.0.3790.0); Thu, 11 Sep 2003 18:57:08 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Thu, 11 Sep 2003 18:57:11 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 18:57:09 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN4yMlhfa42P4xMRMeGgBnj9TO9EAAABrCQ
From: "Ryan M. Hurst" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "Ambarish Malpani" <[e-mail]>, "Julien Stern" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 12 Sep 2003 01:57:11.0931 (UTC) FILETIME=[2E7344B0:01C378D1]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8C1vEeo092976
Sender: [e-mail]
Precedence: 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 gotcha now, this is something we called "VA Delegation" at ValiCert ;)
I don't think any of the RFC documented trust models are relevant to
this though.

On a side note, we have recently implemented an OCSP client for Windows
and the new TLS extensions that allow a server to provide a cached OCSP
response to its client. Some things we did that would be interesting to
other folks would be:
	* Only HTTP is supported as a transport (no HTTPS)
	* HTTP GETs are performed in the first attempt with a fall back
to 
	  HTTP POST if the server connects but doesn't support GET.
	* Requests do not contain a nonce, and a nonce's in the
Responses are
	  ignored.
	* Requests only consist of a single CertID, although responses
with
	  multiple CertIDs are used
	* Responses with critical extensions are treated as errors, all
other
	  extensions are ignored
	* Only CA signed or CA delegated responses are trusted
	* Request signing is not supported

We have interoped with several implementations, including yours
successfully; full attendees going to the MSFT Profesional Developers
Conference will get a build of Windows including this capabilities in
it.

If any of you have also implemented the TLS extensions, let us know as I
would like to interop with some one else on this.

Ryan



-----Original Message-----
From: Florian Oelmaier [mailto:[e-mail]] 
Sent: Thursday, September 11, 2003 5:57 PM
To: Ryan M. Hurst; 'Ambarish Malpani'; 'Julien Stern'
Cc: [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?

> I am not sure I understand your "CA List" model, are you 
> saying "Here is a list of responders that can respond for 
> this CA" if so then this just sounds like a flexible version of iii

I am saying: "Here are some CAs, whose delegated responders are
explicitly trusted [in this trust setting]". 

The Use-Case is something like: A company has some Subs under a
corporate root, which delegates trust to all corporate OCSP reponders.
My clients shall trust all these responders. If I add another responder
(e.g. due to loadbalancing issues), I want this responder to be trusted
without rolling out its certificate.

The configuration that answers the question "How to determine a trusted
OCSP-Responder?" is called trust setting in our client. The question
"Which trust setting is used for a certain certificate?" can be
configured through a set of filters. For example I can use another trust
setting for Digital Signature Cert as I do for Authentication or
Encryption Cert. I could also use different trust settings based on the
cert issuer.

BTW: All these things are done to emulate SCVP with OCSP. Now that SCVP
is nearly finished, I expect the people using these configurations to
adopt SCVP rather quickly.

> 
> Ryan
> -----Original Message-----
> From: Florian Oelmaier [mailto:[e-mail]] 
> Sent: Thursday, September 11, 2003 5:21 PM
> To: Ryan M. Hurst; 'Ambarish Malpani'; 'Julien Stern'
> Cc: [e-mail]
> Subject: RE: [OCSP] are several requests for different CAs at 
> once valid ?
> 
> 
> Hello Ryan,
> 
> > [rmh] My concern is the implicit trust of the root's va
> > not the explicit configuration (III). Although I dislike client 
> > side configuration due to manageability issues the use of direct
> > trust (III) to accomplish this is kosher in my book :)
> 
> > > > Perhaps one thing to add here: It seems to be a fairly common
> > > > requirement that an OCSP-client is configured to trust 
> > > > OCSP-responses from a responder delegated by a CA that is higher
> > > > in the hierarchy than the CA in question.
> 
> I agree completely with you. By no way I wanted to encourage 
> people to see that as an implicit way of operation. Maybe i 
> was not clear enough on that! 
> 
> In our OCSP-Client you may configure any combination of three modes:
> - implicit trust (models i and ii)
> - list of explicitely trusted responders (model iii)
> - CA list: all OCSP-Responders having a OCSP-delegation 
> certificate of any root-CA in that list are trusted (model iii ???)
> 
> These trust settings may be configured differently for 
> different set of certificates.
> 
> I also know that our OCSP client is not the only client 
> working that way
> :)
> 
> Sorry for the confusion,
> 
> -- 
> Florian Oelmaier
> SyTrust
> 
> 
> > -----Original Message-----
> > From: Ryan M. Hurst [mailto:[e-mail]]
> > Sent: Friday, September 12, 2003 1:57 AM
> > To: Florian Oelmaier; Ambarish Malpani; Julien Stern
> > Cc: [e-mail]
> > Subject: RE: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > 
> > In-line
> > -----Original Message-----
> > From: Florian Oelmaier [mailto:[e-mail]]
> > Sent: Thursday, September 11, 2003 4:45 PM
> > To: 'Ambarish Malpani'; 'Julien Stern'; Ryan M. Hurst
> > Cc: [e-mail]
> > Subject: RE: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > Hello Ambarish,
> > 
> > last time I brought this model to the attention of the list I said:
> > 
> > Florian Oelmaier:
> > > I have seen 2 installations using a fourth model:
> > > 
> > > ii-a. Signed by a VA with explicit delegation by any CA in
> > the chain.
> > > 
> > > Thus it is possible to use one OCSP-Responder signed by the
> > Root-CA to
> > 
> > > answer for all Sub-CAs. Interesting idea. But afaik not 
> RfC-conform.
> > 
> > You answered:
> > 
> > > Hi Florian,
> > >    The model you have seen is compliant with the RFC. It is
> > basically
> > > an example of model (iii), where you explicitly trust the
> > root CA to
> > > validate all the certificates and allow it to delegate that
> > > responsibity to the VA that is actually responding.
> > 
> > Educated by your comment, I changed my mind and told people
> > that this mode of operation IS RfC conform using the model 
> > (iii). Should I change my mind again? Is it conform or is it not?
> > 
> > BTW: I never said that I think this is a good idea - I just
> > stated that this seems to be a fairly popular idea. And - 
> > Peter coming into my mind
> > - not always do the people out there care if a special 
> > sophisticated configuration is RfC-conform or not. 
> > 
> > Ryan wrote:
> > > I have to agree that this is certainly a common customer 
> request; I 
> > > have always been leery of implementing such behavior however. The 
> > > main reason is that because this behavior would extend 
> the scope of 
> > > influence of an issuing CA from having control over the 
> identity of 
> > > the sub ca to include direct control over the 
> certificates issued by 
> > > the sub CA.
> > 
> > I see that point - but there are configurations out there
> > where such deliberations are not of concern. Sometimes this 
> > direct control of the root CA is what the customer actually 
> > wants. Often Sub-CAs are only used to overcome certain 
> > compatibility problems. [rmh] My concern is the implicit 
> > trust of the root's va not the explicit configuration (III). 
> > Although I dislike client side configuration due to 
> > manageability issues the use of direct trust (III) to 
> > accomplish this is kosher in my book :)
> > 
> > Again: I am not promoting this model. I do not promote an
> > inclusion into the RfC nor anything else. I am just saying 
> > people are using it out there. Thus our software supports it. 
> > Before the above mention discussion there was a disclaimer 
> > that this is not RfC conform - after Ambarishs comments in 
> > April this disclaimer was removed :) Perhaps I need to put it 
> > in again.
> > 
> > --
> > Florian Oelmaier
> > SyTrust
> > 
> > > -----Original Message-----
> > > From: Ambarish Malpani [mailto:[e-mail]]
> > > Sent: Friday, September 12, 2003 12:06 AM
> > > To: 'Florian Oelmaier'; 'Julien Stern'
> > > Cc: [e-mail]
> > > Subject: RE: [OCSP] are several requests for different CAs at
> > > once valid ?
> > > 
> > > 
> > > 
> > > Hi Florian,
> > >     This is *not* allowed by RFC 2560. For CA delegated trust, it 
> > > specifically says that the CA needs to *directly* issue  the 
> > > delegation certificate to the responder.
> > > 
> > > 
> > > Regards,
> > > Ambarish
> > > 
> > > 
> > > 2.6  OCSP Signature Authority Delegation
> > > 
> > >    The key that signs a certificate's status information 
> need not be 
> > > the
> > >    same key that signed the certificate. A certificate's issuer
> > >    explicitly delegates OCSP signing authority by issuing a
> > > certificate
> > >    containing a unique value for extendedKeyUsage in the 
> > OCSP signer's
> > >    certificate. This certificate MUST be issued directly to the
> > >    responder by the cognizant CA.
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of 
> > Florian Oelmaier
> > > > Sent: Thursday, September 11, 2003 4:54 AM
> > > > To: Julien Stern
> > > > Cc: [e-mail]
> > > > Subject: Re: [OCSP] are several requests for different 
> CAs at once 
> > > > valid ?
> > > > 
> > > > 
> > > > 
> > > > > When the OCSP can answer for several CAs, I guess that
> > attribute
> > > > > certificates would be more appropriate than having different
> > > > > certificates with the same public key signed by several
> > > > CAs, but that
> > > > > would clearly make the clients and the servers much more
> > > > complex, so
> > > > > I'm fairly happy with the way it is ...
> > > > 
> > > > Perhaps one thing to add here: It seems to be a fairly common
> > > > requirement that an OCSP-client is configured to trust 
> > > > OCSP-responses from a responder delegated by a CA that is 
> > higher in
> > > > the hierarchy than the CA in question.
> > > > 
> > > > So a company having some Sub-CAs and one OCSP-Responder
> > for all of
> > > > them would issue a certificate including OCSP-delegation
> > using the
> > > > Root-CA. Now the clients trust this OCSP-Responder for
> > certificates
> > > > issued by the Root-CA or any of its Sub-CAs (or Sub-Sub-CAs).
> > > > 
> > > > This seems to be a popular configuration. This means the
> > OCSP-client
> > > > vendors will not be surprised if you ask them to include support
> > > > into their software :)
> > > > 
> > > > --
> > > > Florian Oelmaier
> > > > SyTrust
> > > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C0uieo087115 for <[e-mail]>; Thu, 11 Sep 2003 17:56:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8C0uisI087114 for ietf-pkix-bks; Thu, 11 Sep 2003 17:56:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C0ugeo087109 for <[e-mail]>; Thu, 11 Sep 2003 17:56:42 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd03.aul.t-online.de  by mailout05.sul.t-online.com with smtp  id 19xcEr-0002t4-03; Fri, 12 Sep 2003 02:56:41 +0200
Received: from hagen (V8pa9aZEQeb1z37nNuQPvlxzzYlmS67qb5vcTxwythZRNFZhJeHS6l@[217.228.236.136]) by fmrl03.sul.t-online.com with esmtp id 19xcEq-0wkPpI0; Fri, 12 Sep 2003 02:56:40 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, "'Julien Stern'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Fri, 12 Sep 2003 02:56:41 +0200
Organization: SyTrust
Message-ID: <000001c378c8$bad4b3c0$4228a8c0@hagen>
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.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
X-Seen: false
X-ID: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> I am not sure I understand your "CA List" model, are you 
> saying "Here is a list of responders that can respond for 
> this CA" if so then this just sounds like a flexible version of iii

I am saying: "Here are some CAs, whose delegated responders are
explicitly trusted [in this trust setting]". 

The Use-Case is something like: A company has some Subs under a
corporate root, which delegates trust to all corporate OCSP reponders.
My clients shall trust all these responders. If I add another responder
(e.g. due to loadbalancing issues), I want this responder to be trusted
without rolling out its certificate.

The configuration that answers the question "How to determine a trusted
OCSP-Responder?" is called trust setting in our client. The question
"Which trust setting is used for a certain certificate?" can be
configured through a set of filters. For example I can use another trust
setting for Digital Signature Cert as I do for Authentication or
Encryption Cert. I could also use different trust settings based on the
cert issuer.

BTW: All these things are done to emulate SCVP with OCSP. Now that SCVP
is nearly finished, I expect the people using these configurations to
adopt SCVP rather quickly.

> 
> Ryan
> -----Original Message-----
> From: Florian Oelmaier [mailto:[e-mail]] 
> Sent: Thursday, September 11, 2003 5:21 PM
> To: Ryan M. Hurst; 'Ambarish Malpani'; 'Julien Stern'
> Cc: [e-mail]
> Subject: RE: [OCSP] are several requests for different CAs at 
> once valid ?
> 
> 
> Hello Ryan,
> 
> > [rmh] My concern is the implicit trust of the root's va
> > not the explicit configuration (III). Although I dislike client 
> > side configuration due to manageability issues the use of direct
> > trust (III) to accomplish this is kosher in my book :)
> 
> > > > Perhaps one thing to add here: It seems to be a fairly common
> > > > requirement that an OCSP-client is configured to trust 
> > > > OCSP-responses from a responder delegated by a CA that is higher
> > > > in the hierarchy than the CA in question.
> 
> I agree completely with you. By no way I wanted to encourage 
> people to see that as an implicit way of operation. Maybe i 
> was not clear enough on that! 
> 
> In our OCSP-Client you may configure any combination of three modes:
> - implicit trust (models i and ii)
> - list of explicitely trusted responders (model iii)
> - CA list: all OCSP-Responders having a OCSP-delegation 
> certificate of any root-CA in that list are trusted (model iii ???)
> 
> These trust settings may be configured differently for 
> different set of certificates.
> 
> I also know that our OCSP client is not the only client 
> working that way
> :)
> 
> Sorry for the confusion,
> 
> -- 
> Florian Oelmaier
> SyTrust
> 
> 
> > -----Original Message-----
> > From: Ryan M. Hurst [mailto:[e-mail]]
> > Sent: Friday, September 12, 2003 1:57 AM
> > To: Florian Oelmaier; Ambarish Malpani; Julien Stern
> > Cc: [e-mail]
> > Subject: RE: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > 
> > In-line
> > -----Original Message-----
> > From: Florian Oelmaier [mailto:[e-mail]]
> > Sent: Thursday, September 11, 2003 4:45 PM
> > To: 'Ambarish Malpani'; 'Julien Stern'; Ryan M. Hurst
> > Cc: [e-mail]
> > Subject: RE: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > Hello Ambarish,
> > 
> > last time I brought this model to the attention of the list I said:
> > 
> > Florian Oelmaier:
> > > I have seen 2 installations using a fourth model:
> > > 
> > > ii-a. Signed by a VA with explicit delegation by any CA in
> > the chain.
> > > 
> > > Thus it is possible to use one OCSP-Responder signed by the
> > Root-CA to
> > 
> > > answer for all Sub-CAs. Interesting idea. But afaik not 
> RfC-conform.
> > 
> > You answered:
> > 
> > > Hi Florian,
> > >    The model you have seen is compliant with the RFC. It is
> > basically
> > > an example of model (iii), where you explicitly trust the
> > root CA to
> > > validate all the certificates and allow it to delegate that
> > > responsibity to the VA that is actually responding.
> > 
> > Educated by your comment, I changed my mind and told people
> > that this mode of operation IS RfC conform using the model 
> > (iii). Should I change my mind again? Is it conform or is it not?
> > 
> > BTW: I never said that I think this is a good idea - I just
> > stated that this seems to be a fairly popular idea. And - 
> > Peter coming into my mind
> > - not always do the people out there care if a special 
> > sophisticated configuration is RfC-conform or not. 
> > 
> > Ryan wrote:
> > > I have to agree that this is certainly a common customer 
> request; I 
> > > have always been leery of implementing such behavior however. The 
> > > main reason is that because this behavior would extend 
> the scope of 
> > > influence of an issuing CA from having control over the 
> identity of 
> > > the sub ca to include direct control over the 
> certificates issued by 
> > > the sub CA.
> > 
> > I see that point - but there are configurations out there
> > where such deliberations are not of concern. Sometimes this 
> > direct control of the root CA is what the customer actually 
> > wants. Often Sub-CAs are only used to overcome certain 
> > compatibility problems. [rmh] My concern is the implicit 
> > trust of the root's va not the explicit configuration (III). 
> > Although I dislike client side configuration due to 
> > manageability issues the use of direct trust (III) to 
> > accomplish this is kosher in my book :)
> > 
> > Again: I am not promoting this model. I do not promote an
> > inclusion into the RfC nor anything else. I am just saying 
> > people are using it out there. Thus our software supports it. 
> > Before the above mention discussion there was a disclaimer 
> > that this is not RfC conform - after Ambarishs comments in 
> > April this disclaimer was removed :) Perhaps I need to put it 
> > in again.
> > 
> > --
> > Florian Oelmaier
> > SyTrust
> > 
> > > -----Original Message-----
> > > From: Ambarish Malpani [mailto:[e-mail]]
> > > Sent: Friday, September 12, 2003 12:06 AM
> > > To: 'Florian Oelmaier'; 'Julien Stern'
> > > Cc: [e-mail]
> > > Subject: RE: [OCSP] are several requests for different CAs at
> > > once valid ?
> > > 
> > > 
> > > 
> > > Hi Florian,
> > >     This is *not* allowed by RFC 2560. For CA delegated trust, it 
> > > specifically says that the CA needs to *directly* issue  the 
> > > delegation certificate to the responder.
> > > 
> > > 
> > > Regards,
> > > Ambarish
> > > 
> > > 
> > > 2.6  OCSP Signature Authority Delegation
> > > 
> > >    The key that signs a certificate's status information 
> need not be 
> > > the
> > >    same key that signed the certificate. A certificate's issuer
> > >    explicitly delegates OCSP signing authority by issuing a
> > > certificate
> > >    containing a unique value for extendedKeyUsage in the 
> > OCSP signer's
> > >    certificate. This certificate MUST be issued directly to the
> > >    responder by the cognizant CA.
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of 
> > Florian Oelmaier
> > > > Sent: Thursday, September 11, 2003 4:54 AM
> > > > To: Julien Stern
> > > > Cc: [e-mail]
> > > > Subject: Re: [OCSP] are several requests for different 
> CAs at once 
> > > > valid ?
> > > > 
> > > > 
> > > > 
> > > > > When the OCSP can answer for several CAs, I guess that
> > attribute
> > > > > certificates would be more appropriate than having different
> > > > > certificates with the same public key signed by several
> > > > CAs, but that
> > > > > would clearly make the clients and the servers much more
> > > > complex, so
> > > > > I'm fairly happy with the way it is ...
> > > > 
> > > > Perhaps one thing to add here: It seems to be a fairly common
> > > > requirement that an OCSP-client is configured to trust 
> > > > OCSP-responses from a responder delegated by a CA that is 
> > higher in
> > > > the hierarchy than the CA in question.
> > > > 
> > > > So a company having some Sub-CAs and one OCSP-Responder
> > for all of
> > > > them would issue a certificate including OCSP-delegation
> > using the
> > > > Root-CA. Now the clients trust this OCSP-Responder for
> > certificates
> > > > issued by the Root-CA or any of its Sub-CAs (or Sub-Sub-CAs).
> > > > 
> > > > This seems to be a popular configuration. This means the
> > OCSP-client
> > > > vendors will not be surprised if you ask them to include support
> > > > into their software :)
> > > > 
> > > > --
> > > > Florian Oelmaier
> > > > SyTrust
> > > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C0Rjeo085972 for <[e-mail]>; Thu, 11 Sep 2003 17:27:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8C0Rj1o085971 for ietf-pkix-bks; Thu, 11 Sep 2003 17:27:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C0Rheo085966 for <[e-mail]>; Thu, 11 Sep 2003 17:27:43 -0700 (PDT) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 11 Sep 2003 17:27:44 -0700
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Thu, 11 Sep 2003 17:27:49 -0700
Received: from 157.54.8.155 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Sep 2003 17:27:42 -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.6713); Thu, 11 Sep 2003 17:27:40 -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(6.0.3790.0); Thu, 11 Sep 2003 17:27:40 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Thu, 11 Sep 2003 17:27:43 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 17:27:28 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN4w8Ozwd+XZR0cSl+ldB2QIFKswAAAKnqA
From: "Ryan M. Hurst" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "Ambarish Malpani" <[e-mail]>, "Julien Stern" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 12 Sep 2003 00:27:43.0972 (UTC) FILETIME=[AEE5BA40:01C378C4]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8C0Rieo085967
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am not sure I understand your "CA List" model, are you saying "Here is
a list of responders that can respond for this CA" if so then this just
sounds like a flexible version of iii

Ryan
-----Original Message-----
From: Florian Oelmaier [mailto:[e-mail]] 
Sent: Thursday, September 11, 2003 5:21 PM
To: Ryan M. Hurst; 'Ambarish Malpani'; 'Julien Stern'
Cc: [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?


Hello Ryan,

> [rmh] My concern is the implicit trust of the root's va 
> not the explicit configuration (III). Although I dislike client 
> side configuration due to manageability issues the use of direct
> trust (III) to accomplish this is kosher in my book :)

> > > Perhaps one thing to add here: It seems to be a fairly common 
> > > requirement that an OCSP-client is configured to trust 
> > > OCSP-responses from a responder delegated by a CA that is higher
> > > in the hierarchy than the CA in question.

I agree completely with you. By no way I wanted to encourage people to
see that as an implicit way of operation. Maybe i was not clear enough
on that! 

In our OCSP-Client you may configure any combination of three modes:
- implicit trust (models i and ii)
- list of explicitely trusted responders (model iii)
- CA list: all OCSP-Responders having a OCSP-delegation certificate of
any root-CA in that list are trusted (model iii ???)

These trust settings may be configured differently for different set of
certificates.

I also know that our OCSP client is not the only client working that way
:)

Sorry for the confusion,

-- 
Florian Oelmaier
SyTrust


> -----Original Message-----
> From: Ryan M. Hurst [mailto:[e-mail]] 
> Sent: Friday, September 12, 2003 1:57 AM
> To: Florian Oelmaier; Ambarish Malpani; Julien Stern
> Cc: [e-mail]
> Subject: RE: [OCSP] are several requests for different CAs at 
> once valid ?
> 
> 
> In-line
> -----Original Message-----
> From: Florian Oelmaier [mailto:[e-mail]] 
> Sent: Thursday, September 11, 2003 4:45 PM
> To: 'Ambarish Malpani'; 'Julien Stern'; Ryan M. Hurst
> Cc: [e-mail]
> Subject: RE: [OCSP] are several requests for different CAs at 
> once valid ?
> 
> Hello Ambarish,
> 
> last time I brought this model to the attention of the list I said:
> 
> Florian Oelmaier:
> > I have seen 2 installations using a fourth model:
> > 
> > ii-a. Signed by a VA with explicit delegation by any CA in 
> the chain.
> > 
> > Thus it is possible to use one OCSP-Responder signed by the 
> Root-CA to
> 
> > answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.
> 
> You answered:
> 
> > Hi Florian,
> >    The model you have seen is compliant with the RFC. It is 
> basically 
> > an example of model (iii), where you explicitly trust the 
> root CA to 
> > validate all the certificates and allow it to delegate that 
> > responsibity to the VA that is actually responding.
> 
> Educated by your comment, I changed my mind and told people 
> that this mode of operation IS RfC conform using the model 
> (iii). Should I change my mind again? Is it conform or is it not?
> 
> BTW: I never said that I think this is a good idea - I just 
> stated that this seems to be a fairly popular idea. And - 
> Peter coming into my mind
> - not always do the people out there care if a special 
> sophisticated configuration is RfC-conform or not. 
> 
> Ryan wrote:
> > I have to agree that this is certainly a common customer request;
> > I have always been leery of implementing such behavior however. 
> > The main reason is that because this behavior would extend the 
> > scope of influence of an issuing CA from having control over the
> > identity of the sub ca to include direct control over the 
> > certificates issued by the sub CA. 
> 
> I see that point - but there are configurations out there 
> where such deliberations are not of concern. Sometimes this 
> direct control of the root CA is what the customer actually 
> wants. Often Sub-CAs are only used to overcome certain 
> compatibility problems. [rmh] My concern is the implicit 
> trust of the root's va not the explicit configuration (III). 
> Although I dislike client side configuration due to 
> manageability issues the use of direct trust (III) to 
> accomplish this is kosher in my book :)
> 
> Again: I am not promoting this model. I do not promote an 
> inclusion into the RfC nor anything else. I am just saying 
> people are using it out there. Thus our software supports it. 
> Before the above mention discussion there was a disclaimer 
> that this is not RfC conform - after Ambarishs comments in 
> April this disclaimer was removed :) Perhaps I need to put it 
> in again.
> 
> -- 
> Florian Oelmaier
> SyTrust
> 
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[e-mail]]
> > Sent: Friday, September 12, 2003 12:06 AM
> > To: 'Florian Oelmaier'; 'Julien Stern'
> > Cc: [e-mail]
> > Subject: RE: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > 
> > 
> > Hi Florian,
> >     This is *not* allowed by RFC 2560. For CA delegated
> > trust, it specifically says that the CA needs to *directly* 
> > issue  the delegation certificate to the responder.
> > 
> > 
> > Regards,
> > Ambarish
> > 
> > 
> > 2.6  OCSP Signature Authority Delegation
> > 
> >    The key that signs a certificate's status information need
> > not be the
> >    same key that signed the certificate. A certificate's issuer
> >    explicitly delegates OCSP signing authority by issuing a 
> > certificate
> >    containing a unique value for extendedKeyUsage in the 
> OCSP signer's
> >    certificate. This certificate MUST be issued directly to the
> >    responder by the cognizant CA.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of 
> Florian Oelmaier
> > > Sent: Thursday, September 11, 2003 4:54 AM
> > > To: Julien Stern
> > > Cc: [e-mail]
> > > Subject: Re: [OCSP] are several requests for different CAs at
> > > once valid ?
> > > 
> > > 
> > > 
> > > > When the OCSP can answer for several CAs, I guess that 
> attribute 
> > > > certificates would be more appropriate than having different 
> > > > certificates with the same public key signed by several
> > > CAs, but that
> > > > would clearly make the clients and the servers much more
> > > complex, so
> > > > I'm fairly happy with the way it is ...
> > > 
> > > Perhaps one thing to add here: It seems to be a fairly common 
> > > requirement that an OCSP-client is configured to trust 
> > > OCSP-responses from a responder delegated by a CA that is 
> higher in 
> > > the hierarchy than the CA in question.
> > > 
> > > So a company having some Sub-CAs and one OCSP-Responder 
> for all of 
> > > them would issue a certificate including OCSP-delegation 
> using the 
> > > Root-CA. Now the clients trust this OCSP-Responder for 
> certificates 
> > > issued by the Root-CA or any of its Sub-CAs (or Sub-Sub-CAs).
> > > 
> > > This seems to be a popular configuration. This means the 
> OCSP-client 
> > > vendors will not be surprised if you ask them to include support 
> > > into their software :)
> > > 
> > > --
> > > Florian Oelmaier
> > > SyTrust
> > > 
> > 
> > 
> 
> 
> 
> 






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C0Kmeo085700 for <[e-mail]>; Thu, 11 Sep 2003 17:20:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8C0KmMS085699 for ietf-pkix-bks; Thu, 11 Sep 2003 17:20:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8C0Kkeo085694 for <[e-mail]>; Thu, 11 Sep 2003 17:20:47 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd03.aul.t-online.de  by mailout08.sul.t-online.com with smtp  id 19xbg5-0008JK-01; Fri, 12 Sep 2003 02:20:45 +0200
Received: from hagen (bHFKQ4Zvoep9Rfy+JjnmDomxieJ4DLfEWKP5AurChAyJU810vGnkkI@[217.228.236.136]) by fmrl03.sul.t-online.com with esmtp id 19xbg0-2GAoiW0; Fri, 12 Sep 2003 02:20:40 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Ryan M. Hurst'" <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>, "'Julien Stern'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Fri, 12 Sep 2003 02:20:40 +0200
Organization: SyTrust
Message-ID: <000801c378c3$b3226f00$4228a8c0@hagen>
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
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-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>

Hello Ryan,

> [rmh] My concern is the implicit trust of the root's va 
> not the explicit configuration (III). Although I dislike client 
> side configuration due to manageability issues the use of direct
> trust (III) to accomplish this is kosher in my book :)

> > > Perhaps one thing to add here: It seems to be a fairly common 
> > > requirement that an OCSP-client is configured to trust 
> > > OCSP-responses from a responder delegated by a CA that is higher
> > > in the hierarchy than the CA in question.

I agree completely with you. By no way I wanted to encourage people to
see that as an implicit way of operation. Maybe i was not clear enough
on that! 

In our OCSP-Client you may configure any combination of three modes:
- implicit trust (models i and ii)
- list of explicitely trusted responders (model iii)
- CA list: all OCSP-Responders having a OCSP-delegation certificate of
any root-CA in that list are trusted (model iii ???)

These trust settings may be configured differently for different set of
certificates.

I also know that our OCSP client is not the only client working that way
:)

Sorry for the confusion,

-- 
Florian Oelmaier
SyTrust


> -----Original Message-----
> From: Ryan M. Hurst [mailto:[e-mail]] 
> Sent: Friday, September 12, 2003 1:57 AM
> To: Florian Oelmaier; Ambarish Malpani; Julien Stern
> Cc: [e-mail]
> Subject: RE: [OCSP] are several requests for different CAs at 
> once valid ?
> 
> 
> In-line
> -----Original Message-----
> From: Florian Oelmaier [mailto:[e-mail]] 
> Sent: Thursday, September 11, 2003 4:45 PM
> To: 'Ambarish Malpani'; 'Julien Stern'; Ryan M. Hurst
> Cc: [e-mail]
> Subject: RE: [OCSP] are several requests for different CAs at 
> once valid ?
> 
> Hello Ambarish,
> 
> last time I brought this model to the attention of the list I said:
> 
> Florian Oelmaier:
> > I have seen 2 installations using a fourth model:
> > 
> > ii-a. Signed by a VA with explicit delegation by any CA in 
> the chain.
> > 
> > Thus it is possible to use one OCSP-Responder signed by the 
> Root-CA to
> 
> > answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.
> 
> You answered:
> 
> > Hi Florian,
> >    The model you have seen is compliant with the RFC. It is 
> basically 
> > an example of model (iii), where you explicitly trust the 
> root CA to 
> > validate all the certificates and allow it to delegate that 
> > responsibity to the VA that is actually responding.
> 
> Educated by your comment, I changed my mind and told people 
> that this mode of operation IS RfC conform using the model 
> (iii). Should I change my mind again? Is it conform or is it not?
> 
> BTW: I never said that I think this is a good idea - I just 
> stated that this seems to be a fairly popular idea. And - 
> Peter coming into my mind
> - not always do the people out there care if a special 
> sophisticated configuration is RfC-conform or not. 
> 
> Ryan wrote:
> > I have to agree that this is certainly a common customer request;
> > I have always been leery of implementing such behavior however. 
> > The main reason is that because this behavior would extend the 
> > scope of influence of an issuing CA from having control over the
> > identity of the sub ca to include direct control over the 
> > certificates issued by the sub CA. 
> 
> I see that point - but there are configurations out there 
> where such deliberations are not of concern. Sometimes this 
> direct control of the root CA is what the customer actually 
> wants. Often Sub-CAs are only used to overcome certain 
> compatibility problems. [rmh] My concern is the implicit 
> trust of the root's va not the explicit configuration (III). 
> Although I dislike client side configuration due to 
> manageability issues the use of direct trust (III) to 
> accomplish this is kosher in my book :)
> 
> Again: I am not promoting this model. I do not promote an 
> inclusion into the RfC nor anything else. I am just saying 
> people are using it out there. Thus our software supports it. 
> Before the above mention discussion there was a disclaimer 
> that this is not RfC conform - after Ambarishs comments in 
> April this disclaimer was removed :) Perhaps I need to put it 
> in again.
> 
> -- 
> Florian Oelmaier
> SyTrust
> 
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[e-mail]]
> > Sent: Friday, September 12, 2003 12:06 AM
> > To: 'Florian Oelmaier'; 'Julien Stern'
> > Cc: [e-mail]
> > Subject: RE: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > 
> > 
> > Hi Florian,
> >     This is *not* allowed by RFC 2560. For CA delegated
> > trust, it specifically says that the CA needs to *directly* 
> > issue  the delegation certificate to the responder.
> > 
> > 
> > Regards,
> > Ambarish
> > 
> > 
> > 2.6  OCSP Signature Authority Delegation
> > 
> >    The key that signs a certificate's status information need
> > not be the
> >    same key that signed the certificate. A certificate's issuer
> >    explicitly delegates OCSP signing authority by issuing a 
> > certificate
> >    containing a unique value for extendedKeyUsage in the 
> OCSP signer's
> >    certificate. This certificate MUST be issued directly to the
> >    responder by the cognizant CA.
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail] 
> > > [mailto:[e-mail]] On Behalf Of 
> Florian Oelmaier
> > > Sent: Thursday, September 11, 2003 4:54 AM
> > > To: Julien Stern
> > > Cc: [e-mail]
> > > Subject: Re: [OCSP] are several requests for different CAs at
> > > once valid ?
> > > 
> > > 
> > > 
> > > > When the OCSP can answer for several CAs, I guess that 
> attribute 
> > > > certificates would be more appropriate than having different 
> > > > certificates with the same public key signed by several
> > > CAs, but that
> > > > would clearly make the clients and the servers much more
> > > complex, so
> > > > I'm fairly happy with the way it is ...
> > > 
> > > Perhaps one thing to add here: It seems to be a fairly common 
> > > requirement that an OCSP-client is configured to trust 
> > > OCSP-responses from a responder delegated by a CA that is 
> higher in 
> > > the hierarchy than the CA in question.
> > > 
> > > So a company having some Sub-CAs and one OCSP-Responder 
> for all of 
> > > them would issue a certificate including OCSP-delegation 
> using the 
> > > Root-CA. Now the clients trust this OCSP-Responder for 
> certificates 
> > > issued by the Root-CA or any of its Sub-CAs (or Sub-Sub-CAs).
> > > 
> > > This seems to be a popular configuration. This means the 
> OCSP-client 
> > > vendors will not be surprised if you ask them to include support 
> > > into their software :)
> > > 
> > > --
> > > Florian Oelmaier
> > > SyTrust
> > > 
> > 
> > 
> 
> 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BNupeo084907 for <[e-mail]>; Thu, 11 Sep 2003 16:56:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BNup5m084906 for ietf-pkix-bks; Thu, 11 Sep 2003 16:56:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail4.microsoft.com (mail4.microsoft.com [131.107.3.122]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BNuneo084899 for <[e-mail]>; Thu, 11 Sep 2003 16:56:49 -0700 (PDT) (envelope-from [e-mail])
Received: from inet-vrs-04.redmond.corp.microsoft.com ([157.54.8.149]) by mail4.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Sep 2003 16:57:05 -0700
Received: from 157.54.5.25 by inet-vrs-04.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Sep 2003 16:56:48 -0700
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Sep 2003 16:56:50 -0700
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(6.0.3790.1060); Thu, 11 Sep 2003 16:56:47 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Thu, 11 Sep 2003 16:56:47 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 16:56:40 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN4vr2fJCgdFlghQEGXYHUVJsjrxAAAWiRQ
From: "Ryan M. Hurst" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "Ambarish Malpani" <[e-mail]>, "Julien Stern" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Sep 2003 23:56:47.0870 (UTC) FILETIME=[5C9309E0:01C378C0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8BNuneo084902
Sender: [e-mail]
Precedence: 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-line
-----Original Message-----
From: Florian Oelmaier [mailto:[e-mail]] 
Sent: Thursday, September 11, 2003 4:45 PM
To: 'Ambarish Malpani'; 'Julien Stern'; Ryan M. Hurst
Cc: [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?

Hello Ambarish,

last time I brought this model to the attention of the list I said:

Florian Oelmaier:
> I have seen 2 installations using a fourth model:
> 
> ii-a. Signed by a VA with explicit delegation by any CA in the chain.
> 
> Thus it is possible to use one OCSP-Responder signed by the Root-CA to

> answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.

You answered:

> Hi Florian,
>    The model you have seen is compliant with the RFC. It is
> basically an example of model (iii), where you explicitly
> trust the root CA to validate all the certificates and allow
> it to delegate that responsibity to the VA that is actually
> responding.

Educated by your comment, I changed my mind and told people that this
mode of operation IS RfC conform using the model (iii). Should I change
my mind again? Is it conform or is it not?

BTW: I never said that I think this is a good idea - I just stated that
this seems to be a fairly popular idea. And - Peter coming into my mind
- not always do the people out there care if a special sophisticated
configuration is RfC-conform or not. 

Ryan wrote:
> I have to agree that this is certainly a common customer request; 
> I have always been leery of implementing such behavior however. 
> The main reason is that because this behavior would extend the 
> scope of influence of an issuing CA from having control over the
> identity of the sub ca to include direct control over the 
> certificates issued by the sub CA. 

I see that point - but there are configurations out there where such
deliberations are not of concern. Sometimes this direct control of the
root CA is what the customer actually wants. Often Sub-CAs are only used
to overcome certain compatibility problems.
[rmh] My concern is the implicit trust of the root's va not the explicit
configuration (III). Although I dislike client side configuration due to
manageability issues the use of direct trust (III) to accomplish this is
kosher in my book :)

Again: I am not promoting this model. I do not promote an inclusion into
the RfC nor anything else. I am just saying people are using it out
there. Thus our software supports it. Before the above mention
discussion there was a disclaimer that this is not RfC conform - after
Ambarishs comments in April this disclaimer was removed :) Perhaps I
need to put it in again.

-- 
Florian Oelmaier
SyTrust

> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]] 
> Sent: Friday, September 12, 2003 12:06 AM
> To: 'Florian Oelmaier'; 'Julien Stern'
> Cc: [e-mail]
> Subject: RE: [OCSP] are several requests for different CAs at 
> once valid ?
> 
> 
> 
> Hi Florian,
>     This is *not* allowed by RFC 2560. For CA delegated 
> trust, it specifically says that the CA needs to *directly* 
> issue  the delegation certificate to the responder.
> 
> 
> Regards,
> Ambarish
> 
> 
> 2.6  OCSP Signature Authority Delegation
> 
>    The key that signs a certificate's status information need 
> not be the
>    same key that signed the certificate. A certificate's issuer
>    explicitly delegates OCSP signing authority by issuing a 
> certificate
>    containing a unique value for extendedKeyUsage in the OCSP signer's
>    certificate. This certificate MUST be issued directly to the
>    responder by the cognizant CA.
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Florian Oelmaier
> > Sent: Thursday, September 11, 2003 4:54 AM
> > To: Julien Stern
> > Cc: [e-mail]
> > Subject: Re: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > 
> > 
> > > When the OCSP can answer for several CAs, I guess that attribute
> > > certificates would be more appropriate than having different 
> > > certificates with the same public key signed by several 
> > CAs, but that
> > > would clearly make the clients and the servers much more
> > complex, so
> > > I'm fairly happy with the way it is ...
> > 
> > Perhaps one thing to add here: It seems to be a fairly common
> > requirement that an OCSP-client is configured to trust 
> > OCSP-responses from a responder delegated by a CA that is 
> > higher in the hierarchy than the CA in question.
> > 
> > So a company having some Sub-CAs and one OCSP-Responder for
> > all of them would issue a certificate including 
> > OCSP-delegation using the Root-CA. Now the clients trust this 
> > OCSP-Responder for certificates issued by the Root-CA or any 
> > of its Sub-CAs (or Sub-Sub-CAs). 
> > 
> > This seems to be a popular configuration. This means the
> > OCSP-client vendors will not be surprised if you ask them to 
> > include support into their software :)
> > 
> > --
> > Florian Oelmaier
> > SyTrust
> > 
> 
> 






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BNijeo084536 for <[e-mail]>; Thu, 11 Sep 2003 16:44:45 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BNijjc084535 for ietf-pkix-bks; Thu, 11 Sep 2003 16:44:45 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BNiheo084530 for <[e-mail]>; Thu, 11 Sep 2003 16:44:44 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd03.aul.t-online.de  by mailout01.sul.t-online.com with smtp  id 19xb7C-0007bm-02; Fri, 12 Sep 2003 01:44:42 +0200
Received: from hagen (EXSfxGZdgeJpuxe48yHi8AmiNhliFT3HR49CDDaCoiiqZqB3WqF5ZK@[217.228.236.136]) by fmrl03.sul.t-online.com with esmtp id 19xb7B-0vS7Xs0; Fri, 12 Sep 2003 01:44:41 +0200
From: "Florian Oelmaier" <[e-mail]>
To: "'Ambarish Malpani'" <[e-mail]>, "'Julien Stern'" <[e-mail]>, "'Ryan M. Hurst'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Fri, 12 Sep 2003 01:44:41 +0200
Organization: SyTrust
Message-ID: <000001c378be$ac3cc910$4228a8c0@hagen>
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
Importance: Normal
In-Reply-To: <002601c378b0$f0b707d0$[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
X-Seen: false
X-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>

Hello Ambarish,

last time I brought this model to the attention of the list I said:

Florian Oelmaier:
> I have seen 2 installations using a fourth model:
> 
> ii-a. Signed by a VA with explicit delegation by any CA in the chain.
> 
> Thus it is possible to use one OCSP-Responder signed by the Root-CA to

> answer for all Sub-CAs. Interesting idea. But afaik not RfC-conform.

You answered:

> Hi Florian,
>    The model you have seen is compliant with the RFC. It is
> basically an example of model (iii), where you explicitly
> trust the root CA to validate all the certificates and allow
> it to delegate that responsibity to the VA that is actually
> responding.

Educated by your comment, I changed my mind and told people that this
mode of operation IS RfC conform using the model (iii). Should I change
my mind again? Is it conform or is it not?

BTW: I never said that I think this is a good idea - I just stated that
this seems to be a fairly popular idea. And - Peter coming into my mind
- not always do the people out there care if a special sophisticated
configuration is RfC-conform or not. 

Ryan wrote:
> I have to agree that this is certainly a common customer request; 
> I have always been leery of implementing such behavior however. 
> The main reason is that because this behavior would extend the 
> scope of influence of an issuing CA from having control over the
> identity of the sub ca to include direct control over the 
> certificates issued by the sub CA. 

I see that point - but there are configurations out there where such
deliberations are not of concern. Sometimes this direct control of the
root CA is what the customer actually wants. Often Sub-CAs are only used
to overcome certain compatibility problems.

Again: I am not promoting this model. I do not promote an inclusion into
the RfC nor anything else. I am just saying people are using it out
there. Thus our software supports it. Before the above mention
discussion there was a disclaimer that this is not RfC conform - after
Ambarishs comments in April this disclaimer was removed :) Perhaps I
need to put it in again.

-- 
Florian Oelmaier
SyTrust

> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]] 
> Sent: Friday, September 12, 2003 12:06 AM
> To: 'Florian Oelmaier'; 'Julien Stern'
> Cc: [e-mail]
> Subject: RE: [OCSP] are several requests for different CAs at 
> once valid ?
> 
> 
> 
> Hi Florian,
>     This is *not* allowed by RFC 2560. For CA delegated 
> trust, it specifically says that the CA needs to *directly* 
> issue  the delegation certificate to the responder.
> 
> 
> Regards,
> Ambarish
> 
> 
> 2.6  OCSP Signature Authority Delegation
> 
>    The key that signs a certificate's status information need 
> not be the
>    same key that signed the certificate. A certificate's issuer
>    explicitly delegates OCSP signing authority by issuing a 
> certificate
>    containing a unique value for extendedKeyUsage in the OCSP signer's
>    certificate. This certificate MUST be issued directly to the
>    responder by the cognizant CA.
> 
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Florian Oelmaier
> > Sent: Thursday, September 11, 2003 4:54 AM
> > To: Julien Stern
> > Cc: [e-mail]
> > Subject: Re: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > 
> > 
> > > When the OCSP can answer for several CAs, I guess that attribute
> > > certificates would be more appropriate than having different 
> > > certificates with the same public key signed by several 
> > CAs, but that
> > > would clearly make the clients and the servers much more
> > complex, so
> > > I'm fairly happy with the way it is ...
> > 
> > Perhaps one thing to add here: It seems to be a fairly common
> > requirement that an OCSP-client is configured to trust 
> > OCSP-responses from a responder delegated by a CA that is 
> > higher in the hierarchy than the CA in question.
> > 
> > So a company having some Sub-CAs and one OCSP-Responder for
> > all of them would issue a certificate including 
> > OCSP-delegation using the Root-CA. Now the clients trust this 
> > OCSP-Responder for certificates issued by the Root-CA or any 
> > of its Sub-CAs (or Sub-Sub-CAs). 
> > 
> > This seems to be a popular configuration. This means the
> > OCSP-client vendors will not be surprised if you ask them to 
> > include support into their software :)
> > 
> > --
> > Florian Oelmaier
> > SyTrust
> > 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BM6meo079600 for <[e-mail]>; Thu, 11 Sep 2003 15:06:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BM6mOA079599 for ietf-pkix-bks; Thu, 11 Sep 2003 15:06:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BM6leo079592 for <[e-mail]>; Thu, 11 Sep 2003 15:06:47 -0700 (PDT) (envelope-from [e-mail])
Received: from AMBARISHW2K (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id h8BM6NPo005066; Thu, 11 Sep 2003 15:06:23 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "'Florian Oelmaier'" <[e-mail]>, "'Julien Stern'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 15:06:23 -0700
Message-ID: <002601c378b0$f0b707d0$[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, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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 Florian,
    This is *not* allowed by RFC 2560. For CA delegated trust, it
specifically says that the CA needs to *directly* issue  the
delegation certificate to the responder.


Regards,
Ambarish


2.6  OCSP Signature Authority Delegation

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. A certificate's issuer
   explicitly delegates OCSP signing authority by issuing a certificate
   containing a unique value for extendedKeyUsage in the OCSP signer's
   certificate. This certificate MUST be issued directly to the
   responder by the cognizant CA.



> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Florian Oelmaier
> Sent: Thursday, September 11, 2003 4:54 AM
> To: Julien Stern
> Cc: [e-mail]
> Subject: Re: [OCSP] are several requests for different CAs at 
> once valid ?
> 
> 
> 
> > When the OCSP can answer for several CAs, I guess that attribute 
> > certificates would be more appropriate than having different 
> > certificates with the same public key signed by several 
> CAs, but that 
> > would clearly make the clients and the servers much more 
> complex, so 
> > I'm fairly happy with the way it is ...
> 
> Perhaps one thing to add here: It seems to be a fairly common 
> requirement that an OCSP-client is configured to trust 
> OCSP-responses from a responder delegated by a CA that is 
> higher in the hierarchy than the CA in question.
> 
> So a company having some Sub-CAs and one OCSP-Responder for 
> all of them would issue a certificate including 
> OCSP-delegation using the Root-CA. Now the clients trust this 
> OCSP-Responder for certificates issued by the Root-CA or any 
> of its Sub-CAs (or Sub-Sub-CAs). 
> 
> This seems to be a popular configuration. This means the 
> OCSP-client vendors will not be surprised if you ask them to 
> include support into their software :)
> 
> -- 
> Florian Oelmaier
> SyTrust
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BJoqeo068735 for <[e-mail]>; Thu, 11 Sep 2003 12:50:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BJoqbP068734 for ietf-pkix-bks; Thu, 11 Sep 2003 12:50:52 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BJopeo068728 for <[e-mail]>; Thu, 11 Sep 2003 12:50:51 -0700 (PDT) (envelope-from [e-mail])
Received: from mail6.microsoft.com ([157.54.6.196]) by mail1.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Sep 2003 12:50:49 -0700
Received: from inet-vrs-06.redmond.corp.microsoft.com ([157.54.6.181]) by mail6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Thu, 11 Sep 2003 12:50:37 -0700
Received: from 157.54.8.109 by inet-vrs-06.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Sep 2003 12:50:47 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Sep 2003 12:50:53 -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(6.0.3790.0); Thu, 11 Sep 2003 12:50:46 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Thu, 11 Sep 2003 12:50:44 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 12:50:33 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [OCSP] are several requests for different CAs at once valid ?
Thread-Index: AcN4acLRTohTIfaNTWKTSlg+ITY7rQAMERkw
From: "Ryan M. Hurst" <[e-mail]>
To: "Florian Oelmaier" <[e-mail]>, "Julien Stern" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Sep 2003 19:50:44.0589 (UTC) FILETIME=[FCF921D0:01C3789D]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8BJopeo068730
Sender: [e-mail]
Precedence: 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 to agree that this is certainly a common customer request; I have
always been leery of implementing such behavior however. The main reason
is that because this behavior would extend the scope of influence of an
issuing CA from having control over the identity of the sub ca to
include direct control over the certificates issued by the sub CA. 

As for the concept of a single request for the status of many
certificates issued by different CAs this can be accomplished using the
defined trust models outlined in other threads. 

For example if a client supports responder identification by key and the
responder has a single key pair certified by each CA he responds for it
is possible to put those certificates in the responder certificate bag
and have a client be able to validate that response as a delegated
response in each case.

When you start to think about a single request representing a query for
multiple potentially un-related CAs you also need to start thinking
about what if the CA has the status to say 2 of 5? Clients should be
able to support this concept, in this case (assuming the client has a
locally configured list of responders like in Mozilla) the client could
try the next responder in his list for 3-5 and work through his
responder list until he found the answer he wanted.

It is also possible with direct trust to accomplish this, but this is
very straight forward.

It would be nice if the OCSP RFC could have a son-of that was clearer on
these concepts, of all the implementations I have worked on in the past
several years these are some of the more common questions people have.

Ryan
 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Florian Oelmaier
Sent: Thursday, September 11, 2003 4:54 AM
To: Julien Stern
Cc: [e-mail]
Subject: Re: [OCSP] are several requests for different CAs at once valid
?


> When the OCSP can answer for several CAs, I guess that attribute
> certificates would be more appropriate than having different
> certificates with the same public key signed by several CAs,
> but that would clearly make the clients and the servers much more
> complex, so I'm fairly happy with the way it is ...

Perhaps one thing to add here: It seems to be a fairly common
requirement that an OCSP-client is configured to trust OCSP-responses
from a responder delegated by a CA that is higher in the hierarchy than
the CA in question.

So a company having some Sub-CAs and one OCSP-Responder for all of them
would issue a certificate including OCSP-delegation using the Root-CA.
Now the clients trust this OCSP-Responder for certificates issued by the
Root-CA or any of its Sub-CAs (or Sub-Sub-CAs). 

This seems to be a popular configuration. This means the OCSP-client
vendors will not be surprised if you ask them to include support into
their software :)

-- 
Florian Oelmaier
SyTrust






Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BJE6eo067339 for <[e-mail]>; Thu, 11 Sep 2003 12:14:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BJE60k067336 for ietf-pkix-bks; Thu, 11 Sep 2003 12:14:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BJE4eo067324 for <[e-mail]>; Thu, 11 Sep 2003 12:14:04 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Thu, 11 Sep 2003 12:13:44 -0700
Received: from 157.54.8.109 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 11 Sep 2003 12:14:00 -0700
Received: from RED-IMC-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Thu, 11 Sep 2003 12:14:03 -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(6.0.3790.0); Thu, 11 Sep 2003 12:14:00 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Thu, 11 Sep 2003 12:13:57 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: SCVP policy
Date: Thu, 11 Sep 2003 12:13:52 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: SCVP policy
Thread-Index: AcN28+vEOGS2T0aEQWWPXC3R1P7PewBotWuA
From: "Trevor Freeman" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 11 Sep 2003 19:13:57.0984 (UTC) FILETIME=[D9BBEE00:01C37898]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h8BJE4eo067331
Sender: [e-mail]
Precedence: 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 Peter Sylvester
Sent: Tuesday, September 09, 2003 8:10 AM
To: [e-mail]
Subject: SCVP policy


Hi Peter,

There were several postings requesting clarifications and document nits
regarding SCVP12. I am very close to finishing SCVP 13 and will be
posting the update shortly.

To answer you immediate questions, I cave changed the wording in SCVP to
clarify how SCVP implements the validation policy as defined in 3379 - I
think we had too many policy terms in use. I have also added a policy ID
which is present in the policy response and the validation response so
the client knows the policy used by the SCVP server on any request. The
client is at liberty to override the defaults used by the server on any
request.


Trevor

 
Hello editors of the SCVP text, dear chairmen.

In a message some weeks ago I commented the
different usages of a policy in the current
SCVP text as

- a configuration identifier

- an identifier used in an ANY DEFINED BY construct

I wonder which kind of clarification will be
made in the next draft of SCVP.  

TIA for any short answer
Peter



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BCqEeo034076 for <[e-mail]>; Thu, 11 Sep 2003 05:52:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BCqEto034075 for ietf-pkix-bks; Thu, 11 Sep 2003 05:52:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8BCqCeo034064 for <[e-mail]>; Thu, 11 Sep 2003 05:52:12 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 22164 invoked by uid 1649); 11 Sep 2003 12:52:12 -0000
Date: 11 Sep 2003 12:52:12 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: [e-mail] (Peter Gutmann)
CC: [e-mail]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
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>

> Maybe people could post indications of responder URLs and sample
> certs that could be used for testing...

http://www.openvalidation.org/useocspservicenew.htm

New design pending :)

I will open an interop-test section on openvalidation.org and will consolidate all the URLs posted here to the site. This way we can get a directory of Responder-Tests. 

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BC24eo028856 for <[e-mail]>; Thu, 11 Sep 2003 05:02:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BC242O028855 for ietf-pkix-bks; Thu, 11 Sep 2003 05:02:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BC22eo028845 for <[e-mail]>; Thu, 11 Sep 2003 05:02:03 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h8BC1fZs028899; Fri, 12 Sep 2003 00:01:41 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h8BC3B317510; Fri, 12 Sep 2003 00:03:11 +1200
Date: Fri, 12 Sep 2003 00:03:11 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Florian Oelmaier" <[e-mail]> writes:

>SyTrust CertControl supports that.  I have to admit, that it may well be that
>early versions of CertControl (2 years ago) had problems with multi-cert
>requests. But that was long ago :)

It looks like things have changed somewhat since I last checked responders,
which would have been around 2000 or 2001 some time.  Certainly back then the
situation was pretty dire, going from source code comments I made at the time
(invalid CA certs, responder gets the OCSP ID calculation wrong, expired CA
cert, hasn't been seen operating for six months, another one with IDs wrong,
etc etc).  Maybe people could post indications of responder URLs and sample
certs that could be used for testing...

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BBrleo028519 for <[e-mail]>; Thu, 11 Sep 2003 04:53:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BBrlTq028518 for ietf-pkix-bks; Thu, 11 Sep 2003 04:53:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8BBrjeo028511 for <[e-mail]>; Thu, 11 Sep 2003 04:53:45 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 20388 invoked by uid 1649); 11 Sep 2003 11:53:45 -0000
Date: 11 Sep 2003 11:53:45 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: "Julien Stern" <[e-mail]>
CC: [e-mail]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
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>

> When the OCSP can answer for several CAs, I guess that attribute
> certificates would be more appropriate than having different
> certificates with the same public key signed by several CAs,
> but that would clearly make the clients and the servers much more
> complex, so I'm fairly happy with the way it is ...

Perhaps one thing to add here: It seems to be a fairly common requirement that an OCSP-client is configured to trust OCSP-responses from a responder delegated by a CA that is higher in the hierarchy than the CA in question.

So a company having some Sub-CAs and one OCSP-Responder for all of them would issue a certificate including OCSP-delegation using the Root-CA. Now the clients trust this OCSP-Responder for certificates issued by the Root-CA or any of its Sub-CAs (or Sub-Sub-CAs). 

This seems to be a popular configuration. This means the OCSP-client vendors will not be surprised if you ask them to include support into their software :)

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BBoleo028353 for <[e-mail]>; Thu, 11 Sep 2003 04:50:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BBolbJ028352 for ietf-pkix-bks; Thu, 11 Sep 2003 04:50:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BBojeo028342 for <[e-mail]>; Thu, 11 Sep 2003 04:50:46 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id NAA25684; Thu, 11 Sep 2003 13:50:45 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 11 Sep 2003 13:50:45 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h8BBoiF23676; Thu, 11 Sep 2003 13:50:44 +0200 (MEST)
Date: Thu, 11 Sep 2003 13:50:44 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Peter,
> 
> I think that the SubjectKeyIdentifier field might be the choice.

I think my question was either stupid or may be considered as a trap. 
If whatever client is implemented in a way that it just validates 
a signature it can just do this as an optimisation.

A server can still do what it wants to create a SignerInfo
structure which may or not help some other relying party. 

In any case, this part of the discussion is not related
to the problem whether we want or not and what in a cert
acting as a pointer to a service. 

I am sure whether some of the argumentation is still in
along: Since we have no certs in some simpler
model, we don't provide for anything concerning them. 

Peter


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BAl2eo019751 for <[e-mail]>; Thu, 11 Sep 2003 03:47:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BAl2Pj019749 for ietf-pkix-bks; Thu, 11 Sep 2003 03:47:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BAl0eo019706 for <[e-mail]>; Thu, 11 Sep 2003 03:47:01 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA25451; Thu, 11 Sep 2003 12:46:55 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Thu, 11 Sep 2003 12:46:55 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h8BAksa23637; Thu, 11 Sep 2003 12:46:54 +0200 (MEST)
Date: Thu, 11 Sep 2003 12:46:54 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> Peter,
> 
> I think that the SubjectKeyIdentifier field might be the choice.

Well, at least you my try this one since the other one is not
possible :-) And then .. even that part is only defined
in terms of content of a certificate. 

> I anticipate that this will cause another round of debate on
> whether the PKIX WG should define an standard way for
> generating an unique key identifier, but I believe that at
> least SCVP should define one if it is going to support "a SCVP
> server without a certficate".

Well, I can understand the need to support the most simple
type of validation for such services.

Anyway, the question is related to "waht does the client do with
the response." Will it be consumed immediately, not logged,
not shown to another RP, or what. In this case, all kinds
of local authentictaion methods are useful. That's why I think
the actual text is not optimal because IMHO it doesn't cleary 
separate the payload from security envelope issues. 

> Well, I think I should further elaborate why the SCVP should
> allow a SCVP client to directly trust the public-key of a SCVP
> server without a certificate. I believe that a SCVP service is especially
> usefull for a dumb RP. (By a dumb RP, I mean a RP which
> is not capable of doing the complex job of certification path
> processing by itself) The question is: if a SCVP server include its own
> certificate within a SCVP Response as required by the current SCVP ID,

Dumb is what: Although I can see a mode of processing where the
client code that talks SCVP is not the one that uses the certificate
to be validated but I am not sure that the SCVP client cannot code
decode ASN1, at least the current spec is much more difficult to
handle than parsing an X509 cert. 

> how does the dumb RP validate the SCVP server certificate before it using
> the certificate to validate the SCVP response? Shouldn't the RP
> build a certificate chain from its trust anchor to the SCVP server
> certificate first and then validate the certificate chain in according
> with the validation policy or constraints? However, please remember
> that it is a dumb RP and it is not capable of doing the complex path
> processing job by itself. If it can do that job by itself, then it is not
> a dumb RP anymore; and if it is not a dumb RP, it is not necessary
> to delegate the path processing job to a SCVP Server. Thus if a dumb
> RP is required to validate the SCVP Server certificate, it will be a
> chicken-and-egg problem. Therefore, I believe it will be more
> practical if the SCVP allows a SCVP client to directly trust the public-key
> of a SCVP server without a certificate.

There is a difference between path validation of a target cert
and a path validation of a server cert.  For a locally trusted
server, the dumb client may for example just have the public key
of the root and its identity, and then can rather easily validate
a server cert presented. Or it has a self signed server cert,



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BA9ieo013943 for <[e-mail]>; Thu, 11 Sep 2003 03:09:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8BA9iZC013940 for ietf-pkix-bks; Thu, 11 Sep 2003 03:09:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-104-thursday.noc.nerim.net [62.4.17.104]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8BA9geo013934 for <[e-mail]>; Thu, 11 Sep 2003 03:09:43 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 41CD462D97 for <[e-mail]>; Thu, 11 Sep 2003 12:07:01 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id D87F8413C for <[e-mail]>; Thu, 11 Sep 2003 12:07:04 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 11310-05 for <[e-mail]>; Thu, 11 Sep 2003 12:07:04 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id A39CE409A for <[e-mail]>; Thu, 11 Sep 2003 12:07:04 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Thu, 11 Sep 2003 12:07:01 +0200
From: "Julien Stern" <[e-mail]>
Date: Thu, 11 Sep 2003 12:07:01 +0200
To: [e-mail]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

On Wed, Sep 10, 2003 at 06:25:09PM +0200, Julien Stern wrote:
> 
> Hi all,
> 
> I was wondering if it was ok to send an OSCPRequest containing
> requests for several certificates issued by different CAs ?
> 
> [Many answers snipped]

Many thanks to all of you for your very valuable answers.
I'm starting to have a really good idea of the behavior
that OCSP clients (just send one cert at a time) and OCSP
servers (deal with utterly complex requests) should have ;)

When the OCSP can answer for several CAs, I guess that attribute
certificates would be more appropriate than having different
certificates with the same public key signed by several CAs,
but that would clearly make the clients and the servers much more
complex, so I'm fairly happy with the way it is ...

Thanks again.

--
Julien Stern


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B9Pmeo008256 for <[e-mail]>; Thu, 11 Sep 2003 02:25:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8B9PmXR008255 for ietf-pkix-bks; Thu, 11 Sep 2003 02:25:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from www16.your-server.de (IDENT:[e-mail] [213.133.104.16]) by above.proper.com (8.12.9/8.12.8) with SMTP id h8B9Pjeo008227 for <[e-mail]>; Thu, 11 Sep 2003 02:25:46 -0700 (PDT) (envelope-from [e-mail])
Received: (qmail 12488 invoked by uid 1649); 11 Sep 2003 09:25:40 -0000
Date: 11 Sep 2003 09:25:40 -0000
Message-ID: <[e-mail]>
From: "Florian Oelmaier" <[e-mail]>
To: "Julien Stern" <[e-mail]>, [e-mail]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
References:   <>
In-Reply-To:  <>
X-Mailer: oMail 0.98.2 - http://webmail.omnis.ch
X-IPAddress: 195.212.95.34
X-Sender: [e-mail]
MIME-Version: 1.0
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>

Hello Julien,

please find the answers regarding the SyTrust CertControl OCSP Responder inline. Just to add: I just checked www.openvalidation.org. We get a lot of testing requests there (around 20.000 per month) and more than 99% percent are single certificate requests.

On Wed, 10 Sep 2003 18:25:09 +0200, "Julien Stern" <[e-mail]> wrote :

> 
> Hi all,
> 
> I was wondering if it was ok to send an OSCPRequest containing
> requests for several certificates issued by different CAs ?

SyTrust CertControl supports that.  I have to admit, that it may well be that early versions of CertControl (2 years ago) had problems with multi-cert requests. But that was long ago :)

But note: there are some configurations where it may not possible for CertControl to answer for all certs in your request. For example when CertControl operates as an OCSP-Proxy but is configured to relay the answer of the "original" proxy unaltered. Given that you ask for certificates that get forwarded to different OCSP-Responders, it is not possible for CertControl to consolidate the responses in "relaying-mode". You would have what we call "hiding mode" for that, where CertControl constructs its own answer based on the information it got.

So you should be aware that the response may contain less information than requested.

> A more problematic case is ii). One could imagine that several
> certificates with the "OCSP delegation extension" are delivered to
> an OSCP responder by different CAs. In that case, these certificates
> should either have the same name, or the same public key, depending
> on how the OSCP responder chooses to identify itself. It this setting
> valid ? SHOULD/MUST it be supported ?

SyTrust CertControl currently operates only by name. So CertControl would require you to use the same DN for all the certificates. I see your point, identification by key will be added soon.

> And while I'm at it, I would also be interested by knowing what the
> existing implementations return in the optional "certs" field of the
> BasicOCSPResponse depending on the aforementionned trust model, if
> anyone has a clue ...

With CertControl this is not an implementation but an configuration issue. We know some CertControl installation that choose not to deliver any certificate at all, some others append the whole certificate chain. As stated by some other, the most common configuration is that the OCSP-Responder append its own certificate. But dont rely on it in your client :)

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B9Baeo006295 for <[e-mail]>; Thu, 11 Sep 2003 02:11:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8B9BaRj006294 for ietf-pkix-bks; Thu, 11 Sep 2003 02:11:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smarthost1.mail.uk.easynet.net (smarthost1.mail.uk.easynet.net [212.135.6.11]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B9BZeo006286 for <[e-mail]>; Thu, 11 Sep 2003 02:11:35 -0700 (PDT) (envelope-from [e-mail])
Received: from [217.205.5.135] (helo=laptoplk) by smarthost1.mail.uk.easynet.net with esmtp (Exim 4.10) id 19xNU9-000EkA-00 for [e-mail]; Thu, 11 Sep 2003 10:11:29 +0100
From: "Liaquat Khan" <[e-mail]>
To: <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 10:13:48 +0100
Message-ID: <000001c37845$02bb1f00$3101a8c0@laptoplk>
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 V6.00.2800.1106
Importance: Normal
In-Reply-To: 
Sender: [e-mail]
Precedence: 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 this is common.  Ascertia's OCSP responder behaves in a similar
way.  We have one key pair for responding to relying parties, but the
public key can be certified by each CA that the responder is responding
for.  

More than one certificate can then be attached to responses being sent
out. 

Regards,
LK


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Ambarish Malpani
Sent: 11 September 2003 06:31
To: Julien Stern; [e-mail]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?



Hi Julian,
    Responses inline of the behavior of the Valicert responder.

Regards,
Ambarish

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Julien Stern
> Sent: Wednesday, September 10, 2003 9:25 AM
> To: [e-mail]
> Subject: [OCSP] are several requests for different CAs at once valid ?
> 
> 
> 
> Hi all,
> 
> I was wondering if it was ok to send an OSCPRequest containing
> requests for several certificates issued by different CAs ?

This works fine. The server responds for all certs in the request.
For servers it doesn't have information for, it returns unknown.

> 
> In case this is ok, more specifically, when trying to figure out
whether
> the signer should be trusted, OCSP defines three models:
> 
> i)   Directly signed by the CA
> ii)  Signed by a specific certificate with the correct extension
directly
>      issued by the CA
> iii) Signed by a certificate which is directly trusted by the user
> 
> My first question obviously does not make sense in case i) as there
> is only one signature per response. It is simple in case iii) as there
> is no relationship any more between the certs to be checked and the
OCSP
> responder.
> 
> A more problematic case is ii). One could imagine that several
> certificates with the "OCSP delegation extension" are delivered to
> an OSCP responder by different CAs. In that case, these certificates
> should either have the same name, or the same public key, depending
> on how the OSCP responder chooses to identify itself. It this setting
> valid ? SHOULD/MUST it be supported ?

The Valicert responder could be configured to respond by name/key or
to respond by key only if the names of all the certs issued to
it by various CAs didn't match.

> 
> 
> And while I'm at it, I would also be interested by knowing what the
> existing implementations return in the optional "certs" field of the
> BasicOCSPResponse depending on the aforementionned trust model, if
> anyone has a clue ...

The responder's cert(s). Could have more than one, if you have
delegated certs from multiple CAs.

> 
> Thanks a lot.
> 
> --
> Julien Stern
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B5Speo070177 for <[e-mail]>; Wed, 10 Sep 2003 22:28:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8B5SpOx070176 for ietf-pkix-bks; Wed, 10 Sep 2003 22:28:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B5Soeo070170 for <[e-mail]>; Wed, 10 Sep 2003 22:28:50 -0700 (PDT) (envelope-from [e-mail])
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.9/8.12.9) with SMTP id h8B5SNPo004205; Wed, 10 Sep 2003 22:28:23 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "Julien Stern" <[e-mail]>, <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Wed, 10 Sep 2003 22:31:26 -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 V6.00.2800.1165
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 Julian,
    Responses inline of the behavior of the Valicert responder.

Regards,
Ambarish

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Julien Stern
> Sent: Wednesday, September 10, 2003 9:25 AM
> To: [e-mail]
> Subject: [OCSP] are several requests for different CAs at once valid ?
> 
> 
> 
> Hi all,
> 
> I was wondering if it was ok to send an OSCPRequest containing
> requests for several certificates issued by different CAs ?

This works fine. The server responds for all certs in the request.
For servers it doesn't have information for, it returns unknown.

> 
> In case this is ok, more specifically, when trying to figure out whether
> the signer should be trusted, OCSP defines three models:
> 
> i)   Directly signed by the CA
> ii)  Signed by a specific certificate with the correct extension directly
>      issued by the CA
> iii) Signed by a certificate which is directly trusted by the user
> 
> My first question obviously does not make sense in case i) as there
> is only one signature per response. It is simple in case iii) as there
> is no relationship any more between the certs to be checked and the OCSP
> responder.
> 
> A more problematic case is ii). One could imagine that several
> certificates with the "OCSP delegation extension" are delivered to
> an OSCP responder by different CAs. In that case, these certificates
> should either have the same name, or the same public key, depending
> on how the OSCP responder chooses to identify itself. It this setting
> valid ? SHOULD/MUST it be supported ?

The Valicert responder could be configured to respond by name/key or
to respond by key only if the names of all the certs issued to
it by various CAs didn't match.

> 
> 
> And while I'm at it, I would also be interested by knowing what the
> existing implementations return in the optional "certs" field of the
> BasicOCSPResponse depending on the aforementionned trust model, if
> anyone has a clue ...

The responder's cert(s). Could have more than one, if you have
delegated certs from multiple CAs.

> 
> Thanks a lot.
> 
> --
> Julien Stern
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B5NUeo069959 for <[e-mail]>; Wed, 10 Sep 2003 22:23:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8B5NUFt069958 for ietf-pkix-bks; Wed, 10 Sep 2003 22:23:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B5NUeo069948 for <[e-mail]>; Wed, 10 Sep 2003 22:23:30 -0700 (PDT) (envelope-from [e-mail])
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.9/8.12.9) with SMTP id h8B5NDPo004200; Wed, 10 Sep 2003 22:23:13 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Wed, 10 Sep 2003 22:26: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)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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>

Not sure what Peter's sample set was, but that has always
worked with the Valicert responder.

Regards,
Ambarish

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Peter Gutmann
> Sent: Wednesday, September 10, 2003 8:37 PM
> To: [e-mail]; [e-mail]
> Subject: Re: [OCSP] are several requests for different CAs at once valid
> ?
>
>
>
> "Julien Stern" <[e-mail]> writes:
>
> >I was wondering if it was ok to send an OSCPRequest containing
> requests for
> >several certificates issued by different CAs ?
>
> Not a good idea.  The behaviour of implementations a year or two back was:
>
> 1. Crash/fail/break in some way and reject the request outright.
> 2. Return an error response.
> 3. Ignore all but the first request in the response.
>
> I think I finally managed to track down one of the Identrus-cabal
> responders
> that would handle more than one cert in a request (I can't
> remember which one
> it was).  Maybe things have improved since then, but in general I wouldn't
> risk sending more than one cert per request, unless you're controlling the
> responder and know that it can handle this.
>
> Peter.
>



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B3ZQeo066065 for <[e-mail]>; Wed, 10 Sep 2003 20:35:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8B3ZQB0066064 for ietf-pkix-bks; Wed, 10 Sep 2003 20:35:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8B3ZOeo066058 for <[e-mail]>; Wed, 10 Sep 2003 20:35:25 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h8B3ZCZs018085; Thu, 11 Sep 2003 15:35:12 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h8B3adD22243; Thu, 11 Sep 2003 15:36:39 +1200
Date: Thu, 11 Sep 2003 15:36:39 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Julien Stern" <[e-mail]> writes:

>I was wondering if it was ok to send an OSCPRequest containing requests for
>several certificates issued by different CAs ?

Not a good idea.  The behaviour of implementations a year or two back was:

1. Crash/fail/break in some way and reject the request outright.
2. Return an error response.
3. Ignore all but the first request in the response.

I think I finally managed to track down one of the Identrus-cabal responders
that would handle more than one cert in a request (I can't remember which one
it was).  Maybe things have improved since then, but in general I wouldn't
risk sending more than one cert per request, unless you're controlling the
responder and know that it can handle this.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AJHweo009146 for <[e-mail]>; Wed, 10 Sep 2003 12:17:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8AJHwnL009145 for ietf-pkix-bks; Wed, 10 Sep 2003 12:17:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from seguridata1.seguridata.com ([200.57.34.107]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AJHveo009119 for <[e-mail]>; Wed, 10 Sep 2003 12:17:57 -0700 (PDT) (envelope-from [e-mail])
Received: from MarsXP ([200.67.231.235]) by seguridata1.seguridata.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Sep 2003 14:19:04 -0500
From: "Miguel Rodriguez" <[e-mail]>
To: "'Julien Stern'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Wed, 10 Sep 2003 14:15:23 -0500
Message-ID: <000201c377cf$e5c71130$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
X-OriginalArrivalTime: 10 Sep 2003 19:19:04.0546 (UTC) FILETIME=[660BD420:01C377D0]
Sender: [e-mail]
Precedence: 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, responses are inline
> 
> A more problematic case is ii). One could imagine that several
> certificates with the "OCSP delegation extension" are delivered to
> an OSCP responder by different CAs. In that case, these certificates
> should either have the same name, or the same public key, depending
> on how the OSCP responder chooses to identify itself. It this setting
> valid ? SHOULD/MUST it be supported ?
> 
In this setting the client is expecting the OCSP responder's certificate
issued by the CA that issued the target certificate.  

> 
> And while I'm at it, I would also be interested by knowing what the
> existing implementations return in the optional "certs" field of the
> BasicOCSPResponse depending on the aforementionned trust model, if
> anyone has a clue ...

Most implementations return the OCSP responder certificate in this
field. Also the standard practice is that an OCSP responder works for a
single CA. When a client is validating a certificate chain it usually
goes in a "one by one" fashion, sending an OCSP request for each
certificate.

Miguel A Rodriguez
SeguriDATA
Mexico




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AGPDeo076457 for <[e-mail]>; Wed, 10 Sep 2003 09:25:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8AGPDFF076456 for ietf-pkix-bks; Wed, 10 Sep 2003 09:25:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mallaury.noc.nerim.net (smtp-103-wednesday.noc.nerim.net [62.4.17.103]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AGPCeo076443 for <[e-mail]>; Wed, 10 Sep 2003 09:25:12 -0700 (PDT) (envelope-from [e-mail])
Received: from jupiter.cry.pto (cryptolog.net1.nerim.net [80.65.224.225]) by mallaury.noc.nerim.net (Postfix) with ESMTP id 87C6D62D08 for <[e-mail]>; Wed, 10 Sep 2003 18:25:08 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by jupiter.cry.pto (Postfix) with ESMTP id E18E34178 for <[e-mail]>; Wed, 10 Sep 2003 18:25:12 +0200 (CEST)
Received: from jupiter.cry.pto ([127.0.0.1]) by localhost (jupiter [127.0.0.1]) (amavisd-new, port 10024) with SMTP id 07451-01 for <[e-mail]>; Wed, 10 Sep 2003 18:25:12 +0200 (CEST)
Received: from callisto.cry.pto (callisto.cry.pto [10.0.1.4]) by jupiter.cry.pto (Postfix) with SMTP id B17BD4177 for <[e-mail]>; Wed, 10 Sep 2003 18:25:12 +0200 (CEST)
Received: by callisto.cry.pto (sSMTP sendmail emulation); Wed, 10 Sep 2003 18:25:09 +0200
From: "Julien Stern" <[e-mail]>
Date: Wed, 10 Sep 2003 18:25:09 +0200
To: [e-mail]
Subject: [OCSP] are several requests for different CAs at once valid ?
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.4i
X-Virus-Scanned: by amavisd-new-20030314-p2 (Debian) at cryptolog.com
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,

I was wondering if it was ok to send an OSCPRequest containing
requests for several certificates issued by different CAs ?

In case this is ok, more specifically, when trying to figure out whether
the signer should be trusted, OCSP defines three models:

i)   Directly signed by the CA
ii)  Signed by a specific certificate with the correct extension directly
     issued by the CA
iii) Signed by a certificate which is directly trusted by the user

My first question obviously does not make sense in case i) as there
is only one signature per response. It is simple in case iii) as there
is no relationship any more between the certs to be checked and the OCSP
responder.

A more problematic case is ii). One could imagine that several
certificates with the "OCSP delegation extension" are delivered to
an OSCP responder by different CAs. In that case, these certificates
should either have the same name, or the same public key, depending
on how the OSCP responder chooses to identify itself. It this setting
valid ? SHOULD/MUST it be supported ?


And while I'm at it, I would also be interested by knowing what the
existing implementations return in the optional "certs" field of the
BasicOCSPResponse depending on the aforementionned trust model, if
anyone has a clue ...

Thanks a lot.

--
Julien Stern


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AC1Teo031879 for <[e-mail]>; Wed, 10 Sep 2003 05:01:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8AC1TOT031878 for ietf-pkix-bks; Wed, 10 Sep 2003 05:01:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gate.chttl.com.tw (gate.chttl.com.tw [202.39.157.254]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8AC1Qeo031837 for <[e-mail]>; Wed, 10 Sep 2003 05:01:27 -0700 (PDT) (envelope-from [e-mail])
Received: from ms7.chttl.com.tw (ms7 [10.144.2.117]) by gate.chttl.com.tw (8.12.9/8.12.9) with ESMTP id h8AC0U3K010961; Wed, 10 Sep 2003 20:00:30 +0800
Received: (from root@localhost) by ms7.chttl.com.tw (8.12.3/8.12.1) id h8AC0T8F007288; Wed, 10 Sep 2003 20:00:29 +0800
Received: from wcwang ([10.144.133.79]) by ms7.chttl.com.tw (8.12.3/8.12.1) with SMTP id h8AC0R7M007240; Wed, 10 Sep 2003 20:00:29 +0800
Message-ID: <00a501c37792$fc61bc20$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: "Peter Sylvester" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 10 Sep 2003 19:59:27 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="big5"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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 that the SubjectKeyIdentifier field might be the choice.
I anticipate that this will cause another round of debate on
whether the PKIX WG should define an standard way for
generating an unique key identifier, but I believe that at
least SCVP should define one if it is going to support "a SCVP
server without a certficate".

Well, I think I should further elaborate why the SCVP should
allow a SCVP client to directly trust the public-key of a SCVP
server without a certificate. I believe that a SCVP service is especially
usefull for a dumb RP. (By a dumb RP, I mean a RP which
is not capable of doing the complex job of certification path
processing by itself) The question is: if a SCVP server include its own
certificate within a SCVP Response as required by the current SCVP ID,
how does the dumb RP validate the SCVP server certificate before it using
the certificate to validate the SCVP response? Shouldn't the RP
build a certificate chain from its trust anchor to the SCVP server
certificate first and then validate the certificate chain in according
with the validation policy or constraints? However, please remember
that it is a dumb RP and it is not capable of doing the complex path
processing job by itself. If it can do that job by itself, then it is not
a dumb RP anymore; and if it is not a dumb RP, it is not necessary
to delegate the path processing job to a SCVP Server. Thus if a dumb
RP is required to validate the SCVP Server certificate, it will be a
chicken-and-egg problem. Therefore, I believe it will be more
practical if the SCVP allows a SCVP client to directly trust the public-key
of a SCVP server without a certificate.

Best Regards,
Wen-Cheng

----- Original Message ----- 
From: "Peter Sylvester" <[e-mail]>
To: <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, September 10, 2003 12:11 AM
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


>
> What do you suggest to put into the SignedData field sid which is
>
> SignerIdentifier ::= CHOICE {
>         issuerAndSerialNumber IssuerAndSerialNumber,
>         subjectKeyIdentifier [0] SubjectKeyIdentifier }
>
>
>
> >
> > Steve,
> >
> > Sure, I totally agree that a SCVP server is not necessary to have
> > a cert. Actually, I am in favor of directly delivering the public-key of the SCVP server to the RP via a secure
out-of-band channel.
> > It is rather unfortunate that the current SCVP ID (draft 12)
> > seems to require a SCVP server MUST have a cert. The section
> > 4 of the current SCVP ID says "The SCVP server MUST include its
> > own certificate in the certificates field within SignedData."
> > I believe the text should be changed.
> >
> > Best Regards,
> > Wen-Cheng
> >
> >
> > Stephen Kent wrote:
> > > Wen-Cheng Wang,
> > > As I mentioned in one of my many messages today, there may be no need
> > > for an SCVP server to have a cert. If the server is used by only
> > > local clients, e.g., in an enterprise context, then the server's
> > > public key need not be signed by anyone. certainly, as your note, the
> > > server is an EE, not a CA, so the usual self-signed cert model may
> > > not apply.
> > > Steve
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89J28eo020680 for <[e-mail]>; Tue, 9 Sep 2003 12:02:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89J27iQ020679 for ietf-pkix-bks; Tue, 9 Sep 2003 12:02:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89J26eo020673 for <[e-mail]>; Tue, 9 Sep 2003 12:02:07 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h89J1te8005010; Tue, 9 Sep 2003 15:01:55 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Tue, 9 Sep 2003 15:01:50 -0400
Message-ID: <007b01c37704$d698f9b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <p05210609bb82b9c45dff@[24.120.164.145]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h89J27eo020674
Sender: [e-mail]
Precedence: 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:

The SCVP Server is like AKID and SKID.  They are not needed for security.
They can aid in path development.

Please see responses in-line in <> with redaction.


At 17:36 -0400 9/8/03, Santosh Chokhani wrote:

>But, if an RP is dealing with multiple enterprises, the pointer does 
>help.

so, we have an RP who has no "local" SCVP server; all the servers are 
"foreign" to him, and he has to choose the right one.

<I do not think "local", "foreign" etc. are meaningful or should be used.  A
client has a set of SCVP Servers that it trusts.  It does not matter where
these servers are physically or organizationally located.  The set could be
empty and DPD will still work> 

>The reason the pointer in the certificate is not critical for DPV also 
>is that the RP client will require some out of band trusted means to 
>obtain the Trusted SCVP Server public key.  For the public key, RP will 
>not rely on the information in the certificate.  All the certificate 
>tells RP is which of the RP client pre-configured servers to try first.

I'm confused again. You say that the client needs to get the public 
key for each server via some other means, not from the cert being 
validated. but then you say that the cert will be used to decide 
which server to "try first."  That seems to suggest that the client 
is willing to let any of these servers verify any cert for him, and 
it's just a matter of which server the cert points to. as I said 
before, this seems to have all the advantages of the browser PKI 
model :-)

<Ha, ha.  If the client has constraints on the SCVP Server, it can impose
them.  Assuming more than one SCVP Servers can be used to verify a
certificate in question, then the SCVP Server pointer information can be
used in prioritization, if the client chooses to.>

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89H42eo009435 for <[e-mail]>; Tue, 9 Sep 2003 10:04:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89H404q009432 for ietf-pkix-bks; Tue, 9 Sep 2003 10:04:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89H3xeo009427 for <[e-mail]>; Tue, 9 Sep 2003 10:04:00 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h89H3se8021190; Tue, 9 Sep 2003 13:03:54 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Tue, 9 Sep 2003 13:03:48 -0400
Message-ID: <003701c376f4$598e4660$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <p05210606bb82b612805b@[24.120.164.145]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h89H40eo009428
Sender: [e-mail]
Precedence: 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:

The idea proposed is very simply.  Let me summarize it.  The pointer in the
certificate is used in prioritization/weighing from zero or more choices of
SCVP Servers.

The prioritization scheme is upto the client and does not impact security or
interoperability.  That is why it need not be defined.  It can be left up to
the client.  Of course, regardless of the pointer in the certificate, if the
client is configured with constraints on an SCVP Server (e.g., in terms of
policies, name spaces, etc.) the client must enforce those constraints for
DPV.

While the SCVP pointer in the certificate can be used for DPD, it may be
used for DPV only if the client is configured with the corresponding SCVP
Server and the server's public key.  Thus, for DPV, the certificate pointer
can be used (at most) to prioritize or weigh the multiple SCVP Servers the
client has.

A compliant client may choose to ignore the SCVP pointer in the certificate
if it chooses to.

See responses in {} with information redacted.

>In all cases, SCVP client will be configured with the SCVP Servers and
>>their public keys and any constraints in terms of limiting the Server
>>for policies, name spaces etc.
>
>I think this would be reasonable, but where do we say this?
>
>[This is appropriate for DPV or trusted SCVP Service.  It should be
>implicit from SCVP Specification that the clients need the SCVP Server 
>public keys in trusted manner.  Now, in terms of constraints, it should 
>be up to the client whether it trusts an SCVP Server for all names and 
>policies or only some. As to where we say these things, security 
>considerations section of SCVP Server may be one place.  I am sure 
>there are better places.]

Implicit is dangerous! we need more precise discussions of how a 
client that uses SCVP is supposed to work, e.g., in terms of 
configuration data, etc. see my comments to Peter on this topic.

{I do not see any danger in clients using their own algorithms and
approaches to selecting the order in which SCVP Servers are queried.  We
need not define the priority or actual algorithm a client uses to define the
order in which it will query SCVP Servers.  We can write an informational
RFC on how to configure the client, how to use the SCVP Server pointer.
But, this is neither a security issue nor an interoperability issue.  If a
client is configured to trust an SCVP Server for certain name spaces,
policies, etc., those must be honored}

>
>>All this will do is select a proper server so that computational
>>complexity is reduced.
>
>what complexity? the selection of the right server based on the cert
>presented?
>
>[If you do not have any algorithm to try, you will try all of them and
>on the average n/2 servers, f the client is configured with n servers.
>This will result in communication delays and needless signature 
>verifications on SCVP Server responses.  Also, whatever work the SCVP 
>server does to determine, it is clueless about the certificate you just 
>asked.]

some strings of words above are not a sentence. so, if we assume N >> 
1, this might be a problem, but in the enterprise case, I would 
generally expect N = 1, right? So, we need to discuss what other 
cases give rise to bigger values for N, and we need to include a 
discussion of why we could not use the scope data for an SCVP server, 
as configured in a client, to determine which server to contact re 
the EE cert in question. I thought we already discussed the dangers 
of having a list of SCVP servers (for DPV) where we would "trust" all 
of them for any cert  we wanted to verify.

{I gave an example of when n>1.  I am not sure if n>>1 to improve
performance.  We could use the client configuration.  The SCVP pointer is
another alternative.  A client could use SCVP server based priority only,
ignore the SCVP Server based priority and use client configuration only, or
use the combination of the two.} 

>  >I see situations where a person has credentials and hence trust
> anchors
>>(these could be SCVP servers some day) from their employer, from one
>>or more public sector customers, and one or more private sector 
>>customers. In this cases, none of these are "foreign" CAs.  A pointer 
>>will select the correct SCVP server.  Security and trust will still be 
>>a function of client configuration and under client control.
>>
>
>What is a "public sector customer" relative to the person above. How
>are these folks "customers" of that person? Same question for the 
>private sector analogs.
>
>[For example, I am a security consultant.  My customers like US
>Government and Banks want me to use certificates minted by them for me 
>using their PKI]

These are examples of you selecting the right cert to use when you 
sign something for one of your customers, but you are not the RP in 
that case and SCVP is a service to an RP. are you trying to say that 
when you receive a cert from one of these customers, that you want 
the customer to tell you which SCVP server to invoke for them? 
first, if that;s the intent, the whole discussion above is backwards! 
second, how do you address the issue of limiting the scope for each 
if these servers? I'm not saying that you cannot address the problem, 
but it seems to come and go as a part of the processing you have 
described.

{When I have a certificate of the client for encryption r for digital
signature verification, I need to verify that the certificate is good.
Thus, my thin client would like to go to an SCVP Server.  As it so happens,
my client has a few and I would like to select the correct one}

Steve
Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89GBeeo007069 for <[e-mail]>; Tue, 9 Sep 2003 09:11:40 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89GBepb007068 for ietf-pkix-bks; Tue, 9 Sep 2003 09:11:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89GBceo007062 for <[e-mail]>; Tue, 9 Sep 2003 09:11:38 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA14124; Tue, 9 Sep 2003 18:11:38 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 9 Sep 2003 18:11:38 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h89GBbY19629; Tue, 9 Sep 2003 18:11:37 +0200 (MEST)
Date: Tue, 9 Sep 2003 18:11:37 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

What do you suggest to put into the SignedData field sid which is 

SignerIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }



> 
> Steve,
> 
> Sure, I totally agree that a SCVP server is not necessary to have
> a cert. Actually, I am in favor of directly delivering the public-key of the SCVP server to the RP via a secure out-of-band channel.
> It is rather unfortunate that the current SCVP ID (draft 12)
> seems to require a SCVP server MUST have a cert. The section
> 4 of the current SCVP ID says "The SCVP server MUST include its
> own certificate in the certificates field within SignedData."
> I believe the text should be changed.
> 
> Best Regards,
> Wen-Cheng
> 
> 
> Stephen Kent wrote:
> > Wen-Cheng Wang,
> > As I mentioned in one of my many messages today, there may be no need 
> > for an SCVP server to have a cert. If the server is used by only 
> > local clients, e.g., in an enterprise context, then the server's 
> > public key need not be signed by anyone. certainly, as your note, the 
> > server is an EE, not a CA, so the usual self-signed cert model may 
> > not apply.
> > Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89F9peo002151 for <[e-mail]>; Tue, 9 Sep 2003 08:09:51 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89F9pDX002150 for ietf-pkix-bks; Tue, 9 Sep 2003 08:09:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89F9neo002142 for <[e-mail]>; Tue, 9 Sep 2003 08:09:50 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA13575 for <[e-mail]>; Tue, 9 Sep 2003 17:09:50 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 9 Sep 2003 17:09:50 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h89F9nu19443 for [e-mail]; Tue, 9 Sep 2003 17:09:49 +0200 (MEST)
Date: Tue, 9 Sep 2003 17:09:49 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: SCVP policy
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello editors of the SCVP text, dear chairmen.

In a message some weeks ago I commented the
different usages of a policy in the current
SCVP text as

- a configuration identifier

- an identifier used in an ANY DEFINED BY construct

I wonder which kind of clarification will be
made in the next draft of SCVP.  

TIA for any short answer
Peter


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89CfDeo085997 for <[e-mail]>; Tue, 9 Sep 2003 05:41:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89CfDL4085996 for ietf-pkix-bks; Tue, 9 Sep 2003 05:41:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89CfCeo085990 for <[e-mail]>; Tue, 9 Sep 2003 05:41:13 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h89Cf7e8022240; Tue, 9 Sep 2003 08:41:07 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Tue, 9 Sep 2003 08:41:02 -0400
Message-ID: <003301c376cf$a3d1cf50$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <p05210605bb82b4d23555@[24.120.164.145]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h89CfDeo085992
Sender: [e-mail]
Precedence: 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:

See responses in [] with text redacted.


>If a certificate in question has an SCVP Server pointer that also
>happens to be in the client's list of SCVP Servers whom it trusts, the 
>client uses that SCVP Server for DPD and for DPV.

This description lacks the scope controls you seem to have suggested 
earlier, i.e., what servers are trusted for what sets of certs?

[The scope control could be used in conjunction or in spite of what is in
the Server.  The way I look at it is a client could select an SCVP Server
purely based on its configuration, based on some combination of its
configuration and what is on the certificate, and purely from the
certificate.  For the DPV services, the selected SCVP Server must be in the
trust list of the client.  For DPD, this is not needed]

>If the SCVP Server pointed to by the certificate is not in the client's
>trust list, the Server can be only used for DPD and you know most 
>likely client will have some work remaining to do to find cross 
>certification from RP domain to subscriber domain.

So, if the client needs the DPV service, because it is dumb, it's up 
the creek here? that may be an odd response to finding this SCVP 
extension in an EE cert. I can see instances where this might be OK, 
but in other cases why doesn't the client just contact its "home" 
SCVP server and ask it to perform the DPV service?

[If the client needs a trusted service (e.g., DPV), it needs the SCVP Server
information such as name and public key pre-configured.  It is unlikely to
be much help having an SCVP Server pointer whose public key the client does
not already trust.  In cases where the SCVP Server pointer in the
certificate is not in the client trust list, the client must use its own
trust list and any deterministic or heuristic algorithm to go through the
trust list of SCVP Servers it has]

Overall, what I see here is a start at how a client might make use of 
an extension, but with a number of holes to be addressed.

[We can discuss this next time we talk.  While I have tended to be brief, I
do not see any holes in the approach.  Your points have made the debate more
clear and my thoughts more sharp, but they have not shown any holes in it.
My assumption all along has been that if the client does not already trust
an SCVP Server, a pointer in the certificate is not the right thing since
then the client will have to do the very path development and validation it
intended to avoid.]

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89Asceo076125 for <[e-mail]>; Tue, 9 Sep 2003 03:54:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89Asaou076116 for ietf-pkix-bks; Tue, 9 Sep 2003 03:54:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89AsYeo076104 for <[e-mail]>; Tue, 9 Sep 2003 03:54:35 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA12163; Tue, 9 Sep 2003 12:54:33 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 9 Sep 2003 12:54:34 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h89AsXR18941; Tue, 9 Sep 2003 12:54:33 +0200 (MEST)
Date: Tue, 9 Sep 2003 12:54:33 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> The use of SIA in TSP makes sense because the extension is used in 
> the cert for the TSA, not for other entities.  At least that's how I 
> read the appendix in 3161.

Indeed. That's one of the cases that I'd like to see. 

> 
> Sorry, but I don't understand the nature of the overkill or what is 
> hard to maintain. AIA and SIA have different semantics; they should 
> be used in different contexts. I don't know yet whether we would need 
> another extension for use with SCVP, or can use one of these, because 
> I still do not have a clear picture of what folks plan to do with the 
> extension.
> 

What I am saying is that one could have used one single extension
saying 'IA' information access, and then put the semantics of being
either something like a SIA or AIA into the OID instead of folding it
out. For comparison see the extensionproposed by David Chadwick where
both SIA and AIA are considered as inappropriate. 

> >
> ></paranthese>
> >
> >>
> >>  >This does seem an afterthought to me but rather a well accepted feature
> >>  >since years which doesn't seem to need a particular requirement.
> >>
> >>  Well, we agree on the afterthought part :-), but probably not the
> >>  "well accepted feature" part. Before the WG says that putting a
> >>  pointer in AIA or SIA makes sense for SCVP, we need to agree on the
> >>  requirements.
> >
> >here are some.
> >
> >- One is in a ee entity whose status is to be queried a location
> >   where to ask for the service. The result of the service need
> >   to be authenticated in whatever is appropriate for the client;
> >   The two CA models of OCSP are examples.
> >   A possible implementation is to put an AIA into an end cert.
> 
> I do not understand this example, please rephrase.

This is like the AIA extension in OCSP for a CA provided service. 

> 
> >- It seems useful to have such a pointer in a CA cert indicating
> >   a service concerning all certificates issued by that CA (vs
> >   the previous IA would indicate where to obtain information
> >   about the CA certificate.)
> 
> If the service is DPD, I think this may make sense. if it is DPV, 
> then what info about the CA cert is to be supplied and how is it to 
> be used? we already have a way to convey CRL and OCSP info relative 
> to a CA, and because the CA is authoritative for revocation info, 
> this is fine. but DPV is very different and so a different argument 
> needs to be made about why one would go to an SCVP server of the 
> Issuer's choosing when trying to verify a cert issued by that CA.

Because the CA's server will return a valid(ated) path. There may
be intermediate CAs, and the CA will check for revocation etc.

> 
> >- A third requirement is to have a simple configuration of
> >   a local SCVP service, which needs to be authenticated either
> >   by some IPSEC, TLS or SMIME signature through a certificate.
> >   This can be done for example by an extension inside the
> >   server cert or any cert in the trustpath of the server's cert.
> 
> You describe here and example where you want to mark an EE cert as 
> being an SCVP server cert and to indicate where the server is. That's 
> very different from the examples above and deserves to be evaluated 
> independently, and might be a different extension. But, when you say 
> that the extension might appear anywhere in the path, I think this is 
> a very different situation, for which I have not seen any indication 
> of the intended processing model.

Yes, this is the case as with the SIA in TSP etc.

By saying that the pointer could be anywhere in a trustpath I
see the following example:

A client is configured with a CA cert of rather long validity.
The actual connection is authenticated with a server cert that
has a rather short validity without the need of frequent 
configuration change.

> 
> >- It is necssary to distinguish SCVP servers, in particular if
> >   end-entity belong to the same CA. A special key-purpose seems
> >   a sufficient way to do this.
> 
> Sorry, but this sentence makes no sense to me, and since you seem to 
> suggest that an extended key usage OID might suffice, maybe we need 
> not pursue it further.

Cf. the second model in OCSP. If a CA signs norma ee certs and also
a SCVP server cert, you want to say: I trust a 'scvp response 
giveing either by a CA or by a designated reponder.' it is
indeed the same requierment for an extended keyusage OID. 

> 
> >  > >A simple way to configure a public key is a certificate. You can have
> >  > >like in TSP a SIA with your local server, and your local server acting
> >>  >as a proxy can contact a CA's server using an AIA in the cert to be
> >>  >validated.
> >>
> >>  Sorry, but you lost me here, i.e., not enough context near your
> >>  answer for me to remember what the question was. But, I'll take a
> >>  stab anyway.
> >>
> >>  We need to distinguish between what a client would do with a pointer
> >>  in an extension vs. what an SCVP server might do, re relay. The
> >>  answers may be different, e.g., one might make sense but the other
> >>  may not. If so, then  we might decide to allow an SCVP reference in
> >>  one of these extensions, BUT also make it clear under which of the
> >>  two cases it is to be used.
> >
> >Not really, since the extensions are not in the same certificate.
> >in one case it is the server's trust chain, the other are the certs
> >to be validated. But, it is probably necessary to distinguish the different
> >usages (at least two).
> 
> all I can get out of this comment is that we may agree on the need to 
> have two different classes of extensions for different semantics.

Yes. There are at least two classes.

> Peter, what I would like to see is a clearer articulation of what 
> problems are being solved by the suggestion extension(s), and how the 
> use of an extension solves the problem, i.e., some discussion of the 
> processing that takes place. The descriptions should say whether we 
> are helping a client find and authenticate an appropriate SCVP 
> server, or whether we are helping an SCVP server in its job. The 
> descriptions should say whether we are using SCVP for DPD or DPV. 
> They should indicate whether the problem is assumed to arise in an 
> enterprise context, or in some other context that is described. The 
> processing description should indicate where the required info comes 
> from, and how the consumer of that info (client or SCVP server) can 
> use that info safely.

I'd like that you make a little bit more effort to understand
a non native english speaker, otherwise I think I can make
a better articulation in German or French, and then the IETF hires a 
professional translator. :-)

Hm, it seems to me that the remaining problem that we seem to see both is
whether a pointer in a 'cert to be validated' indicates a DPV or DPD, 
and whether a client could distingusih this. 
> 
> I think we need this kind of text to clarify the discussion that is 
> taking place. It seems that there are a variety of ways one might use 
> an extension to help with various problems, but we don't have a 
> coherent description of the problems and why the use of one or more 
> types of extensions is an appropriate solution technique. We ought 
> not provide a syntax for including SCVP info in certs generically, 
> without a clear indication of how it is to be used, and by whom.

In another mail you seem to agree that a pointer in a 'cert to be
validated' is not a problem for DPD. Well, indeed, if you compare
this with the similar situation in OCSP, it is the same IMO. Having
an OCSP response from a CA or a delegated OCSP provider does not
mean that a client trusts in that CA. Still, an SCVP client could 
ask such a CA: "Assumed that I trust your CA root, or any of the 
following, please provide me a validated path to any of them.".

A CA needs to publish such a server address in some way. Again,
as for OCSP, the ee cert is one possibility. 


Peter


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89AG5eo069357 for <[e-mail]>; Tue, 9 Sep 2003 03:16:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h89AG5SH069356 for ietf-pkix-bks; Tue, 9 Sep 2003 03:16:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89AG0eo069336 for <[e-mail]>; Tue, 9 Sep 2003 03:16:01 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA12030; Tue, 9 Sep 2003 12:15:55 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Tue, 9 Sep 2003 12:15:55 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h89AFrq18904; Tue, 9 Sep 2003 12:15:53 +0200 (MEST)
Date: Tue, 9 Sep 2003 12:15:53 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> If a client is configured with per-CA info about acceptable SCVP 
> servers, why not configure both the public key info and the name 
> info, vs. putting this info into the certs?

In my experience, each time you can avoid another parameter,
configuration entry etc, you reduce the error potential
by a factor significantly greater than 1. 

You can also simply have the subject alternate name of
a cert.
 
A "cryptic" answer is also in the last paragraph of my previous mail.
A cert is a simple configuration file concerning all what you
need to know about your local scvp server (case 1 see below).

> 
> The latest spec also says that every response must be signed. maybe 
> we need to reconcile these statements in the spec.

MAYBE? In the last spec AuthenticatedData were added as another 
authentication means without consolidation of the rest of the text.
 
> >
> >Where do I talk about a choice? I am rather thinking that
> >both the definitions on TSP and OCSP may make sense.
> 
> sorry if I was unclear. until we figure out whether it makes sense to 
> put a pointer and/or a public key into a target cert, indicating how 
> to find/authenticate a corresponding SCVP server, we need not debate 
> what extension ought to be used.

It would be helpful if you could start distinguishing between the
two cases where 

1 - a pointer is in a server cert. 
2 - a pointer is in a target cert to validated

> 
> >
> >- The AIA in OCSP defines something usable to be put into
> >   certs to be validated;
> >
> >- The SIA in TSP defines a way to configure a server.
> 
> The appendix in 3161 defines is how to use SIA to mark an EE cert for 
> a TSA with info on how to contact the server. That is appropriate, 
> because the cert is an EE cert for the TSA. I would have no objection 
> to putting a similar marker into a cert issued to an SCVP server.
 
Good. This is case 1 above. 


> But, that is not at all the same as putting a pointer to an SCVP 
> server in a cert issued to another entity.  Is the former what you 
> intend, or the latter?

Yes, this is not the same, and that has already been said before.
We do already case 2 for OCSP or for CRLs. Both cases seem useful. 


> >>  >
> >>  >Scenario 2:
> >>  >
> >>  >- The same client wants a pointer to his local server;
> >>  >   this can be done in different ways; the client would
> >>  >   never use an IA in any of the certificate in the
> >>  >   chain to be validated. but would use an extension
> >>  >   in one certificate of a chain usable to authenticate
> >>  >   its local server.
> >>
> >>  I don't understand this example. are you saying that use of an
> >>  extension to identify an SCVP server is a good means of configuring
> >>  this info for a client? you mention a cert chain for the client
> >>  containing this info, but the presumption for DPV is that the client
> >>  may not be able to verify cert chains, and even for DPD that the
> >>  client may not be prepared to fetch and revocation info for chains.
> >>  thus any reference to a cert chain used by a client to verify the
> >>  public key and determine the name for an SCVP server seems
> >>  problematic, in that many of the contexts for which we cretaed SCVP
> >>  would not be able to make use of such a chain.
> >
> >This scenaroi would use an extension like an SIA in RFC 3161. A
> >client has a certificate for its local server, and can use it to
> >authenticate the connection or the response.
> 
> if the client has a cert for its local server, then why does the 
> client need a pointer to a remote server?

I think you are lost (what remote server?)
This case is case 1 above which you treat as appropriate.

> 
> >A client may not be able to verify all kinds of chains concerning
> >the certificates to be validated, but this is not the situation
> >for ONE server. on can argue, that the only thing needed
> >is a key and an address, even in this case a certificate
> >is a convenient place. As soon as one has SignedData as a
> >security mechanism, a certificate to valdidate a response
> >doesn't sound to me to be the most inconvenient way.
> 
> sorry, the typos and language make it too hard for me to figure out 
> what this paragraph is saying. can you rephrase?

This is simple case 1 and an indication a simple configuration 
mechanism using a cert. Since the current text of SCVP makes 
SignedData optional, I cannot say: A response is always signed. 
But, if SignedData are used, or if there are other techniques 
used like TLS, IPSEC that also used public keys, it seems 
reasonable to use a certificate and not just a public key as a 
validation mechanism. 

Regards
Peter


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h89380eo020634 for <[e-mail]>; Mon, 8 Sep 2003 20:08:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8938065020633 for ietf-pkix-bks; Mon, 8 Sep 2003 20:08:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8937weo020623 for <[e-mail]>; Mon, 8 Sep 2003 20:07:59 -0700 (PDT) (envelope-from [e-mail])
Received: from AMBARISHW2K (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id h8937mPo002711; Mon, 8 Sep 2003 20:07:48 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: SCVP delegation (was SCVP-AIA)
Date: Mon, 8 Sep 2003 20:07:48 -0700
Message-ID: <002901c3767f$8d17b090$[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, Build 10.0.4510
Importance: Normal
In-Reply-To: <p05210608bb82b94c41dc@[24.120.164.145]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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 that case, we are in vehement agreement.

What is important IMHO is SCVP indirection.

Regards,
Ambarish

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Stephen Kent
> Sent: Monday, September 08, 2003 3:57 PM
> To: Ambarish Malpani
> Cc: [e-mail]
> Subject: RE: SCVP delegation (was SCVP-AIA)
> 
> 
> 
> At 13:45 -0700 9/8/03, Ambarish Malpani wrote:
> >Hi Steve,
> >     You describe what I meant correctly.
> >
> >I think you are distinguishing between delegation and indirection by 
> >whether the two entities (delegator/delegatee) are controlled by the 
> >same entity or not - where you are calling it delegation if they are 
> >controlled by different entities, but indirection if they are 
> >controlled by the same entity. Is that correct?
> 
> yes.
> 
> >  >From the SCVP client's point of view, I am not sure I see the 
> >difference between delegation and indirection.
> 
> The client can't tell, but I want us to understand the difference as 
> we decide what we are trying to achieve.
> 
> We ought not confuse a syntactic ambiguity with a semantic one.
> 
> Steve
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88N6Reo010194 for <[e-mail]>; Mon, 8 Sep 2003 16:06:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88N6RDH010193 for ietf-pkix-bks; Mon, 8 Sep 2003 16:06:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88N6Peo010178 for <[e-mail]>; Mon, 8 Sep 2003 16:06:26 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h88N6K10012999; Mon, 8 Sep 2003 19:06:22 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210609bb82b9c45dff@[24.120.164.145]>
In-Reply-To: <00b301c37651$49c658b0$[e-mail]>
References: <00b301c37651$49c658b0$[e-mail]>
Date: Mon, 8 Sep 2003 19:02:10 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 17:36 -0400 9/8/03, Santosh Chokhani wrote:
>Steve:
>
>In Enterprise context, pointers may be less useful.

glad to see that we agree, although "less useful" is a more generous 
characterization than I would make :-)

>But, if an RP is dealing with multiple enterprises, the pointer does help.

so, we have an RP who has no "local" SCVP server; all the servers are 
"foreign" to him, and he has to choose the right one.

>The reason the pointer in the certificate is not critical for DPV also is
>that the RP client will require some out of band trusted means to obtain the
>Trusted SCVP Server public key.  For the public key, RP will not rely on the
>information in the certificate.  All the certificate tells RP is which of
>the RP client pre-configured servers to try first.

I'm confused again. You say that the client needs to get the public 
key for each server via some other means, not from the cert being 
validated. but then you say that the cert will be used to decide 
which server to "try first."  That seems to suggest that the client 
is willing to let any of these servers verify any cert for him, and 
it's just a matter of which server the cert points to. as I said 
before, this seems to have all the advantages of the browser PKI 
model :-)

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88N6Peo010186 for <[e-mail]>; Mon, 8 Sep 2003 16:06:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88N6P0I010185 for ietf-pkix-bks; Mon, 8 Sep 2003 16:06:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88N6Oeo010177 for <[e-mail]>; Mon, 8 Sep 2003 16:06:24 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h88N6K0w012999; Mon, 8 Sep 2003 19:06:20 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210608bb82b94c41dc@[24.120.164.145]>
In-Reply-To: <002401c3764a$2bd913d0$[e-mail]>
References: <002401c3764a$2bd913d0$[e-mail]>
Date: Mon, 8 Sep 2003 18:56:36 -0400
To: "Ambarish Malpani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SCVP delegation (was SCVP-AIA)
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 13:45 -0700 9/8/03, Ambarish Malpani wrote:
>Hi Steve,
>     You describe what I meant correctly.
>
>I think you are distinguishing between delegation and indirection by
>whether the two entities (delegator/delegatee) are controlled by the
>same entity or not - where you are calling it delegation if they are
>controlled by different entities, but indirection if they are
>controlled by the same entity. Is that correct?

yes.

>  >From the SCVP client's point of view, I am not sure I see the difference
>between delegation and indirection.

The client can't tell, but I want us to understand the difference as 
we decide what we are trying to achieve.

We ought not confuse a syntactic ambiguity with a semantic one.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Mxreo009837 for <[e-mail]>; Mon, 8 Sep 2003 15:59:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88MxrYW009836 for ietf-pkix-bks; Mon, 8 Sep 2003 15:59:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Mxqeo009830 for <[e-mail]>; Mon, 8 Sep 2003 15:59:52 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h88Mxe10012759; Mon, 8 Sep 2003 18:59:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210608bb82b94c41dc@[24.120.164.145]>
In-Reply-To: <002401c3764a$2bd913d0$[e-mail]>
References: <002401c3764a$2bd913d0$[e-mail]>
Date: Mon, 8 Sep 2003 18:56:36 -0400
To: "Ambarish Malpani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: SCVP delegation (was SCVP-AIA)
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 13:45 -0700 9/8/03, Ambarish Malpani wrote:
>Hi Steve,
>     You describe what I meant correctly.
>
>I think you are distinguishing between delegation and indirection by
>whether the two entities (delegator/delegatee) are controlled by the
>same entity or not - where you are calling it delegation if they are
>controlled by different entities, but indirection if they are
>controlled by the same entity. Is that correct?

yes.

>  >From the SCVP client's point of view, I am not sure I see the difference
>between delegation and indirection.

The client can't tell, but I want us to understand the difference as 
we decide what we are trying to achieve.

We ought not confuse a syntactic ambiguity with a semantic one.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88MsDeo009601 for <[e-mail]>; Mon, 8 Sep 2003 15:54:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88MsDSA009600 for ietf-pkix-bks; Mon, 8 Sep 2003 15:54:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88MsCeo009589 for <[e-mail]>; Mon, 8 Sep 2003 15:54:12 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h88Ms80w012536; Mon, 8 Sep 2003 18:54:09 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210606bb82b612805b@[24.120.164.145]>
In-Reply-To: <007501c37641$7e7d0460$[e-mail]>
References: <007501c37641$7e7d0460$[e-mail]>
Date: Mon, 8 Sep 2003 18:52:47 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 15:43 -0400 9/8/03, Santosh Chokhani wrote:
>Steve:
>
>See responses in-line in [].
>
>-----Original Message-----
>From: Stephen Kent [mailto:[e-mail]]
>Sent: Monday, September 08, 2003 3:00 PM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
>
>
>At 9:25 -0400 9/8/03, Santosh Chokhani wrote:
>>Denis:
>>
>>In all cases, SCVP client will be configured with the SCVP Servers and
>>their public keys and any constraints in terms of limiting the Server
>>for policies, name spaces etc.
>
>I think this would be reasonable, but where do we say this?
>
>[This is appropriate for DPV or trusted SCVP Service.  It should be implicit
>from SCVP Specification that the clients need the SCVP Server public keys in
>trusted manner.  Now, in terms of constraints, it should be up to the client
>whether it trusts an SCVP Server for all names and policies or only some.
>As to where we say these things, security considerations section of SCVP
>Server may be one place.  I am sure there are better places.]

Implicit is dangerous! we need more precise discussions of how a 
client that uses SCVP is supposed to work, e.g., in terms of 
configuration data, etc. see my comments to Peter on this topic.

>
>>All this will do is select a proper server so that computational
>>complexity is reduced.
>
>what complexity? the selection of the right server based on the cert
>presented?
>
>[If you do not have any algorithm to try, you will try all of them and on
>the average n/2 servers, f the client is configured with n servers.  This
>will result in communication delays and needless signature verifications on
>SCVP Server responses.  Also, whatever work the SCVP server does to
>determine, it is clueless about the certificate you just asked.]

some strings of words above are not a sentence. so, if we assume N >> 
1, this might be a problem, but in the enterprise case, I would 
generally expect N = 1, right? So, we need to discuss what other 
cases give rise to bigger values for N, and we need to include a 
discussion of why we could not use the scope data for an SCVP server, 
as configured in a client, to determine which server to contact re 
the EE cert in question. I thought we already discussed the dangers 
of having a list of SCVP servers (for DPV) where we would "trust" all 
of them for any cert  we wanted to verify.

>  >I see situations where a person has credentials and hence trust anchors
>>(these could be SCVP servers some day) from their employer, from one or
>>more public sector customers, and one or more private sector customers. 
>>In this cases, none of these are "foreign" CAs.  A pointer will select
>>the correct SCVP server.  Security and trust will still be a function
>>of client configuration and under client control.
>>
>
>What is a "public sector customer" relative to the person above. How
>are these folks "customers" of that person? Same question for the
>private sector analogs.
>
>[For example, I am a security consultant.  My customers like US Government
>and Banks want me to use certificates minted by them for me using their PKI]

These are examples of you selecting the right cert to use when you 
sign something for one of your customers, but you are not the RP in 
that case and SCVP is a service to an RP. are you trying to say that 
when you receive a cert from one of these customers, that you want 
the customer to tell you which SCVP server to invoke for them? 
first, if that;s the intent, the whole discussion above is backwards! 
second, how do you address the issue of limiting the scope for each 
if these servers? I'm not saying that you cannot address the problem, 
but it seems to come and go as a part of the processing you have 
described.

Steve
Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Mgceo009154 for <[e-mail]>; Mon, 8 Sep 2003 15:42:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88MgcY0009153 for ietf-pkix-bks; Mon, 8 Sep 2003 15:42:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Mgbeo009146 for <[e-mail]>; Mon, 8 Sep 2003 15:42:37 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h88MgW0w012094; Mon, 8 Sep 2003 18:42:33 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210605bb82b4d23555@[24.120.164.145]>
In-Reply-To: <007301c37640$5195eb70$[e-mail]>
References: <007301c37640$5195eb70$[e-mail]>
Date: Mon, 8 Sep 2003 18:41:17 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 15:35 -0400 9/8/03, Santosh Chokhani wrote:
>Steve:
>
>The client is configured with SCVP Servers it trusts.  The client has these
>servers public keys (in trusted manner, e.g., manual means).

OK, good start.

>If a certificate in question has an SCVP Server pointer that also happens to
>be in the client's list of SCVP Servers whom it trusts, the client uses that
>SCVP Server for DPD and for DPV.

This description lacks the scope controls you seem to have suggested 
earlier, i.e., what servers are trusted for what sets of certs?

>If the SCVP Server pointed to by the certificate is not in the client's
>trust list, the Server can be only used for DPD and you know most likely
>client will have some work remaining to do to find cross certification from
>RP domain to subscriber domain.

So, if the client needs the DPV service, because it is dumb, it's up 
the creek here? that may be an odd response to finding this SCVP 
extension in an EE cert. I can see instances where this might be OK, 
but in other cases why doesn't the client just contact its "home" 
SCVP server and ask it to perform the DPV service?

>It may be helpful to include hash of the SCVP Server public key in the
>extension to avoid name collisions.  But, that is not security critical
>since if two SCVP Servers shared the same name, the worst you can do is get
>the service from the wrong one and not verify the signature.

agreed.

Overall, what I see here is a start at how a client might make use of 
an extension, but with a number of holes to be addressed.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88MWXeo008854 for <[e-mail]>; Mon, 8 Sep 2003 15:32:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88MWXjw008853 for ietf-pkix-bks; Mon, 8 Sep 2003 15:32:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88MWVeo008840 for <[e-mail]>; Mon, 8 Sep 2003 15:32:32 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h88MWH16011695; Mon, 8 Sep 2003 18:32:26 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210603bb82aeb4c638@[24.120.164.145]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 8 Sep 2003 18:29:23 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 15:07 +0200 9/8/03, Peter Sylvester wrote:
>  >
>>  I didn't think we had specs that called for AIA/SIA to be used for
>>  any service other than OCSP, among the services you listed. I thought
>>  Denis was saying that IF we were to put a pointer to an SCVP service
>>  in AIA, THHEN it would make sense to put in a pointer to TSP, but
>>  that this was not currently the case. 3280 defines support only for
>>  OCSP here. 3161 makes no reference to AIA, so I'm not sure why you
>>  say that AIA could point to a TSA. Only your informational DVCS RFC
>>  makes reference to AIA (something I admit that I didn't notice).
>
>
>The appendix RFC 3161 an also a corresponding part in 3280.
>I remember the long discussion about the reintroduction of
>that SIA in 3161 before finishing 3280.

The use of SIA in TSP makes sense because the extension is used in 
the cert for the TSA, not for other entities.  At least that's how I 
read the appendix in 3161.

>
><paranthese>
>
>I also remember that I had a very length private discussion
>with you personally about the history of AIA or SIA and
>another extension which came from the internet and was in some
>old draft. I expressed my feeling that having a AIA, an SIA
>and yet another 'class like' definition which still has
>OID based parameters is a slight overkill and sometimes
>difficult to maintain.

Sorry, but I don't understand the nature of the overkill or what is 
hard to maintain. AIA and SIA have different semantics; they should 
be used in different contexts. I don't know yet whether we would need 
another extension for use with SCVP, or can use one of these, because 
I still do not have a clear picture of what folks plan to do with the 
extension.

>
></paranthese>
>
>>
>>  >This does seem an afterthought to me but rather a well accepted feature
>>  >since years which doesn't seem to need a particular requirement.
>>
>>  Well, we agree on the afterthought part :-), but probably not the
>>  "well accepted feature" part. Before the WG says that putting a
>>  pointer in AIA or SIA makes sense for SCVP, we need to agree on the
>>  requirements.
>
>here are some.
>
>- One is in a ee entity whose status is to be queried a location
>   where to ask for the service. The result of the service need
>   to be authenticated in whatever is appropriate for the client;
>   The two CA models of OCSP are examples.
>   A possible implementation is to put an AIA into an end cert.

I do not understand this example, please rephrase.

>- It seems useful to have such a pointer in a CA cert indicating
>   a service concerning all certificates issued by that CA (vs
>   the previous IA would indicate where to obtain information
>   about the CA certificate.)

If the service is DPD, I think this may make sense. if it is DPV, 
then what info about the CA cert is to be supplied and how is it to 
be used? we already have a way to convey CRL and OCSP info relative 
to a CA, and because the CA is authoritative for revocation info, 
this is fine. but DPV is very different and so a different argument 
needs to be made about why one would go to an SCVP server of the 
Issuer's choosing when trying to verify a cert issued by that CA.

>- A third requirement is to have a simple configuration of
>   a local SCVP service, which needs to be authenticated either
>   by some IPSEC, TLS or SMIME signature through a certificate.
>   This can be done for example by an extension inside the
>   server cert or any cert in the trustpath of the server's cert.

You describe here and example where you want to mark an EE cert as 
being an SCVP server cert and to indicate where the server is. That's 
very different from the examples above and deserves to be evaluated 
independently, and might be a different extension. But, when you say 
that the extension might appear anywhere in the path, I think this is 
a very different situation, for which I have not seen any indication 
of the intended processing model.

>- It is necssary to distinguish SCVP servers, in particular if
>   end-entity belong to the same CA. A special key-purpose seems
>   a sufficient way to do this.

Sorry, but this sentence makes no sense to me, and since you seem to 
suggest that an extended key usage OID might suffice, maybe we need 
not pursue it further.

>  > >A simple way to configure a public key is a certificate. You can have
>  > >like in TSP a SIA with your local server, and your local server acting
>>  >as a proxy can contact a CA's server using an AIA in the cert to be
>>  >validated.
>>
>>  Sorry, but you lost me here, i.e., not enough context near your
>>  answer for me to remember what the question was. But, I'll take a
>>  stab anyway.
>>
>>  We need to distinguish between what a client would do with a pointer
>>  in an extension vs. what an SCVP server might do, re relay. The
>>  answers may be different, e.g., one might make sense but the other
>>  may not. If so, then  we might decide to allow an SCVP reference in
>>  one of these extensions, BUT also make it clear under which of the
>>  two cases it is to be used.
>
>Not really, since the extensions are not in the same certificate.
>in one case it is the server's trust chain, the other are the certs
>to be validated. But, it is probably necessary to distinguish the different
>usages (at least two).

all I can get out of this comment is that we may agree on the need to 
have two different classes of extensions for different semantics.


Peter, what I would like to see is a clearer articulation of what 
problems are being solved by the suggestion extension(s), and how the 
use of an extension solves the problem, i.e., some discussion of the 
processing that takes place. The descriptions should say whether we 
are helping a client find and authenticate an appropriate SCVP 
server, or whether we are helping an SCVP server in its job. The 
descriptions should say whether we are using SCVP for DPD or DPV. 
They should indicate whether the problem is assumed to arise in an 
enterprise context, or in some other context that is described. The 
processing description should indicate where the required info comes 
from, and how the consumer of that info (client or SCVP server) can 
use that info safely.

I think we need this kind of text to clarify the discussion that is 
taking place. It seems that there are a variety of ways one might use 
an extension to help with various problems, but we don't have a 
coherent description of the problems and why the use of one or more 
types of extensions is an appropriate solution technique. We ought 
not provide a syntax for including SCVP info in certs generically, 
without a clear indication of how it is to be used, and by whom.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88MWVeo008847 for <[e-mail]>; Mon, 8 Sep 2003 15:32:31 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88MWVAG008846 for ietf-pkix-bks; Mon, 8 Sep 2003 15:32:31 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88MWUeo008839 for <[e-mail]>; Mon, 8 Sep 2003 15:32:30 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h88MWH0w011695; Mon, 8 Sep 2003 18:32:18 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210604bb8282522530@[24.120.164.145]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 8 Sep 2003 18:09:25 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:14 +0200 9/8/03, Peter Sylvester wrote:
>  > >
>>  >- A client asks his local server to validate a cert.
>>  >
>>  >- The local server has a policy/configuration indicating that
>>  >   for the cert in question the AIA of an CA operated DPV
>>  >   service is populated and should be contacted.
>>
>>  How might this be specified? certainly it would be impractical to
>>  specify this on a per cert basis.  do you envision specifying this on
>>  a per CA basis?
>
>For example.

If a client is configured with per-CA info about acceptable SCVP 
servers, why not configure both the public key info and the name 
info, vs. putting this info into the certs?

>  > >- The local server does so and authenticates the response
>  > >   in whatever way is indicated in the policy.
>>
>>  SCVP requires a signature on every server response, other than an
>>  error response. if we don't use the signature for validation, I have
>>  no idea what it might take to trick the server. it also was not clear
>>  to me that there was a policy configuration item for this, i.e., that
>>  one could specify non-signature means of verifying server responses
>>  on a per server basis. can you point me to the part of SCVP that
>>  indicates this?
>
>
>In the latest draft of SCVP there has been added the usage of
>Authenticated data. I had already made a comment concerning
>this. By saying "in whatever way is indicated in the policy"
>I tried to avoid any further discussion.

The latest spec also says that every response must be signed. maybe 
we need to reconcile these statements in the spec.

>  > >Now, one can ask whether the ee-cert needs an AIA. Indeed,
>  > >it may be better to have an SIA extension in a CA cert
>>  >saying that in order to obtain a paricular information
>>  >containing certificates issued by this authority.
>>  >
>>  >A SIA in a CA cert for OCSP also makes sense to me BTW.
>>
>>  we should defer arguing about the choice of extension until we
>>  understand how the extension is used and what the the benefits and
>>  pitfalls.
>
>Where do I talk about a choice? I am rather thinking that
>both the definitions on TSP and OCSP may make sense.

sorry if I was unclear. until we figure out whether it makes sense to 
put a pointer and/or a public key into a target cert, indicating how 
to find/authenticate a corresponding SCVP server, we need not debate 
what extension ought to be used.

>
>- The AIA in OCSP defines something usable to be put into
>   certs to be validated;
>
>- The SIA in TSP defines a way to configure a server.

The appendix in 3161 defines is how to use SIA to mark an EE cert for 
a TSA with info on how to contact the server. That is appropriate, 
because the cert is an EE cert for the TSA. I would have no objection 
to putting a similar marker into a cert issued to an SCVP server. 
But, that is not at all the same as putting a pointer to an SCVP 
server in a cert issued to another entity.  Is the former what you 
intend, or the latter?

>
>>
>>  >
>>  >
>>  >Scenario 2:
>>  >
>>  >- The same client wants a pointer to his local server;
>>  >   this can be done in different ways; the client would
>>  >   never use an IA in any of the certificate in the
>>  >   chain to be validated. but would use an extension
>>  >   in one certificate of a chain usable to authenticate
>>  >   its local server.
>>
>>  I don't understand this example. are you saying that use of an
>>  extension to identify an SCVP server is a good means of configuring
>>  this info for a client? you mention a cert chain for the client
>>  containing this info, but the presumption for DPV is that the client
>>  may not be able to verify cert chains, and even for DPD that the
>>  client may not be prepared to fetch and revocation info for chains.
>>  thus any reference to a cert chain used by a client to verify the
>>  public key and determine the name for an SCVP server seems
>>  problematic, in that many of the contexts for which we cretaed SCVP
>>  would not be able to make use of such a chain.
>
>This scenaroi would use an extension like an SIA in RFC 3161. A
>client has a certificate for its local server, and can use it to
>authenticate the connection or the response.

if the client has a cert for its local server, then why does the 
client need a pointer to a remote server?

>A client may not be able to verify all kinds of chains concerning
>the certificates to be validated, but this is not the situation
>for ONE server. on can argue, that the only thing needed
>is a key and an address, even in this case a certificate
>is a convenient place. As soon as one has SignedData as a
>security mechanism, a certificate to valdidate a response
>doesn't sound to me to be the most inconvenient way.

sorry, the typos and language make it too hard for me to figure out 
what this paragraph is saying. can you rephrase?

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Laieo004471 for <[e-mail]>; Mon, 8 Sep 2003 14:36:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88LaiND004470 for ietf-pkix-bks; Mon, 8 Sep 2003 14:36:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Laheo004464 for <[e-mail]>; Mon, 8 Sep 2003 14:36:43 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h88Lade8022988; Mon, 8 Sep 2003 17:36:39 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Mon, 8 Sep 2003 17:36:34 -0400
Message-ID: <00b301c37651$49c658b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <p05210602bb827ffa9871@[24.120.164.145]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h88Laheo004466
Sender: [e-mail]
Precedence: 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 Enterprise context, pointers may be less useful.

But, if an RP is dealing with multiple enterprises, the pointer does help.

The reason the pointer in the certificate is not critical for DPV also is
that the RP client will require some out of band trusted means to obtain the
Trusted SCVP Server public key.  For the public key, RP will not rely on the
information in the certificate.  All the certificate tells RP is which of
the RP client pre-configured servers to try first.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Monday, September 08, 2003 2:55 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]



At 8:50 -0400 9/8/03, Santosh Chokhani wrote:
>Steve:
>
>The selection is not security critical.  The SCVP Server represented in 
>the certificate is simply known to the CA to have all the relevant 
>certificates and revocation information.
>
I'm sorry, but I can't understand what you are saying.

If a CA puts a pointer to an SCVP server into a cert it issues, then 
that CA is asserting what server should be contacted for DPV or DPD. 
For DPD that does not seem to be security critical,. but for DPV it 
is, and I question whether the Issuer of the cert is the right entity 
to make such a determination. Looking at the intro text for SCVP, it 
emphasizes the enterprise context and in that context, what you said 
does not seem appropriate. But, maybe we're missing too much context, 
again. Can you elaborate on your comment?

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Kjueo002092 for <[e-mail]>; Mon, 8 Sep 2003 13:45:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88KjuBq002091 for ietf-pkix-bks; Mon, 8 Sep 2003 13:45:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Kjueo002084 for <[e-mail]>; Mon, 8 Sep 2003 13:45:56 -0700 (PDT) (envelope-from [e-mail])
Received: from AMBARISHW2K (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id h88KjePo002552; Mon, 8 Sep 2003 13:45:41 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: SCVP delegation (was SCVP-AIA)
Date: Mon, 8 Sep 2003 13:45:40 -0700
Message-ID: <002401c3764a$2bd913d0$[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, Build 10.0.4510
Importance: Normal
In-Reply-To: <p05210600bb823c7491fd@[24.120.164.145]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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,
    You describe what I meant correctly.

I think you are distinguishing between delegation and indirection by
whether the two entities (delegator/delegatee) are controlled by the
same entity or not - where you are calling it delegation if they are
controlled by different entities, but indirection if they are
controlled by the same entity. Is that correct?

>From the SCVP client's point of view, I am not sure I see the difference
between delegation and indirection.

Regards,
Ambarish

> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]] 
> Sent: Monday, September 08, 2003 11:17 AM
> To: Ambarish Malpani
> Cc: [e-mail]
> Subject: Re: SCVP delegation (was SCVP-AIA)
> 
> 
> At 14:21 -0700 9/7/03, Ambarish Malpani wrote:
> >Hi Steve,
> >     I agree with what you say. However, that doesn't respond to the 
> >question of whether the "delegated mode" makes sense for SCVP.
> >
> >With regards to that question, I believe that delegation of SCVP 
> >authority makes perfect sense. Most people like to protect their 
> >"trusted key" very, very carefully and would like to use a different 
> >key for online operations than the one that is trusted by 
> the clients.
> >
> >So, I fully expect SCVP service providers to delegate the trust that 
> >clients have in them to online responders that actually sign the 
> >responses.
> >
> >Regards,
> >Ambarish
> >
> 
> I am puzzled by some of the details of your comment.  Each client 
> must have access to a public key that will be used by it to validate 
> responses from an SCVP server. So, is the thrust of your comment that 
> an SCVP server operator would have one private key that it used to 
> issue certs that serve to identify SCVP servers, to support the 
> indirection and mostly offline operation model you suggest? That way 
> clients would be configured with the corresponding public key, but 
> would use it only to validate the certs for an SCVP server. I just 
> want to clarify what you comments above mean in terms of the 
> mechanisms we are discussing. if this is what you were referring to, 
> then it does not strike me as an example of delegation, but rather an 
> example of indirection.
> 
> Steve
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Jhfeo095787 for <[e-mail]>; Mon, 8 Sep 2003 12:43:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88JhffW095786 for ietf-pkix-bks; Mon, 8 Sep 2003 12:43:41 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Jheeo095778 for <[e-mail]>; Mon, 8 Sep 2003 12:43:40 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h88Jhae8007301; Mon, 8 Sep 2003 15:43:36 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Mon, 8 Sep 2003 15:43:31 -0400
Message-ID: <007501c37641$7e7d0460$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <p05210603bb82810fd99f@[24.120.164.145]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h88Jheeo095781
Sender: [e-mail]
Precedence: 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:

See responses in-line in [].

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Monday, September 08, 2003 3:00 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


At 9:25 -0400 9/8/03, Santosh Chokhani wrote:
>Denis:
>
>In all cases, SCVP client will be configured with the SCVP Servers and 
>their public keys and any constraints in terms of limiting the Server 
>for policies, name spaces etc.

I think this would be reasonable, but where do we say this?

[This is appropriate for DPV or trusted SCVP Service.  It should be implicit
from SCVP Specification that the clients need the SCVP Server public keys in
trusted manner.  Now, in terms of constraints, it should be up to the client
whether it trusts an SCVP Server for all names and policies or only some.
As to where we say these things, security considerations section of SCVP
Server may be one place.  I am sure there are better places.]

>All this will do is select a proper server so that computational 
>complexity is reduced.

what complexity? the selection of the right server based on the cert
presented?

[If you do not have any algorithm to try, you will try all of them and on
the average n/2 servers, f the client is configured with n servers.  This
will result in communication delays and needless signature verifications on
SCVP Server responses.  Also, whatever work the SCVP server does to
determine, it is clueless about the certificate you just asked.]

>I see situations where a person has credentials and hence trust anchors 
>(these could be SCVP servers some day) from their employer, from one or 
>more public sector customers, and one or more private sector customers.  
>In this cases, none of these are "foreign" CAs.  A pointer will select 
>the correct SCVP server.  Security and trust will still be a function 
>of client configuration and under client control.
>

What is a "public sector customer" relative to the person above. How 
are these folks "customers" of that person? Same question for the 
private sector analogs.

[For example, I am a security consultant.  My customers like US Government
and Banks want me to use certificates minted by them for me using their PKI]

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88JZGeo095025 for <[e-mail]>; Mon, 8 Sep 2003 12:35:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88JZGTr095024 for ietf-pkix-bks; Mon, 8 Sep 2003 12:35:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88JZFeo095019 for <[e-mail]>; Mon, 8 Sep 2003 12:35:15 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h88JZBe8006222; Mon, 8 Sep 2003 15:35:11 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Mon, 8 Sep 2003 15:35:06 -0400
Message-ID: <007301c37640$5195eb70$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
In-Reply-To: <p05210602bb827ffa9871@[24.120.164.145]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h88JZGeo095020
Sender: [e-mail]
Precedence: 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:

The client is configured with SCVP Servers it trusts.  The client has these
servers public keys (in trusted manner, e.g., manual means).

If a certificate in question has an SCVP Server pointer that also happens to
be in the client's list of SCVP Servers whom it trusts, the client uses that
SCVP Server for DPD and for DPV.

If the SCVP Server pointed to by the certificate is not in the client's
trust list, the Server can be only used for DPD and you know most likely
client will have some work remaining to do to find cross certification from
RP domain to subscriber domain. 

It may be helpful to include hash of the SCVP Server public key in the
extension to avoid name collisions.  But, that is not security critical
since if two SCVP Servers shared the same name, the worst you can do is get
the service from the wrong one and not verify the signature.


-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Monday, September 08, 2003 2:55 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


At 8:50 -0400 9/8/03, Santosh Chokhani wrote:
>Steve:
>
>The selection is not security critical.  The SCVP Server represented in 
>the certificate is simply known to the CA to have all the relevant 
>certificates and revocation information.
>
I'm sorry, but I can't understand what you are saying.

If a CA puts a pointer to an SCVP server into a cert it issues, then 
that CA is asserting what server should be contacted for DPV or DPD. 
For DPD that does not seem to be security critical,. but for DPV it 
is, and I question whether the Issuer of the cert is the right entity 
to make such a determination. Looking at the intro text for SCVP, it 
emphasizes the enterprise context and in that context, what you said 
does not seem appropriate. But, maybe we're missing too much context, 
again. Can you elaborate on your comment?

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88JAueo092745 for <[e-mail]>; Mon, 8 Sep 2003 12:10:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88JAuwT092744 for ietf-pkix-bks; Mon, 8 Sep 2003 12:10:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88JAteo092732 for <[e-mail]>; Mon, 8 Sep 2003 12:10:55 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h88JAM1A002016; Mon, 8 Sep 2003 15:10:51 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210603bb82810fd99f@[24.120.164.145]>
In-Reply-To: <002c01c3760c$9e419890$[e-mail]>
References: <002c01c3760c$9e419890$[e-mail]>
Date: Mon, 8 Sep 2003 14:59:54 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:25 -0400 9/8/03, Santosh Chokhani wrote:
>Denis:
>
>In all cases, SCVP client will be configured with the SCVP Servers and their
>public keys and any constraints in terms of limiting the Server for
>policies, name spaces etc.

I think this would be reasonable, but where do we say this?

>All this will do is select a proper server so that computational complexity
>is reduced.

what complexity? the selection of the right server based on the cert presented?

>I see situations where a person has credentials and hence trust anchors
>(these could be SCVP servers some day) from their employer, from one or more
>public sector customers, and one or more private sector customers.  In this
>cases, none of these are "foreign" CAs.  A pointer will select the correct
>SCVP server.  Security and trust will still be a function of client
>configuration and under client control.
>

What is a "public sector customer" relative to the person above. How 
are these folks "customers" of that person? Same question for the 
private sector analogs.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88JAseo092738 for <[e-mail]>; Mon, 8 Sep 2003 12:10:54 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88JAsYU092737 for ietf-pkix-bks; Mon, 8 Sep 2003 12:10:54 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88JAreo092728 for <[e-mail]>; Mon, 8 Sep 2003 12:10:53 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h88JAM18002016; Mon, 8 Sep 2003 15:10:49 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210602bb827ffa9871@[24.120.164.145]>
In-Reply-To: <002b01c37607$cbde7bb0$[e-mail]>
References: <002b01c37607$cbde7bb0$[e-mail]>
Date: Mon, 8 Sep 2003 14:55:02 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:50 -0400 9/8/03, Santosh Chokhani wrote:
>Steve:
>
>The selection is not security critical.  The SCVP Server represented in the
>certificate is simply known to the CA to have all the relevant certificates
>and revocation information.
>
I'm sorry, but I can't understand what you are saying.

If a CA puts a pointer to an SCVP server into a cert it issues, then 
that CA is asserting what server should be contacted for DPV or DPD. 
For DPD that does not seem to be security critical,. but for DPV it 
is, and I question whether the Issuer of the cert is the right entity 
to make such a determination. Looking at the intro text for SCVP, it 
emphasizes the enterprise context and in that context, what you said 
does not seem appropriate. But, maybe we're missing too much context, 
again. Can you elaborate on your comment?

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88JAXeo092706 for <[e-mail]>; Mon, 8 Sep 2003 12:10:33 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88JAXiF092705 for ietf-pkix-bks; Mon, 8 Sep 2003 12:10:33 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88JAVeo092697 for <[e-mail]>; Mon, 8 Sep 2003 12:10:32 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h88JAM0w002016; Mon, 8 Sep 2003 15:10:27 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210600bb823c7491fd@[24.120.164.145]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Mon, 8 Sep 2003 14:16:49 -0400
To: "Ambarish Malpani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: SCVP delegation (was SCVP-AIA)
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 14:21 -0700 9/7/03, Ambarish Malpani wrote:
>Hi Steve,
>     I agree with what you say. However, that doesn't respond to the
>question of whether the "delegated mode" makes sense for SCVP.
>
>With regards to that question, I believe that delegation of SCVP
>authority makes perfect sense. Most people like to protect their
>"trusted key" very, very carefully and would like to use a
>different key for online operations than the one that is trusted
>by the clients.
>
>So, I fully expect SCVP service providers to delegate the trust
>that clients have in them to online responders that actually
>sign the responses.
>
>Regards,
>Ambarish
>

I am puzzled by some of the details of your comment.  Each client 
must have access to a public key that will be used by it to validate 
responses from an SCVP server. So, is the thrust of your comment that 
an SCVP server operator would have one private key that it used to 
issue certs that serve to identify SCVP servers, to support the 
indirection and mostly offline operation model you suggest? That way 
clients would be configured with the corresponding public key, but 
would use it only to validate the certs for an SCVP server. I just 
want to clarify what you comments above mean in terms of the 
mechanisms we are discussing. if this is what you were referring to, 
then it does not strike me as an example of delegation, but rather an 
example of indirection.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88DPReo063384 for <[e-mail]>; Mon, 8 Sep 2003 06:25:27 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88DPRtO063383 for ietf-pkix-bks; Mon, 8 Sep 2003 06:25:27 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88DPQeo063377 for <[e-mail]>; Mon, 8 Sep 2003 06:25:26 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (242.arlington-13-14rs.va.dial-access.att.net[12.92.101.242]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <200309081325101120061thoe>; Mon, 8 Sep 2003 13:25:10 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Mon, 8 Sep 2003 09:25:05 -0400
Message-ID: <002c01c3760c$9e419890$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h88DPReo063379
Sender: [e-mail]
Precedence: 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 all cases, SCVP client will be configured with the SCVP Servers and their
public keys and any constraints in terms of limiting the Server for
policies, name spaces etc.

All this will do is select a proper server so that computational complexity
is reduced.

I see situations where a person has credentials and hence trust anchors
(these could be SCVP servers some day) from their employer, from one or more
public sector customers, and one or more private sector customers.  In this
cases, none of these are "foreign" CAs.  A pointer will select the correct
SCVP server.  Security and trust will still be a function of client
configuration and under client control.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]] 
Sent: Monday, September 08, 2003 9:16 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


Santosh,

> Steve:
> 
> The selection is not security critical.  The SCVP Server represented 
> in the certificate is simply known to the CA to have all the relevant 
> certificates and revocation information.

  ... "simply known to have all the relevant certificates and revocation 
information" in order to verify the certificate along *any* validation
policy ? If not "any", which one ? or which ones ?

Maybe, it is not that simple. :-)

Denis


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]]
> Sent: Sunday, September 07, 2003 2:25 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> 
> At 12:21 -0400 9/6/03, Santosh Chokhani wrote:
> 
>>Steve:
>>
>>I agree that for DPD services an extension (AIA or some new extension)
>>can be useful in path discovery.
>>
>>For path validation, the client must always be pre-configured and the
>>most an extension can do is to help select from the ones the client 
>>configured with.
> 
> 
> In an enterprise context, why would one want to have a CA, in general
> a "foreign" CA, make this selection?
> 
> 
>>I also think from semantics and software complexity viewpoints, it is
>>better have a separate extension rather than overload AIA.
> 
> 
> I am more concerned with the semantics at this point, than the choice
> of extension.  Also, since there seems to be less to worry about re 
> DPD vs. DPV, maybe that distinction needs to be part of any 
> extension-based reference.
> 
> 
>>I never felt there was a reason to put the CA cert and OCSP responder
>>in the same extension (namely AIA).
> 
> 
> OK with me.
> 
> 
>>Similarly, if I were to do it again, I would have separate extensions
>>for inhibit policy mapping and require explicit policy.  In general, 
>>unless the fields are related, I would define separate extension.
> 
> 
> Well, X.509 gave us this combination, and I'm not trying to open up
> that can of worms.
> 
> Steve
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88DG4eo061811 for <[e-mail]>; Mon, 8 Sep 2003 06:16:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88DG3YH061810 for ietf-pkix-bks; Mon, 8 Sep 2003 06:16:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88DG1eo061805 for <[e-mail]>; Mon, 8 Sep 2003 06:16:02 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA126358; Mon, 8 Sep 2003 15:21:29 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id PAA09214; Mon, 8 Sep 2003 15:17:00 +0200
Message-ID: <[e-mail]>
Date: Mon, 08 Sep 2003 15:15:54 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
References: <002b01c37607$cbde7bb0$[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>

Santosh,

> Steve:
> 
> The selection is not security critical.  The SCVP Server represented in the
> certificate is simply known to the CA to have all the relevant certificates
> and revocation information.

  ... "simply known to have all the relevant certificates and revocation 
information" in order to verify the certificate along *any* validation
policy ? If not "any", which one ? or which ones ?

Maybe, it is not that simple. :-)

Denis


> -----Original Message-----
> From: Stephen Kent [mailto:[e-mail]] 
> Sent: Sunday, September 07, 2003 2:25 PM
> To: Santosh Chokhani
> Cc: [e-mail]
> Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> 
> At 12:21 -0400 9/6/03, Santosh Chokhani wrote:
> 
>>Steve:
>>
>>I agree that for DPD services an extension (AIA or some new extension) 
>>can be useful in path discovery.
>>
>>For path validation, the client must always be pre-configured and the 
>>most an extension can do is to help select from the ones the client 
>>configured with.
> 
> 
> In an enterprise context, why would one want to have a CA, in general 
> a "foreign" CA, make this selection?
> 
> 
>>I also think from semantics and software complexity viewpoints, it is 
>>better have a separate extension rather than overload AIA.
> 
> 
> I am more concerned with the semantics at this point, than the choice 
> of extension.  Also, since there seems to be less to worry about re 
> DPD vs. DPV, maybe that distinction needs to be part of any 
> extension-based reference.
> 
> 
>>I never felt there was a reason to put the CA cert and OCSP responder 
>>in the same extension (namely AIA).
> 
> 
> OK with me.
> 
> 
>>Similarly, if I were to do it again, I would have separate extensions 
>>for inhibit policy mapping and require explicit policy.  In general, 
>>unless the fields are related, I would define separate extension.
> 
> 
> Well, X.509 gave us this combination, and I'm not trying to open up 
> that can of worms.
> 
> Steve
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88D7Meo061151 for <[e-mail]>; Mon, 8 Sep 2003 06:07:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88D7MhO061150 for ietf-pkix-bks; Mon, 8 Sep 2003 06:07:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88D7Keo061143 for <[e-mail]>; Mon, 8 Sep 2003 06:07:21 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA06256; Mon, 8 Sep 2003 15:07:20 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 8 Sep 2003 15:07:20 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h88D7Im16449; Mon, 8 Sep 2003 15:07:18 +0200 (MEST)
Date: Mon, 8 Sep 2003 15:07:18 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> I didn't think we had specs that called for AIA/SIA to be used for 
> any service other than OCSP, among the services you listed. I thought 
> Denis was saying that IF we were to put a pointer to an SCVP service 
> in AIA, THHEN it would make sense to put in a pointer to TSP, but 
> that this was not currently the case. 3280 defines support only for 
> OCSP here. 3161 makes no reference to AIA, so I'm not sure why you 
> say that AIA could point to a TSA. Only your informational DVCS RFC 
> makes reference to AIA (something I admit that I didn't notice).


The appendix RFC 3161 an also a corresponding part in 3280.
I remember the long discussion about the reintroduction of
that SIA in 3161 before finishing 3280.   

<paranthese>

I also remember that I had a very length private discussion
with you personally about the history of AIA or SIA and
another extension which came from the internet and was in some
old draft. I expressed my feeling that having a AIA, an SIA
and yet another 'class like' definition which still has
OID based parameters is a slight overkill and sometimes
difficult to maintain. 

</paranthese>

> 
> >This does seem an afterthought to me but rather a well accepted feature
> >since years which doesn't seem to need a particular requirement.
> 
> Well, we agree on the afterthought part :-), but probably not the 
> "well accepted feature" part. Before the WG says that putting a 
> pointer in AIA or SIA makes sense for SCVP, we need to agree on the 
> requirements.

here are some. 

- One is in a ee entity whose status is to be queried a location
  where to ask for the service. The result of the service need
  to be authenticated in whatever is appropriate for the client;
  The two CA models of OCSP are examples. 
  A possible implementation is to put an AIA into an end cert.

- It seems useful to have such a pointer in a CA cert indicating
  a service concerning all certificates issued by that CA (vs
  the previous IA would indicate where to obtain information
  about the CA certificate.) 

- A third requirement is to have a simple configuration of 
  a local SCVP service, which needs to be authenticated either
  by some IPSEC, TLS or SMIME signature through a certificate.
  This can be done for example by an extension inside the
  server cert or any cert in the trustpath of the server's cert.

- It is necssary to distinguish SCVP servers, in particular if
  end-entity belong to the same CA. A special key-purpose seems
  a sufficient way to do this.  
  
> >A simple way to configure a public key is a certificate. You can have
> >like in TSP a SIA with your local server, and your local server acting
> >as a proxy can contact a CA's server using an AIA in the cert to be
> >validated.
> 
> Sorry, but you lost me here, i.e., not enough context near your 
> answer for me to remember what the question was. But, I'll take a 
> stab anyway.
> 
> We need to distinguish between what a client would do with a pointer 
> in an extension vs. what an SCVP server might do, re relay. The 
> answers may be different, e.g., one might make sense but the other 
> may not. If so, then  we might decide to allow an SCVP reference in 
> one of these extensions, BUT also make it clear under which of the 
> two cases it is to be used.

Not really, since the extensions are not in the same certificate.
in one case it is the server's trust chain, the other are the certs
to be validated. But, it is probably necessary to distinguish the different
usages (at least two). 

> 
> I'd like te WG to address each of these cases separately, explaining 
> not syntactically or mechanically could be done, but why we believe 
> that this is an appropriate way to use SCVP vs. other options, etc.
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Coieo060310 for <[e-mail]>; Mon, 8 Sep 2003 05:50:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88CoiqP060308 for ietf-pkix-bks; Mon, 8 Sep 2003 05:50:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mtiwmhc13.worldnet.att.net (mtiwmhc13.worldnet.att.net [204.127.131.117]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88Coieo060285 for <[e-mail]>; Mon, 8 Sep 2003 05:50:44 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (242.arlington-13-14rs.va.dial-access.att.net[12.92.101.242]) by mtiwmhc13.worldnet.att.net (mtiwmhc13) with SMTP id <2003090812503711300s93sqe>; Mon, 8 Sep 2003 12:50:38 +0000
From: "Santosh Chokhani" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Mon, 8 Sep 2003 08:50:34 -0400
Message-ID: <002b01c37607$cbde7bb0$[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, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <p05210605bb8127236283@[10.1.71.45]>
Sender: [e-mail]
Precedence: 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:

The selection is not security critical.  The SCVP Server represented in the
certificate is simply known to the CA to have all the relevant certificates
and revocation information.

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Sunday, September 07, 2003 2:25 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


At 12:21 -0400 9/6/03, Santosh Chokhani wrote:
>Steve:
>
>I agree that for DPD services an extension (AIA or some new extension) 
>can be useful in path discovery.
>
>For path validation, the client must always be pre-configured and the 
>most an extension can do is to help select from the ones the client 
>configured with.

In an enterprise context, why would one want to have a CA, in general 
a "foreign" CA, make this selection?

>I also think from semantics and software complexity viewpoints, it is 
>better have a separate extension rather than overload AIA.

I am more concerned with the semantics at this point, than the choice 
of extension.  Also, since there seems to be less to worry about re 
DPD vs. DPV, maybe that distinction needs to be part of any 
extension-based reference.

>I never felt there was a reason to put the CA cert and OCSP responder 
>in the same extension (namely AIA).

OK with me.

>Similarly, if I were to do it again, I would have separate extensions 
>for inhibit policy mapping and require explicit policy.  In general, 
>unless the fields are related, I would define separate extension.

Well, X.509 gave us this combination, and I'm not trying to open up 
that can of worms.

Steve



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88AF5eo044650 for <[e-mail]>; Mon, 8 Sep 2003 03:15:05 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h88AF5Oq044649 for ietf-pkix-bks; Mon, 8 Sep 2003 03:15:05 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h88AF2eo044603 for <[e-mail]>; Mon, 8 Sep 2003 03:15:03 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id MAA05246; Mon, 8 Sep 2003 12:14:53 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 8 Sep 2003 12:14:53 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h88AEp816143; Mon, 8 Sep 2003 12:14:51 +0200 (MEST)
Date: Mon, 8 Sep 2003 12:14:51 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >
> >- A client asks his local server to validate a cert.
> >
> >- The local server has a policy/configuration indicating that
> >   for the cert in question the AIA of an CA operated DPV
> >   service is populated and should be contacted.
> 
> How might this be specified? certainly it would be impractical to 
> specify this on a per cert basis.  do you envision specifying this on 
> a per CA basis?

For example. 

> 
> >- The local server does so and authenticates the response
> >   in whatever way is indicated in the policy.
> 
> SCVP requires a signature on every server response, other than an 
> error response. if we don't use the signature for validation, I have 
> no idea what it might take to trick the server. it also was not clear 
> to me that there was a policy configuration item for this, i.e., that 
> one could specify non-signature means of verifying server responses 
> on a per server basis. can you point me to the part of SCVP that 
> indicates this?


In the latest draft of SCVP there has been added the usage of
Authenticated data. I had already made a comment concerning
this. By saying "in whatever way is indicated in the policy"
I tried to avoid any further discussion. 

> 
> >Now, one can ask whether the ee-cert needs an AIA. Indeed,
> >it may be better to have an SIA extension in a CA cert
> >saying that in order to obtain a paricular information
> >containing certificates issued by this authority.
> >
> >A SIA in a CA cert for OCSP also makes sense to me BTW.
> 
> we should defer arguing about the choice of extension until we 
> understand how the extension is used and what the the benefits and 
> pitfalls.

Where do I talk about a choice? I am rather thinking that
both the definitions on TSP and OCSP may make sense.

- The AIA in OCSP defines something usable to be put into
  certs to be validated;

- The SIA in TSP defines a way to configure a server.  

> 
> >
> >
> >Scenario 2:
> >
> >- The same client wants a pointer to his local server;
> >   this can be done in different ways; the client would
> >   never use an IA in any of the certificate in the
> >   chain to be validated. but would use an extension
> >   in one certificate of a chain usable to authenticate
> >   its local server.
> 
> I don't understand this example. are you saying that use of an 
> extension to identify an SCVP server is a good means of configuring 
> this info for a client? you mention a cert chain for the client 
> containing this info, but the presumption for DPV is that the client 
> may not be able to verify cert chains, and even for DPD that the 
> client may not be prepared to fetch and revocation info for chains. 
> thus any reference to a cert chain used by a client to verify the 
> public key and determine the name for an SCVP server seems 
> problematic, in that many of the contexts for which we cretaed SCVP 
> would not be able to make use of such a chain.

This scenaroi would use an extension like an SIA in RFC 3161. A
client has a certificate for its local server, and can use it to
authenticate the connection or the response. 

A client may not be able to verify all kinds of chains concerning
the certificates to be validated, but this is not the situation
for ONE server. on can argue, that the only thing needed
is a key and an address, even in this case a certificate
is a convenient place. As soon as one has SignedData as a 
security mechanism, a certificate to valdidate a response 
doesn't sound to me to be the most inconvenient way. 

Peter


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h883hceo001863 for <[e-mail]>; Sun, 7 Sep 2003 20:43:38 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h883hcWB001862 for ietf-pkix-bks; Sun, 7 Sep 2003 20:43:38 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h883haeo001855 for <[e-mail]>; Sun, 7 Sep 2003 20:43:37 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h883hK10023640; Sun, 7 Sep 2003 23:43:24 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210606bb8128a5bd0a@[10.1.71.45]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Sun, 7 Sep 2003 14:28:52 -0400
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 14:08 +1200 9/7/03, Peter Gutmann wrote:
>Wen-Cheng Wang <[e-mail]> writes:
>
>>I believe that the section 4.2.2.1 of RFC 3280 says that the purpose of the
>>AIA extension is to indicate how to access CA information or services
>>provided by the CA (i.e., the issuer of the certificate. If the SCVP service
>>is not provided by the CA itself, do you think it is appropriate to convey
>>the SCVP URI via the AIA extension?
>
>I think I've sat back long enough while this thing goes on and on and on, so
>I'll make an observation at this point: If users think the SCVP service (or
>any other service) needs to be referred to in a cert, they're going to stick
>it in there regardless of what PKIX or any PKIX RFC says, as they currently do
>with many other things as well.  The choice therefore is for PKIX to define a
>single, standardised AIA for it, or to have people invent a pile of different
>homebrew ones outside of PKIX.  That's the only point that merits
>consideration.  This endless debate over whether SCVP is or is not a CA
>service is about as productive as debating how many angels will fit on the end
>of a pin.
>
>Peter.

Peter,

Thanks for your periodic "it doesn't make any difference what PKIX 
says, vendors make the rules" reminder. Just to maintain parity I'll 
issue my usual rejoinder: "our job is to create what we believe are 
good standards, not to encourage or condone bad behavior by vendors 
or users."

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h883hQeo001850 for <[e-mail]>; Sun, 7 Sep 2003 20:43:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h883hQOT001849 for ietf-pkix-bks; Sun, 7 Sep 2003 20:43:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h883hPeo001843 for <[e-mail]>; Sun, 7 Sep 2003 20:43:25 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h883hK0w023640; Sun, 7 Sep 2003 23:43:21 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210605bb8127236283@[10.1.71.45]>
In-Reply-To: <001d01c37492$f59e10d0$[e-mail]>
References: <001d01c37492$f59e10d0$[e-mail]>
Date: Sun, 7 Sep 2003 14:25:28 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:21 -0400 9/6/03, Santosh Chokhani wrote:
>Steve:
>
>I agree that for DPD services an extension (AIA or some new extension) can
>be useful in path discovery.
>
>For path validation, the client must always be pre-configured and the most
>an extension can do is to help select from the ones the client configured
>with.

In an enterprise context, why would one want to have a CA, in general 
a "foreign" CA, make this selection?

>I also think from semantics and software complexity viewpoints, it is better
>have a separate extension rather than overload AIA.

I am more concerned with the semantics at this point, than the choice 
of extension.  Also, since there seems to be less to worry about re 
DPD vs. DPV, maybe that distinction needs to be part of any 
extension-based reference.

>I never felt there was a reason to put the CA cert and OCSP responder in the
>same extension (namely AIA).

OK with me.

>Similarly, if I were to do it again, I would have separate extensions for
>inhibit policy mapping and require explicit policy.  In general, unless the
>fields are related, I would define separate extension.

Well, X.509 gave us this combination, and I'm not trying to open up 
that can of worms.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h883dCeo001744 for <[e-mail]>; Sun, 7 Sep 2003 20:39:12 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h883dCWH001743 for ietf-pkix-bks; Sun, 7 Sep 2003 20:39:12 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h883dAeo001738 for <[e-mail]>; Sun, 7 Sep 2003 20:39:11 -0700 (PDT) (envelope-from [e-mail])
Received: from [24.120.164.145] (ssh.bbn.com [192.1.50.70]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h883cq16023533; Sun, 7 Sep 2003 23:39:04 -0400 (EDT)
Mime-Version: 1.0
X-Sender: kent@localhost
Message-Id: <p05210605bb8127236283@[10.1.71.45]>
In-Reply-To: <001d01c37492$f59e10d0$[e-mail]>
References: <001d01c37492$f59e10d0$[e-mail]>
Date: Sun, 7 Sep 2003 14:25:28 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:21 -0400 9/6/03, Santosh Chokhani wrote:
>Steve:
>
>I agree that for DPD services an extension (AIA or some new extension) can
>be useful in path discovery.
>
>For path validation, the client must always be pre-configured and the most
>an extension can do is to help select from the ones the client configured
>with.

In an enterprise context, why would one want to have a CA, in general 
a "foreign" CA, make this selection?

>I also think from semantics and software complexity viewpoints, it is better
>have a separate extension rather than overload AIA.

I am more concerned with the semantics at this point, than the choice 
of extension.  Also, since there seems to be less to worry about re 
DPD vs. DPV, maybe that distinction needs to be part of any 
extension-based reference.

>I never felt there was a reason to put the CA cert and OCSP responder in the
>same extension (namely AIA).

OK with me.

>Similarly, if I were to do it again, I would have separate extensions for
>inhibit policy mapping and require explicit policy.  In general, unless the
>fields are related, I would define separate extension.

Well, X.509 gave us this combination, and I'm not trying to open up 
that can of worms.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h880XQeo095041 for <[e-mail]>; Sun, 7 Sep 2003 17:33:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h880XQ8m095040 for ietf-pkix-bks; Sun, 7 Sep 2003 17:33:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from adacel.com (gunsmoke.adacel.com.au [210.11.130.7]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h880XNeo095027 for <[e-mail]>; Sun, 7 Sep 2003 17:33:24 -0700 (PDT) (envelope-from [e-mail])
Received: from nexus.adacel.com (Not Verified[10.32.240.1]) by adacel.com with NetIQ MailMarshal (v5.5.3.16) id <B00014b8b2>; Mon, 08 Sep 2003 10:27:47 +1000
Received: (qmail 31467 invoked from network); 8 Sep 2003 00:24:22 -0000
Received: from unknown (HELO osmium) (10.32.24.165) by nexus.adacel.com with SMTP; 8 Sep 2003 00:24:22 -0000
Reply-To: <[e-mail]>
From: "Steven Legg" <[e-mail]>
To: <[e-mail]>, "'Stephen Kent'" <[e-mail]>, <[e-mail]>
Subject: RE: WG last call
Date: Mon, 8 Sep 2003 11:33:00 +1100
Message-ID: <010901c375a0$c293d030$[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
Importance: Normal
In-Reply-To: <006601c374fc$be5dba20$[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,

Jim Schaad wrote:
> I have finally figured out what was lying in the back of my mind and
> screaming at me.
> 
> The element IPAddress cannot be DER encoded.  If you take a bit string
> and DER encode it, you will automatically remove all trailing zeros as
> these are assumed not to contain information.

Trailing zero bits are only removed by DER/BER when the BIT STRING type has
a NamedBitList. IPAddress does not have a NamedBitList so trailing zero
bits are retained and regarded as significant.

Regards,
Steven

> However with IPAddress,
> the trailing zeros do contain information. 
> 
> The element IPAddress cannot be BER encoded.  An implemeantion can DER
> encode a bitstring and still claim full compliance to the BER
> specification.
> 
> I cannot see how this draft can possibly progress without changing the
> basic type of IPAddress.
> 
> jim
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Jim Schaad
> > Sent: Friday, September 05, 2003 5:35 PM
> > To: 'Stephen Kent'; [e-mail]
> > Subject: RE: WG last call
> > 
> > 
> > 
> > Steve,
> > 
> > Here are my comments on the draft.
> > 
> > 1.  I don't understand doing a draft to define private 
> > extensions.  This is the phrase used in the abstract.used in 
> > the message.
> > 
> > 2.  I have a complete lack of understanding on how the IP 
> > adresses are to be encoded.  Either a section on this needs 
> > to be added or a reference to this needs to be place in the 
> document.
> > 
> > 3.  There is no ASN.1 module but this document defines new 
> > items.  (At least there is no tagging so I don't need to know 
> > explicit vs implicit.)
> > 
> > Jim
> > 
> > 
> > > -----Original Message-----
> > > From: [e-mail]
> > > [mailto:[e-mail]] On Behalf Of Stephen Kent
> > > Sent: Tuesday, August 19, 2003 7:02 PM
> > > To: [e-mail]
> > > Subject: WG last call
> > > 
> > > 
> > > 
> > > Folks,
> > > 
> > > We have a relatively old ID that was reposted in June, after minor
> > > changes in response to some previous comments. The 
> document defines 
> > > two proposed extensions, one to carry IP address prefix 
> > data and one 
> > > to carry Autonomous System Identifier info, in PK certs. The 
> > > extension was developed to enable creation of a PKI that 
> > reflects the 
> > > assignment of IP addresses and AS numbers, which happens 
> to be done 
> > > in a top down, singly rooted tree fashion, starting with 
> IANA. The 
> > > document is draft-ietf-pkix-x509-ipaddr-as-extn-01.txt.
> > > 
> > > I would like to initiate a 2-week WG last call on this 
> ID. There are
> > > now a couple of protocols that could make use of this 
> extension in 
> > > different contexts and so it would be good to have it as another, 
> > > completed PKIX item.
> > > 
> > > Since I am a co-author of the document, I will recuse 
> > myself from the
> > > process of determining WG consensus in this case, and rely 
> > on Tim to 
> > > deal with any issues that may arise.
> > > 
> > > Steve
> > > 
> > 
> 
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h880Nveo094714 for <[e-mail]>; Sun, 7 Sep 2003 17:23:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h880Nvjw094713 for ietf-pkix-bks; Sun, 7 Sep 2003 17:23:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailo.ntcif.telstra.com.au ([202.12.233.17]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h880Nteo094706 for <[e-mail]>; Sun, 7 Sep 2003 17:23:55 -0700 (PDT) (envelope-from [e-mail])
Received: (from uucp@localhost) by mailo.ntcif.telstra.com.au (8.8.2/8.6.9) id KAA05918 for <[e-mail]>; Mon, 8 Sep 2003 10:23:49 +1000 (EST)
Received: from maili.ntcif.telstra.com.au(202.12.162.17) via SMTP by mailo.ntcif.telstra.com.au, id smtpdxqa4Fl; Mon Sep  8 10:23:45 2003
Received: (from uucp@localhost) by maili.ntcif.telstra.com.au (8.8.2/8.6.9) id KAA07761 for <[e-mail]>; Mon, 8 Sep 2003 10:23:43 +1000 (EST)
Received: from localhost(127.0.0.1), claiming to be "mail.cdn.telstra.com.au" via SMTP by localhost, id smtpdISayHo; Mon Sep  8 10:22:58 2003
Received: from WSMSG0004.srv.dir.telstra.com (wsmsg0004.srv.dir.telstra.com [192.74.168.133]) by mail.cdn.telstra.com.au (8.8.2/8.6.9) with ESMTP id KAA21277 for <[e-mail]>; Mon, 8 Sep 2003 10:22:57 +1000 (EST)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MIMEOLE: Produced By Microsoft Exchange V6.0.6249.0
Subject: RE: WG last call - DER-encoded BIT STRING for IPAddress
Date: Mon, 8 Sep 2003 10:22:38 +1000
Message-ID: <[e-mail]>
Thread-Topic: WG last call
Thread-Index: AcN1DyP5xAhoY0neRLefIm7z3pHEBAAjSIqg
From: "Manger, James H" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h880Nueo094709
Sender: [e-mail]
Precedence: 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,

Trailing zeros are NOT removed when DER-encoding a BIT STRING, unless it is a "NamedBitList".  Hence they are not removed when DER-encoding a value of the IPAddress type in draft-ietf-pkix-x509-ipaddr-as-extn-01.txt.



ITU-T X.690 | ISO/IEC 8825-1 : 1994 "BER, CER & DER":

11.2.2 Where ITU-T Rec. X.680 | ISO/IEC 8824-1 clause 19.7 applies, the bitstring shall have all trailing 0 bits removed before it is encoded.

ITU-T X.680 | ISO/IEC 8824-1 : 1994 "ASN.1":

19.7 When a "NamedBitList" is used in defining a bitstring type ASN.1 encoding rules are free to add (or remove) arbitrarily many trailing 0 bits to (or from) values that are being encoded or decoded.  Application designers should therefore ensure that different semantics are not associated with such values which differ only in the number of trailing 0 bits.


-----Original Message-----
From: Jim Schaad [mailto:[e-mail]]
Sent: Sunday, 7 September 2003 2:59 PM
To: 'Stephen Kent'; [e-mail]
Subject: RE: WG last call



Steve,

I have finally figured out what was lying in the back of my mind and
screaming at me.

The element IPAddress cannot be DER encoded.  If you take a bit string
and DER encode it, you will automatically remove all trailing zeros as
these are assumed not to contain information.  However with IPAddress,
the trailing zeros do contain information. 

The element IPAddress cannot be BER encoded.  An implemeantion can DER
encode a bitstring and still claim full compliance to the BER
specification.

I cannot see how this draft can possibly progress without changing the
basic type of IPAddress.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jim Schaad
> Sent: Friday, September 05, 2003 5:35 PM
> To: 'Stephen Kent'; [e-mail]
> Subject: RE: WG last call
> 
> 
> 
> Steve,
> 
> Here are my comments on the draft.
> 
> 1.  I don't understand doing a draft to define private 
> extensions.  This is the phrase used in the abstract.used in 
> the message.
> 
> 2.  I have a complete lack of understanding on how the IP 
> adresses are to be encoded.  Either a section on this needs 
> to be added or a reference to this needs to be place in the document.
> 
> 3.  There is no ASN.1 module but this document defines new 
> items.  (At least there is no tagging so I don't need to know 
> explicit vs implicit.)
> 
> Jim
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Stephen Kent
> > Sent: Tuesday, August 19, 2003 7:02 PM
> > To: [e-mail]
> > Subject: WG last call
> > 
> > 
> > 
> > Folks,
> > 
> > We have a relatively old ID that was reposted in June, after minor
> > changes in response to some previous comments. The document defines 
> > two proposed extensions, one to carry IP address prefix 
> data and one 
> > to carry Autonomous System Identifier info, in PK certs. The 
> > extension was developed to enable creation of a PKI that 
> reflects the 
> > assignment of IP addresses and AS numbers, which happens to be done 
> > in a top down, singly rooted tree fashion, starting with IANA. The 
> > document is draft-ietf-pkix-x509-ipaddr-as-extn-01.txt.
> > 
> > I would like to initiate a 2-week WG last call on this ID. There are
> > now a couple of protocols that could make use of this extension in 
> > different contexts and so it would be good to have it as another, 
> > completed PKIX item.
> > 
> > Since I am a co-author of the document, I will recuse 
> myself from the
> > process of determining WG consensus in this case, and rely 
> on Tim to 
> > deal with any issues that may arise.
> > 
> > Steve
> > 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h87LJKgc087307 for <[e-mail]>; Sun, 7 Sep 2003 14:19:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h87LJKwn087306 for ietf-pkix-bks; Sun, 7 Sep 2003 14:19:20 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h87LJJgc087298 for <[e-mail]>; Sun, 7 Sep 2003 14:19:19 -0700 (PDT) (envelope-from [e-mail])
Received: from nt1 (nt1.malpani.biz [192.168.25.13]) by ns.malpani.biz (8.12.9/8.12.9) with SMTP id h87LIuPo001704; Sun, 7 Sep 2003 14:18:56 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Liaquat Khan" <[e-mail]>
Cc: <[e-mail]>
Subject: SCVP delegation (was SCVP-AIA)
Date: Sun, 7 Sep 2003 14:21: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 V6.00.2800.1165
Importance: Normal
In-Reply-To: <p0521060dbb7e7da11fa6@[128.89.89.82]>
Sender: [e-mail]
Precedence: 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 with what you say. However, that doesn't respond to the
question of whether the "delegated mode" makes sense for SCVP.

With regards to that question, I believe that delegation of SCVP
authority makes perfect sense. Most people like to protect their
"trusted key" very, very carefully and would like to use a 
different key for online operations than the one that is trusted
by the clients.

So, I fully expect SCVP service providers to delegate the trust
that clients have in them to online responders that actually
sign the responses.

Regards,
Ambarish

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Stephen Kent
> Sent: Friday, September 05, 2003 11:07 AM
> To: Liaquat Khan
> Cc: [e-mail]
> Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> 
> 
> At 21:12 +0100 9/3/03, Liaquat Khan wrote:
> >So I assume from the below that we are we ruling out an equivalent of
> >the "delegated" mode for SCVP? I.e. the ability for the CA to certify
> >the SCVP server's public key and thereby extend trust from the CA to the
> >SCVP service? 
> >
> >If this model was allowed then the use of the AIA extension to identify
> >the SCVP service would have been even more obvious...
> >
> >Regards,
> >LK
> 
> 
> I have to admit that a big part of my problem with your example is 
> that I hate to use the word trust when talking about CAs. So, I 
> cannot personally relate to the example above. But, if I suppress my 
> prejudice in this regard, I'd say the right answer is that an SCVP 
> server is an entity that must be trusted by its clients, but that 
> trust need not be inferred by a relationship to any CA. After all, a 
> dumb client using SCVP for DPV might be configured with a name and a 
> public key for a server, and thus the server need to even hold a cert 
> issued by any CA.
> 
> In general I would like to see separation between the CA that issues 
> a cert and the SCVP server that verifies the cert for an RP. If the 
> RP happens to be a client of the CA, in an enterprise context, then 
> the two probably are managed by the same folks and that fine. But in 
> general a client will need to validate certs issued by a wide range 
> of CAs, and one ought not think that ecah of the purported issuers of 
> certs would be an acceptable DPV server.  Again, note the terrible 
> security problems for the current web browser PKI model, which has a 
> similar flavor.
> 
> Steve
> 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h87Fw6gc064143 for <[e-mail]>; Sun, 7 Sep 2003 08:58:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h87Fw6Q1064142 for ietf-pkix-bks; Sun, 7 Sep 2003 08:58:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h87Fw4gc064136 for <[e-mail]>; Sun, 7 Sep 2003 08:58:05 -0700 (PDT) (envelope-from [e-mail])
Received: from fwd03.aul.t-online.de  by mailout06.sul.t-online.com with smtp  id 19w1vP-0005kz-09; Sun, 07 Sep 2003 17:58:03 +0200
Received: from hagen (bp-HrBZEremxd0+BERaDnQkA6FSWCB1SqAKBFz65AAn62g7RsetAUz@[80.128.85.199]) by fmrl03.sul.t-online.com with esmtp id 19w1vI-0NK8Ce0; Sun, 7 Sep 2003 17:57:56 +0200
From: "Florian Oelmaier" <[e-mail]>
To: <[e-mail]>, "'Peter Gutmann'" <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Sun, 7 Sep 2003 17:57:51 +0200
Organization: SyTrust
Message-ID: <001501c37558$cb6c7380$4228a8c0@hagen>
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
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
X-Seen: false
X-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>

Peter Gutman wrote:

> [...] If 
> users think the SCVP service (or any other service) needs to 
> be referred to in a cert, they're going to stick it in there 
> regardless of what PKIX or any PKIX RFC says, as they 
> currently do with many other things as well.

If PKIX defines an AIA for it, people WILL use it and that will cause a
lot more misunderstandings and problems.

At least one possible problem has been named here: the false indication
of trust for a certain SCVP responder.

Thus I agree with you completely, Peter - people will use it in an AIA
if they think they need it. But I doubt that many people will need it. I
would liek to avoid confusion for all people out there just to satisfy a
minority.

I fully agree with Denis and Steve - if anything, put it in another
extension. And I think we will find a lot of other usefull services that
can be put into that extension (a lot of them already named in this
thread).

Sincerely,

-- 
Florian Oelmaier
SyTrust



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h874vGgc092944 for <[e-mail]>; Sat, 6 Sep 2003 21:57:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h874vGA1092943 for ietf-pkix-bks; Sat, 6 Sep 2003 21:57:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h874vFgc092938 for <[e-mail]>; Sat, 6 Sep 2003 21:57:15 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id AA2CF6AC6E; Sat,  6 Sep 2003 21:57:17 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, <[e-mail]>
Subject: RE: WG last call
Date: Sat, 6 Sep 2003 21:58:56 -0700
Message-ID: <006601c374fc$be5dba20$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <004101c3740e$ab21a960$[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>

Steve,

I have finally figured out what was lying in the back of my mind and
screaming at me.

The element IPAddress cannot be DER encoded.  If you take a bit string
and DER encode it, you will automatically remove all trailing zeros as
these are assumed not to contain information.  However with IPAddress,
the trailing zeros do contain information. 

The element IPAddress cannot be BER encoded.  An implemeantion can DER
encode a bitstring and still claim full compliance to the BER
specification.

I cannot see how this draft can possibly progress without changing the
basic type of IPAddress.

jim

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Jim Schaad
> Sent: Friday, September 05, 2003 5:35 PM
> To: 'Stephen Kent'; [e-mail]
> Subject: RE: WG last call
> 
> 
> 
> Steve,
> 
> Here are my comments on the draft.
> 
> 1.  I don't understand doing a draft to define private 
> extensions.  This is the phrase used in the abstract.used in 
> the message.
> 
> 2.  I have a complete lack of understanding on how the IP 
> adresses are to be encoded.  Either a section on this needs 
> to be added or a reference to this needs to be place in the document.
> 
> 3.  There is no ASN.1 module but this document defines new 
> items.  (At least there is no tagging so I don't need to know 
> explicit vs implicit.)
> 
> Jim
> 
> 
> > -----Original Message-----
> > From: [e-mail]
> > [mailto:[e-mail]] On Behalf Of Stephen Kent
> > Sent: Tuesday, August 19, 2003 7:02 PM
> > To: [e-mail]
> > Subject: WG last call
> > 
> > 
> > 
> > Folks,
> > 
> > We have a relatively old ID that was reposted in June, after minor
> > changes in response to some previous comments. The document defines 
> > two proposed extensions, one to carry IP address prefix 
> data and one 
> > to carry Autonomous System Identifier info, in PK certs. The 
> > extension was developed to enable creation of a PKI that 
> reflects the 
> > assignment of IP addresses and AS numbers, which happens to be done 
> > in a top down, singly rooted tree fashion, starting with IANA. The 
> > document is draft-ietf-pkix-x509-ipaddr-as-extn-01.txt.
> > 
> > I would like to initiate a 2-week WG last call on this ID. There are
> > now a couple of protocols that could make use of this extension in 
> > different contexts and so it would be good to have it as another, 
> > completed PKIX item.
> > 
> > Since I am a co-author of the document, I will recuse 
> myself from the
> > process of determining WG consensus in this case, and rely 
> on Tim to 
> > deal with any issues that may arise.
> > 
> > Steve
> > 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8728Agc089117 for <[e-mail]>; Sat, 6 Sep 2003 19:08:10 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8728AZO089116 for ietf-pkix-bks; Sat, 6 Sep 2003 19:08:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h87282gc089107 for <[e-mail]>; Sat, 6 Sep 2003 19:08:03 -0700 (PDT) (envelope-from [e-mail])
Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by hermes.cs.auckland.ac.nz (8.12.9/8.12.9) with ESMTP id h8727mSU003362; Sun, 7 Sep 2003 14:07:48 +1200
Received: (from pgut001@localhost) by medusa01.cs.auckland.ac.nz (8.11.6/8.11.6) id h8728VT04789; Sun, 7 Sep 2003 14:08:31 +1200
Date: Sun, 7 Sep 2003 14:08:31 +1200
Message-Id: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
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>

Wen-Cheng Wang <[e-mail]> writes:

>I believe that the section 4.2.2.1 of RFC 3280 says that the purpose of the
>AIA extension is to indicate how to access CA information or services
>provided by the CA (i.e., the issuer of the certificate. If the SCVP service
>is not provided by the CA itself, do you think it is appropriate to convey
>the SCVP URI via the AIA extension?

I think I've sat back long enough while this thing goes on and on and on, so
I'll make an observation at this point: If users think the SCVP service (or
any other service) needs to be referred to in a cert, they're going to stick
it in there regardless of what PKIX or any PKIX RFC says, as they currently do
with many other things as well.  The choice therefore is for PKIX to define a
single, standardised AIA for it, or to have people invent a pile of different
homebrew ones outside of PKIX.  That's the only point that merits
consideration.  This endless debate over whether SCVP is or is not a CA
service is about as productive as debating how many angels will fit on the end
of a pin.

Peter.


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86GLigc065163 for <[e-mail]>; Sat, 6 Sep 2003 09:21:44 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h86GLiHD065162 for ietf-pkix-bks; Sat, 6 Sep 2003 09:21:44 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp03.mrf.mail.rcn.net (smtp03.mrf.mail.rcn.net [207.172.4.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h86GLhgc065157 for <[e-mail]>; Sat, 6 Sep 2003 09:21:43 -0700 (PDT) (envelope-from [e-mail])
Received: from 64-121-56-128.c3-0.snmt-ubr2.sfrn-snmt.ca.cable.rcn.com ([64.121.56.128] helo=wchokhani) by smtp03.mrf.mail.rcn.net with esmtp (Exim 3.35 #4) id 19vfom-00067V-00; Sat, 06 Sep 2003 12:21:44 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Sat, 6 Sep 2003 12:21:42 -0400
Message-ID: <001d01c37492$f59e10d0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
In-Reply-To: <p05210622bb7d6eaf59cf@[128.89.89.75]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h86GLigc065158
Sender: [e-mail]
Precedence: 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 agree that for DPD services an extension (AIA or some new extension) can
be useful in path discovery.

For path validation, the client must always be pre-configured and the most
an extension can do is to help select from the ones the client configured
with.

I also think from semantics and software complexity viewpoints, it is better
have a separate extension rather than overload AIA.

I never felt there was a reason to put the CA cert and OCSP responder in the
same extension (namely AIA).

Similarly, if I were to do it again, I would have separate extensions for
inhibit policy mapping and require explicit policy.  In general, unless the
fields are related, I would define separate extension.

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Friday, September 05, 2003 1:26 PM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


At 13:16 -0400 9/3/03, Santosh Chokhani wrote:
>Steve:
>
>Please see responses in-line in []
>
>-----Original Message-----
>From: Stephen Kent [mailto:[e-mail]]
>Sent: Wednesday, September 03, 2003 9:33 AM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
>
>
>At 18:32 -0400 9/2/03, Santosh Chokhani wrote:
>>Steve:
>>
>>The extension could work like OCSP extension in that the local 
>>settings can always override what is in the certificate.
>
>What I noted, was that IF there is no locally configured SCVP server 
>info, THEN the presence of such info in an AIA extension would 
>presumably be used, and that would create a configuration  management 
>vulnerability.
>
>[If there is no locally configured SCVP server, would the client invoke 
>SCVP services?  If so, what else does it have to rely on but the 
>information in the certificate.  Seems that in that scenario you use 
>something from the certificate or do something other than SCVP]

I was not as clear as I should have been. I assume that SCVP info, 
e.g., a public key and a name for an SCVP server, would be configured 
into a client that use SCVP. If the client has no public key to use 
to verify a response from an SCVP server, then how can the client use 
the service? if the intent is to provide central management for cert 
path validation, one would not want the clien to accept a name for a 
server from a random cert that happened to be presented to the 
client. Since I think the AIA extension was proposed as a means of 
conveying only the server name, I did not see that as useful. If the 
client has the server name, it didn't need to get it from a cert. If 
the cert extension overrides the configured name in the client, it 
would allow anyone to cause the client to go to the wrong server, not 
a good start, and certainly a DoS concern at a minimum.


>	<SNIP>
>
>>Now, here is a possible scenario of some utility.  Suppose you are 
>>using the untrusted SCVP servers for path development only.  Suppose 
>>that these servers tend to provide paths to some known trust anchors, 
>>including their Enterprise roots.
>>
>>Now, in cross certified environments and in Bridge environment, this 
>>partial path may be of some help.
>
>This scenario is not clear to me.  Please elaborate.
>
>[In complex trust graph, the certificate discovery problem can be 
>broken down into three chunks: 1.  Finding a trust point in the 
>subscriber domain
>-- this piece is provided by path discovery capability of a trusted or
>untrusted SCVP Server.  2.  Finding a trust point in RP domain -- this is
>straightforward most of the times (a trust list).  3.  Find how the path
>between the two trust points -- hopefully that is a direct cross
>certification, a path through a common bridge or through a series of
>bridges.  If the RP is able to find a path to a trust point in subscriber
>domain through the SCVP server, the path discovery problem is reduced:
>divide and conquer principle]

I'm puzzled by the description above. It seems to assume one model 
for path building, and that may not be the only choice. For example, 
the RP can start with its list of TAs and try to find a path to the 
target cert, period. (I don't think the term "subscriber" has been 
used here, perhaps because it's not clear to what the subscriber is 
subscribed in this case.)  if the target cert is accompanied by some 
CA certs one might choose to use them in the path building process, 
but if there is a complex graph involved, there is no reason to 
believe that the sender of these CA certs really knows what TAs the 
RP has locally configured.

Anyway, I assume that our intent with SCVP, is for the RP to ask his 
configured SCVP server to do whatever is needed to verify the cert, 
starting with path construction, constrained by the explicit or 
implicit policy parameters associated with the request. So, the 
question is whether an SCVP server pointed to by the issuer of the 
target cert, or by some CA cert in the path provided along woth the 
target cert, represents a good way to assist the SCVP server 
operating on behalf of the RP.

To me this could make sense if the server identified in the extension 
provides a DPD service, but not if it provided a DPV service. I say 
that because in the former case the server named in the cert need not 
be trusted by the server acting on behalf of the RP, whereas in the 
latter case it looks like the RP's server is abrogating its 
responsibility.

>  >I agree that for certification path validation (trusted SCVP 
> server),
>>at a first glance, the extension does not seem to be of much use since 
>>the RP clients must be configured with trusted public keys for the 
>>SCVP servers anyway.  It might as well be configured with SCVP names 
>>also.
>  >But, wait, here also, if there is more than 1 SCVP server in the RP
>>configuration, then if a name matches that in a certificate, that name 
>>breaks the tie.
>>
>
>This strikes me as a new twist on the processing model, and one that 
>needs to be examined carefully before we decide it's a good idea.
>
>[I am all for a careful examination.  Do you see any pitfalls in it?]

See my comments above about the roles being fulfilled by the various 
servers and the corresponding concerns.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h860X6gc072667 for <[e-mail]>; Fri, 5 Sep 2003 17:33:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h860X6DR072666 for ietf-pkix-bks; Fri, 5 Sep 2003 17:33:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h860X5gc072660 for <[e-mail]>; Fri, 5 Sep 2003 17:33:05 -0700 (PDT) (envelope-from [e-mail])
Received: from ROMANS (ip237.c132.blk1.bel.nwlink.com [209.20.132.237]) by smtp2.pacifier.net (Postfix) with ESMTP id 272FF6A986; Fri,  5 Sep 2003 17:33:05 -0700 (PDT)
Reply-To: <[e-mail]>
From: "Jim Schaad" <[e-mail]>
To: "'Stephen Kent'" <[e-mail]>, <[e-mail]>
Subject: RE: WG last call
Date: Fri, 5 Sep 2003 17:34:42 -0700
Message-ID: <004101c3740e$ab21a960$[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, Build 10.0.2627
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <p05210603bb6883b3023b@[12.159.173.175]>
Sender: [e-mail]
Precedence: 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,

Here are my comments on the draft.

1.  I don't understand doing a draft to define private extensions.  This
is the phrase used in the abstract.used in the message.

2.  I have a complete lack of understanding on how the IP adresses are
to be encoded.  Either a section on this needs to be added or a
reference to this needs to be place in the document.

3.  There is no ASN.1 module but this document defines new items.  (At
least there is no tagging so I don't need to know explicit vs implicit.)

Jim


> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Stephen Kent
> Sent: Tuesday, August 19, 2003 7:02 PM
> To: [e-mail]
> Subject: WG last call
> 
> 
> 
> Folks,
> 
> We have a relatively old ID that was reposted in June, after minor 
> changes in response to some previous comments. The document defines 
> two proposed extensions, one to carry IP address prefix data and one 
> to carry Autonomous System Identifier info, in PK certs. The 
> extension was developed to enable creation of a PKI that reflects the 
> assignment of IP addresses and AS numbers, which happens to be done 
> in a top down, singly rooted tree fashion, starting with IANA. The 
> document is draft-ietf-pkix-x509-ipaddr-as-extn-01.txt.
> 
> I would like to initiate a 2-week WG last call on this ID. There are 
> now a couple of protocols that could make use of this extension in 
> different contexts and so it would be good to have it as another, 
> completed PKIX item.
> 
> Since I am a co-author of the document, I will recuse myself from the 
> process of determining WG consensus in this case, and rely on Tim to 
> deal with any issues that may arise.
> 
> Steve
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85JT6gc059284 for <[e-mail]>; Fri, 5 Sep 2003 12:29:06 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85JT6me059283 for ietf-pkix-bks; Fri, 5 Sep 2003 12:29:06 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85JT4gc059263 for <[e-mail]>; Fri, 5 Sep 2003 12:29:05 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h85JSn0w026813; Fri, 5 Sep 2003 15:28:49 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210617bb7e93643943@[128.89.89.82]>
In-Reply-To: <7189308.1062788230399.JavaMail.root@10.1.22.7>
References: <7189308.1062788230399.JavaMail.root@10.1.22.7>
Date: Fri, 5 Sep 2003 15:25:21 -0400
To: Wen-Cheng Wang <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:57 +0800 9/6/03, Wen-Cheng Wang wrote:
>Steve,
>
>Sure, I totally agree that a SCVP server is not necessary to have
>a cert. Actually, I am in favor of directly delivering the 
>public-key of the SCVP server to the RP via a secure out-of-band 
>channel.
>It is rather unfortunate that the current SCVP ID (draft 12)
>seems to require a SCVP server MUST have a cert. The section
>4 of the current SCVP ID says "The SCVP server MUST include its
>own certificate in the certificates field within SignedData."
>I believe the text should be changed.
>
>Best Regards,
>Wen-Cheng

I missed that.  We should see what the editors for the doc say about 
changing the text to say that the server cert is optional.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85JDQgc058137 for <[e-mail]>; Fri, 5 Sep 2003 12:13:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85JDQQq058136 for ietf-pkix-bks; Fri, 5 Sep 2003 12:13:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.cht.com.tw ([202.39.162.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85JDOgc058127 for <[e-mail]>; Fri, 5 Sep 2003 12:13:24 -0700 (PDT) (envelope-from [e-mail])
Received: from mailgate.cht.com.tw ([10.1.22.7]) by fw.cht.com.tw (8.12.6/8.12.6) with ESMTP id h85JBsjO075129; Sat, 6 Sep 2003 03:11:54 +0800 (CST) (envelope-from [e-mail])
Received: from linux01 (webmail.cht.com.tw [10.1.22.40]) by mailgate.cht.com.tw (8.11.6/8.10.2) with ESMTP id h85J9wH21371; Sat, 6 Sep 2003 03:09:58 +0800
Message-ID: <7189308.1062788230399.JavaMail.root@10.1.22.7>
Date: Sat, 6 Sep 2003 02:57:10 +0800 (CST)
From: Wen-Cheng Wang <[e-mail]>
To: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: multipart/mixed;  boundary="----=_Part_2_20313166.1062788230395"
X-Mailer: WebMail/Java v0.7.10, built with JDK 1.4.1, SendMessage plugin v1.8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_Part_2_20313166.1062788230395
Content-Type: text/plain; charset="Big5"
Content-Transfer-Encoding: quoted-printable

Steve,

Sure, I totally agree that a SCVP server is not necessary to have
a cert. Actually, I am in favor of directly delivering the public-key of th=
e SCVP server to the RP via a secure out-of-band channel.
It is rather unfortunate that the current SCVP ID (draft 12)
seems to require a SCVP server MUST have a cert. The section
4 of the current SCVP ID says "The SCVP server MUST include its
own certificate in the certificates field within SignedData."
I believe the text should be changed.

Best Regards,
Wen-Cheng


Stephen Kent wrote:
> Wen-Cheng Wang,
> As I mentioned in one of my many messages today, there may be no need=20
> for an SCVP server to have a cert. If the server is used by only=20
> local clients, e.g., in an enterprise context, then the server's=20
> public key need not be signed by anyone. certainly, as your note, the=20
> server is an EE, not a CA, so the usual self-signed cert model may=20
> not apply.
> Steve

------=_Part_2_20313166.1062788230395--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Imwgc056847 for <[e-mail]>; Fri, 5 Sep 2003 11:48:58 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85Imwqr056846 for ietf-pkix-bks; Fri, 5 Sep 2003 11:48:58 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Imugc056836 for <[e-mail]>; Fri, 5 Sep 2003 11:48:57 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h85Imi0w024523; Fri, 5 Sep 2003 14:48:45 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210610bb7e89fe0561@[128.89.89.82]>
In-Reply-To: <24685071.1062784460179.JavaMail.root@10.1.22.7>
References: <24685071.1062784460179.JavaMail.root@10.1.22.7>
Date: Fri, 5 Sep 2003 14:46:11 -0400
To: Wen-Cheng Wang <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wen-Cheng Wang,

As I mentioned in one of my many messages today, there may be no need 
for an SCVP server to have a cert. If the server is used by only 
local clients, e.g., in an enterprise context, then the server's 
public key need not be signed by anyone. certainly, as your note, the 
server is an EE, not a CA, so the usual self-signed cert model may 
not apply.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Ii0gc056602 for <[e-mail]>; Fri, 5 Sep 2003 11:44:00 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85Ii0Gg056601 for ietf-pkix-bks; Fri, 5 Sep 2003 11:44:00 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Ihxgc056592 for <[e-mail]>; Fri, 5 Sep 2003 11:43:59 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h85Ihn0w024202; Fri, 5 Sep 2003 14:43:49 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521060fbb7e8138f6f4@[128.89.89.82]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 5 Sep 2003 14:42:14 -0400
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:57 -0700 9/4/03, Michael Myers wrote:
>  > >Steve,
>>  >
>>  >Static config is easier to attack than dynamic config.
>>  >
>>  >Mike
>>
>>  Mike,
>>
>>  I'm not sure I believe that's uniformly true, but it is an
>>  interesting perspective.
>>
>>  Moreover, an AIA extension is pretty static, in that
>>  certs typically have moderately long life spans,
>>  e.g., a year is pretty common for an EE cert,
>>  several years for a CA cert. So, can we really say
>>  whether a locally configured value for an SCVP server
>>  name is more or less static than a value extracted
>>  from a cert extension?
>>
>>  Steve
>
>Steve,
>
>In using static vs. dynamic I meant the context to be "in
>storage on the RP device".  A configuration file on a router or
>an end-user workstation would exemplify static storage.  My
>reference then to dynamic meant "in memory only", a situation
>that could reliably be assumed to exist since: 1) the SCVP
>process is inherently dynamic and online; and 2) given an AIA,
>the certificate itself bears the necessary addressing
>information.

OK, I see your definition, but I don't think the difference is that 
significant.
Let's look at the possible combinations:

	1. local name, locally-configured public key
	2. extension-derived name, locally-configured public key
	3. extension-derived name, public key acquired from the same cert?


In 1, I would expect it to be just as easy to change the name and the 
key as to change just the name, based on your concerns cited above. 
In 2, is the name more secure because it arrives in an extension for 
a cert that has not been validated by the client? Anyway, if I change 
the public key in the client because you think it is easier to do 
that to static data, then I would claim that an attacker can 
construct a cert with the name of his choice in the extension and 
have the client send it to the attacker to validate, which will work, 
because the attacker has also changed the static, public key.  Case 3 
would be an attacker's dream, i.e., send any cert with an extension 
that gives both the name and public key to use when contacting the 
server ...

>The last point is modulo of course that pesky notion you brought
>up about having to configure the trusted public key anyway. But
>then, that's just one key while the AIA values may vary against
>a locally configured SCVP server that, as we previously
>discussed, could make better and more secure use of those varied
>AIA values via relay.

This paragraph seems to be changing the context, i.e., from client 
use of the extension to local server use of the extension, passed on 
by the client. Either that or I do not understand what you are saying 
here.

>A standardized OID and syntax for SCVP AIA would I believe
>contribute useful architectural options towards the "why is PKI
>hard?" question.  It would not totally eliminate the need for
>local config, but rather complement the practice in a way that
>allows the design and evolution of a more adapative
>infrastructure.

I do not see how this helps at all, given my analysis above. If we 
don't configure the public key for the SCVP server that the client 
will use, I do not see how the client can have any confidence in the 
response, at least not in the DPV case. if we do configure that key, 
I don't see why we can't configure the name at the same time, nor do 
I see why delivering the name in an extension helps, really.

>Thus, in some future timeline where PKI is indeed ubiquitous, if
>my response to all these email-based viruses is to accept only
>signed attachments, my ISP's SCVP server need not have any
>pre-configured knowledge of the SCVP server operated by my
>correspondent's ISP.  My ISP simple needs a server, a key and a
>pointer, the latter two elements being locally configured on my
>client platform.  That server, via AIA, dynamically relays the
>request, receives the response, resigns it and there you go.  No
>messiness of local config on my ISP's part, or any ISP for that
>matter.  The infrastructure is data-driven via the cert.

In your example, your ISP wants to verify external signatures on 
e-mail. So the SMTP sever is configured with the public key and name 
for your ISP's SCVP server. That server, it seems from your text, is 
not performing validation of the certs from the other ISP. Rather it 
is asking an SCVP server operated by that ISP to tell it that the 
cert associated with that ISP is good. That seems awfully circular 
and insecure to me, so I am sure that I am missing something in your 
example. What I would have expected is that your ISP's SCVP server 
would look at the AIA extension to fetch the cert for the CA that 
issued an EE cert to the SMTP server for the other ISP, and maybe the 
CRL for that CA, and that your ISP's SCVP server would then really do 
some work to try to construct a cert path, validate CRLs, etc.  I 
don't see any magic here that makes PKI easy for the servers.  The 
idea of SCVP was to make life easy for the clients.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IXfgc056123 for <[e-mail]>; Fri, 5 Sep 2003 11:33:41 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85IXeN0056122 for ietf-pkix-bks; Fri, 5 Sep 2003 11:33:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IXdgc056115 for <[e-mail]>; Fri, 5 Sep 2003 11:33:39 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.91]) by mailout.fastq.com (8.11.6/8.11.3.FastQ-MailOut) with SMTP id h85IXRD45823; Fri, 5 Sep 2003 11:33:27 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Santosh Chokhani" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 5 Sep 2003 11:37: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)
In-Reply-To: <p05210622bb7d6eaf59cf@[128.89.89.75]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 cert extension overrides the configured name
> in the client, it would allow anyone to cause the
> client to go to the wrong server, not a good start,
> and certainly a DoS concern at a minimum.
> . . .
>
> Steve



It has been my assumption that local config, if present, SHALL
override AIA.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IUEgc055975 for <[e-mail]>; Fri, 5 Sep 2003 11:30:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85IUEZ0055974 for ietf-pkix-bks; Fri, 5 Sep 2003 11:30:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.cht.com.tw ([202.39.162.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IUCgc055967 for <[e-mail]>; Fri, 5 Sep 2003 11:30:12 -0700 (PDT) (envelope-from [e-mail])
Received: from mailgate.cht.com.tw ([10.1.22.7]) by fw.cht.com.tw (8.12.6/8.12.6) with ESMTP id h85IT4jO061471; Sat, 6 Sep 2003 02:29:04 +0800 (CST) (envelope-from [e-mail])
Received: from linux01 (webmail.cht.com.tw [10.1.22.40]) by mailgate.cht.com.tw (8.11.6/8.10.2) with ESMTP id h85IR7H12744; Sat, 6 Sep 2003 02:27:07 +0800
Message-ID: <24165820.1062785659857.JavaMail.root@10.1.22.7>
Date: Sat, 6 Sep 2003 02:14:19 +0800 (CST)
From: Wen-Cheng Wang <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: multipart/mixed;  boundary="----=_Part_177_8523428.1062785659855"
X-Mailer: WebMail/Java v0.7.10, built with JDK 1.4.1, SendMessage plugin v1.8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_Part_177_8523428.1062785659855
Content-Type: text/plain; charset="Big5"
Content-Transfer-Encoding: quoted-printable

Trevor Freeman wrote:
> Using another extesnion is a poitles distinction. The extension already
> qualifies each data item conveyed by an OID.

I believe that the section 4.2.2.1 of RFC 3280 says that the
purpose of the AIA extension is to indicate how to access
CA information or services provided by the CA (i.e., the issuer of
the certificate. If the SCVP service is not provided by the CA
itself, do you think it is appropriate to convey the SCVP URI
via the AIA extension?

Best Regards,
Wen-Cheng Wang
------=_Part_177_8523428.1062785659855--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IAYgc055151 for <[e-mail]>; Fri, 5 Sep 2003 11:10:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85IAYqF055150 for ietf-pkix-bks; Fri, 5 Sep 2003 11:10:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from fw.cht.com.tw ([202.39.162.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85IAWgc055141 for <[e-mail]>; Fri, 5 Sep 2003 11:10:32 -0700 (PDT) (envelope-from [e-mail])
Received: from mailgate.cht.com.tw ([10.1.22.7]) by fw.cht.com.tw (8.12.6/8.12.6) with ESMTP id h85I94jO054225; Sat, 6 Sep 2003 02:09:04 +0800 (CST) (envelope-from [e-mail])
Received: from linux01 (webmail.cht.com.tw [10.1.22.40]) by mailgate.cht.com.tw (8.11.6/8.10.2) with ESMTP id h85I78H07514; Sat, 6 Sep 2003 02:07:08 +0800
Message-ID: <24685071.1062784460179.JavaMail.root@10.1.22.7>
Date: Sat, 6 Sep 2003 01:54:20 +0800 (CST)
From: Wen-Cheng Wang <[e-mail]>
To: [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
Mime-Version: 1.0
Content-Type: multipart/mixed;  boundary="----=_Part_174_20392293.1062784460177"
X-Mailer: WebMail/Java v0.7.10, built with JDK 1.4.1, SendMessage plugin v1.8
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

------=_Part_174_20392293.1062784460177
Content-Type: text/plain; charset="Big5"
Content-Transfer-Encoding: quoted-printable

Liaquat Khan wrote:
> Hi,
> Just on your last point...would the RP really trust the SCVP server
> blindly as you state?? =20
> I mean the RP would validate the signature on the SCVP response, would
> it not?  So it must have the SCVP self-signed certificate in its trust
> anchor list or be able to build a path from the SCVP certificate to a
> trusted certificate. =20

Of course, the RP should validate the signature on the SCVP=20
response. The question is how the RP can 'automatically' and
'safely' obtain the public-key of the SCVP server. I mean
the RP should be able to validate the signature without any
local configuration or installation in advance. If the RP
still needs to install the public-key of the SCVP server
into its PSE anyway, why not simply let the RP bind the URI
of the SCVP server with the public-key at the time of
installing the public-key? (I believe somebody already asked
similar question before.) IMO, if the SCVP server specified
in the certificate can not be 'automatically' trusted, then
add the URI of the SCVP server into the certificate does
not seem to be very useful. My last point is that if somebody
intend to invent a way to let the RP 'automatically' trust
some SCVP server, please be sure to also let it 'safely'
rather than 'blindly' trust the SCVP server.

BTW, I do not think the SCVP server certificate is a self-signed
certificate since I believe if the SCVP server have a certificate
it should be an EE certificate. The question is who should
be the issuer of the SCVP server certificate? It is very strange
that the current SCVP draft (draft-ietf-pkix-scvp-12) does not
mention anything about the format and the handling of the SCVP
server certificate. I believe that it is very tricky for the RP
to handling the SCVP server certificate included in the SCVP
reponse.

Instead of having a SCVP server certificate, another possibility
is to let the SCVP server distribute its public-key (maybe in the
raw format of the public-key rather than in the format of public-key
certificate) via a secure out-of-band channel. However, it seems
that the current SCVP draft rules out that kind of possibility
because it requires that the SCVP response MUST include the SCVP
server certificate.

Best regards,
Wen-Cheng Wang
------=_Part_174_20392293.1062784460177--



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85I8ugc055086 for <[e-mail]>; Fri, 5 Sep 2003 11:08:56 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85I8uwP055085 for ietf-pkix-bks; Fri, 5 Sep 2003 11:08:56 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85I8sgc055076 for <[e-mail]>; Fri, 5 Sep 2003 11:08:55 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h85I8j0w021738; Fri, 5 Sep 2003 14:08:45 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521060dbb7e7da11fa6@[128.89.89.82]>
In-Reply-To: <004701c37257$b8d31bb0$b6d88351@laptoplk>
References: <004701c37257$b8d31bb0$b6d88351@laptoplk>
Date: Fri, 5 Sep 2003 14:06:42 -0400
To: "Liaquat Khan" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 21:12 +0100 9/3/03, Liaquat Khan wrote:
>So I assume from the below that we are we ruling out an equivalent of
>the "delegated" mode for SCVP? I.e. the ability for the CA to certify
>the SCVP server's public key and thereby extend trust from the CA to the
>SCVP service? 
>
>If this model was allowed then the use of the AIA extension to identify
>the SCVP service would have been even more obvious...
>
>Regards,
>LK


I have to admit that a big part of my problem with your example is 
that I hate to use the word trust when talking about CAs. So, I 
cannot personally relate to the example above. But, if I suppress my 
prejudice in this regard, I'd say the right answer is that an SCVP 
server is an entity that must be trusted by its clients, but that 
trust need not be inferred by a relationship to any CA. After all, a 
dumb client using SCVP for DPV might be configured with a name and a 
public key for a server, and thus the server need to even hold a cert 
issued by any CA.

In general I would like to see separation between the CA that issues 
a cert and the SCVP server that verifies the cert for an RP. If the 
RP happens to be a client of the CA, in an enterprise context, then 
the two probably are managed by the same folks and that fine. But in 
general a client will need to validate certs issued by a wide range 
of CAs, and one ought not think that ecah of the purported issuers of 
certs would be an acceptable DPV server.  Again, note the terrible 
security problems for the current web browser PKI model, which has a 
similar flavor.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Hs8gc054483 for <[e-mail]>; Fri, 5 Sep 2003 10:54:08 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85Hs8VT054482 for ietf-pkix-bks; Fri, 5 Sep 2003 10:54:08 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Hs7gc054471 for <[e-mail]>; Fri, 5 Sep 2003 10:54:07 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h85Hrt0w020751; Fri, 5 Sep 2003 13:53:55 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521060bbb7e78df0236@[128.89.89.82]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 5 Sep 2003 13:51:09 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 19:34 +0200 9/3/03, Peter Sylvester wrote:
>  >
>>  But, I'd like to know what use the local server would make of the
>>  pointers in one or more AIA extensions.  I've seen too many examples
>>  of "let's allow X to be put here because maybe there will be some
>>  good use for it that we will figure out later" to be comfortable
>>  going down this path without a better understanding of what purpose
>>  is served.
>
>Scenario 1:
>
>- A client asks his local server to validate a cert.
>
>- The local server has a policy/configuration indicating that
>   for the cert in question the AIA of an CA operated DPV
>   service is populated and should be contacted.

How might this be specified? certainly it would be impractical to 
specify this on a per cert basis.  do you envision specifying this on 
a per CA basis?

>- The local server does so and authenticates the response
>   in whatever way is indicated in the policy.

SCVP requires a signature on every server response, other than an 
error response. if we don't use the signature for validation, I have 
no idea what it might take to trick the server. it also was not clear 
to me that there was a policy configuration item for this, i.e., that 
one could specify non-signature means of verifying server responses 
on a per server basis. can you point me to the part of SCVP that 
indicates this?

>Now, one can ask whether the ee-cert needs an AIA. Indeed,
>it may be better to have an SIA extension in a CA cert
>saying that in order to obtain a paricular information
>containing certificates issued by this authority.
>
>A SIA in a CA cert for OCSP also makes sense to me BTW.

we should defer arguing about the choice of extension until we 
understand how the extension is used and what the the benefits and 
pitfalls.

>
>
>Scenario 2:
>
>- The same client wants a pointer to his local server;
>   this can be done in different ways; the client would
>   never use an IA in any of the certificate in the
>   chain to be validated. but would use an extension
>   in one certificate of a chain usable to authenticate
>   its local server.

I don't understand this example. are you saying that use of an 
extension to identify an SCVP server is a good means of configuring 
this info for a client? you mention a cert chain for the client 
containing this info, but the presumption for DPV is that the client 
may not be able to verify cert chains, and even for DPD that the 
client may not be prepared to fetch and revocation info for chains. 
thus any reference to a cert chain used by a client to verify the 
public key and determine the name for an SCVP server seems 
problematic, in that many of the contexts for which we cretaed SCVP 
would not be able to make use of such a chain.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85HSogc053077 for <[e-mail]>; Fri, 5 Sep 2003 10:28:50 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85HSoPV053074 for ietf-pkix-bks; Fri, 5 Sep 2003 10:28:50 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85HSmgc053063 for <[e-mail]>; Fri, 5 Sep 2003 10:28:49 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h85HSi0w019198; Fri, 5 Sep 2003 13:28:45 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210622bb7d6eaf59cf@[128.89.89.75]>
In-Reply-To: <006901c3723f$219f9b00$[e-mail]>
References: <006901c3723f$219f9b00$[e-mail]>
Date: Fri, 5 Sep 2003 13:25:30 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 13:16 -0400 9/3/03, Santosh Chokhani wrote:
>Steve:
>
>Please see responses in-line in []
>
>-----Original Message-----
>From: Stephen Kent [mailto:[e-mail]]
>Sent: Wednesday, September 03, 2003 9:33 AM
>To: Santosh Chokhani
>Cc: [e-mail]
>Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
>
>
>At 18:32 -0400 9/2/03, Santosh Chokhani wrote:
>>Steve:
>>
>>The extension could work like OCSP extension in that the local settings
>>can always override what is in the certificate.
>
>What I noted, was that IF there is no locally configured SCVP server
>info, THEN the presence of such info in an AIA extension would
>presumably be used, and that would create a configuration  management
>vulnerability.
>
>[If there is no locally configured SCVP server, would the client invoke SCVP
>services?  If so, what else does it have to rely on but the information in
>the certificate.  Seems that in that scenario you use something from the
>certificate or do something other than SCVP]

I was not as clear as I should have been. I assume that SCVP info, 
e.g., a public key and a name for an SCVP server, would be configured 
into a client that use SCVP. If the client has no public key to use 
to verify a response from an SCVP server, then how can the client use 
the service? if the intent is to provide central management for cert 
path validation, one would not want the clien to accept a name for a 
server from a random cert that happened to be presented to the 
client. Since I think the AIA extension was proposed as a means of 
conveying only the server name, I did not see that as useful. If the 
client has the server name, it didn't need to get it from a cert. If 
the cert extension overrides the configured name in the client, it 
would allow anyone to cause the client to go to the wrong server, not 
a good start, and certainly a DoS concern at a minimum.


>	<SNIP>
>
>>Now, here is a possible scenario of some utility.  Suppose you are
>>using the untrusted SCVP servers for path development only.  Suppose
>>that these servers tend to provide paths to some known trust anchors,
>>including their Enterprise roots.
>>
>>Now, in cross certified environments and in Bridge environment, this
>>partial path may be of some help.
>
>This scenario is not clear to me.  Please elaborate.
>
>[In complex trust graph, the certificate discovery problem can be broken
>down into three chunks: 1.  Finding a trust point in the subscriber domain
>-- this piece is provided by path discovery capability of a trusted or
>untrusted SCVP Server.  2.  Finding a trust point in RP domain -- this is
>straightforward most of the times (a trust list).  3.  Find how the path
>between the two trust points -- hopefully that is a direct cross
>certification, a path through a common bridge or through a series of
>bridges.  If the RP is able to find a path to a trust point in subscriber
>domain through the SCVP server, the path discovery problem is reduced:
>divide and conquer principle]

I'm puzzled by the description above. It seems to assume one model 
for path building, and that may not be the only choice. For example, 
the RP can start with its list of TAs and try to find a path to the 
target cert, period. (I don't think the term "subscriber" has been 
used here, perhaps because it's not clear to what the subscriber is 
subscribed in this case.)  if the target cert is accompanied by some 
CA certs one might choose to use them in the path building process, 
but if there is a complex graph involved, there is no reason to 
believe that the sender of these CA certs really knows what TAs the 
RP has locally configured.

Anyway, I assume that our intent with SCVP, is for the RP to ask his 
configured SCVP server to do whatever is needed to verify the cert, 
starting with path construction, constrained by the explicit or 
implicit policy parameters associated with the request. So, the 
question is whether an SCVP server pointed to by the issuer of the 
target cert, or by some CA cert in the path provided along woth the 
target cert, represents a good way to assist the SCVP server 
operating on behalf of the RP.

To me this could make sense if the server identified in the extension 
provides a DPD service, but not if it provided a DPV service. I say 
that because in the former case the server named in the cert need not 
be trusted by the server acting on behalf of the RP, whereas in the 
latter case it looks like the RP's server is abrogating its 
responsibility.

>  >I agree that for certification path validation (trusted SCVP server),
>>at a first glance, the extension does not seem to be of much use since
>>the RP clients must be configured with trusted public keys for the SCVP
>>servers anyway.  It might as well be configured with SCVP names also.
>  >But, wait, here also, if there is more than 1 SCVP server in the RP
>>configuration, then if a name matches that in a certificate, that name
>>breaks the tie.
>>
>
>This strikes me as a new twist on the processing model, and one that
>needs to be examined carefully before we decide it's a good idea.
>
>[I am all for a careful examination.  Do you see any pitfalls in it?]

See my comments above about the roles being fulfilled by the various 
servers and the corresponding concerns.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85FvJgc047121 for <[e-mail]>; Fri, 5 Sep 2003 08:57:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85FvJj7047120 for ietf-pkix-bks; Fri, 5 Sep 2003 08:57:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85FvIgc047102 for <[e-mail]>; Fri, 5 Sep 2003 08:57:18 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h85Fv20w012469; Fri, 5 Sep 2003 11:57:03 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210609bb7e614078d1@[128.89.89.82]>
In-Reply-To: <001601c37391$2ee8d990$3101a8c0@laptoplk>
References: <001601c37391$2ee8d990$3101a8c0@laptoplk>
Date: Fri, 5 Sep 2003 11:54:54 -0400
To: "Liaquat Khan" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:36 +0100 9/5/03, Liaquat Khan wrote:
>Hi,
>
>Just on your last point...would the RP really trust the SCVP server
>blindly as you state?? 
>
>I mean the RP would validate the signature on the SCVP response, would
>it not?  So it must have the SCVP self-signed certificate in its trust
>anchor list or be able to build a path from the SCVP certificate to a
>trusted certificate. 
>
>Regards,
>LK
>

Note the possibility for bad things happening based on the informal 
description above. I would like the WG to agree on how the client 
validates an SCVP response signature, in terms of where the names for 
SCVP servers and corresponding public keys come from. The suggestion 
above might be interpreted to allow any trust anchor to act as an 
SCVP server, which I think would be very dangerous, i.e., it is about 
as bad as the current browser "trust model" where any configured CA 
can vouch for anything! Until we have agreement on what the procedure 
is for identifying and verifying SCVP servers, this is a very 
dangerous, underspecified model.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85FsPgc046733 for <[e-mail]>; Fri, 5 Sep 2003 08:54:25 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85FsP24046732 for ietf-pkix-bks; Fri, 5 Sep 2003 08:54:25 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85FsOgc046715 for <[e-mail]>; Fri, 5 Sep 2003 08:54:24 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h85Frl10012274; Fri, 5 Sep 2003 11:53:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210608bb7e610069fc@[128.89.89.82]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p0521061dbb7d59a36b1e@[128.89.89.75]> <[e-mail]>
Date: Fri, 5 Sep 2003 11:49:46 -0400
To: Denis Pinkas <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:07 +0200 9/5/03, Denis Pinkas wrote:
>Steve,
>
>(...)
>
>>  I thought Denis
>was saying that IF we were to put a pointer to an SCVP service in 
>AIA, THEN it would make sense to put in a pointer to TSP, but that 
>this was not currently the case.
>
>This is not what I was saying.
>
>IF we were to put a pointer to an SCVP service, THEN it would make 
>sense to put in a pointer others added-value services like TSS 
>(Time-Stamping Service). However, these pointers should *not* be in 
>the AIA category.
>
>Denis

OK, thanks for the clarification of your position.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Fs2gc046679 for <[e-mail]>; Fri, 5 Sep 2003 08:54:02 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85Fs21R046678 for ietf-pkix-bks; Fri, 5 Sep 2003 08:54:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Fs1gc046662 for <[e-mail]>; Fri, 5 Sep 2003 08:54:01 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h85Frl0w012274; Fri, 5 Sep 2003 11:53:48 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210607bb7e60403ce0@[128.89.89.82]>
In-Reply-To: <00dd01c37376$c4c55df0$4f85900a@wcwang>
References: <002201c37326$33d25640$[e-mail]> <00dd01c37376$c4c55df0$4f85900a@wcwang>
Date: Fri, 5 Sep 2003 11:49:04 -0400
To: "Wen-Cheng Wang" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Wen-Cheng Wang,

Well said.  I am still working thorough messages from the last few 
days, but I agree with the overall theme of your message, especially 
the security issues that need to be explored in more detail,

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Exqgc038518 for <[e-mail]>; Fri, 5 Sep 2003 07:59:52 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85Exp3f038517 for ietf-pkix-bks; Fri, 5 Sep 2003 07:59:51 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85Exogc038512 for <[e-mail]>; Fri, 5 Sep 2003 07:59:50 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.91]) by mailout.fastq.com (8.11.6/8.11.3.FastQ-MailOut) with SMTP id h85ExaD35613; Fri, 5 Sep 2003 07:59:36 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Peter Sylvester" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 5 Sep 2003 08:03: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)
In-Reply-To: <p0521061dbb7d59a36b1e@[128.89.89.75]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 need to distinguish between what a client would do
> with a pointer in an extension vs. what an SCVP
> server might do, re relay. The answers may be
> different, e.g., one might make sense but the other
> may not. If so, then  we might decide to allow an
> SCVP reference in one of these extensions, BUT
> also make it clear under which of the
> two cases it is to be used.
>
> I'd like the WG to address each of these cases
> separately, explaining not syntactically or
> mechanically could be done, but why we believe
> that this is an appropriate way to use SCVP vs. other
> options, etc.
>
> Steve

Steve,

I trust my posting of yesterday regarding the "why" behind relay
is at least partially responsive to your request.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85DLJgc030993 for <[e-mail]>; Fri, 5 Sep 2003 06:21:19 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h85DLJmc030992 for ietf-pkix-bks; Fri, 5 Sep 2003 06:21:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mail2.microsoft.com (mail2.microsoft.com [131.107.3.124]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h85DLHgc030978 for <[e-mail]>; Fri, 5 Sep 2003 06:21:17 -0700 (PDT) (envelope-from [e-mail])
Received: from INET-VRS-02.redmond.corp.microsoft.com ([157.54.8.110]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.1041); Fri, 5 Sep 2003 06:21:01 -0700
Received: from 157.54.5.25 by INET-VRS-02.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Sep 2003 06:21:13 -0700
Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.0); Fri, 5 Sep 2003 06:21:46 -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(6.0.3790.0); Fri, 5 Sep 2003 06:21:09 -0700
Received: from WIN-MSG-10.wingroup.windeploy.ntdev.microsoft.com ([157.54.12.81]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.1060); Fri, 5 Sep 2003 06:21:17 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 5 Sep 2003 06:21:10 -0700
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
thread-index: AcNzl7Bp+6iFM7/XQ8a1ox3OTSXm9AAGCDKA
From: "Trevor Freeman" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Wen-Cheng Wang" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 05 Sep 2003 13:21:17.0710 (UTC) FILETIME=[96BFDAE0:01C373B0]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h85DLHgc030986
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Using another extesnion is a poitles distinction. The extension already
qualifies each data item conveyed by an OID.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Denis Pinkas
Sent: Friday, September 05, 2003 5:09 AM
To: Wen-Cheng Wang
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


Wen-Cheng,

I basically concur.

Denis

> Folks,
> 
> I suggest let's take our step back and take a look at the nature of
> public-key certificates. The main purpose of a public-key certificate
is to
> express the 'identity' of its subject. In addition to the identity of
the subject,
> it is acceptable for a CA to include some access locations for
'essential
> (or intrinsic) services' such CRL publication or certificate status
query
> service in the certificate it issued to guide or facilitate the
relyping-parties
> to determine the status of the certificate. I know that some of you
believe
> that it is good to allow a CA to advertise 'value-added services'
(meybe
> provided by the CA itself or some TTP, such as a TSA) that it think
will
> be useful to relyping-parties (certificate-using applications).
However, 
> that is not a part of the nature of public-key certificates. I believe
> the size of the certificate should be keep as small as possible since
a
> certificate is not a 'database' or a 'advertising web page' to deliver
so
> much information unrelated to the identity of the subject. Therefore,
I do not
> think it is a good idea to encourage the using of public-key
certificates
> as media for advertising those value-added services.
> 
> To those people who believe that it is good to allow a CA to advertise
'value-added services',
> 
> Well, although I am not a fan of advertising 'value-added services' in
certificates, I
> respect your standpoint. However, I do not think the AIA/SIA extension
is right place to
> deliver the access locations of  'value-added services' such as SCVP.
And I believe
> many people have the same feeling as mine. If you guys still insist
that it is good to
> advertise 'value-added services' in certificates, I suggest that you
should invent another
> exetnsion named Useful-Services Information Access (USIA) extension or
something.
> Then you are free to add into certificates any access location of
'value-added services'
> which maybe provided by the CA itself or some TTP. For example, SCVP,
DVCS,
> TSA, XKMS, Key Recovery Service, Notary Service, ... You name it.
> 
> Finally, when you guys design such kind of access location to be
advertised in
> certificates, please go deep into the security consideration. For
example, what
> if a malicious entity (a fake CA) created a fake certificate with a
malicious SCVP
> (a fake SCVP Server) access location URI in that certificate and let
the fake SCVP
> Server always tell the relyping-parties that the fake certificate is
valid and trustworthy?
> Isn't it dangerous to let the relyping-parties blindly trust the
service provider specified
> by the CA (which might be a malicious hacker) as its default service
provider?
> 
> -----
> Wen-Cheng Wang
> Project Researcher
> Telecommunication Laboratories
> Chunghwa Telecom Co., Ltd
> 
> 
> ----- Original Message ----- 
> From: "Ambarish Malpani"
> To: "'Denis Pinkas'"; "'Michael Myers'"
> Cc: "'Stephen Kent'"; <[e-mail]>
> Sent: Friday, September 05, 2003 4:50 AM
> Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> 
> 
>>
>>Hi Guys,
>>    It isn't clear to me that the AIA extension makes any sense for
>>SCVP. SCVP is a service to allow you to validate a certificate path.
>>It basically allows a client to ask somebody else whether a
certificate
>>is good for a particular use (in a large number of cases, the client
>>doesn't know the certification path for the certificate before making
>>the SCVP query, or even the public key of the CA who issued the cert).
>>
>>The AIA is a way for a CA to tell the world where it can get more
>>information for a particular cert - e.g. its status, etc.
>>
>>When a SCVP client gets a certificate issued by a particular CA, it
>>is trying to figure out whether it should trust the CA at all. Why
>>would the client want to ask a location specified in the certificate
>>when it doesn't even know if the signature on the certificate is
>>any good?
>>
>>Ambarish
>>
>>
>>>-----Original Message-----
>>>From: [e-mail] 
>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>>Sent: Thursday, September 04, 2003 11:04 AM
>>>To: Michael Myers
>>>Cc: Stephen Kent; [e-mail]
>>>Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
>>>
>>>
>>>
>>>Mike and all,
>>>
>>>I have followed that thread.
>>>
>>>"The authority information access extension indicates how to 
>>>access CA information and services for the issuer of the 
>>>certificate in which the extension appears."
>>>
>>>I wonder if the SCVP extension really belongs to the class of 
>>>"CA services 
>>>for the issuer of the certificate in which the extension appears".
>>>
>>>I would consider it as an *SCVP* extension, rather than an *AIA-SCVP*

>>>extension, since the service is not about the certificate in 
>>>which the 
>>>extension appears, but is for other certificates.
>>>
>>>I am aware of the Identrus model. If we want to support this 
>>>model, an 
>>>extension might be useful to indicate the certificate 
>>>validation server the 
>>>owner of the certificate should use to validate certificates 
>>>received from 
>>>elsewhere.
>>>
>>>Is it what everybody has in mind ? Is it something different 
>>>? If different, 
>>>please just provide one sentence to explain what it is.
>>>
>>>Thanks,
>>>
>>>Denis
>>>
>>>
>>>>>>Steve,
>>>>>>
>>>>>>Static config is easier to attack than dynamic config.
>>>>>>
>>>>>>Mike
>>>>>
>>>>>Mike,
>>>>>
>>>>>I'm not sure I believe that's uniformly true, but it is an 
>>>>
>>>interesting 
>>>
>>>>>perspective.
>>>>>
>>>>>Moreover, an AIA extension is pretty static, in that
>>>>>certs typically have moderately long life spans,
>>>>>e.g., a year is pretty common for an EE cert,
>>>>>several years for a CA cert. So, can we really say
>>>>>whether a locally configured value for an SCVP server
>>>>>name is more or less static than a value extracted
>>>>
>>>>>from a cert extension?
>>>>
>>>>>Steve
>>>>
>>>>
>>>>Steve,
>>>>
>>>>In using static vs. dynamic I meant the context to be "in 
>>>
>>>storage on 
>>>
>>>>the RP device".  A configuration file on a router or an end-user 
>>>>workstation would exemplify static storage.  My reference then to 
>>>>dynamic meant "in memory only", a situation that could reliably be 
>>>>assumed to exist since: 1) the SCVP process is inherently 
>>>
>>>dynamic and 
>>>
>>>>online; and 2) given an AIA, the certificate itself bears the 
>>>>necessary addressing information.
>>>>
>>>>The last point is modulo of course that pesky notion you brought up 
>>>>about having to configure the trusted public key anyway. But then, 
>>>>that's just one key while the AIA values may vary against a locally 
>>>>configured SCVP server that, as we previously discussed, could make 
>>>>better and more secure use of those varied AIA values via relay.
>>>>
>>>>A standardized OID and syntax for SCVP AIA would I believe 
>>>
>>>contribute 
>>>
>>>>useful architectural options towards the "why is PKI hard?" 
>>>
>>>question.  
>>>
>>>>It would not totally eliminate the need for local config, 
>>>
>>>but rather 
>>>
>>>>complement the practice in a way that allows the design and 
>>>
>>>evolution 
>>>
>>>>of a more adapative infrastructure.
>>>>
>>>>Thus, in some future timeline where PKI is indeed ubiquitous, if my 
>>>>response to all these email-based viruses is to accept only signed 
>>>>attachments, my ISP's SCVP server need not have any pre-configured 
>>>>knowledge of the SCVP server operated by my correspondent's 
>>>
>>>ISP.  My 
>>>
>>>>ISP simple needs a server, a key and a pointer, the latter two 
>>>>elements being locally configured on my client platform.  
>>>
>>>That server, 
>>>
>>>>via AIA, dynamically relays the request, receives the response, 
>>>>resigns it and there you go.  No messiness of local config 
>>>
>>>on my ISP's 
>>>
>>>>part, or any ISP for that matter.  The infrastructure is 
>>>
>>>data-driven 
>>>
>>>>via the cert.
>>>>
>>>>In summary I believe there's sufficient value to go forward with an 
>>>>AIA for SCVP.  It's not a perfect solution, but neither is total 
>>>>reliance on local config.  Together, possibly so.
>>>>
>>>>Mike
>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h859iggc008973 for <[e-mail]>; Fri, 5 Sep 2003 02:44:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h859igSX008972 for ietf-pkix-bks; Fri, 5 Sep 2003 02:44:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smarthost2.mail.uk.easynet.net (smarthost2.mail.uk.easynet.net [212.135.6.12]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h859iegc008960 for <[e-mail]>; Fri, 5 Sep 2003 02:44:40 -0700 (PDT) (envelope-from [e-mail])
Received: from [217.205.5.135] (helo=laptoplk) by smarthost2.mail.uk.easynet.net with esmtp (Exim 4.10) id 19vD8l-000Pr7-00; Fri, 05 Sep 2003 10:44:27 +0100
From: "Liaquat Khan" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Wen-Cheng Wang'" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 5 Sep 2003 10:36:28 +0100
Message-ID: <001601c37391$2ee8d990$3101a8c0@laptoplk>
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 V6.00.2800.1106
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,

Just on your last point...would the RP really trust the SCVP server
blindly as you state??  

I mean the RP would validate the signature on the SCVP response, would
it not?  So it must have the SCVP self-signed certificate in its trust
anchor list or be able to build a path from the SCVP certificate to a
trusted certificate.  

Regards,
LK

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Denis Pinkas
Sent: 05 September 2003 10:09
To: Wen-Cheng Wang
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


Wen-Cheng,

I basically concur.

Denis

> Finally, when you guys design such kind of access location to be
advertised in
> certificates, please go deep into the security consideration. For
example, what
> if a malicious entity (a fake CA) created a fake certificate with a
malicious SCVP
> (a fake SCVP Server) access location URI in that certificate and let
the fake SCVP
> Server always tell the relyping-parties that the fake certificate is
valid and trustworthy?
> Isn't it dangerous to let the relyping-parties blindly trust the
service provider specified
> by the CA (which might be a malicious hacker) as its default service
provider?
> 
> -----
> Wen-Cheng Wang
> Project Researcher
> Telecommunication Laboratories
> Chunghwa Telecom Co., Ltd
> 
> 
> ----- Original Message ----- 
> From: "Ambarish Malpani"
> To: "'Denis Pinkas'"; "'Michael Myers'"
> Cc: "'Stephen Kent'"; <[e-mail]>
> Sent: Friday, September 05, 2003 4:50 AM
> Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> 
> 
>>
>>Hi Guys,
>>    It isn't clear to me that the AIA extension makes any sense for
>>SCVP. SCVP is a service to allow you to validate a certificate path.
>>It basically allows a client to ask somebody else whether a
certificate
>>is good for a particular use (in a large number of cases, the client
>>doesn't know the certification path for the certificate before making
>>the SCVP query, or even the public key of the CA who issued the cert).
>>
>>The AIA is a way for a CA to tell the world where it can get more
>>information for a particular cert - e.g. its status, etc.
>>
>>When a SCVP client gets a certificate issued by a particular CA, it
>>is trying to figure out whether it should trust the CA at all. Why
>>would the client want to ask a location specified in the certificate
>>when it doesn't even know if the signature on the certificate is
>>any good?
>>
>>Ambarish
>>
>>
>>>-----Original Message-----
>>>From: [e-mail] 
>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>>Sent: Thursday, September 04, 2003 11:04 AM
>>>To: Michael Myers
>>>Cc: Stephen Kent; [e-mail]
>>>Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
>>>
>>>
>>>
>>>Mike and all,
>>>
>>>I have followed that thread.
>>>
>>>"The authority information access extension indicates how to 
>>>access CA information and services for the issuer of the 
>>>certificate in which the extension appears."
>>>
>>>I wonder if the SCVP extension really belongs to the class of 
>>>"CA services 
>>>for the issuer of the certificate in which the extension appears".
>>>
>>>I would consider it as an *SCVP* extension, rather than an *AIA-SCVP*

>>>extension, since the service is not about the certificate in 
>>>which the 
>>>extension appears, but is for other certificates.
>>>
>>>I am aware of the Identrus model. If we want to support this 
>>>model, an 
>>>extension might be useful to indicate the certificate 
>>>validation server the 
>>>owner of the certificate should use to validate certificates 
>>>received from 
>>>elsewhere.
>>>
>>>Is it what everybody has in mind ? Is it something different 
>>>? If different, 
>>>please just provide one sentence to explain what it is.
>>>
>>>Thanks,
>>>
>>>Denis
>>>
>>>
>>>>>>Steve,
>>>>>>
>>>>>>Static config is easier to attack than dynamic config.
>>>>>>
>>>>>>Mike
>>>>>
>>>>>Mike,
>>>>>
>>>>>I'm not sure I believe that's uniformly true, but it is an 
>>>>
>>>interesting 
>>>
>>>>>perspective.
>>>>>
>>>>>Moreover, an AIA extension is pretty static, in that
>>>>>certs typically have moderately long life spans,
>>>>>e.g., a year is pretty common for an EE cert,
>>>>>several years for a CA cert. So, can we really say
>>>>>whether a locally configured value for an SCVP server
>>>>>name is more or less static than a value extracted
>>>>
>>>>>from a cert extension?
>>>>
>>>>>Steve
>>>>
>>>>
>>>>Steve,
>>>>
>>>>In using static vs. dynamic I meant the context to be "in 
>>>
>>>storage on 
>>>
>>>>the RP device".  A configuration file on a router or an end-user 
>>>>workstation would exemplify static storage.  My reference then to 
>>>>dynamic meant "in memory only", a situation that could reliably be 
>>>>assumed to exist since: 1) the SCVP process is inherently 
>>>
>>>dynamic and 
>>>
>>>>online; and 2) given an AIA, the certificate itself bears the 
>>>>necessary addressing information.
>>>>
>>>>The last point is modulo of course that pesky notion you brought up 
>>>>about having to configure the trusted public key anyway. But then, 
>>>>that's just one key while the AIA values may vary against a locally 
>>>>configured SCVP server that, as we previously discussed, could make 
>>>>better and more secure use of those varied AIA values via relay.
>>>>
>>>>A standardized OID and syntax for SCVP AIA would I believe 
>>>
>>>contribute 
>>>
>>>>useful architectural options towards the "why is PKI hard?" 
>>>
>>>question.  
>>>
>>>>It would not totally eliminate the need for local config, 
>>>
>>>but rather 
>>>
>>>>complement the practice in a way that allows the design and 
>>>
>>>evolution 
>>>
>>>>of a more adapative infrastructure.
>>>>
>>>>Thus, in some future timeline where PKI is indeed ubiquitous, if my 
>>>>response to all these email-based viruses is to accept only signed 
>>>>attachments, my ISP's SCVP server need not have any pre-configured 
>>>>knowledge of the SCVP server operated by my correspondent's 
>>>
>>>ISP.  My 
>>>
>>>>ISP simple needs a server, a key and a pointer, the latter two 
>>>>elements being locally configured on my client platform.  
>>>
>>>That server, 
>>>
>>>>via AIA, dynamically relays the request, receives the response, 
>>>>resigns it and there you go.  No messiness of local config 
>>>
>>>on my ISP's 
>>>
>>>>part, or any ISP for that matter.  The infrastructure is 
>>>
>>>data-driven 
>>>
>>>>via the cert.
>>>>
>>>>In summary I believe there's sufficient value to go forward with an 
>>>>AIA for SCVP.  It's not a perfect solution, but neither is total 
>>>>reliance on local config.  Together, possibly so.
>>>>
>>>>Mike
>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h859Blgc006387 for <[e-mail]>; Fri, 5 Sep 2003 02:11:47 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h859BlDD006386 for ietf-pkix-bks; Fri, 5 Sep 2003 02:11:47 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h859Bjgc006380 for <[e-mail]>; Fri, 5 Sep 2003 02:11:46 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA63836; Fri, 5 Sep 2003 11:17:10 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id LAA15100; Fri, 5 Sep 2003 11:12:42 +0200
Message-ID: <[e-mail]>
Date: Fri, 05 Sep 2003 11:11:42 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
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>

Mike,

> Denis,

> Following Steve's guidance on the purpose(s) served by an SCVP
> AIA, I described a scenario based on relay.  Your response
> appears to be in that context, but it is difficult to determine
> if you agree with that analysis.  Please clarify your position.

Please, provide one sentence to explain what would be the meaning of this 
extension.

"This extension indicates ... "

Denis


> Mike
> 
> 
>>-----Original Message-----
>>From: Denis Pinkas [mailto:[e-mail]]
>>Sent: Thursday, September 04, 2003 11:04 AM
>>To: Michael Myers
>>Cc: Stephen Kent; [e-mail]
>>Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt
>>[SCVP-AIA]
>>
>>
>>Mike and all,
>>
>>I have followed that thread.
>>
>>"The authority information access extension indicates
>>how to access CA information and services for the
>>issuer of the certificate in which the extension appears."
>>
>>I wonder if the SCVP extension really belongs to the
>>class of "CA services for the issuer of the certificate
>>in which the extension appears".
>>
>>I would consider it as an *SCVP* extension, rather
>>than an *AIA-SCVP* extension, since the service is
>>not about the certificate in which the extension
>>appears, but is for other certificates.
>>
>>I am aware of the Identrus model. If we want to
>>support this model, an extension might be useful
>>to indicate the certificate validation server the
>>owner of the certificate should use to validate
>>certificates received from elsewhere.
>>
>>Is it what everybody has in mind ? Is it something
>>different ? If different, please just provide one
>>sentence to explain what it is.
>>
>>Thanks,
>>
>>Denis
> 
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8599Ggc006245 for <[e-mail]>; Fri, 5 Sep 2003 02:09:16 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8599Gc4006244 for ietf-pkix-bks; Fri, 5 Sep 2003 02:09:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8599Egc006238 for <[e-mail]>; Fri, 5 Sep 2003 02:09:15 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA19436; Fri, 5 Sep 2003 11:14:39 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id LAA15053; Fri, 5 Sep 2003 11:10:10 +0200
Message-ID: <[e-mail]>
Date: Fri, 05 Sep 2003 11:09:10 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Wen-Cheng Wang <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
References: <002201c37326$33d25640$[e-mail]> <00dd01c37376$c4c55df0$4f85900a@wcwang>
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>

Wen-Cheng,

I basically concur.

Denis

> Folks,
> 
> I suggest let's take our step back and take a look at the nature of
> public-key certificates. The main purpose of a public-key certificate is to
> express the 'identity' of its subject. In addition to the identity of the subject,
> it is acceptable for a CA to include some access locations for 'essential
> (or intrinsic) services' such CRL publication or certificate status query
> service in the certificate it issued to guide or facilitate the relyping-parties
> to determine the status of the certificate. I know that some of you believe
> that it is good to allow a CA to advertise 'value-added services' (meybe
> provided by the CA itself or some TTP, such as a TSA) that it think will
> be useful to relyping-parties (certificate-using applications). However, 
> that is not a part of the nature of public-key certificates. I believe
> the size of the certificate should be keep as small as possible since a
> certificate is not a 'database' or a 'advertising web page' to deliver so
> much information unrelated to the identity of the subject. Therefore, I do not
> think it is a good idea to encourage the using of public-key certificates
> as media for advertising those value-added services.
> 
> To those people who believe that it is good to allow a CA to advertise 'value-added services',
> 
> Well, although I am not a fan of advertising 'value-added services' in certificates, I
> respect your standpoint. However, I do not think the AIA/SIA extension is right place to
> deliver the access locations of  'value-added services' such as SCVP. And I believe
> many people have the same feeling as mine. If you guys still insist that it is good to
> advertise 'value-added services' in certificates, I suggest that you should invent another
> exetnsion named Useful-Services Information Access (USIA) extension or something.
> Then you are free to add into certificates any access location of 'value-added services'
> which maybe provided by the CA itself or some TTP. For example, SCVP, DVCS,
> TSA, XKMS, Key Recovery Service, Notary Service, ... You name it.
> 
> Finally, when you guys design such kind of access location to be advertised in
> certificates, please go deep into the security consideration. For example, what
> if a malicious entity (a fake CA) created a fake certificate with a malicious SCVP
> (a fake SCVP Server) access location URI in that certificate and let the fake SCVP
> Server always tell the relyping-parties that the fake certificate is valid and trustworthy?
> Isn't it dangerous to let the relyping-parties blindly trust the service provider specified
> by the CA (which might be a malicious hacker) as its default service provider?
> 
> -----
> Wen-Cheng Wang
> Project Researcher
> Telecommunication Laboratories
> Chunghwa Telecom Co., Ltd
> 
> 
> ----- Original Message ----- 
> From: "Ambarish Malpani"
> To: "'Denis Pinkas'"; "'Michael Myers'"
> Cc: "'Stephen Kent'"; <[e-mail]>
> Sent: Friday, September 05, 2003 4:50 AM
> Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> 
> 
>>
>>Hi Guys,
>>    It isn't clear to me that the AIA extension makes any sense for
>>SCVP. SCVP is a service to allow you to validate a certificate path.
>>It basically allows a client to ask somebody else whether a certificate
>>is good for a particular use (in a large number of cases, the client
>>doesn't know the certification path for the certificate before making
>>the SCVP query, or even the public key of the CA who issued the cert).
>>
>>The AIA is a way for a CA to tell the world where it can get more
>>information for a particular cert - e.g. its status, etc.
>>
>>When a SCVP client gets a certificate issued by a particular CA, it
>>is trying to figure out whether it should trust the CA at all. Why
>>would the client want to ask a location specified in the certificate
>>when it doesn't even know if the signature on the certificate is
>>any good?
>>
>>Ambarish
>>
>>
>>>-----Original Message-----
>>>From: [e-mail] 
>>>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>>>Sent: Thursday, September 04, 2003 11:04 AM
>>>To: Michael Myers
>>>Cc: Stephen Kent; [e-mail]
>>>Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
>>>
>>>
>>>
>>>Mike and all,
>>>
>>>I have followed that thread.
>>>
>>>"The authority information access extension indicates how to 
>>>access CA information and services for the issuer of the 
>>>certificate in which the extension appears."
>>>
>>>I wonder if the SCVP extension really belongs to the class of 
>>>"CA services 
>>>for the issuer of the certificate in which the extension appears".
>>>
>>>I would consider it as an *SCVP* extension, rather than an *AIA-SCVP* 
>>>extension, since the service is not about the certificate in 
>>>which the 
>>>extension appears, but is for other certificates.
>>>
>>>I am aware of the Identrus model. If we want to support this 
>>>model, an 
>>>extension might be useful to indicate the certificate 
>>>validation server the 
>>>owner of the certificate should use to validate certificates 
>>>received from 
>>>elsewhere.
>>>
>>>Is it what everybody has in mind ? Is it something different 
>>>? If different, 
>>>please just provide one sentence to explain what it is.
>>>
>>>Thanks,
>>>
>>>Denis
>>>
>>>
>>>>>>Steve,
>>>>>>
>>>>>>Static config is easier to attack than dynamic config.
>>>>>>
>>>>>>Mike
>>>>>
>>>>>Mike,
>>>>>
>>>>>I'm not sure I believe that's uniformly true, but it is an 
>>>>
>>>interesting 
>>>
>>>>>perspective.
>>>>>
>>>>>Moreover, an AIA extension is pretty static, in that
>>>>>certs typically have moderately long life spans,
>>>>>e.g., a year is pretty common for an EE cert,
>>>>>several years for a CA cert. So, can we really say
>>>>>whether a locally configured value for an SCVP server
>>>>>name is more or less static than a value extracted
>>>>
>>>>>from a cert extension?
>>>>
>>>>>Steve
>>>>
>>>>
>>>>Steve,
>>>>
>>>>In using static vs. dynamic I meant the context to be "in 
>>>
>>>storage on 
>>>
>>>>the RP device".  A configuration file on a router or an end-user 
>>>>workstation would exemplify static storage.  My reference then to 
>>>>dynamic meant "in memory only", a situation that could reliably be 
>>>>assumed to exist since: 1) the SCVP process is inherently 
>>>
>>>dynamic and 
>>>
>>>>online; and 2) given an AIA, the certificate itself bears the 
>>>>necessary addressing information.
>>>>
>>>>The last point is modulo of course that pesky notion you brought up 
>>>>about having to configure the trusted public key anyway. But then, 
>>>>that's just one key while the AIA values may vary against a locally 
>>>>configured SCVP server that, as we previously discussed, could make 
>>>>better and more secure use of those varied AIA values via relay.
>>>>
>>>>A standardized OID and syntax for SCVP AIA would I believe 
>>>
>>>contribute 
>>>
>>>>useful architectural options towards the "why is PKI hard?" 
>>>
>>>question.  
>>>
>>>>It would not totally eliminate the need for local config, 
>>>
>>>but rather 
>>>
>>>>complement the practice in a way that allows the design and 
>>>
>>>evolution 
>>>
>>>>of a more adapative infrastructure.
>>>>
>>>>Thus, in some future timeline where PKI is indeed ubiquitous, if my 
>>>>response to all these email-based viruses is to accept only signed 
>>>>attachments, my ISP's SCVP server need not have any pre-configured 
>>>>knowledge of the SCVP server operated by my correspondent's 
>>>
>>>ISP.  My 
>>>
>>>>ISP simple needs a server, a key and a pointer, the latter two 
>>>>elements being locally configured on my client platform.  
>>>
>>>That server, 
>>>
>>>>via AIA, dynamically relays the request, receives the response, 
>>>>resigns it and there you go.  No messiness of local config 
>>>
>>>on my ISP's 
>>>
>>>>part, or any ISP for that matter.  The infrastructure is 
>>>
>>>data-driven 
>>>
>>>>via the cert.
>>>>
>>>>In summary I believe there's sufficient value to go forward with an 
>>>>AIA for SCVP.  It's not a perfect solution, but neither is total 
>>>>reliance on local config.  Together, possibly so.
>>>>
>>>>Mike
>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8597hgc006093 for <[e-mail]>; Fri, 5 Sep 2003 02:07:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h8597h73006092 for ietf-pkix-bks; Fri, 5 Sep 2003 02:07:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h8597cgc006071 for <[e-mail]>; Fri, 5 Sep 2003 02:07:42 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA40278; Fri, 5 Sep 2003 11:13:03 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id LAA15033; Fri, 5 Sep 2003 11:08:35 +0200
Message-ID: <[e-mail]>
Date: Fri, 05 Sep 2003 11:07:34 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Stephen Kent <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
References: <[e-mail]> <p0521061dbb7d59a36b1e@[128.89.89.75]>
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>

Steve,

(...)

 > I thought Denis
> was saying that IF we were to put a pointer to an SCVP service in AIA, 
> THEN it would make sense to put in a pointer to TSP, but that this was 
> not currently the case. 

This is not what I was saying.

IF we were to put a pointer to an SCVP service, THEN it would make sense to 
put in a pointer others added-value services like TSS (Time-Stamping 
Service). However, these pointers should *not* be in the AIA category.

Denis



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h856TEgc081046 for <[e-mail]>; Thu, 4 Sep 2003 23:29:14 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h856TEFe081045 for ietf-pkix-bks; Thu, 4 Sep 2003 23:29:14 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from gate3.chttl.com.tw (gate3.chttl.com.tw [203.75.28.115]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h856T6gc081036 for <[e-mail]>; Thu, 4 Sep 2003 23:29:12 -0700 (PDT) (envelope-from [e-mail])
Received: from ms7.chttl.com.tw (ms7 [10.144.2.117]) by gate3.chttl.com.tw (8.12.9/8.12.9) with ESMTP id h856SO5Y028884; Fri, 5 Sep 2003 14:28:24 +0800
Received: (from root@localhost) by ms7.chttl.com.tw (8.12.3/8.12.1) id h856SNVJ027372; Fri, 5 Sep 2003 14:28:23 +0800
Received: from wcwang ([10.144.133.79]) by ms7.chttl.com.tw (8.12.3/8.12.1) with SMTP id h856SGB6027087; Fri, 5 Sep 2003 14:28:23 +0800
Message-ID: <00dd01c37376$c4c55df0$4f85900a@wcwang>
From: "Wen-Cheng Wang" <[e-mail]>
To: <[e-mail]>
Cc: "'Stephen Kent'" <[e-mail]>, "Ambarish Malpani" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'Michael Myers'" <[e-mail]>
References: <002201c37326$33d25640$[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 5 Sep 2003 14:27:17 +0800
MIME-Version: 1.0
X-scanner: scanned by Inflex 1.0.10 - (http://pldaniels.com/inflex/)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: 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 suggest let's take our step back and take a look at the nature of
public-key certificates. The main purpose of a public-key certificate is to
express the 'identity' of its subject. In addition to the identity of the subject,
it is acceptable for a CA to include some access locations for 'essential
(or intrinsic) services' such CRL publication or certificate status query
service in the certificate it issued to guide or facilitate the relyping-parties
to determine the status of the certificate. I know that some of you believe
that it is good to allow a CA to advertise 'value-added services' (meybe
provided by the CA itself or some TTP, such as a TSA) that it think will
be useful to relyping-parties (certificate-using applications). However, 
that is not a part of the nature of public-key certificates. I believe
the size of the certificate should be keep as small as possible since a
certificate is not a 'database' or a 'advertising web page' to deliver so
much information unrelated to the identity of the subject. Therefore, I do not
think it is a good idea to encourage the using of public-key certificates
as media for advertising those value-added services.

To those people who believe that it is good to allow a CA to advertise 'value-added services',

Well, although I am not a fan of advertising 'value-added services' in certificates, I
respect your standpoint. However, I do not think the AIA/SIA extension is right place to
deliver the access locations of  'value-added services' such as SCVP. And I believe
many people have the same feeling as mine. If you guys still insist that it is good to
advertise 'value-added services' in certificates, I suggest that you should invent another
exetnsion named Useful-Services Information Access (USIA) extension or something.
Then you are free to add into certificates any access location of 'value-added services'
which maybe provided by the CA itself or some TTP. For example, SCVP, DVCS,
TSA, XKMS, Key Recovery Service, Notary Service, ... You name it.

Finally, when you guys design such kind of access location to be advertised in
certificates, please go deep into the security consideration. For example, what
if a malicious entity (a fake CA) created a fake certificate with a malicious SCVP
(a fake SCVP Server) access location URI in that certificate and let the fake SCVP
Server always tell the relyping-parties that the fake certificate is valid and trustworthy?
Isn't it dangerous to let the relyping-parties blindly trust the service provider specified
by the CA (which might be a malicious hacker) as its default service provider?

-----
Wen-Cheng Wang
Project Researcher
Telecommunication Laboratories
Chunghwa Telecom Co., Ltd


----- Original Message ----- 
From: "Ambarish Malpani"
To: "'Denis Pinkas'"; "'Michael Myers'"
Cc: "'Stephen Kent'"; <[e-mail]>
Sent: Friday, September 05, 2003 4:50 AM
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


> 
> 
> Hi Guys,
>     It isn't clear to me that the AIA extension makes any sense for
> SCVP. SCVP is a service to allow you to validate a certificate path.
> It basically allows a client to ask somebody else whether a certificate
> is good for a particular use (in a large number of cases, the client
> doesn't know the certification path for the certificate before making
> the SCVP query, or even the public key of the CA who issued the cert).
> 
> The AIA is a way for a CA to tell the world where it can get more
> information for a particular cert - e.g. its status, etc.
> 
> When a SCVP client gets a certificate issued by a particular CA, it
> is trying to figure out whether it should trust the CA at all. Why
> would the client want to ask a location specified in the certificate
> when it doesn't even know if the signature on the certificate is
> any good?
> 
> Ambarish
> 
> > -----Original Message-----
> > From: [e-mail] 
> > [mailto:[e-mail]] On Behalf Of Denis Pinkas
> > Sent: Thursday, September 04, 2003 11:04 AM
> > To: Michael Myers
> > Cc: Stephen Kent; [e-mail]
> > Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> > 
> > 
> > 
> > Mike and all,
> > 
> > I have followed that thread.
> > 
> > "The authority information access extension indicates how to 
> > access CA information and services for the issuer of the 
> > certificate in which the extension appears."
> > 
> > I wonder if the SCVP extension really belongs to the class of 
> > "CA services 
> > for the issuer of the certificate in which the extension appears".
> > 
> > I would consider it as an *SCVP* extension, rather than an *AIA-SCVP* 
> > extension, since the service is not about the certificate in 
> > which the 
> > extension appears, but is for other certificates.
> > 
> > I am aware of the Identrus model. If we want to support this 
> > model, an 
> > extension might be useful to indicate the certificate 
> > validation server the 
> > owner of the certificate should use to validate certificates 
> > received from 
> > elsewhere.
> > 
> > Is it what everybody has in mind ? Is it something different 
> > ? If different, 
> > please just provide one sentence to explain what it is.
> > 
> > Thanks,
> > 
> > Denis
> > 
> > >>>Steve,
> > >>>
> > >>>Static config is easier to attack than dynamic config.
> > >>>
> > >>>Mike
> > >>
> > >>Mike,
> > >>
> > >>I'm not sure I believe that's uniformly true, but it is an 
> > interesting 
> > >>perspective.
> > >>
> > >>Moreover, an AIA extension is pretty static, in that
> > >>certs typically have moderately long life spans,
> > >>e.g., a year is pretty common for an EE cert,
> > >>several years for a CA cert. So, can we really say
> > >>whether a locally configured value for an SCVP server
> > >>name is more or less static than a value extracted
> > >>from a cert extension?
> > >>
> > >>Steve
> > > 
> > > 
> > > Steve,
> > > 
> > > In using static vs. dynamic I meant the context to be "in 
> > storage on 
> > > the RP device".  A configuration file on a router or an end-user 
> > > workstation would exemplify static storage.  My reference then to 
> > > dynamic meant "in memory only", a situation that could reliably be 
> > > assumed to exist since: 1) the SCVP process is inherently 
> > dynamic and 
> > > online; and 2) given an AIA, the certificate itself bears the 
> > > necessary addressing information.
> > > 
> > > The last point is modulo of course that pesky notion you brought up 
> > > about having to configure the trusted public key anyway. But then, 
> > > that's just one key while the AIA values may vary against a locally 
> > > configured SCVP server that, as we previously discussed, could make 
> > > better and more secure use of those varied AIA values via relay.
> > > 
> > > A standardized OID and syntax for SCVP AIA would I believe 
> > contribute 
> > > useful architectural options towards the "why is PKI hard?" 
> > question.  
> > > It would not totally eliminate the need for local config, 
> > but rather 
> > > complement the practice in a way that allows the design and 
> > evolution 
> > > of a more adapative infrastructure.
> > > 
> > > Thus, in some future timeline where PKI is indeed ubiquitous, if my 
> > > response to all these email-based viruses is to accept only signed 
> > > attachments, my ISP's SCVP server need not have any pre-configured 
> > > knowledge of the SCVP server operated by my correspondent's 
> > ISP.  My 
> > > ISP simple needs a server, a key and a pointer, the latter two 
> > > elements being locally configured on my client platform.  
> > That server, 
> > > via AIA, dynamically relays the request, receives the response, 
> > > resigns it and there you go.  No messiness of local config 
> > on my ISP's 
> > > part, or any ISP for that matter.  The infrastructure is 
> > data-driven 
> > > via the cert.
> > > 
> > > In summary I believe there's sufficient value to go forward with an 
> > > AIA for SCVP.  It's not a perfect solution, but neither is total 
> > > reliance on local config.  Together, possibly so.
> > > 
> > > Mike
> > > 
> > > 
> > > 
> > 
> > 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84NxQgc061169 for <[e-mail]>; Thu, 4 Sep 2003 16:59:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84NxQkl061168 for ietf-pkix-bks; Thu, 4 Sep 2003 16:59:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from visa.com (portal3.visa.com [198.80.42.3]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84NxPgc061159 for <[e-mail]>; Thu, 4 Sep 2003 16:59:26 -0700 (PDT) (envelope-from [e-mail])
Received: from ([10.72.11.168]) by portal3.visa.com with ESMTP ; Thu, 04 Sep 2003 16:57:45 -0700 (PDT)
Received: by sw720x001.visa.com with Internet Mail Service (5.5.2653.19) id <RH53MQJ9>; Thu, 4 Sep 2003 16:57:57 -0700
Message-ID: <[e-mail]>
From: "Terwilliger, Ann" <[e-mail]>
To: "'Michael Myers'" <[e-mail]>, Stephen Kent <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Thu, 4 Sep 2003 16:57:56 -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>

Actually, there is a good description of the four corner model in the Certification Authority Rating and Assessment Task Force (CARAT) Guidlines published by the NACHA Internet Council (final version published in 2000).  It's now an old document but still worthwhile reading.  

-----Original Message-----
From: Michael Myers [mailto:[e-mail]]
Sent: Wednesday, September 03, 2003 8:15 AM
To: Stephen Kent
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]




> BTW, what is the origin of the phrase "four corner
> model" that has cropped up here?
>
> Steve


Steve,

The "four-corner model" derives from the picture that Mack Hicks
and others always drew to explain how Identrus would work
vis-a-vis trust and especially how OCSP relay fit into their
bank-to-bank risk management scheme.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MbTgc056235 for <[e-mail]>; Thu, 4 Sep 2003 15:37:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84MbTG4056234 for ietf-pkix-bks; Thu, 4 Sep 2003 15:37:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84MbSgc056227 for <[e-mail]>; Thu, 4 Sep 2003 15:37:28 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h84MbD0w003308; Thu, 4 Sep 2003 18:37:13 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521061dbb7d59a36b1e@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Thu, 4 Sep 2003 18:35:18 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 17:11 +0200 9/3/03, Peter Sylvester wrote:
>  >
>>  One motivation for DPV is to allow clients to receive a public key
>>  and to use it, because the server said it was OK to use relative to
>>  the policy indicated by the client in the query. The notion is that a
>>  client need not be able to parse certs and CRLs in this case, but
>>  rather can just pass an opaque blob of bits to the server and use a
>>  configured policy reference, specific to the local use context, and
>>  be told the answer.  Obviously this would not be true in the DPD
>>  case, but it is reasonable for DPV.
>
>Can you point me to the text in 3379.
>
>As far as I can see, the text does not talk about public key
>retrieval, but about certificate validation.

Whoops, you're right! During the debates on DPV I recall that we 
wanted to support clients who might not even be able to parse certs, 
but this did not become part of the requirements doc.

>Nowhere in the text there is a requirement that the protocol
>MUST provide a means that a client can treat a cert as a blob.

yes, consistent with my comment above, I was in error in saying that 
this was part of the requirements spec.

>  The text says that one of the unambigouous references
>may for example be  "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]."
>
>" The DPV server MUST
>    include either the certificate or an unambiguous reference to the
>    certificate (in case of a CA key compromise) in the DPV response."
>
>except for a hash, the other references require interpretation of
>the cert.

right again. the client does need to be able to parse a cert to 
extract a public key, although the client need not be able to perform 
cert path processing, at least not for DPV.

<SNIP>

>  > Yes, a CA could operate an SCVP service for its local clients, but
>  > such operation is not intrinsic to the general model. I have yet to
>>  see a good explanation of the benefits that accrue from putting the
>>  name of an SCVP server into an extension, if we agree that the public
>>  key for that server needs to be configured in the client anyway.
>>  Moreover, the suggestion of putting this info into the AIA extension
>>  seems to be an afterthought, especially when viewed relative to 3379.
>
>The usage of AIA or SIA to point to services is a common feature that
>has been used in various PKIX protocols, OCSP, TSP, DVCS for example as
>a general mechanism to convey a contact address in a certificate.

I didn't think we had specs that called for AIA/SIA to be used for 
any service other than OCSP, among the services you listed. I thought 
Denis was saying that IF we were to put a pointer to an SCVP service 
in AIA, THHEN it would make sense to put in a pointer to TSP, but 
that this was not currently the case. 3280 defines support only for 
OCSP here. 3161 makes no reference to AIA, so I'm not sure why you 
say that AIA could point to a TSA. Only your informational DVCS RFC 
makes reference to AIA (something I admit that I didn't notice).

>This does seem an afterthought to me but rather a well accepted feature
>since years which doesn't seem to need a particular requirement.

Well, we agree on the afterthought part :-), but probably not the 
"well accepted feature" part. Before the WG says that putting a 
pointer in AIA or SIA makes sense for SCVP, we need to agree on the 
requirements.

>A simple way to configure a public key is a certificate. You can have
>like in TSP a SIA with your local server, and your local server acting
>as a proxy can contact a CA's server using an AIA in the cert to be
>validated.

Sorry, but you lost me here, i.e., not enough context near your 
answer for me to remember what the question was. But, I'll take a 
stab anyway.

We need to distinguish between what a client would do with a pointer 
in an extension vs. what an SCVP server might do, re relay. The 
answers may be different, e.g., one might make sense but the other 
may not. If so, then  we might decide to allow an SCVP reference in 
one of these extensions, BUT also make it clear under which of the 
two cases it is to be used.

I'd like te WG to address each of these cases separately, explaining 
not syntactically or mechanically could be done, but why we believe 
that this is an appropriate way to use SCVP vs. other options, etc.


<SNIP>

(let's not mix discussion of changes to OCSP semantics with SCVP, 
since we have enough to discuss already)

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Kpmgc046273 for <[e-mail]>; Thu, 4 Sep 2003 13:51:48 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84KpmUQ046272 for ietf-pkix-bks; Thu, 4 Sep 2003 13:51:48 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from ns.malpani.biz (adsl-63-194-89-166.dsl.snfc21.pacbell.net [63.194.89.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84Kplgc046263 for <[e-mail]>; Thu, 4 Sep 2003 13:51:47 -0700 (PDT) (envelope-from [e-mail])
Received: from AMBARISHW2K (ns.malpani.biz [192.168.25.5]) by ns.malpani.biz (8.12.9/8.12.9) with ESMTP id h84KobPo023704; Thu, 4 Sep 2003 13:50:38 -0700
From: "Ambarish Malpani" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, "'Michael Myers'" <[e-mail]>
Cc: "'Stephen Kent'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Thu, 4 Sep 2003 13:50:36 -0700
Message-ID: <002201c37326$33d25640$[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, Build 10.0.4510
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
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 Guys,
    It isn't clear to me that the AIA extension makes any sense for
SCVP. SCVP is a service to allow you to validate a certificate path.
It basically allows a client to ask somebody else whether a certificate
is good for a particular use (in a large number of cases, the client
doesn't know the certification path for the certificate before making
the SCVP query, or even the public key of the CA who issued the cert).

The AIA is a way for a CA to tell the world where it can get more
information for a particular cert - e.g. its status, etc.

When a SCVP client gets a certificate issued by a particular CA, it
is trying to figure out whether it should trust the CA at all. Why
would the client want to ask a location specified in the certificate
when it doesn't even know if the signature on the certificate is
any good?

Ambarish

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Denis Pinkas
> Sent: Thursday, September 04, 2003 11:04 AM
> To: Michael Myers
> Cc: Stephen Kent; [e-mail]
> Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> 
> 
> Mike and all,
> 
> I have followed that thread.
> 
> "The authority information access extension indicates how to 
> access CA information and services for the issuer of the 
> certificate in which the extension appears."
> 
> I wonder if the SCVP extension really belongs to the class of 
> "CA services 
> for the issuer of the certificate in which the extension appears".
> 
> I would consider it as an *SCVP* extension, rather than an *AIA-SCVP* 
> extension, since the service is not about the certificate in 
> which the 
> extension appears, but is for other certificates.
> 
> I am aware of the Identrus model. If we want to support this 
> model, an 
> extension might be useful to indicate the certificate 
> validation server the 
> owner of the certificate should use to validate certificates 
> received from 
> elsewhere.
> 
> Is it what everybody has in mind ? Is it something different 
> ? If different, 
> please just provide one sentence to explain what it is.
> 
> Thanks,
> 
> Denis
> 
> >>>Steve,
> >>>
> >>>Static config is easier to attack than dynamic config.
> >>>
> >>>Mike
> >>
> >>Mike,
> >>
> >>I'm not sure I believe that's uniformly true, but it is an 
> interesting 
> >>perspective.
> >>
> >>Moreover, an AIA extension is pretty static, in that
> >>certs typically have moderately long life spans,
> >>e.g., a year is pretty common for an EE cert,
> >>several years for a CA cert. So, can we really say
> >>whether a locally configured value for an SCVP server
> >>name is more or less static than a value extracted
> >>from a cert extension?
> >>
> >>Steve
> > 
> > 
> > Steve,
> > 
> > In using static vs. dynamic I meant the context to be "in 
> storage on 
> > the RP device".  A configuration file on a router or an end-user 
> > workstation would exemplify static storage.  My reference then to 
> > dynamic meant "in memory only", a situation that could reliably be 
> > assumed to exist since: 1) the SCVP process is inherently 
> dynamic and 
> > online; and 2) given an AIA, the certificate itself bears the 
> > necessary addressing information.
> > 
> > The last point is modulo of course that pesky notion you brought up 
> > about having to configure the trusted public key anyway. But then, 
> > that's just one key while the AIA values may vary against a locally 
> > configured SCVP server that, as we previously discussed, could make 
> > better and more secure use of those varied AIA values via relay.
> > 
> > A standardized OID and syntax for SCVP AIA would I believe 
> contribute 
> > useful architectural options towards the "why is PKI hard?" 
> question.  
> > It would not totally eliminate the need for local config, 
> but rather 
> > complement the practice in a way that allows the design and 
> evolution 
> > of a more adapative infrastructure.
> > 
> > Thus, in some future timeline where PKI is indeed ubiquitous, if my 
> > response to all these email-based viruses is to accept only signed 
> > attachments, my ISP's SCVP server need not have any pre-configured 
> > knowledge of the SCVP server operated by my correspondent's 
> ISP.  My 
> > ISP simple needs a server, a key and a pointer, the latter two 
> > elements being locally configured on my client platform.  
> That server, 
> > via AIA, dynamically relays the request, receives the response, 
> > resigns it and there you go.  No messiness of local config 
> on my ISP's 
> > part, or any ISP for that matter.  The infrastructure is 
> data-driven 
> > via the cert.
> > 
> > In summary I believe there's sufficient value to go forward with an 
> > AIA for SCVP.  It's not a perfect solution, but neither is total 
> > reliance on local config.  Together, possibly so.
> > 
> > Mike
> > 
> > 
> > 
> 
> 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JYrgc041316 for <[e-mail]>; Thu, 4 Sep 2003 12:34:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84JYrFw041314 for ietf-pkix-bks; Thu, 4 Sep 2003 12:34:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84JYqgc041307 for <[e-mail]>; Thu, 4 Sep 2003 12:34:52 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.91]) by mailout.fastq.com (8.11.6/8.11.3.FastQ-MailOut) with SMTP id h84JYjD02153; Thu, 4 Sep 2003 12:34:45 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Thu, 4 Sep 2003 12:38:48 -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 V6.00.2800.1106
Sender: [e-mail]
Precedence: 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,

Following Steve's guidance on the purpose(s) served by an SCVP
AIA, I described a scenario based on relay.  Your response
appears to be in that context, but it is difficult to determine
if you agree with that analysis.  Please clarify your position.

Mike

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, September 04, 2003 11:04 AM
> To: Michael Myers
> Cc: Stephen Kent; [e-mail]
> Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt
> [SCVP-AIA]
>
>
> Mike and all,
>
> I have followed that thread.
>
> "The authority information access extension indicates
> how to access CA information and services for the
> issuer of the certificate in which the extension appears."
>
> I wonder if the SCVP extension really belongs to the
> class of "CA services for the issuer of the certificate
> in which the extension appears".
>
> I would consider it as an *SCVP* extension, rather
> than an *AIA-SCVP* extension, since the service is
> not about the certificate in which the extension
> appears, but is for other certificates.
>
> I am aware of the Identrus model. If we want to
> support this model, an extension might be useful
> to indicate the certificate validation server the
> owner of the certificate should use to validate
> certificates received from elsewhere.
>
> Is it what everybody has in mind ? Is it something
> different ? If different, please just provide one
> sentence to explain what it is.
>
> Thanks,
>
> Denis




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84I4Sgc032433 for <[e-mail]>; Thu, 4 Sep 2003 11:04:28 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84I4SKw032432 for ietf-pkix-bks; Thu, 4 Sep 2003 11:04:28 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84I4Qgc032422 for <[e-mail]>; Thu, 4 Sep 2003 11:04:27 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id UAA16002; Thu, 4 Sep 2003 20:09:52 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id UAA01340; Thu, 4 Sep 2003 20:05:20 +0200
Message-ID: <[e-mail]>
Date: Thu, 04 Sep 2003 20:04:21 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Michael Myers <[e-mail]>
CC: Stephen Kent <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
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>

Mike and all,

I have followed that thread.

"The authority information access extension indicates how to access CA
information and services for the issuer of the certificate in which
the extension appears."

I wonder if the SCVP extension really belongs to the class of "CA services 
for the issuer of the certificate in which the extension appears".

I would consider it as an *SCVP* extension, rather than an *AIA-SCVP* 
extension, since the service is not about the certificate in which the 
extension appears, but is for other certificates.

I am aware of the Identrus model. If we want to support this model, an 
extension might be useful to indicate the certificate validation server the 
owner of the certificate should use to validate certificates received from 
elsewhere.

Is it what everybody has in mind ? Is it something different ? If different, 
please just provide one sentence to explain what it is.

Thanks,

Denis

>>>Steve,
>>>
>>>Static config is easier to attack than dynamic config.
>>>
>>>Mike
>>
>>Mike,
>>
>>I'm not sure I believe that's uniformly true, but it is an
>>interesting perspective.
>>
>>Moreover, an AIA extension is pretty static, in that
>>certs typically have moderately long life spans,
>>e.g., a year is pretty common for an EE cert,
>>several years for a CA cert. So, can we really say
>>whether a locally configured value for an SCVP server
>>name is more or less static than a value extracted
>>from a cert extension?
>>
>>Steve
> 
> 
> Steve,
> 
> In using static vs. dynamic I meant the context to be "in
> storage on the RP device".  A configuration file on a router or
> an end-user workstation would exemplify static storage.  My
> reference then to dynamic meant "in memory only", a situation
> that could reliably be assumed to exist since: 1) the SCVP
> process is inherently dynamic and online; and 2) given an AIA,
> the certificate itself bears the necessary addressing
> information.
> 
> The last point is modulo of course that pesky notion you brought
> up about having to configure the trusted public key anyway. But
> then, that's just one key while the AIA values may vary against
> a locally configured SCVP server that, as we previously
> discussed, could make better and more secure use of those varied
> AIA values via relay.
> 
> A standardized OID and syntax for SCVP AIA would I believe
> contribute useful architectural options towards the "why is PKI
> hard?" question.  It would not totally eliminate the need for
> local config, but rather complement the practice in a way that
> allows the design and evolution of a more adapative
> infrastructure.
> 
> Thus, in some future timeline where PKI is indeed ubiquitous, if
> my response to all these email-based viruses is to accept only
> signed attachments, my ISP's SCVP server need not have any
> pre-configured knowledge of the SCVP server operated by my
> correspondent's ISP.  My ISP simple needs a server, a key and a
> pointer, the latter two elements being locally configured on my
> client platform.  That server, via AIA, dynamically relays the
> request, receives the response, resigns it and there you go.  No
> messiness of local config on my ISP's part, or any ISP for that
> matter.  The infrastructure is data-driven via the cert.
> 
> In summary I believe there's sufficient value to go forward with
> an AIA for SCVP.  It's not a perfect solution, but neither is
> total reliance on local config.  Together, possibly so.
> 
> Mike
> 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HMLgc030090 for <[e-mail]>; Thu, 4 Sep 2003 10:22:21 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84HMLoX030089 for ietf-pkix-bks; Thu, 4 Sep 2003 10:22:21 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84HMJgc030084 for <[e-mail]>; Thu, 4 Sep 2003 10:22:20 -0700 (PDT) (envelope-from [e-mail])
Received: from wmcooper (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h84HMIiW009840; Thu, 4 Sep 2003 13:22:18 -0400
From: "Matt Cooper" <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>
Cc: "'PKIX List'" <[e-mail]>
Subject: RE: draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 4 Sep 2003 13:22:13 -0400
Message-ID: <001a01c37309$17abf0b0$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Importance: Normal
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h84HMKgc030085
Sender: [e-mail]
Precedence: 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,

We have decided to keep basic information on retrieval in the draft. We look
forward to any additional commentary you may have when we submit the next
version.

-Matt

> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Wednesday, August 27, 2003 9:34 AM
> To: Matt Cooper
> Cc: 'PKIX List'
> Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
> 
> 
> Matt,
> 
> > Hi Denis,
> 
> > First, apologies for taking so long to get you a reply.
> > 
> > You're right, the topic of retrieval (where to find certificates, 
> > discussions of various sources, how to obtain revocation 
> information, 
> > and what CAs should put in certs to facilitate all of this) 
> is a very 
> > important topic that is intimately related to path 
> building. However, 
> > I think that they are separable topics.
> 
> I do not think so.
> 
> The story starts with a target certificate and a candidate 
> trust point. The question is then using information that may 
> be found both in the 
> certificate and in the trust point, how can we find CA 
> certificates and 
> certificate revocation information related to a candidate 
> path bewteen the 
> target certificate and the candidate trust point.
> 
> The "navigation" is subject to which CA certificates can be obtained.
> 
>  > Our document shies away from retrieval topics and
> > focuses on ideas for how to go about navigating the 
> decision tree once 
> > you have the certificates. (Perhaps we have put the cart before 
> > horse!?)
> 
> Yes, indeed. :-)
> 
>  > On the
> > other hand, we didn't feel that we could address the topic 
> of building 
> > without some limited discussion on retrieval. (Hence the 
> rather short 
> > sections you referred to.)
> 
> > I agree with you 110% that additional guidance for both PKI 
> consumers 
> > and CAs in this area would be very helpful. BUT, in the interest of 
> > keeping the document from growing out of control, I submit that 
> > retrieval would be an ideal topic for a new document.
> 
> Certificate retrieval cannot be fully separated from path 
> construction.
> 
>  > (In fact, this idea was brought up at the
> > meeting in Vienna.) Items A-C in your message would be 
> ideal content 
> > for such a document. What do you (and others) think of this idea?
> 
> I could suggest deletions in your document, but it appears 
> that you think 
> that nothing should be suppressed. :-)
> 
> In fact, a restructuring of the document would be necessary 
> to mix for each 
> step the story of path building and of CA certificate fetching.
> 
> Denis
> 
> >>From: Denis Pinkas
> >>1. The difference between a CA-certificate and a 
> cross-certificate is
> >>still very hazy since what means a "realm" is either left 
> undefined or 
> >>is said to be "dependant upon local policy". It is thus 
> impossible to 
> >>have standard rules with such an approach.
> > 
> > 
> > I assume you referring to the sorting method that suggests you 
> > traverse certs from cACertificate prior to 
> crossCertificatePair? This 
> > is based solely on what we've seen in the field as common practice. 
> > So, although realm is a fuzzy notion, more often than not 
> (from what 
> > I've seen at least) it seems that if both cACertificate and 
> > crossCertificatePair are populated, that cACertificate is 
> the "local 
> > realm" and usually confines searches to the local network. 
> But, like 
> > all the other sorting methods, it won't work all the time for every 
> > scenario. I personally like this sorting method, but there 
> are other 
> > dissenters. I certainly wouldn't oppose removal if that seems to be 
> > the consensus or the group feels it won't contribute to 
> optimizing the 
> > path building.
> > 
> > 
> >>From: Denis Pinkas
> >>Is it really important to make the difference if both:
> >>
> >>  - the pointers to CA repositories are present, and
> >>  - these repositories entries are correctly filled-in ?
> > 
> > 
> > I think so. Retrieving the certs is only half the problem - these 
> > pointers help you find certs, but they don't necessarily help you 
> > decide what to do with them once you have them. If we can use some 
> > information to guess at whether the CA is local to the PKI consumer 
> > vs. remote, we can use this to try to consume paths from the local 
> > (and presumably faster) network first. Were you looking for a 
> > statement that says use of these sources should over-ride other 
> > available sources?
> > 
> > 
> >>From: Denis Pinkas
> >>Figure 3 does not make sense unless the trust points
> >>are indicated.
> > 
> > 
> > Is it necessary for the diagram to indicate which CA (if 
> any of them) 
> > is the trust point? On the other hand, to make it 
> consistent with the 
> > other examples, I agree there should be one designated. The other 
> > thing I don't like about this diagram is that it needs to be 4 or 5 
> > CAs instead of three - 3 CAs looks just like a ring 
> topology. I  will 
> > change this in the next version.
> > 
> > 
> >>From: Denis Pinkas
> >>3. The case of validating a certificate in the past after a CA key
> >>rollover (using the new root key) should be addressed.
> > 
> > 
> > Do you mean validating an old certificate at some past T where T 
> > precedes the notBefore in the cert issued from the new CA 
> key to the 
> > old CA key? I don't think this should validate. Then on the 
> other side 
> > of the notBefore, no additional discussion should be 
> necessary, or am 
> > I missing what you are telling me? I think the current 
> sorting methods 
> > will handle key-rollover for a T post the notBefore time without a 
> > problem.
> > 
> > 
> >>From: Denis Pinkas
> >>4. An interesting case to discuss would be the encoding of 
> the issuer
> >>name before and after December 31, 2003 since all 
> certificates issued 
> >>after December 31, 2003 MUST use the UTF8String encoding of 
> >>DirectoryString (except as noted). The case of "name rollover" 
> >>certificates to support an orderly migration to UTF8String encoding 
> >>should be explained.
> > 
> > 
> > Excellent idea and thanks for pointing it out. Although, I think we 
> > should not use  MUST here since this is informational only.
> > 
> > 
> >>From: Denis Pinkas
> >>5. The document is far too long.
> > 
> > 
> > Denis, you told me this immediately following a bunch of 
> suggestions 
> > on how to make it longer! To tell you the truth, I agree, 
> it is rather 
> > lengthy. On the other hand, I would be reticent to remove 
> any of the 
> > sorting discussion. And, I think absent a retrieval doc, 
> there needs 
> > to be at least some limited discussion of retrieval. I'm 
> not certain 
> > how to shorten it without removing something that others 
> may well find 
> > to be of value. Perhaps the sorting methods could be moved to an 
> > appendix?
> > 
> > -Matt
> > 
> > 
> >>-----Original Message-----
> >>From: Denis Pinkas [mailto:[e-mail]]
> >>Sent: Tuesday, July 15, 2003 5:23 AM
> >>To: Peter Hesse; 'Matt Cooper'; 'Yuriy Dzambasow'; 'Susan 
> >>Joseph'; Richard E. Nicholas (Nicholas, Richard)
> >>Cc: Steve Hanna; 'PKIX List'
> >>Subject: Re: draft-ietf-pkix-certpathbuild-00.txt
> >>
> >>
> >>Comments on certpathbuild-00.txt
> >>
> >>The title of the document was promising, but the content is
> >>not exactly what 
> >>would have been expected.
> >>
> >>The topic should be how to allow interoperability to find out
> >>the elements 
> >>(i.e. both the certificates and the associated revocation status 
> >>information) needed for to build a certification path 
> either walking 
> >>downwards or upwards the certification tree.
> >>
> >>The document should explain how inserting some of the
> >>extensions defined in 
> >>RFC 3280 will allow to build the certification path, 
> >>irrespective of local 
> >>conditions (e.g. the user does not have a XX-xxxxxxDirectory where 
> >>everything needed is stored. :-)  )
> >>
> >>Some interesting elements are provided starting page 54, in
> >>sections 6.2 and 
> >>6.3. but this is far from sufficient.
> >>
> >>There are two solutions to this problem, either walking
> >>downwards or upwards 
> >>the certification tree.
> >>
> >>
> >>A. Walking downwards the certification tree.
> >>
> >>Each trust point SHOULD include in the self-signed
> >>certificate the way to 
> >>find out where the CA has placed the CA certificates that it 
> >>issues. This 
> >>SHALL be done using the Subject Information Access extension 
> >>defined in 
> >>section 4.2.2.2 from RFC 3280.
> >>
> >>The id-ad-caRepository OID SHALL be used to indicate in which
> >>repository the 
> >>CA publishes its certificates and CRLs (if issued).
> >>
> >>Each CA certificate SHOULD also include the Subject
> >>Information Access 
> >>extension defined in section 4.2.2.2. from RFC 3280.
> >>
> >>This is the preferred method, since anyway trust points 
> MUST be known.
> >>
> >>
> >>B. Walking upwards the certification tree.
> >>
> >>Each end-entity certificate and each CA certificate SHOULD
> >>include the way 
> >>to find out where the CA is placing the other certificates. 
> >>This SHALL be 
> >>done using the Authority Information Access extension defined 
> >>in section 
> >>4.2.2.1 from RFC 3280 :
> >>
> >>The id-ad-caIssuers OID SHALL be used to list where the CA
> >>that has issued 
> >>the certificate lists CA certificates issued to the CA.
> >>
> >>This extension SHOULD be included in end-entity certificates and CA
> >>certificates.
> >>
> >>This can only be a complement to the previous method, since
> >>anyway trust 
> >>points MUST be known. When the downwards approach does not 
> >>succeed (explain 
> >>in which cases, it may not succeed), then a combination of 
> >>both methods may 
> >>succeed.
> >>
> >>Note: The location of CRLs is not specified in this extension. That
> >>information is provided by the cRLDistributionPoints extension.
> >>
> >>
> >>C. Revocation checking
> >>
> >>For revocation checking each end-entity and CA certificate
> >>SHALL either 
> >>include :
> >>
> >>    a) a cRLDistributionPoints extension, or
> >>    b) Subject Information access extension that includes the
> >>id-ad-ocsp OID
> >>       to indicate the location of servers using the Online 
> >>Certificate
> >>       Status Protocol (OCSP) [RFC 2560].
> >>
> >>
> >>Other comments.
> >>
> >>1. The difference between a CA-certificate and a
> >>cross-certificate is still 
> >>very hazy since what means a "realm" is either left undefined 
> >>or is said to 
> >>be "dependant upon local policy". It is thus impossible to 
> >>have standard 
> >>rules with such an approach.
> >>
> >>Introducing naming constraints between subject and issuer
> >>names might be 
> >>more appropriate; however, the real question is the following:
> >>
> >>Is it really important to make the difference if both:
> >>
> >>  - the pointers to CA repositories are present, and
> >>  - these repositories entries are correctly filled-in ?
> >>
> >>
> >>2. There is, as usual, some confusion between cross
> >>certification (which is, 
> >>by definition, unilateral) and mutual cross certification 
> >>(see section 
> >>13.2). Figure 3 does not make sense unless the trust points 
> >>are indicated.
> >>
> >>
> >>3. The case of validating a certificate in the past after a
> >>CA key rollover 
> >>(using the new root key) should be addressed.
> >>
> >>
> >>4. An interesting case to discuss would be the encoding of
> >>the issuer name 
> >>before and after December 31, 2003 since all certificates 
> >>issued after 
> >>December 31, 2003 MUST use the UTF8String encoding of 
> DirectoryString 
> >>(except as noted). The case of "name rollover" certificates 
> >>to support an 
> >>orderly migration to UTF8String encoding should be explained .
> >>
> >>
> >>5. The document is far too long.
> >>
> >>
> >>Denis
> >>
> > 
> > 
> > 
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84GrHgc067910 for <[e-mail]>; Thu, 4 Sep 2003 09:53:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h84GrHPr067909 for ietf-pkix-bks; Thu, 4 Sep 2003 09:53:17 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h84GrGgc067902 for <[e-mail]>; Thu, 4 Sep 2003 09:53:16 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.91]) by mailout.fastq.com (8.11.6/8.11.3.FastQ-MailOut) with SMTP id h84GrAD93642; Thu, 4 Sep 2003 09:53:10 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Thu, 4 Sep 2003 09:57: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)
Importance: Normal
In-Reply-To: <p0521060abb7bf2ae3408@[128.89.89.82]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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,
> >
> >Static config is easier to attack than dynamic config.
> >
> >Mike
>
> Mike,
>
> I'm not sure I believe that's uniformly true, but it is an
> interesting perspective.
>
> Moreover, an AIA extension is pretty static, in that
> certs typically have moderately long life spans,
> e.g., a year is pretty common for an EE cert,
> several years for a CA cert. So, can we really say
> whether a locally configured value for an SCVP server
> name is more or less static than a value extracted
> from a cert extension?
>
> Steve

Steve,

In using static vs. dynamic I meant the context to be "in
storage on the RP device".  A configuration file on a router or
an end-user workstation would exemplify static storage.  My
reference then to dynamic meant "in memory only", a situation
that could reliably be assumed to exist since: 1) the SCVP
process is inherently dynamic and online; and 2) given an AIA,
the certificate itself bears the necessary addressing
information.

The last point is modulo of course that pesky notion you brought
up about having to configure the trusted public key anyway. But
then, that's just one key while the AIA values may vary against
a locally configured SCVP server that, as we previously
discussed, could make better and more secure use of those varied
AIA values via relay.

A standardized OID and syntax for SCVP AIA would I believe
contribute useful architectural options towards the "why is PKI
hard?" question.  It would not totally eliminate the need for
local config, but rather complement the practice in a way that
allows the design and evolution of a more adapative
infrastructure.

Thus, in some future timeline where PKI is indeed ubiquitous, if
my response to all these email-based viruses is to accept only
signed attachments, my ISP's SCVP server need not have any
pre-configured knowledge of the SCVP server operated by my
correspondent's ISP.  My ISP simple needs a server, a key and a
pointer, the latter two elements being locally configured on my
client platform.  That server, via AIA, dynamically relays the
request, receives the response, resigns it and there you go.  No
messiness of local config on my ISP's part, or any ISP for that
matter.  The infrastructure is data-driven via the cert.

In summary I believe there's sufficient value to go forward with
an AIA for SCVP.  It's not a perfect solution, but neither is
total reliance on local config.  Together, possibly so.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83Kfrgc070435 for <[e-mail]>; Wed, 3 Sep 2003 13:41:53 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83KfrHv070434 for ietf-pkix-bks; Wed, 3 Sep 2003 13:41:53 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83Kfqgc070429 for <[e-mail]>; Wed, 3 Sep 2003 13:41:53 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h83KfoiW029895; Wed, 3 Sep 2003 16:41:50 -0400
From: "Santosh Chokhani" <[e-mail]>
To: "'Liaquat Khan'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 3 Sep 2003 16:41:45 -0400
Message-ID: <00cc01c3725b$ccf032f0$[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, Build 10.0.4510
Importance: Normal
In-Reply-To: <004701c37257$b8d31bb0$b6d88351@laptoplk>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I am not ruling it out.  If the AIA extension had the public key of the
server, the question may remain as to how the RP will be notified of the
break in that binding if the CA needs to break that binding.

All I am trying to do is learn and help figure out if the inclusion of AIA
in a certificate has some value.

I think there may be some value to the pointer regardless of how the SCVP
server public key (for trusted SCVP services) is provided to the RP.

-----Original Message-----
From: Liaquat Khan [mailto:[e-mail]] 
Sent: Wednesday, September 03, 2003 4:13 PM
To: 'Santosh Chokhani'; [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


So I assume from the below that we are we ruling out an equivalent of the
"delegated" mode for SCVP? I.e. the ability for the CA to certify the SCVP
server's public key and thereby extend trust from the CA to the SCVP
service?  

If this model was allowed then the use of the AIA extension to identify the
SCVP service would have been even more obvious... 

Regards,
LK



>>Good point, but this raises the question of where the client will get
a public key for a server whose name appears in an extension. If the 
public key for an SCVP server must be configured specially, i.e., not 
just be verifiable as any EE, then why is it any harder to configure 
the name/URI for the server at the same time? What benefit accrues 
from carrying the name in the extension, since by itself the name is 
not sufficient to enable sue of the server.

[Agreed.  I made the same point in the next para]





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83KKYgc069768 for <[e-mail]>; Wed, 3 Sep 2003 13:20:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83KKYqJ069767 for ietf-pkix-bks; Wed, 3 Sep 2003 13:20:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from protactinium.btinternet.com (protactinium.btinternet.com [194.73.73.176]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83KKWgc069760 for <[e-mail]>; Wed, 3 Sep 2003 13:20:33 -0700 (PDT) (envelope-from [e-mail])
Received: from dial81-131-216-182.in-addr.btopenworld.com ([81.131.216.182] helo=laptoplk) by protactinium.btinternet.com with esmtp (Exim 3.22 #23) id 19ue79-0006bL-00; Wed, 03 Sep 2003 21:20:28 +0100
From: "Liaquat Khan" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 3 Sep 2003 21:12:36 +0100
Message-ID: <004701c37257$b8d31bb0$b6d88351@laptoplk>
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 V6.00.2800.1106
Importance: Normal
In-Reply-To: <006901c3723f$219f9b00$[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 assume from the below that we are we ruling out an equivalent of
the "delegated" mode for SCVP? I.e. the ability for the CA to certify
the SCVP server's public key and thereby extend trust from the CA to the
SCVP service?  

If this model was allowed then the use of the AIA extension to identify
the SCVP service would have been even more obvious... 

Regards,
LK



>>Good point, but this raises the question of where the client will get 
a public key for a server whose name appears in an extension. If the 
public key for an SCVP server must be configured specially, i.e., not 
just be verifiable as any EE, then why is it any harder to configure 
the name/URI for the server at the same time? What benefit accrues 
from carrying the name in the extension, since by itself the name is 
not sufficient to enable sue of the server.

[Agreed.  I made the same point in the next para]





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83Jcegc066310 for <[e-mail]>; Wed, 3 Sep 2003 12:38:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83JceT3066308 for ietf-pkix-bks; Wed, 3 Sep 2003 12:38:40 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83Jcdgc066285 for <[e-mail]>; Wed, 3 Sep 2003 12:38:39 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h83JcSQ8004378; Wed, 3 Sep 2003 15:38:29 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521060abb7bf2ae3408@[128.89.89.82]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 3 Sep 2003 15:37:25 -0400
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 11:39 -0700 9/3/03, Michael Myers wrote:
>  > -----Original Message-----
>>  From: [e-mail]
>>  [mailto:[e-mail]]On Behalf Of Stephen Kent
>>  Sent: Wednesday, September 03, 2003 7:56 AM
>>
>>  . . .
>>
>>  But, I'd like to know what use the local server would
>>  make of the pointers in one or more AIA extensions.
>>  I've seen too many examples of "let's allow X to be
>>  put here because maybe there will be some good use for
>>  it that we will figure out later" to be comfortable
>>  going down this path without a better understanding
>>  of what purpose is served.
>>
>>  . . .
>>
>>  Steve
>
>Steve,
>
>Static config is easier to attack than dynamic config.
>
>Mike

Mike,

I'm not sure I believe that's uniformly true, but it is an 
interesting perspective.

Moreover, an AIA extension is pretty static, in that certs typically 
have moderately long life spans, e.g., a year is pretty common for an 
EE cert, several years for a CA cert. So, can we really say whether a 
locally configured value for an SCVP server name is more or less 
static than a value extracted from a cert extension?

Steve

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83IZ4gc060845 for <[e-mail]>; Wed, 3 Sep 2003 11:35:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83IZ432060844 for ietf-pkix-bks; Wed, 3 Sep 2003 11:35:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83IZ3gc060838 for <[e-mail]>; Wed, 3 Sep 2003 11:35:03 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.91]) by mailout.fastq.com (8.11.6/8.11.3.FastQ-MailOut) with SMTP id h83IZ4D37201; Wed, 3 Sep 2003 11:35:04 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 3 Sep 2003 11:39:10 -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: <p05210605bb7bb02f9e54@[128.89.89.82]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 Stephen Kent
> Sent: Wednesday, September 03, 2003 7:56 AM
>
> . . .
>
> But, I'd like to know what use the local server would
> make of the pointers in one or more AIA extensions.
> I've seen too many examples of "let's allow X to be
> put here because maybe there will be some good use for
> it that we will figure out later" to be comfortable
> going down this path without a better understanding
> of what purpose is served.
>
> . . .
>
> Steve

Steve,

Static config is easier to attack than dynamic config.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83HZ1gc054848 for <[e-mail]>; Wed, 3 Sep 2003 10:35:01 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83HZ1sV054847 for ietf-pkix-bks; Wed, 3 Sep 2003 10:35:01 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83HYxgc054832 for <[e-mail]>; Wed, 3 Sep 2003 10:35:00 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA10588; Wed, 3 Sep 2003 19:35:00 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Wed, 3 Sep 2003 19:35:00 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h83HYxu05740; Wed, 3 Sep 2003 19:34:59 +0200 (MEST)
Date: Wed, 3 Sep 2003 19:34:59 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> But, I'd like to know what use the local server would make of the 
> pointers in one or more AIA extensions.  I've seen too many examples 
> of "let's allow X to be put here because maybe there will be some 
> good use for it that we will figure out later" to be comfortable 
> going down this path without a better understanding of what purpose 
> is served. 

Scenario 1:

- A client asks his local server to validate a cert. 

- The local server has a policy/configuration indicating that
  for the cert in question the AIA of an CA operated DPV
  service is populated and should be contacted.

- The local server does so and authenticates the response
  in whatever way is indicated in the policy. 

Now, one can ask whether the ee-cert needs an AIA. Indeed,
it may be better to have an SIA extension in a CA cert
saying that in order to obtain a paricular information 
containing certificates issued by this authority.

A SIA in a CA cert for OCSP also makes sense to me BTW. 
  

Scenario 2:

- The same client wants a pointer to his local server; 
  this can be done in different ways; the client would
  never use an IA in any of the certificate in the
  chain to be validated. but would use an extension
  in one certificate of a chain usable to authenticate
  its local server. 



 


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83HGagc053578 for <[e-mail]>; Wed, 3 Sep 2003 10:16:36 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83HGaA3053577 for ietf-pkix-bks; Wed, 3 Sep 2003 10:16:36 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83HGZgc053572 for <[e-mail]>; Wed, 3 Sep 2003 10:16:36 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h83HGaiW001966 for <[e-mail]>; Wed, 3 Sep 2003 13:16:36 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 3 Sep 2003 13:16:31 -0400
Message-ID: <006901c3723f$219f9b00$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <p05210600bb7b9c45f34b@[128.89.89.75]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h83HGagc053573
Sender: [e-mail]
Precedence: 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:

Please see responses in-line in []

-----Original Message-----
From: Stephen Kent [mailto:[e-mail]] 
Sent: Wednesday, September 03, 2003 9:33 AM
To: Santosh Chokhani
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]


At 18:32 -0400 9/2/03, Santosh Chokhani wrote:
>Steve:
>
>The extension could work like OCSP extension in that the local settings 
>can always override what is in the certificate.

What I noted, was that IF there is no locally configured SCVP server 
info, THEN the presence of such info in an AIA extension would 
presumably be used, and that would create a configuration  management 
vulnerability.

[If there is no locally configured SCVP server, would the client invoke SCVP
services?  If so, what else does it have to rely on but the information in
the certificate.  Seems that in that scenario you use something from the
certificate or do something other than SCVP] 

>Also, when you say "bad security idea", I assume you mean from 
>availability and performance viewpoints since a name asserted in the 
>AIA extension is not going to form the basis of trust.  The RP will use 
>a public key trusted in some other fashion to trust an SCVP server.

Good point, but this raises the question of where the client will get 
a public key for a server whose name appears in an extension. If the 
public key for an SCVP server must be configured specially, i.e., not 
just be verifiable as any EE, then why is it any harder to configure 
the name/URI for the server at the same time? What benefit accrues 
from carrying the name in the extension, since by itself the name is 
not sufficient to enable sue of the server.

[Agreed.  I made the same point in the next para]

>Now, here is a possible scenario of some utility.  Suppose you are 
>using the untrusted SCVP servers for path development only.  Suppose 
>that these servers tend to provide paths to some known trust anchors, 
>including their Enterprise roots.
>
>Now, in cross certified environments and in Bridge environment, this 
>partial path may be of some help.

This scenario is not clear to me.  Please elaborate.

[In complex trust graph, the certificate discovery problem can be broken
down into three chunks: 1.  Finding a trust point in the subscriber domain
-- this piece is provided by path discovery capability of a trusted or
untrusted SCVP Server.  2.  Finding a trust point in RP domain -- this is
straightforward most of the times (a trust list).  3.  Find how the path
between the two trust points -- hopefully that is a direct cross
certification, a path through a common bridge or through a series of
bridges.  If the RP is able to find a path to a trust point in subscriber
domain through the SCVP server, the path discovery problem is reduced:
divide and conquer principle]

>I agree that for certification path validation (trusted SCVP server), 
>at a first glance, the extension does not seem to be of much use since 
>the RP clients must be configured with trusted public keys for the SCVP 
>servers anyway.  It might as well be configured with SCVP names also.  
>But, wait, here also, if there is more than 1 SCVP server in the RP 
>configuration, then if a name matches that in a certificate, that name 
>breaks the tie.
>

This strikes me as a new twist on the processing model, and one that 
needs to be examined carefully before we decide it's a good idea.

[I am all for a careful examination.  Do you see any pitfalls in it?]

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83G8kgc048360 for <[e-mail]>; Wed, 3 Sep 2003 09:08:46 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83G8kOB048359 for ietf-pkix-bks; Wed, 3 Sep 2003 09:08:46 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83G8igc048352 for <[e-mail]>; Wed, 3 Sep 2003 09:08:45 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h83G8OQA027132; Wed, 3 Sep 2003 12:08:25 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210608bb7bc1b9bac2@[128.89.89.82]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 3 Sep 2003 12:06:03 -0400
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 8:15 -0700 9/3/03, Michael Myers wrote:
>  > BTW, what is the origin of the phrase "four corner
>>  model" that has cropped up here?
>>
>>  Steve
>
>
>Steve,
>
>The "four-corner model" derives from the picture that Mack Hicks
>and others always drew to explain how Identrus would work
>vis-a-vis trust and especially how OCSP relay fit into their
>bank-to-bank risk management scheme.
>
>Mike


OK, now I know why I was unfamiliar with the reference.

Thanks,

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83FBMgc045533 for <[e-mail]>; Wed, 3 Sep 2003 08:11:22 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83FBM73045532 for ietf-pkix-bks; Wed, 3 Sep 2003 08:11:22 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83FBLgc045527 for <[e-mail]>; Wed, 3 Sep 2003 08:11:21 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.91]) by mailout.fastq.com (8.11.6/8.11.3.FastQ-MailOut) with SMTP id h83FBFD27537; Wed, 3 Sep 2003 08:11:15 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 3 Sep 2003 08:15:23 -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: <p05210605bb7bb02f9e54@[128.89.89.82]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> BTW, what is the origin of the phrase "four corner
> model" that has cropped up here?
>
> Steve


Steve,

The "four-corner model" derives from the picture that Mack Hicks
and others always drew to explain how Identrus would work
vis-a-vis trust and especially how OCSP relay fit into their
bank-to-bank risk management scheme.

Mike





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83FB7gc045513 for <[e-mail]>; Wed, 3 Sep 2003 08:11:07 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83FB71b045512 for ietf-pkix-bks; Wed, 3 Sep 2003 08:11:07 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83FB5gc045507 for <[e-mail]>; Wed, 3 Sep 2003 08:11:06 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA09486; Wed, 3 Sep 2003 17:11:05 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Wed, 3 Sep 2003 17:11:05 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h83FB4c05331; Wed, 3 Sep 2003 17:11:04 +0200 (MEST)
Date: Wed, 3 Sep 2003 17:11:04 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> One motivation for DPV is to allow clients to receive a public key 
> and to use it, because the server said it was OK to use relative to 
> the policy indicated by the client in the query. The notion is that a 
> client need not be able to parse certs and CRLs in this case, but 
> rather can just pass an opaque blob of bits to the server and use a 
> configured policy reference, specific to the local use context, and 
> be told the answer.  Obviously this would not be true in the DPD 
> case, but it is reasonable for DPV.

Can you point me to the text in 3379.

As far as I can see, the text does not talk about public key 
retrieval, but about certificate validation. 

Nowhere in the text there is a requirement that the protocol
MUST provide a means that a client can treat a cert as a blob.
 

The text says that one of the unambigouous references
may for example be  "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]."

" The DPV server MUST
   include either the certificate or an unambiguous reference to the
   certificate (in case of a CA key compromise) in the DPV response."

except for a hash, the other references require interpretation of
the cert. 

> >Your main argument seems to me: 'As soon as there is one particular
> >situation where a feature cannot be used, one MUST NOT even think
> >to use it.'
> 
> The primary focus of what we are doing was established in RFC 3379. 
> It think it is appropriate to judge a suggestion of this sort 
> relative to that set of agreed upon requirements.

But you have already argued differently without success so far,
and you just use this as a last resort for your refusal. 

> 
> >I am not sure whether we (the group, not just you) can get consensus
> >that there is a subset of use cases for DPV which matches the use
> >cases for OCSP.
> 
> 3379 represents WG consensus on the requirements for this protocol, 
> so it is valid to make decisions based on that.
> 
> >
> >>  >  > >On the other hand, you seem to restrict DVP to just just that model.
> >>  >>  >I think it has been mentioned several times that a DPV service
> >>  >>  >can be operated in exactly the same trust models as OCSP, i.e.,
> >>  >>  >as a CA provided service.
> >>  >>
> >>  >>  Is there a part of the DVP/DVD requirements RFC that suggests this
> >>  >>  model?  I don't recall.
> >>  >
> >>  >Wasn't one of the initial motiviations of the activity the
> >>  >problem that OCSP only creates 'negative' responses?
> >>
> >>  I don't see that cited in RFC 3379 as a motivation.
> >
> >I fail to decrypt this sentence.
> >
> >Do you agree mean that 3379 lists the only valid points, or
> >do you accept this motivation as a valid one which was
> >omitted in 3379 for whatever reason, or ... ??
> 
> Yes, a CA could operate an SCVP service for its local clients, but 
> such operation is not intrinsic to the general model. I have yet to 
> see a good explanation of the benefits that accrue from putting the 
> name of an SCVP server into an extension, if we agree that the public 
> key for that server needs to be configured in the client anyway. 
> Moreover, the suggestion of putting this info into the AIA extension 
> seems to be an afterthought, especially when viewed relative to 3379.

The usage of AIA or SIA to point to services is a common feature that
has been used in various PKIX protocols, OCSP, TSP, DVCS for example as
a general mechanism to convey a contact address in a certificate. 

This does seem an afterthought to me but rather a well accepted feature
since years which doesn't seem to need a particular requirement.

A simple way to configure a public key is a certificate. You can have
like in TSP a SIA with your local server, and your local server acting
as a proxy can contact a CA's server using an AIA in the cert to be 
validated. 


> Is that clearer?
In one paragraph you hide yourself behind 3379, and on
the other hand you pretend to discuss more until your run out of
arguments. 

> >>  >Well, of course, there is a simple fix for OCSP.
> >>
> >>  you omitted the emoticon at the end of the sentence, e.g., :-) or ;-)
> >
> >No.
> 
> Oh, then you should say what simple fix you have in mind. I assumed 
> that you were suggesting, in jest, the idea of  changing the 
> semantics of OCSP to be a cert status protocol, vs. a cert revocation 
> status protocol, something that has been debated on the list on a 
> number of occasions and thus did not seem to merit further, serious 
> discussion.
You do not mention that many of the proposals simply work, so indeed,
further discussion would not change this. 

- return a valid cert as an extension
- define in your CPS that all ok response mean that the cert exists

Peter


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83ExDgc044520 for <[e-mail]>; Wed, 3 Sep 2003 07:59:13 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83ExDdp044519 for ietf-pkix-bks; Wed, 3 Sep 2003 07:59:13 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83ExCgc044506 for <[e-mail]>; Wed, 3 Sep 2003 07:59:12 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h83Ex1Q8022182; Wed, 3 Sep 2003 10:59:01 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210605bb7bb02f9e54@[128.89.89.82]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 3 Sep 2003 10:55:43 -0400
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 7:37 -0700 9/3/03, Michael Myers wrote:
>  > -----Original Message-----
>>  From: [e-mail]
>>  [mailto:[e-mail]]On Behalf Of Stephen Kent
>>  Sent: Tuesday, September 02, 2003 1:00 PM
>>  . . .
>>  But, if an enterprise CA relied on an AIA pointer to
>>  direct the local clients to its SCVP server for its
>>  certs, does that mean the local CA would want to
>>  have its clients directed to other servers based on
>>  pointers in certs from other CAs? In general, this
>>  would be a bad security idea.
>>  . . .
>>
>>  Steve
>
>
>Steve,
>
>One architectural deployment scenario would be to have a
>community's members indeed vectored to that community's trusted
>server independant of the AIA for reasons of uniform policy
>enforcement.  However, that server could then use the AIA in
>some back office fashion.  This in essence is the four corner
>model.

OK, at least that convention would avoid the concern I raised.  If we 
were to extend the AIA extension to include such a pointer, then we 
would have to ensure that this is how clients did operate, to avoid 
the concern I cited.

But, I'd like to know what use the local server would make of the 
pointers in one or more AIA extensions.  I've seen too many examples 
of "let's allow X to be put here because maybe there will be some 
good use for it that we will figure out later" to be comfortable 
going down this path without a better understanding of what purpose 
is served.

BTW, what is the origin of the phrase "four corner model" that has 
cropped up here?

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83EXggc041245 for <[e-mail]>; Wed, 3 Sep 2003 07:33:42 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83EXg5O041244 for ietf-pkix-bks; Wed, 3 Sep 2003 07:33:42 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83EXegc041237 for <[e-mail]>; Wed, 3 Sep 2003 07:33:40 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.91]) by mailout.fastq.com (8.11.6/8.11.3.FastQ-MailOut) with SMTP id h83EXVD26014; Wed, 3 Sep 2003 07:33:31 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 3 Sep 2003 07:37:38 -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: <p05210613bb7aa5f09093@[128.89.89.75]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 Stephen Kent
> Sent: Tuesday, September 02, 2003 1:00 PM
> . . .
> But, if an enterprise CA relied on an AIA pointer to
> direct the local clients to its SCVP server for its
> certs, does that mean the local CA would want to
> have its clients directed to other servers based on
> pointers in certs from other CAs? In general, this
> would be a bad security idea.
> . . .
>
> Steve


Steve,

One architectural deployment scenario would be to have a
community's members indeed vectored to that community's trusted
server independant of the AIA for reasons of uniform policy
enforcement.  However, that server could then use the AIA in
some back office fashion.  This in essence is the four corner
model.

Mike




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83DsQgc035270 for <[e-mail]>; Wed, 3 Sep 2003 06:54:26 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83DsQ7r035269 for ietf-pkix-bks; Wed, 3 Sep 2003 06:54:26 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83DsOgc035254 for <[e-mail]>; Wed, 3 Sep 2003 06:54:25 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h83DrPQ8017118; Wed, 3 Sep 2003 09:53:25 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210601bb7b9f0397d9@[128.89.89.82]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Wed, 3 Sep 2003 09:49:29 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 14:40 +0200 9/3/03, Peter Sylvester wrote:
>  > >Maybe not into the cert in question, but into the cert that
>>  >may be used to authenticate a connection of a client to
>>  >such a server in order to have a simple place for
>>  >configuration.
>>
>>  I'm afraid this seems like too trivial a configuration issue to
>>  warrant a place in our standards.
>
>Is there is missing 'to me' ?

yes, it seems to trivial to me, but I don't think my opinion is 
unique in this case :-)

>
>>  >
>>  >Alternatively, it could be in a SIA of a service cert.
>>
>>  see my comments to Trevor re 3379 assumptions about clients, in general.
>
>A client that is unable to decode a cert would use a certifiacte in
>which way? Isn't there at least a need to extract the public key?

One motivation for DPV is to allow clients to receive a public key 
and to use it, because the server said it was OK to use relative to 
the policy indicated by the client in the query. The notion is that a 
client need not be able to parse certs and CRLs in this case, but 
rather can just pass an opaque blob of bits to the server and use a 
configured policy reference, specific to the local use context, and 
be told the answer.  Obviously this would not be true in the DPD 
case, but it is reasonable for DPV.

>Your main argument seems to me: 'As soon as there is one particular
>situation where a feature cannot be used, one MUST NOT even think
>to use it.'

The primary focus of what we are doing was established in RFC 3379. 
It think it is appropriate to judge a suggestion of this sort 
relative to that set of agreed upon requirements.

>I am not sure whether we (the group, not just you) can get consensus
>that there is a subset of use cases for DPV which matches the use
>cases for OCSP.

3379 represents WG consensus on the requirements for this protocol, 
so it is valid to make decisions based on that.

>
>>  >  > >On the other hand, you seem to restrict DVP to just just that model.
>>  >>  >I think it has been mentioned several times that a DPV service
>>  >>  >can be operated in exactly the same trust models as OCSP, i.e.,
>>  >>  >as a CA provided service.
>>  >>
>>  >>  Is there a part of the DVP/DVD requirements RFC that suggests this
>>  >>  model?  I don't recall.
>>  >
>>  >Wasn't one of the initial motiviations of the activity the
>>  >problem that OCSP only creates 'negative' responses?
>>
>>  I don't see that cited in RFC 3379 as a motivation.
>
>I fail to decrypt this sentence.
>
>Do you agree mean that 3379 lists the only valid points, or
>do you accept this motivation as a valid one which was
>omitted in 3379 for whatever reason, or ... ??

Yes, a CA could operate an SCVP service for its local clients, but 
such operation is not intrinsic to the general model. I have yet to 
see a good explanation of the benefits that accrue from putting the 
name of an SCVP server into an extension, if we agree that the public 
key for that server needs to be configured in the client anyway. 
Moreover, the suggestion of putting this info into the AIA extension 
seems to be an afterthought, especially when viewed relative to 3379. 
Is that clearer?

>
>>  >Well, of course, there is a simple fix for OCSP.
>>
>>  you omitted the emoticon at the end of the sentence, e.g., :-) or ;-)
>
>No.

Oh, then you should say what simple fix you have in mind. I assumed 
that you were suggesting, in jest, the idea of  changing the 
semantics of OCSP to be a cert status protocol, vs. a cert revocation 
status protocol, something that has been debated on the list on a 
number of occasions and thus did not seem to merit further, serious 
discussion.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83DXYgc033966 for <[e-mail]>; Wed, 3 Sep 2003 06:33:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83DXYKA033965 for ietf-pkix-bks; Wed, 3 Sep 2003 06:33:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83DXXgc033956 for <[e-mail]>; Wed, 3 Sep 2003 06:33:33 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.82] (dhcp89-089-082.bbn.com [128.89.89.82]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h83DXOQ8015836; Wed, 3 Sep 2003 09:33:25 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210600bb7b9c45f34b@[128.89.89.75]>
In-Reply-To: <006001c371a2$28f74440$[e-mail]>
References: <006001c371a2$28f74440$[e-mail]>
Date: Wed, 3 Sep 2003 09:33:05 -0400
To: "Santosh Chokhani" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 18:32 -0400 9/2/03, Santosh Chokhani wrote:
>Steve:
>
>The extension could work like OCSP extension in that the local settings can
>always override what is in the certificate.

What I noted, was that IF there is no locally configured SCVP server 
info, THEN the presence of such info in an AIA extension would 
presumably be used, and that would create a configuration  management 
vulnerability.

>Also, when you say "bad security idea", I assume you mean from availability
>and performance viewpoints since a name asserted in the AIA extension is not
>going to form the basis of trust.  The RP will use a public key trusted in
>some other fashion to trust an SCVP server.

Good point, but this raises the question of where the client will get 
a public key for a server whose name appears in an extension. If the 
public key for an SCVP server must be configured specially, i.e., not 
just be verifiable as any EE, then why is it any harder to configure 
the name/URI for the server at the same time? What benefit accrues 
from carrying the name in the extension, since by itself the name is 
not sufficient to enable sue of the server.

>Now, here is a possible scenario of some utility.  Suppose you are using the
>untrusted SCVP servers for path development only.  Suppose that these
>servers tend to provide paths to some known trust anchors, including their
>Enterprise roots.
>
>Now, in cross certified environments and in Bridge environment, this partial
>path may be of some help.

This scenario is not clear to me.  Please elaborate.

>I agree that for certification path validation (trusted SCVP server), at a
>first glance, the extension does not seem to be of much use since the RP
>clients must be configured with trusted public keys for the SCVP servers
>anyway.  It might as well be configured with SCVP names also.  But, wait,
>here also, if there is more than 1 SCVP server in the RP configuration, then
>if a name matches that in a certificate, that name breaks the tie.
>

This strikes me as a new twist on the processing model, and one that 
needs to be examined carefully before we decide it's a good idea.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83CeBgc029589 for <[e-mail]>; Wed, 3 Sep 2003 05:40:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h83CeBE6029588 for ietf-pkix-bks; Wed, 3 Sep 2003 05:40:11 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h83Ce9gc029583 for <[e-mail]>; Wed, 3 Sep 2003 05:40:10 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA08474; Wed, 3 Sep 2003 14:40:09 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Wed, 3 Sep 2003 14:40:09 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h83Ce0R04933; Wed, 3 Sep 2003 14:40:00 +0200 (MEST)
Date: Wed, 3 Sep 2003 14:40:00 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail], [e-mail], [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> >Maybe not into the cert in question, but into the cert that
> >may be used to authenticate a connection of a client to
> >such a server in order to have a simple place for
> >configuration.
> 
> I'm afraid this seems like too trivial a configuration issue to 
> warrant a place in our standards.

Is there is missing 'to me' ? 

> >
> >Alternatively, it could be in a SIA of a service cert.
> 
> see my comments to Trevor re 3379 assumptions about clients, in general.

A client that is unable to decode a cert would use a certifiacte in
which way? Isn't there at least a need to extract the public key?

Your main argument seems to me: 'As soon as there is one particular
situation where a feature cannot be used, one MUST NOT even think
to use it.' 

I am not sure whether we (the group, not just you) can get consensus
that there is a subset of use cases for DPV which matches the use
cases for OCSP. 

> >  > >On the other hand, you seem to restrict DVP to just just that model.
> >>  >I think it has been mentioned several times that a DPV service
> >>  >can be operated in exactly the same trust models as OCSP, i.e.,
> >>  >as a CA provided service.
> >>
> >>  Is there a part of the DVP/DVD requirements RFC that suggests this
> >>  model?  I don't recall.
> >
> >Wasn't one of the initial motiviations of the activity the
> >problem that OCSP only creates 'negative' responses?
> 
> I don't see that cited in RFC 3379 as a motivation.

I fail to decrypt this sentence.

Do you agree mean that 3379 lists the only valid points, or
do you accept this motivation as a valid one which was
omitted in 3379 for whatever reason, or ... ??

> >Well, of course, there is a simple fix for OCSP.
> 
> you omitted the emoticon at the end of the sentence, e.g., :-) or ;-)

No. 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82MWvgc057499 for <[e-mail]>; Tue, 2 Sep 2003 15:32:57 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82MWvml057498 for ietf-pkix-bks; Tue, 2 Sep 2003 15:32:57 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from host13.websitesource.com (host13.websitesource.com [209.239.35.152]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82MWugc057493 for <[e-mail]>; Tue, 2 Sep 2003 15:32:56 -0700 (PDT) (envelope-from [e-mail])
Received: from wchokhani (dpvc-138-88-161-20.res.east.verizon.net [138.88.161.20]) by host13.websitesource.com (8.12.9/8.12.9) with ESMTP id h82MWwiW025206 for <[e-mail]>; Tue, 2 Sep 2003 18:32:58 -0400
From: "Santosh Chokhani" <[e-mail]>
To: <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Tue, 2 Sep 2003 18:32:50 -0400
Message-ID: <006001c371a2$28f74440$[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.4510
Importance: Normal
In-Reply-To: <p05210613bb7aa5f09093@[128.89.89.75]>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id h82MWugc057494
Sender: [e-mail]
Precedence: 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:

The extension could work like OCSP extension in that the local settings can
always override what is in the certificate.

Also, when you say "bad security idea", I assume you mean from availability
and performance viewpoints since a name asserted in the AIA extension is not
going to form the basis of trust.  The RP will use a public key trusted in
some other fashion to trust an SCVP server.

Now, here is a possible scenario of some utility.  Suppose you are using the
untrusted SCVP servers for path development only.  Suppose that these
servers tend to provide paths to some known trust anchors, including their
Enterprise roots.

Now, in cross certified environments and in Bridge environment, this partial
path may be of some help.

I agree that for certification path validation (trusted SCVP server), at a
first glance, the extension does not seem to be of much use since the RP
clients must be configured with trusted public keys for the SCVP servers
anyway.  It might as well be configured with SCVP names also.  But, wait,
here also, if there is more than 1 SCVP server in the RP configuration, then
if a name matches that in a certificate, that name breaks the tie.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Stephen Kent
Sent: Tuesday, September 02, 2003 4:00 PM
To: Michael Myers
Cc: Trevor Freeman; Faisal; Denis Pinkas; [e-mail]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]



At 12:33 -0700 9/2/03, Michael Myers wrote:
>Steve,
>
>The notion that "CAs do OCSP" while "somebody else does SCVP" is being 
>overly polarized.  We should bear in mind the enterprise-level case 
>where trusted certificate production is only one aspect of an overall 
>information security management policy.  A standardized means of 
>including an SCVP pointer in the certificates issued by such 
>environments would benefit uniform and automated enforcement of this 
>aspect of enterprise security policies.
>
>Mike
>

I agree that there will be contexts in which the CA and the SCVP 
server operator are the same, for some set of clients. Your 
enterprise example is a valid one.

But, if an enterprise CA relied on an AIA pointer to direct the local 
clients to its SCVP server for its certs, does that mean the local CA 
would want to have its clients directed to other servers based on 
pointers in certs from other CAs? In general, this would be a bad 
security idea.  Thus it would seem that the local CA needs to be able 
to configure its clients with a pointer to the local SCVP server, in 
a fashion independent of the AIA extension, to prevent clients from 
being vectored to other SCVP servers. In that case, a pointer in the 
AIA extension would not seem to offer the benefit you cite.

Steve




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82K4Tgc049026 for <[e-mail]>; Tue, 2 Sep 2003 13:04:29 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82K4TBj049025 for ietf-pkix-bks; Tue, 2 Sep 2003 13:04:29 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82K4Sgc049019 for <[e-mail]>; Tue, 2 Sep 2003 13:04:28 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h82K3TQ8016050; Tue, 2 Sep 2003 16:03:29 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210613bb7aa5f09093@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 2 Sep 2003 16:00:15 -0400
To: "Michael Myers" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: "Trevor Freeman" <[e-mail]>, "Faisal" <[e-mail]>, "Denis Pinkas" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:33 -0700 9/2/03, Michael Myers wrote:
>Steve,
>
>The notion that "CAs do OCSP" while "somebody else does SCVP" is
>being overly polarized.  We should bear in mind the
>enterprise-level case where trusted certificate production is
>only one aspect of an overall information security management
>policy.  A standardized means of including an SCVP pointer in
>the certificates issued by such environments would benefit
>uniform and automated enforcement of this aspect of enterprise
>security policies.
>
>Mike
>

I agree that there will be contexts in which the CA and the SCVP 
server operator are the same, for some set of clients. Your 
enterprise example is a valid one.

But, if an enterprise CA relied on an AIA pointer to direct the local 
clients to its SCVP server for its certs, does that mean the local CA 
would want to have its clients directed to other servers based on 
pointers in certs from other CAs? In general, this would be a bad 
security idea.  Thus it would seem that the local CA needs to be able 
to configure its clients with a pointer to the local SCVP server, in 
a fashion independent of the AIA extension, to prevent clients from 
being vectored to other SCVP servers. In that case, a pointer in the 
AIA extension would not seem to offer the benefit you cite.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82JU2gc044464 for <[e-mail]>; Tue, 2 Sep 2003 12:30:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82JU2Ru044463 for ietf-pkix-bks; Tue, 2 Sep 2003 12:30:02 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from mailout.fastq.com (mailout.fastq.com [204.62.193.66]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82JTxgc044447 for <[e-mail]>; Tue, 2 Sep 2003 12:30:01 -0700 (PDT) (envelope-from [e-mail])
Received: from MMyersLapTop ([65.39.77.91]) by mailout.fastq.com (8.11.6/8.11.3.FastQ-MailOut) with SMTP id h82JTcD92573; Tue, 2 Sep 2003 12:29:38 -0700 (MST) (envelope-from [e-mail])
From: "Michael Myers" <[e-mail]>
To: "Stephen Kent" <[e-mail]>, "Trevor Freeman" <[e-mail]>
Cc: "Faisal" <[e-mail]>, "Denis Pinkas" <[e-mail]>, <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Tue, 2 Sep 2003 12:33: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)
In-Reply-To: <p05210606bb7a789ef15b@[128.89.89.75]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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,

The notion that "CAs do OCSP" while "somebody else does SCVP" is
being overly polarized.  We should bear in mind the
enterprise-level case where trusted certificate production is
only one aspect of an overall information security management
policy.  A standardized means of including an SCVP pointer in
the certificates issued by such environments would benefit
uniform and automated enforcement of this aspect of enterprise
security policies.

Mike


> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of Stephen Kent
> Sent: Tuesday, September 02, 2003 10:50 AM
> To: Trevor Freeman
> Cc: Faisal; Denis Pinkas; [e-mail]
> Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt
> [SCVP-AIA]
>
>
>
> At 9:53 -0700 8/29/03, Trevor Freeman wrote:
> >Steve,
> >I don't see why the use of AIA is inappropriate for
> SCVP. It's just a
> >hint like a lot of other things in certificates such
> as SKID. If the
> >client has configured SCVP server it uses, it is
> free to ignore the
> >information provided by the AIA, just as client with
> a locally
> >configured OCSP server can ignore the OSCP pointer
> in the AIA extension
> >today.
> >Trevor
> >
> Trevor,
>
> In part the question is what one views as the primary
> model for use
> of SCVP, and whether putting an SCBP pointer into a
> cert represents a
> significant opportunity for a new configuration management
> vulnerability, i.e., failure to populate a local SCVP
> pointer would
> allow the AIA value to be used instead.
>
> Another matter is that SCVP (in its DPV role) is also
> designed for
> environments where the client is not presumed to be
> capable of
> processing certs. In that context, it does not seem
> to be useful to
> put in a pointer to a server, since the client would
> not be likely to
> be able to extract and make use of the pointer.
>
> I have reread RFC 3379, the DPD/DPV requirements doc,
> and I see no
> references that would lead me to believe that a CA would be
> appropriate as a server for all RPs that might deal
> with certs issued
> by the CA.
>
> What if several certs in a path each contained an
> SCVP server pointer
> in an AIA extension? While this would make sense for
> OCSP, it is not
> appropriate for SCVP.
>
> Steve
>
>




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82IEKgc038810 for <[e-mail]>; Tue, 2 Sep 2003 11:14:20 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82IEJLR038809 for ietf-pkix-bks; Tue, 2 Sep 2003 11:14:19 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82IEIgc038794 for <[e-mail]>; Tue, 2 Sep 2003 11:14:18 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h82IDTQ8007034; Tue, 2 Sep 2003 14:13:31 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521060bbb7a88e3c1b7@[128.89.89.75]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 2 Sep 2003 14:11:26 -0400
To: Peter Sylvester <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail], [e-mail], [e-mail], [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 19:40 +0200 9/2/03, Peter Sylvester wrote:
>  > True, and in that case it would not make sense to put a pointer to
>>  that server in the AIA extension.
>
>Maybe not into the cert in question, but into the cert that
>may be used to authenticate a connection of a client to
>such a server in order to have a simple place for
>configuration.

I'm afraid this seems like too trivial a configuration issue to 
warrant a place in our standards.

>
>Alternatively, it could be in a SIA of a service cert.

see my comments to Trevor re 3379 assumptions about clients, in general.

>  > >On the other hand, you seem to restrict DVP to just just that model.
>>  >I think it has been mentioned several times that a DPV service
>>  >can be operated in exactly the same trust models as OCSP, i.e.,
>>  >as a CA provided service.
>>
>>  Is there a part of the DVP/DVD requirements RFC that suggests this
>>  model?  I don't recall.
>
>Wasn't one of the initial motiviations of the activity the
>problem that OCSP only creates 'negative' responses?

I don't see that cited in RFC 3379 as a motivation.

>
>Well, of course, there is a simple fix for OCSP.

you omitted the emoticon at the end of the sentence, e.g., :-) or ;-)

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82IEIgc038803 for <[e-mail]>; Tue, 2 Sep 2003 11:14:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82IEIna038802 for ietf-pkix-bks; Tue, 2 Sep 2003 11:14:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82IEHgc038792 for <[e-mail]>; Tue, 2 Sep 2003 11:14:17 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h82IDTQA007034; Tue, 2 Sep 2003 14:13:36 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0521060dbb7a8a922695@[128.89.89.75]>
In-Reply-To: <000401c36ed5$bacafb20$452f7ad5@laptoplk>
References: <000401c36ed5$bacafb20$452f7ad5@laptoplk>
Date: Tue, 2 Sep 2003 14:10:16 -0400
To: "Liaquat Khan" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: "'Faisal'" <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 10:04 +0100 8/30/03, Liaquat Khan wrote:
>Steve,
>
>I appreciate the difference you point out.  Although it's not a major
>issue for me, I still feel that the CA may want to direct RPs to the
>SCVP service it thinks is best for its certificates (whether or not the
>CA operates this SCVP service).

If one examines the various motivations given for creating a DPD/DPV 
standard, as documented in RFC 3379, many of them clearly do not 
align with this notion. OCSP is qualitatively different; the CA that 
issues a cert is authoritative for the revocation status of the cert. 
But DPV is about whether a cert is valid relative to a policy 
context, and the policy context is generally a function of the 
client's environment, and thus not generally known to the Issuer of 
the cert. That's why, in general, it would be inappropriate to put 
this info into an AIA extension.

>  Furthermore, whether RPs make use of this AIA extension or not is up to
>them.  This is the reality today with the use of AIA for OCSP.  Many
>PKIs require their RPs to ignore this field and go to a locally
>configured OCSP responder (4-corner model).

Again, OCSP is different, because the Issuer IS authoritative for the 
revocation status and that status is not affected by who asks the 
question.

>Also even if RPs choose their own SCVP service, their may be a need to
>relay the SCVP request on.  The current SCVP draft mentions server
>relaying as a possibility.  The information from AIA extension could in
>this instance be used to aid SCVP server relaying.

That's a fair point; not one I had considered. But it does not negate 
the objections noted above.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HsUgc037515 for <[e-mail]>; Tue, 2 Sep 2003 10:54:30 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82HsUqq037514 for ietf-pkix-bks; Tue, 2 Sep 2003 10:54:30 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HsSgc037489 for <[e-mail]>; Tue, 2 Sep 2003 10:54:29 -0700 (PDT) (envelope-from [e-mail])
Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h82HrjQ8005649; Tue, 2 Sep 2003 13:53:46 -0400 (EDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05210606bb7a789ef15b@[128.89.89.75]>
In-Reply-To:  <[e-mail] v.microsoft.com>
References:  <[e-mail] v.microsoft.com>
Date: Tue, 2 Sep 2003 13:50:09 -0400
To: "Trevor Freeman" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: "Faisal" <[e-mail]>, "Denis Pinkas" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:53 -0700 8/29/03, Trevor Freeman wrote:
>Steve,
>I don't see why the use of AIA is inappropriate for SCVP. It's just a
>hint like a lot of other things in certificates such as SKID. If the
>client has configured SCVP server it uses, it is free to ignore the
>information provided by the AIA, just as client with a locally
>configured OCSP server can ignore the OSCP pointer in the AIA extension
>today.
>Trevor
>
Trevor,

In part the question is what one views as the primary model for use 
of SCVP, and whether putting an SCBP pointer into a cert represents a 
significant opportunity for a new configuration management 
vulnerability, i.e., failure to populate a local SCVP pointer would 
allow the AIA value to be used instead.

Another matter is that SCVP (in its DPV role) is also designed for 
environments where the client is not presumed to be capable of 
processing certs. In that context, it does not seem to be useful to 
put in a pointer to a server, since the client would not be likely to 
be able to extract and make use of the pointer.

I have reread RFC 3379, the DPD/DPV requirements doc, and I see no 
references that would lead me to believe that a CA would be 
appropriate as a server for all RPs that might deal with certs issued 
by the CA.

What if several certs in a path each contained an SCVP server pointer 
in an AIA extension? While this would make sense for OCSP, it is not 
appropriate for SCVP.

Steve


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HKIgc032063 for <[e-mail]>; Tue, 2 Sep 2003 10:20:18 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82HKIbL032062 for ietf-pkix-bks; Tue, 2 Sep 2003 10:20:18 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp-ft3.fr.colt.net (smtp-ft3.fr.colt.net [213.41.78.27]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82HKFgc032033 for <[e-mail]>; Tue, 2 Sep 2003 10:20:16 -0700 (PDT) (envelope-from [e-mail])
Received: from alussinan.org (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft3.fr.colt.net with ESMTP id h82HKAW01252 for <[e-mail]>; Tue, 2 Sep 2003 19:20:10 +0200
Message-ID: <[e-mail]>
Date: Tue, 02 Sep 2003 19:20:09 +0200
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030811
X-Accept-Language: en, fr, en-us, ja
MIME-Version: 1.0
To: [e-mail]
Subject: Re: UTF8 revisited
References: <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lars Johansson wrote:
> ....but since RFC 3280 (and 2459) states that 
> all certificates issued after December 31
> 2003(!) MUST use UTF8 encoding of DN:s and 
> [....] I wonder if there´s a "easy" 
> way to find out which applications (operating 
> systems, webservers etc) that can handle
> these kinds of certs and - more importantly - 
> which applications that doesn't.
> 
> Will I have to do all the testing myself
> or does sombody on this list know about
> this thing?

In my opinion, maybe this requirement shouldn't have been blindly copied 
from RFC2459 to 3280 without some reflexion in the group about whether 
the recommandation was reasonnably in line with the market was about to 
accept, or voicing more that what used to be distant perspective in 
RFC2459 was going to happen soon after the release of RFC 3280.

I'm afraid the recommandation will end up being almost completely 
ignored. I even think that whatever respect for standards you have 
ignoring the instruction to systematically use only UTF-8 will probably 
be a lot more reasonnable.

Any PKI application released today really should have perfect support 
for UTF8String, but this is certainly not the case.
I'm not even talking about application that are still used a long time 
after release.

I'd distinguesh three degree of support of UTF-8 :
1 - perfect support
2 - support, but utf8string encoded field actually using characters 
outsite of ISO-8859-1 show some or many presentation bugs and problems
3 - blocking problems when using utf-8 fields

In the document about experiment of PKI interoperability in Japan that 
was publicised here some time ago, the description of the state of UTF-8 
support was AFAIR that they did some testing, but had to stop using it 
after that if they wanted to be able to get proper support in a 
reasonnable number of applications.
See here for the horror story :
http://www.ipa.go.jp/security/fy13/report/pki_interop/chalange2001.html
(almost every problem described there is an horror story in terms of 
respect of even basic PKI properties, not only utf8)

I haven't extensive information about the effective support, but from 
what I do know I'd expect the situation to be the following :
- Extremly few application in situation 1, certainly the case of the 
Microsoft tools, but not of many third party Windows based utilities
- An enormous number of application in situation 2, some of which having 
very, very annoying problems making any use of certificate in UTF-8 
containing non US-ASCII characters redhibitory.
- Some old but still used application in situation 3, for example the 
old Netscape 4.x that have very little public use left, but are still 
the standard of some corporate users.

In most case, situation 2 will be the result of a badly developed 
application using a utf8string clean API (this is the case of most 
popular API : Microsoft Crypto API, OpenSSL, NSS, etc...).
This case should be considered *the* usual situation.

Fully testing the applications will also be extremly long.
For example Mozilla might initially seem to support utf8 properly, but 
they are several presentation bugs (view details in certificate 
manager), and maybe some bugs are more severe than that.




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82Dghgc012613 for <[e-mail]>; Tue, 2 Sep 2003 06:42:43 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82DghTV012612 for ietf-pkix-bks; Tue, 2 Sep 2003 06:42:43 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from tessla.levonline.com (ns3.levonline.com [217.70.32.4]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82Dgfgc012606 for <[e-mail]>; Tue, 2 Sep 2003 06:42:41 -0700 (PDT) (envelope-from [e-mail])
Received: from localhost (localhost [[UNIX: localhost]]) by tessla.levonline.com (8.11.6/8.11.6) id h82DguL04527; Tue, 2 Sep 2003 15:42:56 +0200
Message-Id: <[e-mail]>
Subject: UTF8 revisited
Content-Transfer-Encoding: 8bit
Date: Tue, 02 Sep 2003 15:42:56 +0300
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
X-Originating-IP: [137.61.234.225]
From: Lars Johansson <[e-mail]>
User-Agent: IMHO/0.98.3 (Webmail for Roxen)
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>

Sorry to bother you with this old thread...

....but since RFC 3280 (and 2459) states that 
all certificates issued after December 31
2003(!) MUST use UTF8 encoding of DN:s and 
I'm currently in the process of updating an 
old CA service, I wonder if there´s a "easy" 
way to find out which applications (operating 
systems, webservers etc) that can handle
these kinds of certs and - more importantly - 
which applications that doesn't.

Will I have to do all the testing myself
or does sombody on this list know about
this thing?

Kind regards!
_________________________________________________
Lars Johansson | Consultant
[e-mail] | www.omegapoint.se
tel [phone] | fax [phone]
Omegapoint AB


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82DA4gc010792 for <[e-mail]>; Tue, 2 Sep 2003 06:10:04 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h82DA4wp010791 for ietf-pkix-bks; Tue, 2 Sep 2003 06:10:04 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp1.fre.skanova.net (smtp1.fre.skanova.net [195.67.227.94]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h82D9xgc010761; Tue, 2 Sep 2003 06:10:02 -0700 (PDT) (envelope-from [e-mail])
Received: from arport (t7o913p37.telia.com [213.64.26.37]) by smtp1.fre.skanova.net (8.12.9/8.12.9) with SMTP id h82D9tit005555; Tue, 2 Sep 2003 15:09:56 +0200 (CEST)
Message-ID: <001501c37153$4ff1d960$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Standards for Web-signing
Date: Tue, 2 Sep 2003 15:07:33 +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 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
Sender: [e-mail]
Precedence: 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 just wanted to know the status of possible standardization
efforts regarding signing on-line forms etc. on web.  As web-signing
is a core function of many e-governments when communicating
with their citizens it seems that this should be standardized if
not already is.

Pointers are welcome.  Off-list or on-list.

rgds
Anders Rundgren


Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h819CGgc076210 for <[e-mail]>; Mon, 1 Sep 2003 02:12:17 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h819CGNc076209 for ietf-pkix-bks; Mon, 1 Sep 2003 02:12:16 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h819CEgc076174 for <[e-mail]>; Mon, 1 Sep 2003 02:12:14 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA15266; Mon, 1 Sep 2003 11:17:31 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id LAA16402; Mon, 1 Sep 2003 11:13:05 +0200
Message-ID: <[e-mail]>
Date: Mon, 01 Sep 2003 11:12:07 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
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>

Peter,

>>"Using an extension to indicate the location of a SCVP service would be a 
>>pointer to a "useful" service in the same way like a CA could indicate the 
>>location of useful Time-Stamping Units (TSUs). So, if we accept this 
>>extension, we will have to accept pointers to TSUs and in the future 
>>pointers to some other "useful" services like an *electronic* signature 
>>validation service, and maybe more.

> Having a AIA extension for a TSA or some other service
> in a certificate seeems quite useful but not as you see it.
                                            ^^^
I guess you mean :                        "not only"

Denis

> In fact, if the access to such a service is made using
> an 'access control cert', it seems conveniant to configure the
> service access point in that cert, thus avoiding additional
> configuration. On the other hand, you can also add such
> an extension in a cert that is part of your traustbase,
> for example like in the SIA of a TSA which is already part of
> the current text (as far as I remember).





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h819BYgc076054 for <[e-mail]>; Mon, 1 Sep 2003 02:11:34 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h819BYeW076052 for ietf-pkix-bks; Mon, 1 Sep 2003 02:11:34 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h819BXgc076041 for <[e-mail]>; Mon, 1 Sep 2003 02:11:33 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA22824; Mon, 1 Sep 2003 11:11:32 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 1 Sep 2003 11:11:32 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h819BVW28984; Mon, 1 Sep 2003 11:11:31 +0200 (MEST)
Date: Mon, 1 Sep 2003 11:11:31 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> The original request was for XKMS, then moved to SCVP.
> Is it now moving to DVP ?

I respond to faisal's question regarding SCVP which is 
an attempt to respond to the DPV requirements. 



Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h819Angc075877 for <[e-mail]>; Mon, 1 Sep 2003 02:10:49 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h819AnHj075876 for ietf-pkix-bks; Mon, 1 Sep 2003 02:10:49 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h819Algc075849 for <[e-mail]>; Mon, 1 Sep 2003 02:10:48 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA14840; Mon, 1 Sep 2003 11:16:06 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id LAA16393; Mon, 1 Sep 2003 11:11:40 +0200
Message-ID: <[e-mail]>
Date: Mon, 01 Sep 2003 11:10:43 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
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>

Peter,

>>OCSP is explicitly an alternative to CRLs, and CRLs are managed by 
>>CAs. Thus a CA issuing a cert can reasonably choose to insert a 
>>pointer in AIA to an OCSP server that the CA (or its designee) 
>>operates, just as it would have inserted a pointer to a repository 
>>for retrieving CRLs signed by that CA.  In contrast, the choice of an 
>>SCVP server is a local matter, relative to an RP, and thus it would 
>>generally be inappropriate for a CA to direct an RP to an SCVP server.
> 
> 
> Steve, 
> 
> you are mentioning only one of the possible usages of OCSP. In the
> third trust model you have an OCSP server trusted via local procedures.
> 
> On the other hand, you seem to restrict DVP to just just that model.

DVP is not SCVP and is not XKMS either.

The original request was for XKMS, then moved to SCVP.
Is it now moving to DVP ?

Is there a request for one extension or for three extensions ?

Denis

> I think it has been mentioned several times that a DPV service
> can be operated in exactly the same trust models as OCSP, i.e.,
> as a CA provided service. 
> 
> As M.M. says, I'd vote for if there would be a straw poll.
> 
> 




Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h81983gc075245 for <[e-mail]>; Mon, 1 Sep 2003 02:08:03 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h81983dh075244 for ietf-pkix-bks; Mon, 1 Sep 2003 02:08:03 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h81981gc075232 for <[e-mail]>; Mon, 1 Sep 2003 02:08:02 -0700 (PDT) (envelope-from [e-mail])
Received: from chandon.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA22779; Mon, 1 Sep 2003 11:08:00 +0200 (MET DST)
Received: from chandon.edelweb.fr (chandon.edelweb.fr [193.51.14.162]) by edelweb.fr (nospam/1.7); Mon, 1 Sep 2003 11:08:01 +0200 (MET DST)
Received: (from peter@localhost) by chandon.edelweb.fr (8.11.7+Sun/8.11.7) id h8197xe28977; Mon, 1 Sep 2003 11:07:59 +0200 (MEST)
Date: Mon, 1 Sep 2003 11:07:59 +0200 (MEST)
From: Peter Sylvester <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [e-mail]
X-Sun-Charset: US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> "Using an extension to indicate the location of a SCVP service would be a 
> pointer to a "useful" service in the same way like a CA could indicate the 
> location of useful Time-Stamping Units (TSUs). So, if we accept this 
> extension, we will have to accept pointers to TSUs and in the future 
> pointers to some other "useful" services like an *electronic* signature 
> validation service, and maybe more.

Having a AIA extension for a TSA or some other service
in a certificate seeems quite useful but not as you see it. 
In fact, if the access to such a service is made using
an 'access control cert', it seems conveniant to configure the
service access point in that cert, thus avoiding additional
configuration. On the other hand, you can also add such
an extension in a cert that is part of your traustbase,
for example like in the SIA of a TSA which is already part of
the current text (as far as I remember).





Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h817UAgc059157 for <[e-mail]>; Mon, 1 Sep 2003 00:30:11 -0700 (PDT) (envelope-from [e-mail])
Received: (from majordom@localhost) by above.proper.com (8.12.9/8.12.9/Submit) id h817UAKG059144 for ietf-pkix-bks; Mon, 1 Sep 2003 00:30:10 -0700 (PDT)
X-Authentication-Warning: above.proper.com: majordom set sender to [e-mail] using -f
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h817U3gc059049 for <[e-mail]>; Mon, 1 Sep 2003 00:30:06 -0700 (PDT) (envelope-from [e-mail])
Received: from clbull.frcl.bull.fr (IDENT:[e-mail] [129.182.8.31]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA31362; Mon, 1 Sep 2003 09:35:19 +0200
Received: from bull.net (frcls4013.frcl.bull.fr [129.182.108.120]) by clbull.frcl.bull.fr (8.9.3/8.9.3) with ESMTP id JAA14743; Mon, 1 Sep 2003 09:30:49 +0200
Message-ID: <[e-mail]>
Date: Mon, 01 Sep 2003 09:29:51 +0200
From: Denis Pinkas <[e-mail]>
Organization: Bull SA.
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0
X-Accept-Language: en-us, en, fr
MIME-Version: 1.0
To: Trevor Freeman <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
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>

Trevor,

> Denis,
> The question of what is or is not useful information is down to your
> point of view. Just because you don't value it, does not mean others
> will view it likewise.

This is not an argumentation. Please, do not use terms like "your point of 
view" or "other may view it otherwise", but concentrate on the arguments 
raised in the response to Faisal, and attempt to reply to the issue that was 
raised there. That e-mail stated:

"Using an extension to indicate the location of a SCVP service would be a 
pointer to a "useful" service in the same way like a CA could indicate the 
location of useful Time-Stamping Units (TSUs). So, if we accept this 
extension, we will have to accept pointers to TSUs and in the future 
pointers to some other "useful" services like an *electronic* signature 
validation service, and maybe more.

Either we open the door to "useful" services like SCVP, or we don't."

Denis

> Trevor
>  
> 
> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Friday, August 29, 2003 10:05 AM
> To: Trevor Freeman
> Cc: Stephen Kent; Faisal; [e-mail]
> Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
> 
> Trevor,
> 
> In my reply to Faisal, there are other arguments which basically support
> 
> Steve's position. We should refrain to include "a lot of other things"
> in 
> public key certificates, otherwise we would open the door to a lot of 
> extensions which are not directly related to CAs, like CA best partners,
> low 
> rates for insurances if you have a certificate from that CA, best
> refinance 
> conditions if you have a certificate from that CA, ...
> 
> This would look like spam.
> 
> Denis
> 
> 
> BTW, we are awaiting your explanations (and possibly new text) about the
> 
> differences between the concept of validation policy, as included in RFC
> 
> 3379, and the same wording as used in the SCVP draft.
> 
> 
> 
>>Steve,
>>I don't see why the use of AIA is inappropriate for SCVP. It's just a
>>hint like a lot of other things in certificates such as SKID. If the
>>client has configured SCVP server it uses, it is free to ignore the
>>information provided by the AIA, just as client with a locally
>>configured OCSP server can ignore the OSCP pointer in the AIA
> 
> extension
> 
>>today.
>>Trevor
>>
>>-----Original Message-----
>>From: [e-mail]
> 
> [mailto:[e-mail]]
> 
>>On Behalf Of Stephen Kent
>>Sent: Thursday, August 28, 2003 6:08 PM
>>To: Faisal
>>Cc: Denis Pinkas; [e-mail]
>>Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
>>
>>
>>At 10:24 +0500 8/28/03, Faisal wrote:
>>
>>
>>>Denis,
>>>
>>>- Why is SCVP considered not part of a CA service and
>>>OCSP is?
>>>- Where is this defined?
>>>- Also whether the SCVP service is provided by a CA or provided by
>>
> some
> 
>>>other trusted third party, would it still not be a good idea for the
>>
> CA
> 
>>>to identify how to locate the responsible SCVP service for its
>>>certificates (assuming there is one)?
>>>- Why does it matter who is providing the service?
>>>
>>>I don't understand
>>>
>>>Regards,
>>>F a i s a l
>>
>>
>>OCSP is explicitly an alternative to CRLs, and CRLs are managed by 
>>CAs. Thus a CA issuing a cert can reasonably choose to insert a 
>>pointer in AIA to an OCSP server that the CA (or its designee) 
>>operates, just as it would have inserted a pointer to a repository 
>>for retrieving CRLs signed by that CA.  In contrast, the choice of an 
>>SCVP server is a local matter, relative to an RP, and thus it would 
>>generally be inappropriate for a CA to direct an RP to an SCVP server.
>>
>>Steve
>>
> 
> 
> 
>