Subject: RE: OCSP response pre-production

From: "Florian Oelmaier" <[email-masked]>
Date: 30 Sep 2003 17:45:26 -0000

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" <[email-masked]> 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
> 
> 
> 
> 
>

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 30 Sep 2003 11:27:52 -0700

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

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 30 Sep 2003 11:43:51 -0700

Florian,

Responses embedded below.

Mike

> -----Original Message-----
> From: Florian Oelmaier [mailto:[email-masked]]
> Sent: Tuesday, September 30, 2003 10:45 AM
> To: [email-masked]
> Cc: [email-masked]
> 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

---

From: "Florian Oelmaier" <[email-masked]>
Date: Tue, 30 Sep 2003 21:10:47 +0200

> 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

---

From: "Florian Oelmaier" <[email-masked]>
Date: Tue, 30 Sep 2003 22:20:19 +0200

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

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

> 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

---

From: "Michael Myers" <[email-masked]>
Date: Tue, 30 Sep 2003 13:56:51 -0700

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

---

From: "Florian Oelmaier" <[email-masked]>
Date: Tue, 30 Sep 2003 23:06:34 +0200

> Michael Myers

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

---

From: Paul Hoffman / IMC <[email-masked]>
Date: Tue, 30 Sep 2003 15:34:11 -0700

At 9:10 PM +0200 9/30/03, Florian Oelmaier wrote:
>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

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

--Paul Hoffman, Director

Date: Tue, 30 Sep 2003 15:34:11 -0700
To: "Florian Oelmaier" <[email-masked]>, <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: OCSP response pre-production
Cc: <[email-masked]>
Sender: [email-masked]

At 9:10 PM +0200 9/30/03, Florian Oelmaier wrote:
>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

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

--Paul Hoffman, Director

From: "Miguel Rodriguez" <[email-masked]>
To: "'Florian Oelmaier'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 16:26:21 -0500
Importance: Normal
Sender: [email-masked]

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
  
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Julien Stern
> > Sent: Tuesday, September 30, 2003 6:26 PM
> > To: [email-masked]
> > 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
> > >
> > >
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of Denis Pinkas
> > > > Sent: Tuesday, September 30, 2003 12:41 AM
> > > > To: Florian Oelmaier
> > > > Cc: [email-masked]
> > > > 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.]
> > > >
> > > >
> > > >
> > >
> > >
> >

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 16:17:41 -0500
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Florian Oelmaier
> Sent: Tuesday, September 30, 2003 2:05 PM
> To: 'Julien Stern'; [email-masked]
> 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
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Julien Stern
> > Sent: Tuesday, September 30, 2003 6:26 PM
> > To: [email-masked]
> > 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
> >
> >

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 23:06:34 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

-- 
Florian Oelmaier
SyTrust

From: "Michael Myers" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 13:56:51 -0700
Importance: Normal
Sender: [email-masked]

Michael Myers
-------------

Florian Oelmaier
----------------

Florian,

Mike

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 22:20:19 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

If no: 

If yes:

 

-- 
Florian Oelmaier
SyTrust

From: "Florian Oelmaier" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 21:10:47 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

-- 
Florian Oelmaier
SyTrust

From: "Florian Oelmaier" <[email-masked]>
To: "'Julien Stern'" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 21:05:26 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julien Stern
> Sent: Tuesday, September 30, 2003 6:26 PM
> To: [email-masked]
> 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
> > 
> > 
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Denis Pinkas
> > > Sent: Tuesday, September 30, 2003 12:41 AM
> > > To: Florian Oelmaier
> > > Cc: [email-masked]
> > > 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.]
> > > 
> > > 
> > > 
> > 
> > 
> 

From: "Michael Myers" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 11:43:51 -0700
Importance: Normal
Sender: [email-masked]

Florian,

Mike

Mike

Date: Tue, 30 Sep 2003 11:27:52 -0700
To: "Florian Oelmaier" <[email-masked]>, <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: OCSP response pre-production
Cc: [email-masked]
Sender: [email-masked]

--Paul Hoffman, Director

Date: 30 Sep 2003 17:45:26 -0000
From: "Florian Oelmaier" <[email-masked]>
To: <[email-masked]>
CC: [email-masked]
Subject: RE: OCSP response pre-production
Sender: [email-masked]

Michael,

-- 
Florian Oelmaier
SyTrust

> want to they can have that overridden on a per-request basis.

From: "Michael Myers" <[email-masked]>
To: "Ambarish Malpani" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 10:30:02 -0700
Importance: Normal
Sender: [email-masked]

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

> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Tuesday, September 30, 2003 9:42 AM
> To: 'Michael Myers'; [email-masked]
> 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
>
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of
> Michael Myers
> > Sent: Tuesday, September 30, 2003 8:08 AM
> > To: [email-masked]
> > and thought I might ask if it's possible we could all get
> > behind the following simple fix.
> >
> >
> > Thus, essentially, requestors can set "nonce always" but if
> > they want to they can have that overridden on a
> per-request basis.
> >
> > Opinions?
> >
> > Mike
> >
> >
>
>

From: "Ambarish Malpani" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 09:42:18 -0700
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Michael Myers
> Sent: Tuesday, September 30, 2003 8:08 AM
> To: [email-masked]
> and thought I might ask if it's possible we could all get 
> behind the following simple fix.
> 
> 
> Thus, essentially, requestors can set "nonce always" but if 
> they want to they can have that overridden on a per-request basis.
> 
> Opinions?
> 
> Mike
> 
> 

From: "Julien Stern" <[email-masked]>
Date: Tue, 30 Sep 2003 18:26:16 +0200
To: [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

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
> 
> 
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Denis Pinkas
> > Sent: Tuesday, September 30, 2003 12:41 AM
> > To: Florian Oelmaier
> > Cc: [email-masked]
> > 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.]
> > 
> > 
> > 
> 
> 

From: "Ambarish Malpani" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 08:23:33 -0700
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Tuesday, September 30, 2003 12:41 AM
> To: Florian Oelmaier
> Cc: [email-masked]
> 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.]
> 
> 
> 

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 08:08:03 -0700
Importance: Normal
Sender: [email-masked]

All,

Opinions?

Mike

From: "Faisal Maqsood" <[email-masked]>
To: <[email-masked]>
Subject: Self-Issued certificate requirements?
Date: Tue, 30 Sep 2003 19:03:11 +0500
Organization: Ascertia Ltd
Sender: [email-masked]

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

Date: Tue, 30 Sep 2003 14:00:15 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: OCSP response pre-production
Cc: [email-masked]
Sender: [email-masked]

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. 

From: "Anders Rundgren" <[email-masked]>
To: "Nakagawa" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: request for reviewing our interoperability experiment report
Date: Tue, 30 Sep 2003 13:23:43 +0200
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
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

Date: 30 Sep 2003 10:17:56 -0000
From: "Florian Oelmaier" <[email-masked]>
To: "Manger, James H" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Sender: [email-masked]

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" <[email-masked]> 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).
> 
> 
> 
> Sent: Tuesday, 30 September 2003 9:58 AM
> To: 'Michael Myers'; [email-masked]
> > 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
> 
> 
> 
> 
> 

Date: Tue, 30 Sep 2003 09:40:49 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Florian Oelmaier <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 13:03:23 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
Sent: Tuesday, 30 September 2003 9:58 AM
To: 'Michael Myers'; [email-masked]
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

content-class: urn:content-classes:message
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 15:18:04 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
Sent: Monday, 29 September 2003 8:07 PM
To: Deacon, Alex
Cc: [email-masked]
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".

Date: Mon, 29 Sep 2003 17:21:48 -0700
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Man-in-the-middle attacks (was: OCSP response pre-production)
Sender: [email-masked]

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

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Tue, 30 Sep 2003 01:58:17 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> 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

Content-class: urn:content-classes:message
Subject: RE: OCSP response pre-production
Date: Mon, 29 Sep 2003 16:40:20 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Manger, James H" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Mon, 29 Sep 2003 12:14:06 -0700
Importance: Normal
Sender: [email-masked]

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

From: "Florian Oelmaier" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Mon, 29 Sep 2003 18:06:30 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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

Date: Mon, 29 Sep 2003 17:44:52 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Florian Oelmaier <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

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

From: "Florian Oelmaier" <[email-masked]>
To: "'Julien Stern'" <[email-masked]>
Cc: <[email-masked]>
Subject: [offlist] RE: Not using nonce does not necessarily allow replay attacks ...
Date: Mon, 29 Sep 2003 17:43:00 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> 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

From: "Florian Oelmaier" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Manger, James H'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Mon, 29 Sep 2003 17:15:12 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-x509-ipaddr-as-extn-03.txt
Date: Mon, 29 Sep 2003 10:57:31 -0400
Sender: [email-masked]

--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 [email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Mon, 29 Sep 2003 17:49:01 +0300
From: Vadim Fedukovich <[email-masked]>
To: [email-masked]
Cc: Julien Stern <[email-masked]>
Subject: Re: Not using nonce does not necessarily allow replay attacks ...
Sender: [email-masked]

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

Date: Mon, 29 Sep 2003 12:07:02 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Deacon, Alex" <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP response pre-production (was RE: POLL:  Use of nonces in OCSP)
Sender: [email-masked]

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
>>From: Russ Housley [mailto:[email-masked]]
>>Sent: Friday, September 26, 2003 9:31 AM
>>To: Deacon, Alex
>>Cc: [email-masked]
>>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
>>>
>>>
>>>
>>>
>>>
>>>>From: Michael Myers [mailto:[email-masked]]
>>>>Sent: Wednesday, September 24, 2003 7:38 AM
>>>>To: [email-masked]
>>>>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
>>>>
>>>>
>>>
> 

Date: Mon, 29 Sep 2003 12:03:16 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: "Manger, James H" <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP response pre-production
Sender: [email-masked]

(...)

[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

Date: Mon, 29 Sep 2003 18:50:47 +0900
From: Nakagawa <[email-masked]>
To: [email-masked]
Subject: request for reviewing our interoperability experiment report
Cc: [email-masked]
Sender: [email-masked]

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

From: "Julien Stern" <[email-masked]>
Date: Mon, 29 Sep 2003 11:26:17 +0200
To: [email-masked]
Subject: Not using nonce does not necessarily allow replay attacks ...
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: RE: OCSP response pre-production
Date: Mon, 29 Sep 2003 10:36:25 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
Sent: Saturday, 27 September 2003 7:29 AM
To: 'Deacon, Alex'; 'Michael Myers'; 'David Engberg'
Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; [email-masked]; '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

> > Sent: Friday, September 26, 2003 10:37 AM
> > To: 'Michael Myers'; 'David Engberg'
> > Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; [email-masked]; 'Russ
> > Housley'; 'Stephen Kent'; 'Tim Polk'
> > [...]
> > > 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
> > 
> 

Date: Sun, 28 Sep 2003 09:25:11 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Vadim Fedukovich <[email-masked]>
CC: [email-masked]
Subject: Re: would a key-less responder make better security
Sender: [email-masked]

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.

Date: Sun, 28 Sep 2003 23:25:50 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: would a key-less responder make better security
Cc: [email-masked]
Sender: [email-masked]

Vadim Fedukovich <[email-masked]> 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.

Date: Sun, 28 Sep 2003 09:11:05 +0300
From: Vadim Fedukovich <[email-masked]>
To: [email-masked]
Cc: David Engberg <[email-masked]>
Subject: Re: would a key-less responder make better security
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: WG last call re draft-pkix-acpolicies-extn-03.txt
Date: Sat, 27 Sep 2003 20:05:35 -0700
Importance: Normal
Sender: [email-masked]

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

Date: Sat, 27 Sep 2003 12:53:47 -0700
To: "Florian Oelmaier" <[email-masked]>, "'Deacon, Alex'" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, "'Michael Myers'" <[email-masked]>, "'David Engberg'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>, <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: OCSP response pre-production
Cc: "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "'Tim Polk'" <[email-masked]>
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Sat, 27 Sep 2003 12:46:53 -0700
Importance: Normal
Sender: [email-masked]

"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

From: "Florian Oelmaier" <[email-masked]>
To: "'Paul Hoffman / IMC'" <[email-masked]>, "'Deacon, Alex'" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, "'Michael Myers'" <[email-masked]>, "'David Engberg'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>, <[email-masked]>
Cc: "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "'Tim Polk'" <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Sat, 27 Sep 2003 21:09:17 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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

Date: Sat, 27 Sep 2003 10:54:19 -0700
To: "Deacon, Alex" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, Michael Myers <[email-masked]>, David Engberg	 <[email-masked]>, [email-masked], Ambarish Malpani	 <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: OCSP response pre-production
Cc: Russ Housley <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
Sender: [email-masked]

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

Date: Sat, 27 Sep 2003 10:53:48 -0700
To: "Deacon, Alex" <[email-masked]>, "'Russ Housley'" <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: OCSP response pre-production (was RE: POLL:  Use of nonces in OCS 	P)
Cc: [email-masked]
Sender: [email-masked]

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

From: "Miguel Rodriguez" <[email-masked]>
To: "'Julien Pierre'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP and Nonces
Date: Fri, 26 Sep 2003 19:37:02 -0500
Importance: Normal
Sender: [email-masked]

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 17:51:59 -0500
Importance: Normal
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: "Deacon, Alex" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 15:25:17 -0700
Importance: Normal
Sender: [email-masked]

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

> From: Deacon, Alex [mailto:[email-masked]]
> Sent: Friday, September 26, 2003 3:13 PM
> To: 'Michael Myers'; Deacon, Alex; [email-masked]
> 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
>
>
> > From: Michael Myers [mailto:[email-masked]]
> > Sent: Friday, September 26, 2003 2:35 PM
> > To: Deacon, Alex; [email-masked]
> > 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
> >
> >
> >
> >
> > > From: Deacon, Alex [mailto:[email-masked]]
> > > Sent: Friday, September 26, 2003 2:09 PM
> > > To: 'Ryan M. Hurst'; Paul Hoffman / IMC; Michael
> > > Myers; David Engberg;
> > > [email-masked]; Ambarish Malpani; [email-masked]
> > > Cc: Russ Housley; Stephen Kent; Tim Polk
> > > 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
> >
> >
>
>

From: "Deacon, Alex" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, "Deacon, Alex" <[email-masked]>, [email-masked]
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 15:12:45 -0700
Sender: [email-masked]

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

> From: Michael Myers [mailto:[email-masked]]
> Sent: Friday, September 26, 2003 2:35 PM
> To: Deacon, Alex; [email-masked]
> 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
> 
> 
> 
> 
> > From: Deacon, Alex [mailto:[email-masked]]
> > Sent: Friday, September 26, 2003 2:09 PM
> > To: 'Ryan M. Hurst'; Paul Hoffman / IMC; Michael
> > Myers; David Engberg;
> > [email-masked]; Ambarish Malpani; [email-masked]
> > Cc: Russ Housley; Stephen Kent; Tim Polk
> > 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
> 
> 

From: "Michael Myers" <[email-masked]>
To: "Deacon, Alex" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 14:35:29 -0700
Importance: Normal
Sender: [email-masked]

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

> From: Deacon, Alex [mailto:[email-masked]]
> Sent: Friday, September 26, 2003 2:09 PM
> To: 'Ryan M. Hurst'; Paul Hoffman / IMC; Michael
> Myers; David Engberg;
> [email-masked]; Ambarish Malpani; [email-masked]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> 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

From: "Florian Oelmaier" <[email-masked]>
To: "'Deacon, Alex'" <[email-masked]>, "'Michael Myers'" <[email-masked]>, "'David Engberg'" <[email-masked]>
Cc: "'Ryan M. Hurst'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>, <[email-masked]>, "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "'Tim Polk'" <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 23:29:00 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> 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

> > Sent: Friday, September 26, 2003 10:37 AM
> > To: 'Michael Myers'; 'David Engberg'
> > Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; [email-masked]; 'Russ
> > Housley'; 'Stephen Kent'; 'Tim Polk'
> > [...]
> > > 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
> > 
> 

From: "Deacon, Alex" <[email-masked]>
To: "'Florian Oelmaier'" <[email-masked]>, "'Michael Myers'" <[email-masked]>, "'David Engberg'" <[email-masked]>
Cc: "'Ryan M. Hurst'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>, [email-masked], "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "'Tim Polk'" <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 14:11:40 -0700
Sender: [email-masked]

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

> Sent: Friday, September 26, 2003 10:37 AM
> To: 'Michael Myers'; 'David Engberg'
> Cc: 'Ryan M. Hurst'; 'Ambarish Malpani'; [email-masked]; 'Russ
> Housley'; 'Stephen Kent'; 'Tim Polk'
> [...]
> > 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
> 

From: "Deacon, Alex" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>, Paul Hoffman / IMC <[email-masked]>, Michael Myers <[email-masked]>, David Engberg <[email-masked]>, [email-masked], Ambarish Malpani <[email-masked]>, [email-masked]
Cc: Russ Housley <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 14:08:51 -0700
Sender: [email-masked]

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

> From: Ryan M. Hurst [mailto:[email-masked]]
> Sent: Friday, September 26, 2003 10:01 AM
> To: Paul Hoffman / IMC; Michael Myers; David Engberg;
> [email-masked]; Ambarish Malpani; [email-masked]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> I concur with this, er "me too" :)
> 
> Ryan
> 
> From: Paul Hoffman / IMC [mailto:[email-masked]] 
> Sent: Friday, September 26, 2003 9:40 AM
> To: Michael Myers; Ryan M. Hurst; David Engberg; [email-masked];
> Ambarish Malpani; [email-masked]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> 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

From: "Deacon, Alex" <[email-masked]>
To: "'Russ Housley'" <[email-masked]>, "Deacon, Alex" <[email-masked]>
Cc: [email-masked]
Subject: OCSP response pre-production (was RE: POLL:  Use of nonces in OCS P)
Date: Fri, 26 Sep 2003 13:55:11 -0700
Sender: [email-masked]

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

> From: Russ Housley [mailto:[email-masked]]
> Sent: Friday, September 26, 2003 9:31 AM
> To: Deacon, Alex
> Cc: [email-masked]
> 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
> >
> >
> >
> >
> > > From: Michael Myers [mailto:[email-masked]]
> > > Sent: Wednesday, September 24, 2003 7:38 AM
> > > To: [email-masked]
> > > 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
> > >
> > >
> 

Date: Fri, 26 Sep 2003 21:15:20 +0100
From: Dr Stephen N Henson <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: Michael Myers <[email-masked]>, "Ryan M. Hurst" <[email-masked]>, David Engberg <[email-masked]>, [email-masked], Ambarish Malpani <[email-masked]>, [email-masked], Russ Housley <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
Subject: Re: OCSP response pre-production
Sender: [email-masked]

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: [email-masked], PGP key: via homepage.

Content-class: urn:content-classes:message
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 12:41:20 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "Michael Myers" <[email-masked]>, "David Engberg" <[email-masked]>
Cc: "Ambarish Malpani" <[email-masked]>, <[email-masked]>, "Russ Housley" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Tim Polk" <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Florian Oelmaier
Sent: Friday, September 26, 2003 10:37 AM
To: 'Michael Myers'; 'David Engberg'
Cc: Ryan M. Hurst; 'Ambarish Malpani'; [email-masked]; '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

Date: Fri, 26 Sep 2003 12:34:02 -0700
To: Dr Stephen Henson <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: OCSP response pre-production
Cc: Michael Myers <[email-masked]>, "Ryan M. Hurst" <[email-masked]>, David Engberg <[email-masked]>, [email-masked], Ambarish Malpani <[email-masked]>, [email-masked], Russ Housley <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 26 Sep 2003 15:26:59 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet, Ltd.
To: Vadim Fedukovich <[email-masked]>
CC: [email-masked]
Subject: Re: would a key-less responder make better security
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 12:20:25 -0700
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> David Engberg
> Sent: Friday, September 26, 2003 10:54 AM
> To: Michael Myers
> Cc: Ryan M. Hurst; [email-masked]; Ambarish Malpani;
> [email-masked]; 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

Date: Fri, 26 Sep 2003 21:16:33 +0300
From: Vadim Fedukovich <[email-masked]>
To: [email-masked]
Subject: would a key-less responder make better security (was: POLL: Use of nonces in OCSP)
Sender: [email-masked]

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

Date: Fri, 26 Sep 2003 13:54:26 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet, Ltd.
To: Michael Myers <[email-masked]>
CC: "Ryan M. Hurst" <[email-masked]>, [email-masked], Ambarish Malpani <[email-masked]>, [email-masked], Russ Housley <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
Subject: Re: OCSP response pre-production
Sender: [email-masked]

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

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, "'David Engberg'" <[email-masked]>
Cc: "'Ryan M. Hurst'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>, <[email-masked]>, "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "'Tim Polk'" <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 19:37:19 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

[...]

> 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

Content-class: urn:content-classes:message
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 10:27:57 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Dr Stephen Henson" <[email-masked]>, "Paul Hoffman / IMC" <[email-masked]>
Cc: "Michael Myers" <[email-masked]>, "David Engberg" <[email-masked]>, <[email-masked]>, "Ambarish Malpani" <[email-masked]>, <[email-masked]>, "Russ Housley" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Tim Polk" <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Friday, September 26, 2003 10:22 AM
To: Paul Hoffman / IMC
Cc: Michael Myers; Ryan M. Hurst; David Engberg; [email-masked];
Ambarish Malpani; [email-masked]; 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: [email-masked], PGP key: via homepage.

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>
Cc: "Ryan M. Hurst" <[email-masked]>, <[email-masked]>, "Ambarish Malpani" <[email-masked]>, <[email-masked]>, "Russ Housley" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Tim Polk" <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 10:30:28 -0700
Importance: Normal
Sender: [email-masked]

> From: David Engberg [mailto:[email-masked]]
> . . .
> 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

From: "Miguel Rodriguez" <[email-masked]>
To: <[email-masked]>
Subject: OCSP and Nonces
Date: Fri, 26 Sep 2003 12:21:34 -0500
Importance: Normal
Sender: [email-masked]

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: +52 (55) 5339-0158
Fax: +52 (55) 5339 5829
=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:[email-masked]">
<!--[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'>+52 (55) 5339 =
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--

Date: Fri, 26 Sep 2003 18:22:25 +0100
From: Dr Stephen Henson <[email-masked]>
To: Paul Hoffman / IMC <[email-masked]>
CC: Michael Myers <[email-masked]>, "Ryan M. Hurst" <[email-masked]>, David Engberg <[email-masked]>, [email-masked], Ambarish Malpani <[email-masked]>, [email-masked], Russ Housley <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
Subject: Re: OCSP response pre-production
Sender: [email-masked]

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: [email-masked], PGP key: via homepage.

Content-class: urn:content-classes:message
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 10:10:07 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "Michael Myers" <[email-masked]>, "David Engberg" <[email-masked]>, "Ambarish Malpani" <[email-masked]>, <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Tim Polk" <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Friday, September 26, 2003 10:07 AM
To: 'Michael Myers'; Ryan M. Hurst; 'David Engberg'; 'Ambarish Malpani';
[email-masked]
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

> From: Michael Myers [mailto:[email-masked]] 
> Sent: Friday, September 26, 2003 5:54 PM
> To: Ryan M. Hurst; David Engberg; [email-masked]; 
> Ambarish Malpani; [email-masked]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> 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
> 
> 
> 
> 

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, "'David Engberg'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>, <[email-masked]>
Cc: "'Russ Housley'" <[email-masked]>, "'Stephen Kent'" <[email-masked]>, "'Tim Polk'" <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 19:06:44 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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

> From: Michael Myers [mailto:[email-masked]] 
> Sent: Friday, September 26, 2003 5:54 PM
> To: Ryan M. Hurst; David Engberg; [email-masked]; 
> Ambarish Malpani; [email-masked]
> Cc: Russ Housley; Stephen Kent; Tim Polk
> 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--

Content-class: urn:content-classes:message
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 10:05:56 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "David Engberg" <[email-masked]>, "Michael Myers" <[email-masked]>
Cc: <[email-masked]>, "Ambarish Malpani" <[email-masked]>, <[email-masked]>, "Russ Housley" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Tim Polk" <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Friday, September 26, 2003 9:49 AM
To: Michael Myers
Cc: Ryan M. Hurst; [email-masked]; Ambarish Malpani;
[email-masked]; 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.

Content-class: urn:content-classes:message
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 10:00:39 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Paul Hoffman / IMC" <[email-masked]>, "Michael Myers" <[email-masked]>, "David Engberg" <[email-masked]>, <[email-masked]>, "Ambarish Malpani" <[email-masked]>, <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Tim Polk" <[email-masked]>
Sender: [email-masked]

I concur with this, er "me too" :)

Ryan

-----Original Message-----
From: Paul Hoffman / IMC [mailto:[email-masked]] 
Sent: Friday, September 26, 2003 9:40 AM
To: Michael Myers; Ryan M. Hurst; David Engberg; [email-masked];
Ambarish Malpani; [email-masked]
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

Date: Fri, 26 Sep 2003 12:49:00 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet, Ltd.
To: Michael Myers <[email-masked]>
CC: "Ryan M. Hurst" <[email-masked]>, [email-masked], Ambarish Malpani <[email-masked]>, [email-masked], Russ Housley <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
Subject: Re: OCSP response pre-production
Sender: [email-masked]

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.

Date: Fri, 26 Sep 2003 09:40:15 -0700
To: "Michael Myers" <[email-masked]>, "Ryan M. Hurst" <[email-masked]>, "David Engberg" <[email-masked]>, <[email-masked]>, "Ambarish Malpani" <[email-masked]>, <[email-masked]>
From: Paul Hoffman / IMC <[email-masked]>
Subject: RE: OCSP response pre-production
Cc: "Russ Housley" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Tim Polk" <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 26 Sep 2003 12:30:55 -0400
To: "Deacon, Alex" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: POLL:  Use of nonces in OCSP
Cc: [email-masked]
Sender: [email-masked]

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
>
>
>
>
> > From: Michael Myers [mailto:[email-masked]]
> > Sent: Wednesday, September 24, 2003 7:38 AM
> > To: [email-masked]
> > 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
> >
> >

From: "Michael Myers" <[email-masked]>
To: "Ryan M. Hurst" <[email-masked]>, "David Engberg" <[email-masked]>, <[email-masked]>, "Ambarish Malpani" <[email-masked]>, <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Tim Polk" <[email-masked]>
Subject: RE: OCSP response pre-production
Date: Fri, 26 Sep 2003 08:54:12 -0700
Importance: Normal
Sender: [email-masked]

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

Date: Fri, 26 Sep 2003 08:49:16 +0200
From: Marius Marian <[email-masked]>
To: [email-masked]
Subject: Re: POLL:  Use of nonces in OCSP
Sender: [email-masked]

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.

Date: Thu, 25 Sep 2003 23:27:33 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: POLL: Use of nonces in OCSP
Sender: [email-masked]

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
> 
> 
>>From: [email-masked]
>>[mailto:[email-masked]]On Behalf Of
>>David Engberg
>>Sent: Thursday, September 25, 2003 2:45 PM
>>To: [email-masked]
>>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.
>>
>>
>>
> 
> 
> 
> 

Date: Thu, 25 Sep 2003 23:37:33 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet
To: [email-masked]
CC: [email-masked]
Subject: Re: POLL: Use of nonces in OCSP
Sender: [email-masked]

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

[email-masked] 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
> 

From: "Michael Myers" <[email-masked]>
To: "Ryan M. Hurst" <[email-masked]>, "David Engberg" <[email-masked]>, <[email-masked]>
Subject: Re: OCSP response pre-production
Date: Thu, 25 Sep 2003 18:28:51 -0700
Importance: Normal
Sender: [email-masked]

> 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

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: "Alex Deacon" <[email-masked]>
Subject: OCSP response pre-production
Date: Thu, 25 Sep 2003 17:41:26 -0700
Importance: Normal
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: POLL: Use of nonces in OCSP
Date: Thu, 25 Sep 2003 17:27:41 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "David Engberg" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of David Engberg
Sent: Thursday, September 25, 2003 2:45 PM
To: [email-masked]
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.

From: "Deacon, Alex" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, [email-masked]
Cc: Stephen Kent <[email-masked]>, Ambarish Malpani <[email-masked]>
Subject: RE: POLL:  Use of nonces in OCSP
Date: Thu, 25 Sep 2003 17:12:48 -0700
Sender: [email-masked]

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

> From: Michael Myers [mailto:[email-masked]]
> Sent: Wednesday, September 24, 2003 7:38 AM
> To: [email-masked]
> 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
> 
> 

From: "Michael Myers" <[email-masked]>
To: "David Engberg" <[email-masked]>, <[email-masked]>
Subject: RE: POLL: Use of nonces in OCSP
Date: Thu, 25 Sep 2003 16:43:30 -0700
Importance: Normal
Sender: [email-masked]

David,

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

Mike

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> David Engberg
> Sent: Thursday, September 25, 2003 2:45 PM
> To: [email-masked]
> 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.
>
>
>

Date: Thu, 25 Sep 2003 17:44:53 -0400
From: David Engberg <[email-masked]>
Organization: CoreStreet, Ltd.
To: [email-masked]
Subject: RE: POLL: Use of nonces in OCSP
Sender: [email-masked]

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.

Content-class: urn:content-classes:message
Subject: RE: POLL:  Use of nonces in OCSP
Date: Thu, 25 Sep 2003 10:50:51 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, "Ambarish Malpani" <[email-masked]>
Sender: [email-masked]

Yes, that is what I meant :)

-----Original Message-----
From: Michael Myers [mailto:[email-masked]] 
Sent: Thursday, September 25, 2003 10:53 AM
To: Ryan M. Hurst; [email-masked]
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

> From: Ryan M. Hurst [mailto:[email-masked]]
> Sent: Thursday, September 25, 2003 10:39 AM
> To: Michael Myers; [email-masked]
> 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
>
> From: [email-masked]
> [mailto:[email-masked]]
> On Behalf Of Michael Myers
> Sent: Wednesday, September 24, 2003 7:38 AM
> To: [email-masked]
> 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
>
>
>
>
>
>

From: "Michael Myers" <[email-masked]>
To: "Ryan M. Hurst" <[email-masked]>, <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, "Ambarish Malpani" <[email-masked]>
Subject: RE: POLL:  Use of nonces in OCSP
Date: Thu, 25 Sep 2003 10:53:03 -0700
Importance: Normal
Sender: [email-masked]

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

> From: Ryan M. Hurst [mailto:[email-masked]]
> Sent: Thursday, September 25, 2003 10:39 AM
> To: Michael Myers; [email-masked]
> 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
>
> From: [email-masked]
> [mailto:[email-masked]]
> On Behalf Of Michael Myers
> Sent: Wednesday, September 24, 2003 7:38 AM
> To: [email-masked]
> 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
>
>
>
>
>
>

Content-class: urn:content-classes:message
Subject: RE: POLL:  Use of nonces in OCSP
Date: Thu, 25 Sep 2003 10:38:42 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Michael Myers" <[email-masked]>, <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, "Ambarish Malpani" <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: Wednesday, September 24, 2003 7:38 AM
To: [email-masked]
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

Reply-To: "Yasir Khan" <[email-masked]>
From: "Yasir Khan" <[email-masked]>
To: <[email-masked]>
Subject: Re: POLL:  Use of nonces in OCSP
Date: Thu, 25 Sep 2003 21:05:28 +0500
Organization: Ascertia Limited.
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Michael Myers
Sent: 24 September 2003 15:38
To: [email-masked]
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

Date: Thu, 25 Sep 2003 11:46:59 -0400
To: Stephen Kent <[email-masked]>, "Ryan M. Hurst" <[email-masked]>
From: Tim Polk <[email-masked]>
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID  matching)
Cc: <[email-masked]>
Sender: [email-masked]

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

From: "Miguel Rodriguez" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: POLL:  Use of nonces in OCSP
Date: Thu, 25 Sep 2003 10:00:26 -0500
Importance: Normal
Sender: [email-masked]

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

Miguel A Rodriguez
SeguriDATA
Mexico

> From: Michael Myers [mailto:[email-masked]]
> 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
> +1-602-739-7744.
> 
> Michael Myers
> 
> > From: Miguel Rodriguez [mailto:[email-masked]]
> > 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
> >
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Michael Myers
> > > Sent: Wednesday, September 24, 2003 9:38 AM
> > > To: [email-masked]
> > > 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
> >
> >
> >
> >
> 

Date: Wed, 24 Sep 2003 18:54:11 -0400
To: "Ryan M. Hurst" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: Making more of Key IDs (was RE: 3280 Question WRT SKID/AKID  matching)
Cc: <[email-masked]>
Sender: [email-masked]

--============_-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============--

Date: Thu, 25 Sep 2003 09:38:54 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: POLL:  Use of nonces in OCSP
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

From: "Wertz, Eric" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, [email-masked]
Cc: Stephen Kent <[email-masked]>, Ambarish Malpani <[email-masked]>
Subject: RE: POLL:  Use of nonces in OCSP
Date: Wed, 24 Sep 2003 14:58:41 -0700
Sender: [email-masked]

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

-e

From: "Florian Oelmaier" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, <[email-masked]>
Cc: "'Stephen Kent'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>
Subject: RE: POLL:  Use of nonces in OCSP
Date: Wed, 24 Sep 2003 22:21:05 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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

Date: Wed, 24 Sep 2003 11:02:16 -0700
From: "Terry Hayes" <[email-masked]>
Subject: Re: POLL:  Use of nonces in OCSP
To: [email-masked]
Organization: AOL
Sender: [email-masked]

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

Date: Wed, 24 Sep 2003 18:16:20 +0100
From: Dr Stephen Henson <[email-masked]>
To: Dr Stephen Henson <[email-masked]>
CC: Michael Myers <[email-masked]>, [email-masked], Stephen Kent <[email-masked]>, Ambarish Malpani <[email-masked]>
Subject: Re: POLL:  Use of nonces in OCSP
Sender: [email-masked]

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: [email-masked], PGP key: via homepage.

From: "Ambarish Malpani" <[email-masked]>
To: "Richard Levitte - VMS Whacker" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: POLL: Use of nonces in OCSP
Date: Wed, 24 Sep 2003 10:13:33 -0700
Importance: Normal
Sender: [email-masked]

Hi Mike,
    Neither will the Valicert one.

A

> From: Richard Levitte - VMS Whacker [mailto:[email-masked]]
> Sent: Wednesday, September 24, 2003 9:47 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: POLL: Use of nonces in OCSP
> 
> 
> In message <[email-masked]> on 
> Wed, 24 Sep 2003 07:38:09 -0700, "Michael Myers" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
>      "Price, performance, quality...  choose the two you like"
> 

Date: Wed, 24 Sep 2003 18:47:16 +0200 (CEST)
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: POLL: Use of nonces in OCSP
From: Richard Levitte - VMS Whacker <[email-masked]>
Sender: [email-masked]

In message <[email-masked]> on Wed, 24 Sep 2003 07:38:09 -0700, "Michael Myers" <[email-masked]> 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: +46-708-26 53 44 |                             | SWEDEN
     "Price, performance, quality...  choose the two you like"

Date: Wed, 24 Sep 2003 16:46:28 +0100
From: Dr Stephen Henson <[email-masked]>
To: Michael Myers <[email-masked]>
CC: [email-masked], Stephen Kent <[email-masked]>, Ambarish Malpani <[email-masked]>
Subject: Re: POLL:  Use of nonces in OCSP
Sender: [email-masked]

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: [email-masked], PGP key: via homepage.

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, "Ambarish Malpani" <[email-masked]>
Subject: POLL:  Use of nonces in OCSP
Date: Wed, 24 Sep 2003 07:38:09 -0700
Importance: Normal
Sender: [email-masked]

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

Date: Fri, 19 Sep 2003 09:26:38 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SCVP additions
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 19 Sep 2003 09:00:59 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: SCVP additions
Sender: [email-masked]

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
> 

Content-class: urn:content-classes:message
Subject: RE: SCVP additions
Date: Thu, 18 Sep 2003 16:18:36 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Thursday, September 18, 2003 3:40 PM
To: [email-masked]
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

Date: Thu, 18 Sep 2003 18:40:17 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: SCVP additions
Sender: [email-masked]

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

Date: Thu, 18 Sep 2003 09:44:31 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: WG last call re draft-pkix-acpolicies-extn-03.txt
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Subject: RE: draft-ietf-pkix-x509-ipaddr-as-extn-02.txt
Date: Thu, 18 Sep 2003 10:09:20 -0700
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Wednesday, September 17, 2003 1:59 PM
> To: [email-masked]
> 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
> 

Date: Wed, 17 Sep 2003 16:59:07 -0400
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: draft-ietf-pkix-x509-ipaddr-as-extn-02.txt
Sender: [email-masked]

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

Date: 17 Sep 2003 13:07:56 -0000
From: "Florian Oelmaier" <[email-masked]>
To: [email-masked] (Peter Gutmann), [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

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, [email-masked] (Peter Gutmann) wrote :

> "Florian Oelmaier" <[email-masked]> 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.
> 

Date: Thu, 18 Sep 2003 01:01:00 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

"Florian Oelmaier" <[email-masked]> 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.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-x509-ipaddr-as-extn-02.txt
Date: Tue, 16 Sep 2003 10:20:24 -0400
Sender: [email-masked]

--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 [email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-pkixrep-02.txt
Date: Tue, 16 Sep 2003 10:20:19 -0400
Sender: [email-masked]

--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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

Date: Tue, 16 Sep 2003 08:50:40 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Wen-Cheng Wang <[email-masked]>
CC: [email-masked]
Subject: Re: How a SCVP client authenticates the SCVP server?
Sender: [email-masked]

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

From: "Wen-Cheng Wang" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: How a SCVP client authenticates the SCVP server?
Date: Tue, 16 Sep 2003 13:53:33 +0800
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Charles Lynn'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: WG last call
Date: Mon, 15 Sep 2003 22:51:56 -0700
Importance: Normal
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: RE: IP addr: 01: WG last call
Date: Tue, 16 Sep 2003 15:11:06 +1000
From: "Manger, James H" <[email-masked]>
To: "Charles Lynn" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
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

From: Charles Lynn <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: new version of draft-ietf-pkix-x509-ipaddr-as-extn-02.txt
Date: Tue, 16 Sep 2003 00:27:12 -0400 (EDT)
Sender: [email-masked]

Folks,

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

Thanks for your feedback,
Charlie

From: Charles Lynn <[email-masked]>
To: "Jim Schaad" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: WG last call
Date: Tue, 16 Sep 2003 00:22:43 -0400 (EDT)
Sender: [email-masked]

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

From: Charles Lynn <[email-masked]>
To: "Manger, James H" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: IP addr: 01: WG last call
Date: Tue, 16 Sep 2003 00:20:53 -0400 (EDT)
Sender: [email-masked]

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

From: "Florian Oelmaier" <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Tue, 16 Sep 2003 01:31:34 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
Sent: Monday, September 15, 2003 7:40 PM
To: 'Ryan M. Hurst'; 'Florian Oelmaier'; 'Peter Gutmann';
[email-masked]; [email-masked]
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:[email-masked]] 
Sent: Monday, September 15, 2003 8:55 AM
To: Florian Oelmaier; Peter Gutmann; [email-masked];
[email-masked]; [email-masked]
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; [email-masked];
[email-masked]; [email-masked]; [email-masked]
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:[email-masked]] <BR><B>Sent:</B> Monday, September 15, =
2003 7:40=20
  PM<BR><B>To:</B> 'Ryan M. Hurst'; 'Florian Oelmaier'; 'Peter Gutmann'; =

  [email-masked]; [email-masked]<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:[email-masked]] <BR><B>Sent:</B> Monday, =
September 15,=20
    2003 8:55 AM<BR><B>To:</B> Florian Oelmaier; Peter Gutmann;=20
    [email-masked]; [email-masked]; =
[email-masked]<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
    [email-masked]; [email-masked]; [email-masked];=20
    [email-masked]<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--

Date: Mon, 15 Sep 2003 18:19:46 -0400
To: "Deacon, Alex" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Cc: "'Ryan M. Hurst'" <[email-masked]>, Peter Gutmann	 <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

--============_-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============--

Date: Tue, 16 Sep 2003 10:01:56 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

"Ryan M. Hurst" <[email-masked]> 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.

From: "Deacon, Alex" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>, Peter Gutmann <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 14:37:05 -0700
Sender: [email-masked]

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:[email-masked]]
Sent: Monday, September 15, 2003 8:49 AM
To: Peter Gutmann; [email-masked]; [email-masked];
[email-masked]; [email-masked]
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: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?

"Ryan M. Hurst" <[email-masked]> 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:[email-masked]]<BR><B>Sent:</B> Monday, September =
15, 2003=20
  8:49 AM<BR><B>To:</B> Peter Gutmann; [email-masked]; =
[email-masked];=20
  [email-masked]; [email-masked]<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> [email-masked]; =
[email-masked];=20
  [email-masked]; [email-masked]; =
[email-masked];=20
  [email-masked]<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;[email-masked]&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--

From: "Ambarish Malpani" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>, "'Florian Oelmaier'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 10:40:18 -0700
Importance: Normal
Sender: [email-masked]

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:[email-masked]]=20
Sent: Monday, September 15, 2003 8:55 AM
To: Florian Oelmaier; Peter Gutmann; [email-masked];
[email-masked]; [email-masked]
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; [email-masked]; =
[email-masked];
[email-masked]; [email-masked]
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:[email-masked]] <BR><B>Sent:</B> Monday, September =
15, 2003=20
  8:55 AM<BR><B>To:</B> Florian Oelmaier; Peter Gutmann; =
[email-masked];=20
  [email-masked]; [email-masked]<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
  [email-masked]; [email-masked]; [email-masked];=20
  [email-masked]<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--

Subject: RE: [OCSP] are several requests for different CAs at once valid ?
From: "Ryan M. Hurst" <[email-masked]>
To: Florian Oelmaier <[email-masked]>, Peter Gutmann <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 15 Sep 2003 08:54:33 -0700
Sender: [email-masked]

--------------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; [email-masked]; [email-masked]; =
[email-masked]; [email-masked]
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; [email-masked]; [email-masked]; [email-masked]<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--

Subject: RE: [OCSP] are several requests for different CAs at once valid ?
From: "Ryan M. Hurst" <[email-masked]>
To: Peter Gutmann <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 15 Sep 2003 08:49:21 -0700
Sender: [email-masked]

--------------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: [email-masked]; [email-masked]; [email-masked]; pgut001@=
cs.auckland.ac.nz; [email-masked]; [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?

"Ryan M. Hurst" <[email-masked]> 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> [email-masked]; [email-masked]; o=
[email-masked]; [email-masked]; [email-masked]; =
[email-masked]<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;[email-masked]=
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--

Date: 15 Sep 2003 15:47:52 -0000
From: "Florian Oelmaier" <[email-masked]>
To: "Ryan M. Hurst" <[email-masked]>, Peter Gutmann <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

> 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

Date: Tue, 16 Sep 2003 03:29:42 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

"Ryan M. Hurst" <[email-masked]> 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.

Subject: RE: [OCSP] are several requests for different CAs at once valid ?
From: "Ryan M. Hurst" <[email-masked]>
To: Florian Oelmaier <[email-masked]>, Ambarish Malpani <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 15 Sep 2003 08:14:47 -0700
Sender: [email-masked]

--------------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=
[email-masked]; [email-masked]
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" <[email-masked]=
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
>   Sent: Sunday, September 14, 2003 6:06 PM
>   To: 'Ambarish Malpani'; 'Ryan M. Hurst'; 'Peter Gutmann';
> [email-masked]; [email-masked]
>   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
>     From: Ambarish Malpani [mailto:[email-masked]]
>     Sent: Monday, September 15, 2003 1:58 AM
>     To: Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann';
> [email-masked]; [email-masked]
>     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
>       From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Florian Oelmaier
>       Sent: Sunday, September 14, 2003 3:14 PM
>       To: 'Ryan M. Hurst'; 'Peter Gutmann'; [email-masked]; [email-masked]=
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
>       From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Ryan M. Hurst
>       Sent: Sunday, September 14, 2003 8:55 PM
>       To: Peter Gutmann; [email-masked]; [email-masked]
>       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: [email-masked]; [email-masked]; [email-masked]
>         Subject: RE: [OCSP] are several requests for different CAs at onc=
e
> valid ?
>=20
>=20
> "Ryan M. Hurst" <[email-masked]> 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'; [email-masked]; [email-masked]<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:[email-masked]]
&gt;   Sent: Sunday, September 14, 2003 6:06 PM
&gt;   To: 'Ambarish Malpani'; 'Ryan M. Hurst'; 'Peter Gutmann';
&gt; [email-masked]; [email-masked]
&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:[email-masked]]
&gt;     Sent: Monday, September 15, 2003 1:58 AM
&gt;     To: Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann';
&gt; [email-masked]; [email-masked]
&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: [email-masked]
&gt; [mailto:[email-masked]]On Behalf Of Florian Oelmaier
&gt;       Sent: Sunday, September 14, 2003 3:14 PM
&gt;       To: 'Ryan M. Hurst'; 'Peter Gutmann'; [email-masked]; 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: [email-masked]
&gt; [mailto:[email-masked]] On Behalf Of Ryan M. Hurst
&gt;       Sent: Sunday, September 14, 2003 8:55 PM
&gt;       To: Peter Gutmann; [email-masked]; [email-masked]
&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: [email-masked]; [email-masked]; [email-masked]
&gt;         Subject: RE: [OCSP] are several requests for different CAs at =
once
&gt; valid ?
&gt;=20
&gt;=20
&gt; "Ryan M. Hurst" &lt;[email-masked]&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--

Subject: RE: [OCSP] are several requests for different CAs at once valid ?
From: "Ryan M. Hurst" <[email-masked]>
To: Peter Gutmann <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 15 Sep 2003 07:52:15 -0700
Sender: [email-masked]

--------------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: [email-masked]; [email-masked]; [email-masked]; pgut001@=
cs.auckland.ac.nz; [email-masked]; [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?

"Florian Oelmaier" <[email-masked]> 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> [email-masked]; [email-masked]; o=
[email-masked]; [email-masked]; [email-masked]; =
[email-masked]<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--

Date: 15 Sep 2003 14:33:29 -0000
From: "Florian Oelmaier" <[email-masked]>
To: "Ambarish Malpani" <[email-masked]>, "Florian Oelmaier" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

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" <[email-masked]> 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
>   Sent: Sunday, September 14, 2003 6:06 PM
>   To: 'Ambarish Malpani'; 'Ryan M. Hurst'; 'Peter Gutmann';
> [email-masked]; [email-masked]
>   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
>     From: Ambarish Malpani [mailto:[email-masked]]
>     Sent: Monday, September 15, 2003 1:58 AM
>     To: Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann';
> [email-masked]; [email-masked]
>     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
>       From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Florian Oelmaier
>       Sent: Sunday, September 14, 2003 3:14 PM
>       To: 'Ryan M. Hurst'; 'Peter Gutmann'; [email-masked]; [email-masked]
>       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
> 
>       From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Ryan M. Hurst
>       Sent: Sunday, September 14, 2003 8:55 PM
>       To: Peter Gutmann; [email-masked]; [email-masked]
>       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: [email-masked]; [email-masked]; [email-masked]
>         Subject: RE: [OCSP] are several requests for different CAs at once
> valid ?
> 
> 
> "Ryan M. Hurst" <[email-masked]> 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.
> 
> 

Date: 15 Sep 2003 14:28:14 -0000
From: "Florian Oelmaier" <[email-masked]>
To: [email-masked] (Peter Gutmann), [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

> 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

From: "Ambarish Malpani" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 07:25:01 -0700
Importance: Normal
Sender: [email-masked]

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:[email-masked]]
  Sent: Sunday, September 14, 2003 6:06 PM
  To: 'Ambarish Malpani'; 'Ryan M. Hurst'; 'Peter Gutmann';
[email-masked]; [email-masked]
  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:[email-masked]]
    Sent: Monday, September 15, 2003 1:58 AM
    To: Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann';
[email-masked]; [email-masked]
    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: [email-masked]
[mailto:[email-masked]]On Behalf Of Florian Oelmaier
      Sent: Sunday, September 14, 2003 3:14 PM
      To: 'Ryan M. Hurst'; 'Peter Gutmann'; [email-masked]; [email-masked]
      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: [email-masked]
[mailto:[email-masked]] On Behalf Of Ryan M. Hurst
      Sent: Sunday, September 14, 2003 8:55 PM
      To: Peter Gutmann; [email-masked]; [email-masked]
      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: [email-masked]; [email-masked]; [email-masked]
        Subject: RE: [OCSP] are several requests for different CAs at once
valid ?

"Ryan M. Hurst" <[email-masked]> 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:[email-masked]]<BR><B>Sent:</B> Sunday, September 14, =
2003 6:06=20
  PM<BR><B>To:</B> 'Ambarish Malpani'; 'Ryan M. Hurst'; 'Peter Gutmann'; =

  [email-masked]; [email-masked]<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:[email-masked]] <BR><B>Sent:</B> Monday, September 15, =
2003=20
    1:58 AM<BR><B>To:</B> Florian Oelmaier; 'Ryan M. Hurst'; 'Peter =
Gutmann';=20
    [email-masked]; [email-masked]<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
      [email-masked] =
[mailto:[email-masked]]<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'; =
[email-masked];=20
      [email-masked]<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
      [email-masked] [mailto:[email-masked]] =
<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; [email-masked];=20
      [email-masked]<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
        [email-masked]; [email-masked];=20
        [email-masked]<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;[email-masked]&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--

From: "Liaquat Khan" <[email-masked]>
To: <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 15:21:28 +0100
Importance: Normal
Sender: [email-masked]

:-) 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: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Gutmann
Sent: 15 September 2003 14:49
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?

"Florian Oelmaier" <[email-masked]> 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.

Date: Tue, 16 Sep 2003 01:48:39 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

"Florian Oelmaier" <[email-masked]> 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.

Date: Mon, 15 Sep 2003 09:19:25 -0400
To: <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: WG last call - DER-encoded BIT STRING for IPAddress
Cc: "'Manger, James H'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 15 Sep 2003 14:12:11 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Wen-Cheng Wang <[email-masked]>
CC: [email-masked]
Subject: Re: How a SCVP client authenticates the SCVP server?
Sender: [email-masked]

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

From: "Wen-Cheng Wang" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Trevor Freeman" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: How a SCVP client authenticates the SCVP server?
Date: Mon, 15 Sep 2003 18:09:18 +0800
Sender: [email-masked]

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

From: "Wen-Cheng Wang" <[email-masked]>
To: "Trevor Freeman" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: How a SCVP client authenticates the SCVP server?
Date: Mon, 15 Sep 2003 17:25:28 +0800
Sender: [email-masked]

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" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>
Cc: <[email-masked]>
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 
> 
> 
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 11:14 PM
> To: Trevor Freeman
> Cc: [email-masked]
> 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
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Wen-Cheng Wang
> > Sent: Friday, September 12, 2003 7:35 PM
> > To: Trevor Freeman
> > Cc: [email-masked]
> > 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
> > > From: [email-masked]
> > [mailto:[email-masked]]
> > > On Behalf Of Wen-Cheng Wang
> > > Sent: Friday, September 12, 2003 5:00 AM
> > > To: [email-masked]
> > > 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
> 

Date: Mon, 15 Sep 2003 09:47:26 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: How a SCVP client authenticates the SCVP server?
Sender: [email-masked]

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.

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 8:00 AM
> To: [email-masked]
> 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
> 
> 

Date: Mon, 15 Sep 2003 09:23:23 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: [email-masked]
Subject: Re: How a SCVP client authenticates the SCVP server?
Sender: [email-masked]

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
> 
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 5:00 AM
> To: [email-masked]
> 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
> 
> 

Subject: RE: [OCSP] are several requests for different CAs at once valid ?
From: "Ryan M. Hurst" <[email-masked]>
To: Florian Oelmaier <[email-masked]>
Cc: "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sun, 14 Sep 2003 21:33:40 -0700
Sender: [email-masked]

--------------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'; [email-masked]; [email-masked]
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'; [email-masked]; [email-masked]<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--

From: "Florian Oelmaier" <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 03:06:09 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
Sent: Monday, September 15, 2003 1:58 AM
To: Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann';
[email-masked]; [email-masked]
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: [email-masked]
[mailto:[email-masked]]On Behalf Of Florian Oelmaier
Sent: Sunday, September 14, 2003 3:14 PM
To: 'Ryan M. Hurst'; 'Peter Gutmann'; [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan M. Hurst
Sent: Sunday, September 14, 2003 8:55 PM
To: Peter Gutmann; [email-masked]; [email-masked]
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: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?

"Ryan M. Hurst" <[email-masked]> 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:[email-masked]] <BR><B>Sent:</B> Monday, September 15, =
2003 1:58=20
  AM<BR><B>To:</B> Florian Oelmaier; 'Ryan M. Hurst'; 'Peter Gutmann';=20
  [email-masked]; [email-masked]<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
    [email-masked] =
[mailto:[email-masked]]<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'; =
[email-masked];=20
    [email-masked]<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
    [email-masked] [mailto:[email-masked]] =
<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; [email-masked];=20
    [email-masked]<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
      [email-masked]; [email-masked];=20
      [email-masked]<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;[email-masked]&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--

From: "Ambarish Malpani" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Sun, 14 Sep 2003 16:57:45 -0700
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]On
Behalf Of Florian Oelmaier
  Sent: Sunday, September 14, 2003 3:14 PM
  To: 'Ryan M. Hurst'; 'Peter Gutmann'; [email-masked]; [email-masked]
  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: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan M. Hurst
  Sent: Sunday, September 14, 2003 8:55 PM
  To: Peter Gutmann; [email-masked]; [email-masked]
  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: [email-masked]; [email-masked]; [email-masked]
    Subject: RE: [OCSP] are several requests for different CAs at once valid
?

"Ryan M. Hurst" <[email-masked]> 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> =
[email-masked]=20
  [mailto:[email-masked]]<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'; [email-masked];=20
  [email-masked]<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
  [email-masked] [mailto:[email-masked]] =
<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; [email-masked];=20
  [email-masked]<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
    [email-masked]; [email-masked];=20
    [email-masked]<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;[email-masked]&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--

From: "Florian Oelmaier" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>
Cc: "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 01:20:09 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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

Subject: RE: [OCSP] are several requests for different CAs at once valid ?
From: "Ryan M. Hurst" <[email-masked]>
To: Florian Oelmaier <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sun, 14 Sep 2003 15:32:35 -0700
Sender: [email-masked]

--------------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'; [email-masked]; [email-masked]
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: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Ryan M. Hurst
Sent: Sunday, September 14, 2003 8:55 PM
To: Peter Gutmann; [email-masked]; [email-masked]
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: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?

"Ryan M. Hurst" <[email-masked]> 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'; [email-masked]; [email-masked]<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=
> [email-masked] [mailto:[email-masked]] <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; [email-masked]; [email-masked]<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> [email-masked]; rmh@wind=
ows.microsoft.com; [email-masked]<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;[email-masked]=
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--

From: "Florian Oelmaier" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Mon, 15 Sep 2003 00:13:47 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Ryan M. Hurst
Sent: Sunday, September 14, 2003 8:55 PM
To: Peter Gutmann; [email-masked]; [email-masked]
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: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid
?

"Ryan M. Hurst" <[email-masked]> 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
[email-masked] [mailto:[email-masked]] <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; [email-masked];=20
[email-masked]<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> =
[email-masked];=20
  [email-masked]; [email-masked]<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;[email-masked]&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--

Subject: RE: [OCSP] are several requests for different CAs at once valid ?
From: "Ryan M. Hurst" <[email-masked]>
To: Peter Gutmann <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Sun, 14 Sep 2003 11:54:36 -0700
Sender: [email-masked]

--------------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: [email-masked]; [email-masked]; [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?

"Ryan M. Hurst" <[email-masked]> 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> [email-masked]; rmh@wind=
ows.microsoft.com; [email-masked]<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;[email-masked]=
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--

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Sun, 14 Sep 2003 09:36:08 -0400
Importance: Normal
Sender: [email-masked]

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

Date: Mon, 15 Sep 2003 00:26:24 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

"Ryan M. Hurst" <[email-masked]> 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.

Content-class: urn:content-classes:message
Subject: RE: How a SCVP client authenticates the SCVP server?
Date: Sat, 13 Sep 2003 16:27:58 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Wen-Cheng Wang
Sent: Friday, September 12, 2003 11:14 PM
To: Trevor Freeman
Cc: [email-masked]
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
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 7:35 PM
> To: Trevor Freeman
> Cc: [email-masked]
> 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
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Wen-Cheng Wang
> > Sent: Friday, September 12, 2003 5:00 AM
> > To: [email-masked]
> > 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

Date: Sat, 13 Sep 2003 14:14:14 +0800 (CST)
From: Wen-Cheng Wang <[email-masked]>
To: "\"Trevor Freeman\"" <[email-masked]>
Subject: RE: How a SCVP client authenticates the SCVP server?
Cc: [email-masked]
Sender: [email-masked]

------=_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
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 7:35 PM
> To: Trevor Freeman
> Cc: [email-masked]
> 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
> > From: [email-masked]
> [mailto:[email-masked]]
> > On Behalf Of Wen-Cheng Wang
> > Sent: Friday, September 12, 2003 5:00 AM
> > To: [email-masked]
> > 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--

Content-class: urn:content-classes:message
Subject: RE: How a SCVP client authenticates the SCVP server?
Date: Fri, 12 Sep 2003 22:19:07 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Wen-Cheng Wang
Sent: Friday, September 12, 2003 7:35 PM
To: Trevor Freeman
Cc: [email-masked]
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
> From: [email-masked]
[mailto:[email-masked]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 5:00 AM
> To: [email-masked]
> 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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Manger, James H'" <[email-masked]>, <[email-masked]>
Subject: RE: WG last call - DER-encoded BIT STRING for IPAddress
Date: Fri, 12 Sep 2003 21:44:44 -0700
Importance: Normal
Sender: [email-masked]

I withdraw my objection on this issue.  I still think that some
clarification language on how IPAddresses are encoded makes sense.

jim

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Manger, James H
> Sent: Sunday, September 07, 2003 5:23 PM
> To: [email-masked]
> 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.
> 
> 
> From: Jim Schaad [mailto:[email-masked]]
> Sent: Sunday, 7 September 2003 2:59 PM
> To: 'Stephen Kent'; [email-masked]
> 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
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Jim Schaad
> > Sent: Friday, September 05, 2003 5:35 PM
> > To: 'Stephen Kent'; [email-masked]
> > 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
> > 
> > 
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of Stephen Kent
> > > Sent: Tuesday, August 19, 2003 7:02 PM
> > > To: [email-masked]
> > > 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
> > > 
> > 
> 
> 

Date: Sat, 13 Sep 2003 10:34:43 +0800 (CST)
From: Wen-Cheng Wang <[email-masked]>
To: "\"Trevor Freeman\"" <[email-masked]>
Subject: RE: How a SCVP client authenticates the SCVP server?
Cc: [email-masked]
Sender: [email-masked]

------=_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
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Wen-Cheng Wang
> Sent: Friday, September 12, 2003 5:00 AM
> To: [email-masked]
> 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--

Date: Fri, 12 Sep 2003 18:26:57 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: How a SCVP client authenticates the SCVP server?
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 12 Sep 2003 17:56:12 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: How a SCVP client authenticates the SCVP server?
Date: Fri, 12 Sep 2003 14:49:05 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Wen-Cheng Wang" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Wen-Cheng Wang
Sent: Friday, September 12, 2003 5:00 AM
To: [email-masked]
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

Content-class: urn:content-classes:message
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Fri, 12 Sep 2003 10:47:45 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Vadim Fedukovich" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Vadim Fedukovich
Sent: Friday, September 12, 2003 8:16 AM
To: [email-masked]
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: [email-masked]
> 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: [email-masked]; [email-masked];
[email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [OCSP] are several requests for different CAs at once
valid ?
> > 
> > 
> > "Ryan M. Hurst" <[email-masked]> 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.

Date: Fri, 12 Sep 2003 11:56:33 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 12 Sep 2003 11:50:42 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

From: "Santosh Chokhani" <[email-masked]>
To: "'Wen-Cheng Wang'" <[email-masked]>, <[email-masked]>
Subject: RE: How a SCVP client authenticates the SCVP server?
Date: Fri, 12 Sep 2003 12:41:16 -0400
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Wen-Cheng Wang
Sent: Friday, September 12, 2003 8:00 AM
To: [email-masked]
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

Date: Fri, 12 Sep 2003 18:15:46 +0300
From: Vadim Fedukovich <[email-masked]>
To: [email-masked]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

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: [email-masked]
> 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: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> > Cc: [email-masked]
> > Subject: RE: [OCSP] are several requests for different CAs at once valid ?
> > 
> > 
> > "Ryan M. Hurst" <[email-masked]> 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.

Subject: RE: [OCSP] are several requests for different CAs at once valid ?
From: "Ryan M. Hurst" <[email-masked]>
To: Vadim Fedukovich <[email-masked]>, <[email-masked]>
Date: Fri, 12 Sep 2003 07:47:21 -0700
Sender: [email-masked]

--------------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: [email-masked]
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: [email-masked]; [email-masked]; [email-masked]=
m; [email-masked]
> Cc: [email-masked]
> Subject: RE: [OCSP] are several requests for different CAs at once valid =
?
>=20
>=20
> "Ryan M. Hurst" <[email-masked]> 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> [email-masked]<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: [email-masked]; [email-masked]; oelmaier@sytrust=
.com; [email-masked]
&gt; Cc: [email-masked]
&gt; Subject: RE: [OCSP] are several requests for different CAs at once val=
id ?
&gt;=20
&gt;=20
&gt; "Ryan M. Hurst" &lt;[email-masked]&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--

Date: Fri, 12 Sep 2003 15:33:08 +0300
From: Vadim Fedukovich <[email-masked]>
To: [email-masked]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

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: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [OCSP] are several requests for different CAs at once valid ?
> 
> 
> "Ryan M. Hurst" <[email-masked]> 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.

From: "Wen-Cheng Wang" <[email-masked]>
To: <[email-masked]>
Subject: How a SCVP client authenticates the SCVP server?
Date: Fri, 12 Sep 2003 20:00:24 +0800
Sender: [email-masked]

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

From: "Wen-Cheng Wang" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 12 Sep 2003 20:00:19 +0800
Sender: [email-masked]

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

From: "Ambarish Malpani" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "'Julien Stern'" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 23:14:30 -0700
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Florian Oelmaier
> Sent: Thursday, September 11, 2003 4:45 PM
> To: 'Ambarish Malpani'; 'Julien Stern'; 'Ryan M. Hurst'
> Cc: [email-masked]
> 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
> 
> > From: Ambarish Malpani [mailto:[email-masked]] 
> > Sent: Friday, September 12, 2003 12:06 AM
> > To: 'Florian Oelmaier'; 'Julien Stern'
> > Cc: [email-masked]
> > 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.
> > 
> > 
> > 
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Florian Oelmaier
> > > Sent: Thursday, September 11, 2003 4:54 AM
> > > To: Julien Stern
> > > Cc: [email-masked]
> > > 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
> > > 
> > 
> > 
> 

Subject: RE: [OCSP] are several requests for different CAs at once valid ?
From: "Ryan M. Hurst" <[email-masked]>
To: Peter Gutmann <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Date: Thu, 11 Sep 2003 20:57:58 -0700
Sender: [email-masked]

--------------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: [email-masked]; [email-masked]; [email-masked];=
 [email-masked]
Cc: [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?

"Ryan M. Hurst" <[email-masked]> 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> [email-masked]; julien.stern@cryptol=
og.com; [email-masked]; [email-masked]<BR><B>Cc:</B> ietf-=
[email-masked]<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;[email-masked]=
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--

Date: Fri, 12 Sep 2003 15:00:30 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Cc: [email-masked]
Sender: [email-masked]

"Ryan M. Hurst" <[email-masked]> 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.

Content-class: urn:content-classes:message
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 18:57:09 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "Ambarish Malpani" <[email-masked]>, "Julien Stern" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Thursday, September 11, 2003 5:57 PM
To: Ryan M. Hurst; 'Ambarish Malpani'; 'Julien Stern'
Cc: [email-masked]
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
> Sent: Thursday, September 11, 2003 5:21 PM
> To: Ryan M. Hurst; 'Ambarish Malpani'; 'Julien Stern'
> Cc: [email-masked]
> 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
> 
> 
> > From: Ryan M. Hurst [mailto:[email-masked]]
> > Sent: Friday, September 12, 2003 1:57 AM
> > To: Florian Oelmaier; Ambarish Malpani; Julien Stern
> > Cc: [email-masked]
> > Subject: RE: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > 
> > In-line
> > Sent: Thursday, September 11, 2003 4:45 PM
> > To: 'Ambarish Malpani'; 'Julien Stern'; Ryan M. Hurst
> > Cc: [email-masked]
> > 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
> > 
> > > From: Ambarish Malpani [mailto:[email-masked]]
> > > Sent: Friday, September 12, 2003 12:06 AM
> > > To: 'Florian Oelmaier'; 'Julien Stern'
> > > Cc: [email-masked]
> > > 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.
> > > 
> > > 
> > > 
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of 
> > Florian Oelmaier
> > > > Sent: Thursday, September 11, 2003 4:54 AM
> > > > To: Julien Stern
> > > > Cc: [email-masked]
> > > > 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
> > > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 

From: "Florian Oelmaier" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>, "'Julien Stern'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Fri, 12 Sep 2003 02:56:41 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

> 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
> Sent: Thursday, September 11, 2003 5:21 PM
> To: Ryan M. Hurst; 'Ambarish Malpani'; 'Julien Stern'
> Cc: [email-masked]
> 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
> 
> 
> > From: Ryan M. Hurst [mailto:[email-masked]]
> > Sent: Friday, September 12, 2003 1:57 AM
> > To: Florian Oelmaier; Ambarish Malpani; Julien Stern
> > Cc: [email-masked]
> > Subject: RE: [OCSP] are several requests for different CAs at 
> > once valid ?
> > 
> > 
> > In-line
> > Sent: Thursday, September 11, 2003 4:45 PM
> > To: 'Ambarish Malpani'; 'Julien Stern'; Ryan M. Hurst
> > Cc: [email-masked]
> > 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
> > 
> > > From: Ambarish Malpani [mailto:[email-masked]]
> > > Sent: Friday, September 12, 2003 12:06 AM
> > > To: 'Florian Oelmaier'; 'Julien Stern'
> > > Cc: [email-masked]
> > > 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.
> > > 
> > > 
> > > 
> > > > From: [email-masked]
> > > > [mailto:[email-masked]] On Behalf Of 
> > Florian Oelmaier
> > > > Sent: Thursday, September 11, 2003 4:54 AM
> > > > To: Julien Stern
> > > > Cc: [email-masked]
> > > > 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
> > > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> 
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 17:27:28 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "Ambarish Malpani" <[email-masked]>, "Julien Stern" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Thursday, September 11, 2003 5:21 PM
To: Ryan M. Hurst; 'Ambarish Malpani'; 'Julien Stern'
Cc: [email-masked]
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

> From: Ryan M. Hurst [mailto:[email-masked]] 
> Sent: Friday, September 12, 2003 1:57 AM
> To: Florian Oelmaier; Ambarish Malpani; Julien Stern
> Cc: [email-masked]
> Subject: RE: [OCSP] are several requests for different CAs at 
> once valid ?
> 
> 
> In-line
> Sent: Thursday, September 11, 2003 4:45 PM
> To: 'Ambarish Malpani'; 'Julien Stern'; Ryan M. Hurst
> Cc: [email-masked]
> 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
> 
> > From: Ambarish Malpani [mailto:[email-masked]]
> > Sent: Friday, September 12, 2003 12:06 AM
> > To: 'Florian Oelmaier'; 'Julien Stern'
> > Cc: [email-masked]
> > 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.
> > 
> > 
> > 
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of 
> Florian Oelmaier
> > > Sent: Thursday, September 11, 2003 4:54 AM
> > > To: Julien Stern
> > > Cc: [email-masked]
> > > 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
> > > 
> > 
> > 
> 
> 
> 
> 

From: "Florian Oelmaier" <[email-masked]>
To: "'Ryan M. Hurst'" <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>, "'Julien Stern'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Fri, 12 Sep 2003 02:20:40 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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

> From: Ryan M. Hurst [mailto:[email-masked]] 
> Sent: Friday, September 12, 2003 1:57 AM
> To: Florian Oelmaier; Ambarish Malpani; Julien Stern
> Cc: [email-masked]
> Subject: RE: [OCSP] are several requests for different CAs at 
> once valid ?
> 
> 
> In-line
> Sent: Thursday, September 11, 2003 4:45 PM
> To: 'Ambarish Malpani'; 'Julien Stern'; Ryan M. Hurst
> Cc: [email-masked]
> 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
> 
> > From: Ambarish Malpani [mailto:[email-masked]]
> > Sent: Friday, September 12, 2003 12:06 AM
> > To: 'Florian Oelmaier'; 'Julien Stern'
> > Cc: [email-masked]
> > 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.
> > 
> > 
> > 
> > > From: [email-masked] 
> > > [mailto:[email-masked]] On Behalf Of 
> Florian Oelmaier
> > > Sent: Thursday, September 11, 2003 4:54 AM
> > > To: Julien Stern
> > > Cc: [email-masked]
> > > 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
> > > 
> > 
> > 
> 
> 
> 
> 

Content-class: urn:content-classes:message
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 16:56:40 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "Ambarish Malpani" <[email-masked]>, "Julien Stern" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

In-line
-----Original Message-----
From: Florian Oelmaier [mailto:[email-masked]] 
Sent: Thursday, September 11, 2003 4:45 PM
To: 'Ambarish Malpani'; 'Julien Stern'; Ryan M. Hurst
Cc: [email-masked]
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

> From: Ambarish Malpani [mailto:[email-masked]] 
> Sent: Friday, September 12, 2003 12:06 AM
> To: 'Florian Oelmaier'; 'Julien Stern'
> Cc: [email-masked]
> 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.
> 
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Florian Oelmaier
> > Sent: Thursday, September 11, 2003 4:54 AM
> > To: Julien Stern
> > Cc: [email-masked]
> > 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
> > 
> 
> 

From: "Florian Oelmaier" <[email-masked]>
To: "'Ambarish Malpani'" <[email-masked]>, "'Julien Stern'" <[email-masked]>, "'Ryan M. Hurst'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Fri, 12 Sep 2003 01:44:41 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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

> From: Ambarish Malpani [mailto:[email-masked]] 
> Sent: Friday, September 12, 2003 12:06 AM
> To: 'Florian Oelmaier'; 'Julien Stern'
> Cc: [email-masked]
> 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.
> 
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Florian Oelmaier
> > Sent: Thursday, September 11, 2003 4:54 AM
> > To: Julien Stern
> > Cc: [email-masked]
> > 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
> > 
> 
> 

From: "Ambarish Malpani" <[email-masked]>
To: "'Florian Oelmaier'" <[email-masked]>, "'Julien Stern'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 15:06:23 -0700
Importance: Normal
Sender: [email-masked]

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.

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Florian Oelmaier
> Sent: Thursday, September 11, 2003 4:54 AM
> To: Julien Stern
> Cc: [email-masked]
> 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
> 

Content-class: urn:content-classes:message
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 12:50:33 -0700
From: "Ryan M. Hurst" <[email-masked]>
To: "Florian Oelmaier" <[email-masked]>, "Julien Stern" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Florian Oelmaier
Sent: Thursday, September 11, 2003 4:54 AM
To: Julien Stern
Cc: [email-masked]
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

Content-class: urn:content-classes:message
Subject: RE: SCVP policy
Date: Thu, 11 Sep 2003 12:13:52 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Peter Sylvester
Sent: Tuesday, September 09, 2003 8:10 AM
To: [email-masked]
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

Date: 11 Sep 2003 12:52:12 -0000
From: "Florian Oelmaier" <[email-masked]>
To: [email-masked] (Peter Gutmann)
CC: [email-masked]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

> 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

Date: Fri, 12 Sep 2003 00:03:11 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

"Florian Oelmaier" <[email-masked]> 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.

Date: 11 Sep 2003 11:53:45 -0000
From: "Florian Oelmaier" <[email-masked]>
To: "Julien Stern" <[email-masked]>
CC: [email-masked]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

> 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

Date: Thu, 11 Sep 2003 13:50:44 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

> 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

Date: Thu, 11 Sep 2003 12:46:54 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

From: "Julien Stern" <[email-masked]>
Date: Thu, 11 Sep 2003 12:07:01 +0200
To: [email-masked]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

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

Date: 11 Sep 2003 09:25:40 -0000
From: "Florian Oelmaier" <[email-masked]>
To: "Julien Stern" <[email-masked]>, [email-masked]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

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" <[email-masked]> 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

From: "Liaquat Khan" <[email-masked]>
To: <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Thu, 11 Sep 2003 10:13:48 +0100
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Ambarish Malpani
Sent: 11 September 2003 06:31
To: Julien Stern; [email-masked]
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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Julien Stern
> Sent: Wednesday, September 10, 2003 9:25 AM
> To: [email-masked]
> 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

From: "Ambarish Malpani" <[email-masked]>
To: "Julien Stern" <[email-masked]>, <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Wed, 10 Sep 2003 22:31:26 -0700
Importance: Normal
Sender: [email-masked]

Hi Julian,
    Responses inline of the behavior of the Valicert responder.

Regards,
Ambarish

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Julien Stern
> Sent: Wednesday, September 10, 2003 9:25 AM
> To: [email-masked]
> 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

From: "Ambarish Malpani" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Wed, 10 Sep 2003 22:26:16 -0700
Importance: Normal
Sender: [email-masked]

Not sure what Peter's sample set was, but that has always
worked with the Valicert responder.

Regards,
Ambarish

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Peter Gutmann
> Sent: Wednesday, September 10, 2003 8:37 PM
> To: [email-masked]; [email-masked]
> Subject: Re: [OCSP] are several requests for different CAs at once valid
> ?
>
>
>
> "Julien Stern" <[email-masked]> 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.
>

Date: Thu, 11 Sep 2003 15:36:39 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

"Julien Stern" <[email-masked]> 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.

From: "Miguel Rodriguez" <[email-masked]>
To: "'Julien Stern'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: [OCSP] are several requests for different CAs at once valid ?
Date: Wed, 10 Sep 2003 14:15:23 -0500
Importance: Normal
Sender: [email-masked]

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

From: "Julien Stern" <[email-masked]>
Date: Wed, 10 Sep 2003 18:25:09 +0200
To: [email-masked]
Subject: [OCSP] are several requests for different CAs at once valid ?
Sender: [email-masked]

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

From: "Wen-Cheng Wang" <[email-masked]>
To: "Peter Sylvester" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 10 Sep 2003 19:59:27 +0800
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
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
>

From: "Santosh Chokhani" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Tue, 9 Sep 2003 15:01:50 -0400
Importance: Normal
Sender: [email-masked]

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

From: "Santosh Chokhani" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Tue, 9 Sep 2003 13:03:48 -0400
Importance: Normal
Sender: [email-masked]

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

Date: Tue, 9 Sep 2003 18:11:37 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

Date: Tue, 9 Sep 2003 17:09:49 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: SCVP policy
Sender: [email-masked]

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

From: "Santosh Chokhani" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Tue, 9 Sep 2003 08:41:02 -0400
Importance: Normal
Sender: [email-masked]

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

Date: Tue, 9 Sep 2003 12:54:33 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

Date: Tue, 9 Sep 2003 12:15:53 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

From: "Ambarish Malpani" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: SCVP delegation (was SCVP-AIA)
Date: Mon, 8 Sep 2003 20:07:48 -0700
Importance: Normal
Sender: [email-masked]

In that case, we are in vehement agreement.

What is important IMHO is SCVP indirection.

Regards,
Ambarish

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Monday, September 08, 2003 3:57 PM
> To: Ambarish Malpani
> Cc: [email-masked]
> 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
> 

Date: Mon, 8 Sep 2003 19:02:10 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 8 Sep 2003 18:56:36 -0400
To: "Ambarish Malpani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SCVP delegation (was SCVP-AIA)
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 8 Sep 2003 18:56:36 -0400
To: "Ambarish Malpani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: SCVP delegation (was SCVP-AIA)
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 8 Sep 2003 18:52:47 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

At 15:43 -0400 9/8/03, Santosh Chokhani wrote:
>Steve:
>
>See responses in-line in [].
>
>From: Stephen Kent [mailto:[email-masked]]
>Sent: Monday, September 08, 2003 3:00 PM
>To: Santosh Chokhani
>Cc: [email-masked]
>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

Date: Mon, 8 Sep 2003 18:41:17 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 8 Sep 2003 18:29:23 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

Date: Mon, 8 Sep 2003 18:09:25 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

From: "Santosh Chokhani" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Mon, 8 Sep 2003 17:36:34 -0400
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Monday, September 08, 2003 2:55 PM
To: Santosh Chokhani
Cc: [email-masked]
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

From: "Ambarish Malpani" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: SCVP delegation (was SCVP-AIA)
Date: Mon, 8 Sep 2003 13:45:40 -0700
Importance: Normal
Sender: [email-masked]

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

> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Monday, September 08, 2003 11:17 AM
> To: Ambarish Malpani
> Cc: [email-masked]
> 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
> 

From: "Santosh Chokhani" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Mon, 8 Sep 2003 15:43:31 -0400
Importance: Normal
Sender: [email-masked]

Steve:

See responses in-line in [].

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Monday, September 08, 2003 3:00 PM
To: Santosh Chokhani
Cc: [email-masked]
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

From: "Santosh Chokhani" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Mon, 8 Sep 2003 15:35:06 -0400
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
Sent: Monday, September 08, 2003 2:55 PM
To: Santosh Chokhani
Cc: [email-masked]
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

Date: Mon, 8 Sep 2003 14:59:54 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 8 Sep 2003 14:55:02 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 8 Sep 2003 14:16:49 -0400
To: "Ambarish Malpani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: SCVP delegation (was SCVP-AIA)
Cc: <[email-masked]>
Sender: [email-masked]

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

From: "Santosh Chokhani" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Mon, 8 Sep 2003 09:25:05 -0400
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
Sent: Monday, September 08, 2003 9:16 AM
To: Santosh Chokhani
Cc: [email-masked]
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

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Sunday, September 07, 2003 2:25 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> 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
> 
> 

Date: Mon, 08 Sep 2003 15:15:54 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Sender: [email-masked]

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

> From: Stephen Kent [mailto:[email-masked]] 
> Sent: Sunday, September 07, 2003 2:25 PM
> To: Santosh Chokhani
> Cc: [email-masked]
> 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
> 
> 

Date: Mon, 8 Sep 2003 15:07:18 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

From: "Santosh Chokhani" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Mon, 8 Sep 2003 08:50:34 -0400
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
Sent: Sunday, September 07, 2003 2:25 PM
To: Santosh Chokhani
Cc: [email-masked]
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

Date: Mon, 8 Sep 2003 12:14:51 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

Date: Sun, 7 Sep 2003 14:28:52 -0400
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

At 14:08 +1200 9/7/03, Peter Gutmann wrote:
>Wen-Cheng Wang <[email-masked]> 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

Date: Sun, 7 Sep 2003 14:25:28 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Sun, 7 Sep 2003 14:25:28 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Steven Legg" <[email-masked]>
To: <[email-masked]>, "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Subject: RE: WG last call
Date: Mon, 8 Sep 2003 11:33:00 +1100
Importance: Normal
Sender: [email-masked]

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
> 
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Jim Schaad
> > Sent: Friday, September 05, 2003 5:35 PM
> > To: 'Stephen Kent'; [email-masked]
> > 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
> > 
> > 
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Stephen Kent
> > > Sent: Tuesday, August 19, 2003 7:02 PM
> > > To: [email-masked]
> > > 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
> > > 
> > 
> 
> 

content-class: urn:content-classes:message
Subject: RE: WG last call - DER-encoded BIT STRING for IPAddress
Date: Mon, 8 Sep 2003 10:22:38 +1000
From: "Manger, James H" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
Sent: Sunday, 7 September 2003 2:59 PM
To: 'Stephen Kent'; [email-masked]
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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: Friday, September 05, 2003 5:35 PM
> To: 'Stephen Kent'; [email-masked]
> 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
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stephen Kent
> > Sent: Tuesday, August 19, 2003 7:02 PM
> > To: [email-masked]
> > 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
> > 
> 

From: "Ambarish Malpani" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Liaquat Khan" <[email-masked]>
Cc: <[email-masked]>
Subject: SCVP delegation (was SCVP-AIA)
Date: Sun, 7 Sep 2003 14:21:55 -0700
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Stephen Kent
> Sent: Friday, September 05, 2003 11:07 AM
> To: Liaquat Khan
> Cc: [email-masked]
> 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
> 

From: "Florian Oelmaier" <[email-masked]>
To: <[email-masked]>, "'Peter Gutmann'" <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Sun, 7 Sep 2003 17:57:51 +0200
Organization: SyTrust
Importance: Normal
Sender: [email-masked]

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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Subject: RE: WG last call
Date: Sat, 6 Sep 2003 21:58:56 -0700
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Jim Schaad
> Sent: Friday, September 05, 2003 5:35 PM
> To: 'Stephen Kent'; [email-masked]
> 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
> 
> 
> > From: [email-masked]
> > [mailto:[email-masked]] On Behalf Of Stephen Kent
> > Sent: Tuesday, August 19, 2003 7:02 PM
> > To: [email-masked]
> > 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
> > 
> 

Date: Sun, 7 Sep 2003 14:08:31 +1200
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

Wen-Cheng Wang <[email-masked]> 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.

From: "Santosh Chokhani" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Sat, 6 Sep 2003 12:21:42 -0400
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
Sent: Friday, September 05, 2003 1:26 PM
To: Santosh Chokhani
Cc: [email-masked]
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 []
>
>From: Stephen Kent [mailto:[email-masked]]
>Sent: Wednesday, September 03, 2003 9:33 AM
>To: Santosh Chokhani
>Cc: [email-masked]
>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

Reply-To: <[email-masked]>
From: "Jim Schaad" <[email-masked]>
To: "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Subject: RE: WG last call
Date: Fri, 5 Sep 2003 17:34:42 -0700
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stephen Kent
> Sent: Tuesday, August 19, 2003 7:02 PM
> To: [email-masked]
> 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
> 

Date: Fri, 5 Sep 2003 15:25:21 -0400
To: Wen-Cheng Wang <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

Date: Sat, 6 Sep 2003 02:57:10 +0800 (CST)
From: Wen-Cheng Wang <[email-masked]>
To: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

------=_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--

Date: Fri, 5 Sep 2003 14:46:11 -0400
To: Wen-Cheng Wang <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 5 Sep 2003 14:42:14 -0400
To: "Michael Myers" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Santosh Chokhani" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 5 Sep 2003 11:37:29 -0700
Importance: Normal
Sender: [email-masked]

> 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

Date: Sat, 6 Sep 2003 02:14:19 +0800 (CST)
From: Wen-Cheng Wang <[email-masked]>
To: [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

------=_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--

Date: Sat, 6 Sep 2003 01:54:20 +0800 (CST)
From: Wen-Cheng Wang <[email-masked]>
To: [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

------=_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--

Date: Fri, 5 Sep 2003 14:06:42 -0400
To: "Liaquat Khan" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 5 Sep 2003 13:51:09 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 5 Sep 2003 13:25:30 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

At 13:16 -0400 9/3/03, Santosh Chokhani wrote:
>Steve:
>
>Please see responses in-line in []
>
>From: Stephen Kent [mailto:[email-masked]]
>Sent: Wednesday, September 03, 2003 9:33 AM
>To: Santosh Chokhani
>Cc: [email-masked]
>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

Date: Fri, 5 Sep 2003 11:54:54 -0400
To: "Liaquat Khan" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 5 Sep 2003 11:49:46 -0400
To: Denis Pinkas <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 5 Sep 2003 11:49:04 -0400
To: "Wen-Cheng Wang" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Peter Sylvester" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 5 Sep 2003 08:03:40 -0700
Importance: Normal
Sender: [email-masked]

> 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

Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 5 Sep 2003 06:21:10 -0700
From: "Trevor Freeman" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Wen-Cheng Wang" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

Using another extesnion is a poitles distinction. The extension already
qualifies each data item conveyed by an OID.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: Friday, September 05, 2003 5:09 AM
To: Wen-Cheng Wang
Cc: [email-masked]
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'"; <[email-masked]>
> 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
>>
>>
>>>From: [email-masked] 
>>>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>>>Sent: Thursday, September 04, 2003 11:04 AM
>>>To: Michael Myers
>>>Cc: Stephen Kent; [email-masked]
>>>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
>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 

From: "Liaquat Khan" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Wen-Cheng Wang'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 5 Sep 2003 10:36:28 +0100
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Denis Pinkas
Sent: 05 September 2003 10:09
To: Wen-Cheng Wang
Cc: [email-masked]
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'"; <[email-masked]>
> 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
>>
>>
>>>From: [email-masked] 
>>>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>>>Sent: Thursday, September 04, 2003 11:04 AM
>>>To: Michael Myers
>>>Cc: Stephen Kent; [email-masked]
>>>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
>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 

Date: Fri, 05 Sep 2003 11:11:42 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Michael Myers <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Sender: [email-masked]

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

>>From: Denis Pinkas [mailto:[email-masked]]
>>Sent: Thursday, September 04, 2003 11:04 AM
>>To: Michael Myers
>>Cc: Stephen Kent; [email-masked]
>>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
> 
> 
> 
> 

Date: Fri, 05 Sep 2003 11:09:10 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Wen-Cheng Wang <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Sender: [email-masked]

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'"; <[email-masked]>
> 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
>>
>>
>>>From: [email-masked] 
>>>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>>>Sent: Thursday, September 04, 2003 11:04 AM
>>>To: Michael Myers
>>>Cc: Stephen Kent; [email-masked]
>>>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
>>>>
>>>>
>>>>
>>>
>>>
>>
> 
> 

Date: Fri, 05 Sep 2003 11:07:34 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Stephen Kent <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Sender: [email-masked]

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

From: "Wen-Cheng Wang" <[email-masked]>
To: <[email-masked]>
Cc: "'Stephen Kent'" <[email-masked]>, "Ambarish Malpani" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, "'Michael Myers'" <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Fri, 5 Sep 2003 14:27:17 +0800
Sender: [email-masked]

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'"; <[email-masked]>
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
> 
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Denis Pinkas
> > Sent: Thursday, September 04, 2003 11:04 AM
> > To: Michael Myers
> > Cc: Stephen Kent; [email-masked]
> > 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
> > > 
> > > 
> > > 
> > 
> > 
> 
> 

From: "Terwilliger, Ann" <[email-masked]>
To: "'Michael Myers'" <[email-masked]>, Stephen Kent <[email-masked]>
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Thu, 4 Sep 2003 16:57:56 -0700 
Sender: [email-masked]

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:[email-masked]]
Sent: Wednesday, September 03, 2003 8:15 AM
To: Stephen Kent
Cc: [email-masked]
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

Date: Thu, 4 Sep 2003 18:35:18 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

From: "Ambarish Malpani" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, "'Michael Myers'" <[email-masked]>
Cc: "'Stephen Kent'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Thu, 4 Sep 2003 13:50:36 -0700
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Denis Pinkas
> Sent: Thursday, September 04, 2003 11:04 AM
> To: Michael Myers
> Cc: Stephen Kent; [email-masked]
> 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
> > 
> > 
> > 
> 
> 

From: "Michael Myers" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Thu, 4 Sep 2003 12:38:48 -0700
Importance: Normal
Sender: [email-masked]

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

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, September 04, 2003 11:04 AM
> To: Michael Myers
> Cc: Stephen Kent; [email-masked]
> 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

Date: Thu, 04 Sep 2003 20:04:21 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Michael Myers <[email-masked]>
CC: Stephen Kent <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Sender: [email-masked]

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

From: "Matt Cooper" <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>
Cc: "'PKIX List'" <[email-masked]>
Subject: RE: draft-ietf-pkix-certpathbuild-00.txt
Date: Thu, 4 Sep 2003 13:22:13 -0400
Importance: Normal
Sender: [email-masked]

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

> From: Denis Pinkas [mailto:[email-masked]] 
> 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
> > 
> > 
> >>From: Denis Pinkas [mailto:[email-masked]]
> >>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
> >>
> > 
> > 
> > 
> 
> 

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Thu, 4 Sep 2003 09:57:14 -0700
Importance: Normal
Sender: [email-masked]

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

From: "Santosh Chokhani" <[email-masked]>
To: "'Liaquat Khan'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 3 Sep 2003 16:41:45 -0400
Importance: Normal
Sender: [email-masked]

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:[email-masked]] 
Sent: Wednesday, September 03, 2003 4:13 PM
To: 'Santosh Chokhani'; [email-masked]
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]

From: "Liaquat Khan" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 3 Sep 2003 21:12:36 +0100
Importance: Normal
Sender: [email-masked]

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]

Date: Wed, 3 Sep 2003 15:37:25 -0400
To: "Michael Myers" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

At 11:39 -0700 9/3/03, Michael Myers wrote:
>>  From: [email-masked]
>>  [mailto:[email-masked]]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

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 3 Sep 2003 11:39:10 -0700
Importance: Normal
Sender: [email-masked]

> From: [email-masked]
> [mailto:[email-masked]]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

Date: Wed, 3 Sep 2003 19:34:59 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 3 Sep 2003 13:16:31 -0400
Importance: Normal
Sender: [email-masked]

Steve:

Please see responses in-line in []

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]] 
Sent: Wednesday, September 03, 2003 9:33 AM
To: Santosh Chokhani
Cc: [email-masked]
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

Date: Wed, 3 Sep 2003 12:06:03 -0400
To: "Michael Myers" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 3 Sep 2003 08:15:23 -0700
Importance: Normal
Sender: [email-masked]

> 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

Date: Wed, 3 Sep 2003 17:11:04 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

Date: Wed, 3 Sep 2003 10:55:43 -0400
To: "Michael Myers" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

At 7:37 -0700 9/3/03, Michael Myers wrote:
>>  From: [email-masked]
>>  [mailto:[email-masked]]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

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Wed, 3 Sep 2003 07:37:38 -0700
Importance: Normal
Sender: [email-masked]

> From: [email-masked]
> [mailto:[email-masked]]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

Date: Wed, 3 Sep 2003 09:49:29 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Wed, 3 Sep 2003 09:33:05 -0400
To: "Santosh Chokhani" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 3 Sep 2003 14:40:00 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

From: "Santosh Chokhani" <[email-masked]>
To: <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Tue, 2 Sep 2003 18:32:50 -0400
Importance: Normal
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]] On
Behalf Of Stephen Kent
Sent: Tuesday, September 02, 2003 4:00 PM
To: Michael Myers
Cc: Trevor Freeman; Faisal; Denis Pinkas; [email-masked]
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

Date: Tue, 2 Sep 2003 16:00:15 -0400
To: "Michael Myers" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: "Trevor Freeman" <[email-masked]>, "Faisal" <[email-masked]>, "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

From: "Michael Myers" <[email-masked]>
To: "Stephen Kent" <[email-masked]>, "Trevor Freeman" <[email-masked]>
Cc: "Faisal" <[email-masked]>, "Denis Pinkas" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Date: Tue, 2 Sep 2003 12:33:46 -0700
Importance: Normal
Sender: [email-masked]

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

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Stephen Kent
> Sent: Tuesday, September 02, 2003 10:50 AM
> To: Trevor Freeman
> Cc: Faisal; Denis Pinkas; [email-masked]
> 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
>
>

Date: Tue, 2 Sep 2003 14:11:26 -0400
To: Peter Sylvester <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Tue, 2 Sep 2003 14:10:16 -0400
To: "Liaquat Khan" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: "'Faisal'" <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 2 Sep 2003 13:50:09 -0400
To: "Trevor Freeman" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: RE: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: "Faisal" <[email-masked]>, "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 02 Sep 2003 19:20:09 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: UTF8 revisited
Sender: [email-masked]

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.

Subject: UTF8 revisited
Date: Tue, 02 Sep 2003 15:42:56 +0300
From: Lars Johansson <[email-masked]>
To: [email-masked]
Sender: [email-masked]

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
[email-masked] | www.omegapoint.se
tel 070-915 88 40 | fax 08-517 008 29
Omegapoint AB

From: "Anders Rundgren" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Standards for Web-signing
Date: Tue, 2 Sep 2003 15:07:33 +0200
Sender: [email-masked]

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

Date: Mon, 01 Sep 2003 11:12:07 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Sender: [email-masked]

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

Date: Mon, 1 Sep 2003 11:11:31 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

Date: Mon, 01 Sep 2003 11:10:43 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Peter Sylvester <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Sender: [email-masked]

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

Date: Mon, 1 Sep 2003 11:07:59 +0200 (MEST)
From: Peter Sylvester <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Cc: [email-masked]
Sender: [email-masked]

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

Date: Mon, 01 Sep 2003 09:29:51 +0200
From: Denis Pinkas <[email-masked]>
Organization: Bull SA.
To: Trevor Freeman <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-deacon-xkms-aia-00.txt [SCVP-AIA]
Sender: [email-masked]

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
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Friday, August 29, 2003 10:05 AM
> To: Trevor Freeman
> Cc: Stephen Kent; Faisal; [email-masked]
> 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
>>
>>From: [email-masked]
> 
> [mailto:[email-masked]]
> 
>>On Behalf Of Stephen Kent
>>Sent: Thursday, August 28, 2003 6:08 PM
>>To: Faisal
>>Cc: Denis Pinkas; [email-masked]
>>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
>>
> 
> 
> 
>