Re: I-D ACTION:draft-ietf-pkix-okid-00.txt

[[e-mail] (Peter Gutmann)]

Denis Pinkas <[e-mail]> writes:

>So the document should be changed to consider the hash of the certificate
>instead of only the hash of the public key (and of the algorithm identifier).
>
>If we do so, then the "protocol" will also be usable for any type of
>certificate, not only self-signed certificates.

Actually I think the main problem with this draft (which others have also
alluded to indirectly) is that it's trying to do two things at once: Identify
certs using a hash, and provide a way of encoding binary values as user-
friendly keys.  I think it'd be better to split the two, create a universal
user-friendly key-encoding RFC and then move the identifying-certs bit
elsewhere.  The key-encoding is useful in lots of other places, for example
I've been using it with CMP for enrolment details.

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g117vOG00212 for ietf-pkix-bks; Thu, 31 Jan 2002 23:57:24 -0800 (PST)
Received: from atsgw.cyber.ee (atsgw.cyber.ee [195.50.202.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g117vM300208 for <[e-mail]>; Thu, 31 Jan 2002 23:57:22 -0800 (PST)
Received: Message by Barricade atsgw.cyber.ee  with ESMTP id g117vLx24910; Fri, 1 Feb 2002 09:57:21 +0200
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 09:59:50 +0200
From: Margus Freudenthal <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (WinNT; U)
X-Accept-Language: ee,et,en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail]
Subject: Re: TSP interop update
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-info: Headers changed by Barricade
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> 
> What if the client prefers policy X, but will accept anything if that's not
> available?  This is standard procedure for restaurants, libraries, ...
> 
The client doesn't request some specific policy just for the kicks. He
needs the time stamp for proving something to someone. This someone will
most likely have rules according which he verifies time stamps ("I
expect time stamps to be signed by TSA X and issued under policy Y").
Therefore, receiving time stamp with policy which may or may not be
equal or similar to the one requested, is of little value to the
time-stamping client. In addition, this makes the protocol more complex
as the client must implement procedures for dealing with time stamps
with funny and unexpected policy identifiers.



-- 
Margus


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g112tN012567 for ietf-pkix-bks; Thu, 31 Jan 2002 18:55:23 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g112tL312561; Thu, 31 Jan 2002 18:55:21 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id PAA09622; Fri, 1 Feb 2002 15:55:18 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA466129; Fri, 1 Feb 2002 15:55:17 +1300 (NZDT) (sender [e-mail])
Date: Fri, 1 Feb 2002 15:55:17 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>So the document should be changed to consider the hash of the certificate
>instead of only the hash of the public key (and of the algorithm identifier).
>
>If we do so, then the "protocol" will also be usable for any type of
>certificate, not only self-signed certificates.

Actually I think the main problem with this draft (which others have also
alluded to indirectly) is that it's trying to do two things at once: Identify
certs using a hash, and provide a way of encoding binary values as user-
friendly keys.  I think it'd be better to split the two, create a universal
user-friendly key-encoding RFC and then move the identifying-certs bit
elsewhere.  The key-encoding is useful in lots of other places, for example
I've been using it with CMP for enrolment details.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g112oUS12446 for ietf-pkix-bks; Thu, 31 Jan 2002 18:50:30 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g112oR312442 for <[e-mail]>; Thu, 31 Jan 2002 18:50:28 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id PAA10171; Fri, 1 Feb 2002 15:50:21 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA465876; Fri, 1 Feb 2002 15:50:20 +1300 (NZDT) (sender [e-mail])
Date: Fri, 1 Feb 2002 15:50:20 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jean-Marc Desperrier <[e-mail]> writes:

>Clearly  if finding a collision does not suffice for Mallory in the first
>case, but that he has to find a collision for valid data, in that case a valid
>key, then in the second case, he also has to find a collision for valid data,
>therefore a valid certificate. And the second case is as a minimum as
>difficult as the first, because there must be a valid key inside the
>certificate.

Actually finding a collision for a cert isn't nearly that hard, because you can
trivially manipulate the bits of a cert which aren't protected by the signature
(through non-DER encodings, for example).  You can therefore get a large number
of (equally valid but with different hashes) variants of a single cert.  Using
a truncated hash to uniquely identify a cert is therefore somewhat risky.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g112FIu11509 for ietf-pkix-bks; Thu, 31 Jan 2002 18:15:18 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g112FG311504 for <[e-mail]>; Thu, 31 Jan 2002 18:15:16 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id PAA09452; Fri, 1 Feb 2002 15:15:06 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA460341; Fri, 1 Feb 2002 15:15:06 +1300 (NZDT) (sender [e-mail])
Date: Fri, 1 Feb 2002 15:15:06 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman / VPNC <[e-mail]> writes:

>Do other people think that the value of adding check digits is worth the cost
>(making the OKIDs longer and therefore less friendly)? In order to keep the
>symmetry of groups of four characters, we could add four check digits, making
>the string 22 characters instead of 18. Personally, I think it isn't worth it,
>but two people here (one off-list) have said they like the idea.

It's easier if you work backwards instead of forwards, my code takes as
parameter the number of groups of 5 characters which you want, then takes as
many bits of input as it needs (typically from an SHA-1 hash) to fill that.
It's a universal system so you can select the tradeoff between size and
collision-resistance.

(Given that people are going to implement this in all sorts of strange ways
 from a text-only specification, you could just take my code and stick an RFC
 header on it, that way it'll work for everyone with little or no effort).

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g11298211216 for ietf-pkix-bks; Thu, 31 Jan 2002 18:09:08 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g11295311209; Thu, 31 Jan 2002 18:09:05 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id PAA09214; Fri, 1 Feb 2002 15:08:58 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA459979; Fri, 1 Feb 2002 15:08:56 +1300 (NZDT) (sender [e-mail])
Date: Fri, 1 Feb 2002 15:08:56 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Farrell <[e-mail]> writes:

>Without a check digit the user has no way to distinguish the typo case from
>the bad public key value case. I'd say that makes it more likely that the user
>hits the "mistrust" button needlessly. ("Hey, that public key you sent me is
>bad - it didn't match the okid I typed in - maybe you should turn it off
>too.")

That's more or less the reason why I went with check digits, people didn't want
to get fifteen levels deep into a transaction only to discover that the user
had typed the wrong value at the start, and without it there was no way to
differentiate between typos and genuine errors.

I have a full implementation of this if anyone wants it, it'll encode and
decode with check digits, you can specify how many groups of five you want as
output and it'll use that many bits.  There's also a verification function to
identify keys formatted in this manner.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g1124xt11156 for ietf-pkix-bks; Thu, 31 Jan 2002 18:04:59 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1124v311150 for <[e-mail]>; Thu, 31 Jan 2002 18:04:58 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id PAA09143; Fri, 1 Feb 2002 15:04:51 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA459940; Fri, 1 Feb 2002 15:04:50 +1300 (NZDT) (sender [e-mail])
Date: Fri, 1 Feb 2002 15:04:50 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: Comments on draft-ietf-pkix-okid-00.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[Redirected back to PKIX since there's another thread on this as well]

>>>(Note that all the characters are uppercase and that the characters "0", "1",
>>>"8", and "9" are not used.)
>>
>>Hmm, you still run into confusion over O and I.  I've been using:
>>
>>static const char codeTable[] = \
>>
>>       "ABCDEFGHJKLMNPQRSTUVWXYZ23456789";     /* No O/0, I/1 */
>
>We discussed this in the IDN context. We decided that it wasn't that
>important, but I might change it to your string.

I've checked this with users/developers and it was generally regarded as a Good
Thing.

>>You also probably want to checksum the values to detect users mistyping the ID
>>(which is not that uncommon) rather than the cert not matching.
>
>Disagree. These will be used in environments where there is communication
>between the parties, and the person who got the "wrong" calculation would
>simply go back to the person who sent it and say "this doesn't seem right".
>With a checksum, you go from good/bad to good/bad/mistype, and I think that
>three states are much worse than two.

The masses (or at least the "developers" part of the masses) seem to think
otherwise.  There was a strong demand for a means of checking that the user had
entered a correct value before anything further was done - that's why the code
I sent you had an isUserValue() function, you could feed it an arbitrary string
and it would tell you that what you had was a correctly-formatted key.

>Also, it would mess up the symmetry of the "four sets of four".

The consensus among users/developers was to go with groups of five.  Most users
have been conditioned to this pattern by MS registration codes (which have in
turn been emulated by other vendors), moving to groups of four for this one
case was seen as asking for trouble.

Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g111vXG10989 for ietf-pkix-bks; Thu, 31 Jan 2002 17:57:33 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g111vU310983 for <[e-mail]>; Thu, 31 Jan 2002 17:57:31 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id OAA08884; Fri, 1 Feb 2002 14:57:25 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id OAA459887; Fri, 1 Feb 2002 14:57:19 +1300 (NZDT) (sender [e-mail])
Date: Fri, 1 Feb 2002 14:57:19 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis Pinkas <[e-mail]> writes:

>It is simmple: if a client requests a policy and if the server supports that
>policy, why should the server choose a different policy ? Just to annoy the
>client ?

What if the client prefers policy X, but will accept anything if that's not
available?  This is standard procedure for restaurants, libraries, ...

Twitchen: "We'll have the duck".
Fawlty: "Duck's off, sorry".
Twitchen: "We'll have the trifle then".

TSP however requires:

Twitchen: "We'll have the duck".
Fawlty: "You ponce in here expecting to be waited on hand and foot. Well, I'm
         trying to run a TSA here. Have you any idea how much there is to do?
         Go away".

Ah, we have an RFC which standardises Fawlty Towers.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g1113tI09832 for ietf-pkix-bks; Thu, 31 Jan 2002 17:03:55 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1113B309817; Thu, 31 Jan 2002 17:03:11 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101404b87f9917a7aa@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <p05101360b87f4f6e63ee@[165.227.249.20]> <[e-mail]>
Date: Thu, 31 Jan 2002 17:03:15 -0800
To: Jean-Marc Desperrier <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 12:28 AM +0100 2/1/02, Jean-Marc Desperrier wrote:
>Paul Hoffman / IMC wrote:
>
>>  >    So the document should be changed to consider the hash of the 
>>certificate
>>  >    instead of only the hash of the public key (and of the algorithm
>>  >    identifier).
>>
>>  You then make Mallory's job many orders of magnitude easier. Instead
>>  of having to create 2^79 key pairs, he only has to create 2^79 hashes
>>  looking for one that matches Alice's OKID.
>
>No.
>Clearly  if finding a collision does not suffice for Mallory in the 
>first case,
>but that he has to find a collision for valid data, in that case a 
>valid key, then
>in the second case, he also has to find a collision for valid data, 
>therefore a
>valid certificate.
>And the second case is as a minimum as difficult as the first, 
>because there must
>be a valid key inside the certificate.
>
>If just finding a collision is dangerous, not matter if the data it 
>comes from can
>be parsed as valid, then the two cases are perfectly equal.

We disagree here. Given Alice's OCID (it is now a cert ID, not a key 
ID), Mallory creates a template certificate with his own public key 
in it. In the template, he adds an extension that has an octet stream 
of length 10. He then cycles through all the combinations of 2^80 
values in the octet stream until the hash over the template 
certificate matches Alice's OCID, signs the cert, and is done.

Mallory does *not* need to change the public key in an OCID: he can 
change any value in the certificate to get the right hash.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by above.proper.com (8.11.6/8.11.3) id g0VNXfh07436 for ietf-pkix-bks; Thu, 31 Jan 2002 15:33:41 -0800 (PST)
Received: from carbone.certplus.com ([195.101.88.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VNXe307428 for <[e-mail]>; Thu, 31 Jan 2002 15:33:40 -0800 (PST)
Received: from certplus.com ([192.168.212.27]) by carbone.certplus.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 00:33:48 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 00:33:47 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: TSP interop update
References: <[e-mail]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 Jan 2002 23:33:48.0981 (UTC) FILETIME=[BBCC4650:01C1AAAF]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Sylvester wrote:

> A client can never 'prove' that
> a response is not conformant to what he had requested for the simple
> reason that a client cannot prove to someone else that he had send
> a particular request.

If people really need this kind of proof that means it could be an interesting
extension to require the server to include the hash of the request inside an
extension in the token.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VNVLW07344 for ietf-pkix-bks; Thu, 31 Jan 2002 15:31:21 -0800 (PST)
Received: from carbone.certplus.com ([195.101.88.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VNVK307340 for <[e-mail]>; Thu, 31 Jan 2002 15:31:20 -0800 (PST)
Received: from certplus.com ([192.168.212.27]) by carbone.certplus.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 1 Feb 2002 00:28:53 +0100
Message-ID: <[e-mail]>
Date: Fri, 01 Feb 2002 00:28:52 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
References: <[e-mail]> <[e-mail]> <p05101360b87f4f6e63ee@[165.227.249.20]>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 31 Jan 2002 23:28:53.0950 (UTC) FILETIME=[0BF21DE0:01C1AAAF]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul Hoffman / IMC wrote:

> >    So the document should be changed to consider the hash of the certificate
> >    instead of only the hash of the public key (and of the algorithm
> >    identifier).
>
> You then make Mallory's job many orders of magnitude easier. Instead
> of having to create 2^79 key pairs, he only has to create 2^79 hashes
> looking for one that matches Alice's OKID.

No.
Clearly  if finding a collision does not suffice for Mallory in the first case,
but that he has to find a collision for valid data, in that case a valid key, then
in the second case, he also has to find a collision for valid data, therefore a
valid certificate.
And the second case is as a minimum as difficult as the first, because there must
be a valid key inside the certificate.

If just finding a collision is dangerous, not matter if the data it comes from can
be parsed as valid, then the two cases are perfectly equal.




Received: by above.proper.com (8.11.6/8.11.3) id g0VMbwP05659 for ietf-pkix-bks; Thu, 31 Jan 2002 14:37:58 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VMbv305654 for <[e-mail]>; Thu, 31 Jan 2002 14:37:57 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA20290 for <[e-mail]>; Thu, 31 Jan 2002 17:37:54 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510030cb87f76164073@[128.89.88.34]>
Date: Thu, 31 Jan 2002 17:34:51 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: whoops
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Folks,

A PKIX WG member noticed an extraneous "not" in a previous message of 
mine, which made the first sentence below essentially unreadable.

>  > PKIX adopted a time stamping protocol not because it is an
>>  infrastructure service in support of non-repudiation, which is a
>>  common function for PKIs.  A "space stamping" protocol would not seem
>>  to offer a service which is intrinsically related to PKI, and thus
>  > would not seem to be a suitable PKIX work item.

The sentence reads as intended if one ignores "not".

Sorry 'bout that,

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VM87o04942 for ietf-pkix-bks; Thu, 31 Jan 2002 14:08:07 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VM86304938 for <[e-mail]>; Thu, 31 Jan 2002 14:08:06 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA16499; Thu, 31 Jan 2002 17:08:02 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100308b87f6dde51e3@[128.89.88.34]>
In-Reply-To: <00da01c1a999$c3ecefe0$020aff0c@tsg1>
References:  <[e-mail]> <p0510030ab87bbee859e8@[128.33.238.78]> <033d01c1a8d4$14b42d10$020aff0c@tsg1> <p05100305b87cc5ebae43@[10.1.15.165]> <00da01c1a999$c3ecefe0$020aff0c@tsg1>
Date: Thu, 31 Jan 2002 17:03:19 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Space stamping protocol
Cc: <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 6:24 AM -0800 1/30/02, todd glassey wrote:
>Stephen - Its time for you to be replaced as the WG Chair. Take this as an
>official motion before the Group.

You still don't seem to understand how the IETF works. You may appeal 
to the IESG if you don't feel that a WG chair is appropriately 
fulfilling the job. Note that a chair disagreeing with a WG member, 
or questioning a WG member's ability to articulate an argument, or 
questioning the technical merits of an argument does not generally 
qualify as grounds for replacement.

WG's don't vote on chairs (nor do we formally "vote" on anything) and 
no "motions" are entertained.

>This WG above all others needs term limits on how long a WG Chair can sit on
>it and I would like to propose that your time is up and that we need fresh
>blood at the top.Perhaps from someone more adequately representing the rest
>of the World since the WG now is chaired by you and Tim (A US Government
>Employee). Maybe someone like Nick Pope or another. Ian Lloyd of the
>OpenGroup would be a good choice as well. He is the Director of Security
>Verticals within the OG and it would be very powerful for the IETF to get a
>liaison with them as well since they own the UNIX Trademark and its
>validation suites amongst other things.
>
>Either way - its time for you to go on to some other role. You have been
>this WG Chair for too long now.
>
>TODD

Feel free to discuss this with the Security Areas directors, directly.

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g0VLumv04641 for ietf-pkix-bks; Thu, 31 Jan 2002 13:56:48 -0800 (PST)
Received: from anchor-post-32.mail.demon.net (anchor-post-32.mail.demon.net [194.217.242.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VLuk304637 for <[e-mail]>; Thu, 31 Jan 2002 13:56:46 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=gemplus.com) by anchor-post-32.mail.demon.net with esmtp (Exim 2.12 #1) id 16WPCF-0004y6-0W for [e-mail]; Thu, 31 Jan 2002 21:56:43 +0000
Message-ID: <[e-mail]>
Date: Thu, 31 Jan 2002 21:55:13 +0000
From: Dr S N Henson <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I have a few comments on the first draft. They all are roughly based on
whether 80 bits of SHA1 hash is sufficient.

Assuming that the current drafts method of hashing the public key only
is used then various optimizations could be performed to generate large
numbers of private keys. One way be to generate a large number of primes
and generate keys by selecting pairs. This would involve the generation
of ~2^40 primes and ~2^80 multiplication operations to generate each
key. Use of multi-prime RSA would reduce the number of primes that would
need to be generated further.

In any case this would seem to imply that the limiting factor in such an
attack would no longer be the speed of private key generation but the
speed of computing around 2^80 SHA1 hashes.

Could someone comment on whether such an operation is beyond the reach
of current technology?

Second issue is if Alice could gain anything by performing a birthday
attack (which would involve considerably less resources) and generating
two certificates with the same OKID.

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VKUeZ02066 for ietf-pkix-bks; Thu, 31 Jan 2002 12:30:40 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VKUc302062 for <[e-mail]>; Thu, 31 Jan 2002 12:30:38 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 31 Jan 2002 12:30:40 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Thu, 31 Jan 2002 12:30:40 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <D6WG8A7B>; Thu, 31 Jan 2002 12:30:39 -0800
Content-return: allowed
Date: Thu, 31 Jan 2002 12:30:37 -0800
From: Ambarish Malpani <[e-mail]>
Subject: Candidate for moving OCSP to a Draft Standard
To: "'[e-mail]'" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/mixed; boundary="Boundary_(ID_Vw+J6SAKb3Us0Sw9tOar+w)"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_Vw+J6SAKb3Us0Sw9tOar+w)
Content-type: text/plain; charset="ISO-8859-1"


Hi Guys,
    Here is a candidate for moving OCSP to a Draft Standard. There
are no changes in the bytes that go across the wire - basically all
clarifications.

A list of all the changes between this document and RFC 2560 are
in Appendix D (reproduced here).

I hope we can get to the Draft Standard state before this IETF.

Regards,
Ambarish


Appendix D. Changes

   This section contains the differences in this document from RFC 2560

   - Mention Appendix D in Section 1 and added an appendix D.
   - Added a paragraph in Section 1 equating a client with a requestor and
     server with responder
   - Section 2.2 - clarified the explanation of good, revoked and unknown
   - Added Section 2.8 requiring clients and responders to support HTTP
   - Added a note at the end of section 3.2, which allows a client to
     accept a response that provides statuses for only some of the
     certificates requested.
   - Clarified the issuerKeyHash in Section 4.1.1
   - Added "DER encoding of the" in the third paragraph Section 4.1.2
   - Section 4.2.1 - clarified that the signature is on the DER encoding
     of tbsResponseData (and not its hash)
   - Section 4.2.1 - specified the use of the certs field in
     BasicOCSPResponse
   - Section 4.2.1 - clarified how you compute KeyHash when providing
     the ResponderID byKey.
   - Section 4.2.2.2 - removed an extra quote in point 3
   - Section 4.3 - Made RSA mandatory. Also changed the references to
     point to the appropriate documents. Added the references to the
     References section
   - Section 4.4.1 - Clarified that a nonce in the request MUST be
   - included in the response for the response to be trusted.
   - Appendix A - A.1.1. - Got rid of support for GET - not sure that
     anybody does it. It is also unclear how a server would tell a
     client to ever use GET in the URL specified in the AIA
   - Add the module tag for the ASN.1 in OCSP
   - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
     Certificate OPTIONAL in the ASN.1 defintions. The avoids the
     ambiguity of whether the optional sequence may be present, but
     with 0 elements. This was done by definining a new element called
     Certificates, which is used. Look at the defintion of both
     Signature and BasicOCSPResponse.
   - Clarified the meaning of nextUpdate being absent (Section 2.4)
   - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
     correct OID - id-kp-OCSPSigning
   - Clarified criteria for response acceptance (Section 3.2)
   - Added a line in Section 5 indicating that nonces can be used to
     prevent prevent attacks using replays of precomputed responses
   - Added a paragraph in Section 5 requiring nonces to be unique for
     replay protection

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


--Boundary_(ID_Vw+J6SAKb3Us0Sw9tOar+w)
Content-type: application/octet-stream; name="OCSP-draft-03.txt"
Content-disposition: attachment; filename="OCSP-draft-03.txt"
Content-transfer-encoding: quoted-printable






Network Working Group                                           M. =
Myers
Request for Comments: xxxx                           Traceroute =
Security
Category: Standards Track                                      R. =
Ankney
                                                                  =
CertCo
                                                              A. =
Malpani
                                                                =
ValiCert
                                                             S. =
Galperin
                                                                  My =
CFO
                                                                C. =
Adams
                                                    Entrust =
Technologies
Jan 2002


                X.509 Internet Public Key Infrastructure
               Online Certificate Status Protocol - OCSP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is =
unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999-2002).  All Rights =
Reserved.

1.  Abstract

   This document specifies a protocol useful in determining the current
   status of a digital certificate without requiring CRLs. Additional
   mechanisms addressing PKIX operational requirements are specified in
   separate documents.

   An overview of the protocol is provided in section 2. Functional
   requirements are specified in section 4. Details of the protocol are
   in section 5. We cover security issues with the protocol in section
   6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
   syntactic elements and appendix C specifies the mime types for the
   messages. Appendix D describes the changes between this document and
   RFC 2560.

   In this document, the terms client and requestor are used
   interchangeably to indicate the entity making the OCSP request,
   while the terms server and responder are used to indicate the entity
   providing the response.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document (in uppercase, as shown) are to be interpreted as described
   in [RFC2119].


2.  Protocol Overview

   In lieu of or as a supplement to checking against a periodic CRL, it
   may be necessary to obtain timely information regarding the
   revocation status of a certificate (cf. [RFC2459], Section 3.3).
   Examples include high-value funds transfer or large stock trades.

   The Online Certificate Status Protocol (OCSP) enables applications =
to
   determine the (revocation) state of an identified certificate. OCSP
   may be used to satisfy some of the operational requirements of
   providing more timely revocation information than is possible with
   CRLs and may also be used to obtain additional status information. =
An
   OCSP client issues a status request to an OCSP responder and =
suspends
   acceptance of the certificate in question until the responder
   provides a response.

   This protocol specifies the data that needs to be exchanged between
   an application checking the status of a certificate and the server
   providing that status.


2.1  Request

   An OCSP request contains the following data:

   -- protocol version
   -- service request
   -- target certificate identifier
   -- optional extensions which MAY be processed by the OCSP Responder

   Upon receipt of a request, an OCSP Responder determines if:

   1. the message is well formed

   2. the responder is configured to provide the requested service and

   3. the request contains the information needed by the responder. If
   any one of the prior conditions are not met, the OCSP responder
   produces an error message; otherwise, it returns a definitive
   response.

2.2  Response

   OCSP responses can be of various types.  An OCSP response consists =
of
   a response type and the bytes of the actual response. There is one
   basic type of OCSP response that MUST be supported by all OCSP
   servers and clients. The rest of this section pertains only to this
   basic response type.

   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requestor
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, =
indicating
      that the responder may issue OCSP responses for that CA

   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

   The response for each of the certificates in a request consists of

   -- target certificate identifier
   -- certificate status value
   -- response validity interval
   -- optional extensions

   This specification defines the following definitive response
   indicators for use in the certificate status value:

   -- good
   -- revoked
   -- unknown

   The "good" state indicates that the certificate has not been
   revoked. It does not indicate that the certificate was ever issued,
   is or is in its validity interval.

   The "revoked" state indicates that the certificate has been revoked
   (either permanently or temporarily (on hold)).

   The "unknown" state indicates that the responder does not know, or
   is unwilling to tell, the requestor the status of the certificate. A
   client may be able to get a definitive response later, or at another
   responder.

   Response extensions may be used to convey additional information on
   assertions made by the responder regarding the status of the =
certificate
   such as positive statement about issuance, expiry, etc.



2.3  Exception Cases

   In case of errors, the OCSP Responder may return an error message.
   These messages are not signed. Errors can be of the following types:

   -- malformedRequest
   -- internalError
   -- tryLater
   -- sigRequired
   -- unauthorized

   A server produces the "malformedRequest" response if the request
   received does not conform to the OCSP syntax.

   The response "internalError" indicates that the OCSP responder
   reached an inconsistent internal state. The query should be retried,
   potentially with another responder.

   In the event that the OCSP responder is operational, but unable to
   return a status for the requested certificate, the "tryLater"
   response can be used to indicate that the service exists, but is
   temporarily unable to respond.

   The response "sigRequired" is returned in cases where the server
   requires the client sign the request in order to construct a
   response.

   The response "unauthorized" is returned in cases where the client is
   not authorized to make this query to this server.

2.4  Semantics of thisUpdate, nextUpdate and producedAt

   Responses can contain three times in them - thisUpdate, nextUpdate
   and producedAt. The semantics of these fields are:

   - thisUpdate: The time at which the status being indicated is known
                 to be correct
   - nextUpdate: The time at or before which newer information will be
                 available about the status of the certificate
   - producedAt: The time at which the OCSP responder signed this
                 response.

   If nextUpdate is not set, the responder is indicating that it is
   does not know when newer revocation information will be available
   (examples of why a responder might not know when new revocation
   information is likely to be available are that the CA hasn't told
   it, or because newer information is available all the time).



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.

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.

2.7  CA Key Compromise

   If an OCSP responder knows that a particular CA's private key has
   been compromised, it MAY return the revoked state for all
   certificates issued by that CA.

2.8  Transports for OCSP

   While OCSP can be used over many transports, for interoperability,
   all OCSP clients and responders MUST support the use of HTTP [HTTP]
   as the transport.

3.  Functional Requirements

3.1  Certificate Content

   In order to convey to OCSP clients a well-known point of information
   access, CAs SHALL provide the capability to include the
   AuthorityInfoAccess extension (defined in [RFC2459], section =
4.2.2.1)
   in certificates that can be checked using OCSP.  Alternatively, the
   accessLocation for the OCSP provider may be configured locally at =
the
   OCSP client.

   CAs that support an OCSP service, either hosted locally or provided
   by an Authorized Responder, MUST provide for the inclusion of a =
value
   for a uniformResourceIndicator (URI) accessLocation and the OID =
value
   id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

   The value of the accessLocation field in the subject certificate
   defines the transport (e.g. HTTP) used to access the OCSP responder
   and may contain other transport dependent information (e.g. a URL).


3.2  Signed Response Acceptance Requirements

   Prior to accepting a signed response as valid, OCSP clients SHALL
   confirm that:

   1. The certificate identified in a received response corresponds to
   that which was identified in the corresponding request;

   2. The signature on the response is valid;

   3. The identity of the signer matches the intended recipient of the
   request.

   4. The signer is currently authorized to sign the response.

   5. The time at which the status being indicated is known to be
   correct (thisUpdate) is sufficiently recent.

   6. When nextUpdate is set in the response, it is
   greater than the current time.

   7. The producedAt time in the response is sufficiently recent.

   8. If the request contained a nonce, the response must contain the
      same nonce (see section 4.4.1).

   NOTE: The first criteria does not imply that a client should reject
   an OCSP response from a server that contains statuses of
   a superset or subset of the certificates whose statuses were =
requested
   i.e. it is all right for a server to, in an OCSP response provide =
the
   statuses of only some of the certificates requested, and some other
   certificates whose statues were not requested. For example, if a
   client requests the status of certificates with serial numbers 1 and
   2 and gets a response which has the statuses of certificates with
   serial numbers 1 and 3, the client can accept that response for the
   status of the certificate with serial number 1, assuming the rest of =
the
   response acceptance criteria were met.


4.  Detailed Protocol

   The ASN.1 syntax imports terms defined in [RFC2459]. For signature
   calculation, the data to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690].

   ASN.1 EXPLICIT tagging is used as a default unless specified
   otherwise.

   The terms imported from elsewhere are: Extensions,
   CertificateSerialNumber, SubjectPublicKeyInfo, Name,
   AlgorithmIdentifier, CRLReason

4.1  Requests

   This section specifies the ASN.1 specification for a confirmation
   request. The actual formatting of the message could vary depending =
on
   the transport mechanism used (HTTP, SMTP, LDAP, etc.).

4.1.1  Request Syntax

   OCSPRequest     ::=3D     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

   TBSRequest      ::=3D     SEQUENCE {
       version             [0]     EXPLICIT Version DEFAULT v1,
       requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

   Signature       ::=3D     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs               [0] EXPLICIT Certificates OPTIONAL}

   Version         ::=3D             INTEGER  {  v1(0) }

   Request         ::=3D     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

   Certificates    ::=3D     SEQUENCE SIZE(1..MAX) of Certificate

   CertID          ::=3D     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

   issuerNameHash is the hash of the Issuer's distinguished name. The
   hash shall be calculated over the DER encoding of the issuer's name
   field in the certificate being checked. issuerKeyHash is the hash
   of the Issuer's public key. The hash shall be calculated over the
   value of the BIT STRING subjectPublicKey field (excluding the tag,
   length and number of unused bits) in the issuer's certificate. The
   hash algorithm used for both these hashes, is identified in
   hashAlgorithm. serialNumber is the serial number of the certificate
   for which status is being requested.

4.1.2  Notes on the Request Syntax

   The primary reason to use the hash of the CA's public key in =
addition
   to the hash of the CA's name, to identify the issuer, is that it is
   possible that two CAs may choose to use the same Name (uniqueness in
   the Name is a recommendation that cannot be enforced). Two CAs will
   never, however, have the same public key unless the CAs either
   explicitly decided to share their private key, or the key of one of
   the CAs was compromised.

   Support for any specific extension is OPTIONAL. The critical flag
   SHOULD NOT be set for any of them.  Section 4.4 suggests several
   useful extensions.  Additional extensions MAY be defined in
   additional RFCs. Unrecognized extensions MUST be ignored (unless =
they
   have the critical flag set and are not understood).

   The requestor MAY choose to sign the OCSP request. In that case,
   the signature is computed over the DER encoding of the tbsRequest
   structure.  If the request is signed, the requestor SHALL specify
   its name in the requestorName field. Also, for signed requests, the
   requestor MAY include certificates that help the OCSP responder
   verify the requestor's signature in the certs field of Signature.

4.2  Response Syntax

   This section specifies the ASN.1 specification for a confirmation
   response. The actual formatting of the message could vary depending
   on the transport mechanism used (HTTP, SMTP, LDAP, etc.).

4.2.1  ASN.1 Specification of the OCSP Response

   An OCSP response at a minimum consists of a responseStatus field
   indicating the processing status of the prior request. If the value
   of responseStatus is one of the error conditions, responseBytes are
   not set.

   OCSPResponse ::=3D SEQUENCE {
      responseStatus         OCSPResponseStatus,
      responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

   OCSPResponseStatus ::=3D ENUMERATED {
       successful            (0),  --Response has valid confirmations
       malformedRequest      (1),  --Illegal confirmation request
       internalError         (2),  --Internal error in issuer
       tryLater              (3),  --Try again later
                                   --(4) is not used
       sigRequired           (5),  --Must sign the request
       unauthorized          (6)   --Request unauthorized
   }

   The value for responseBytes consists of an OBJECT IDENTIFIER and a
   response syntax identified by that OID encoded as an OCTET STRING.

   ResponseBytes ::=3D       SEQUENCE {
       responseType   OBJECT IDENTIFIER,
       response       OCTET STRING }

   For a basic OCSP responder, responseType will be id-pkix-ocsp-basic.

   id-pkix-ocsp           OBJECT IDENTIFIER ::=3D { id-ad-ocsp }
   id-pkix-ocsp-basic     OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 1 }



   OCSP responders SHALL be capable of producing responses of the id-
   pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL =
be
   capable of receiving and processing responses of the id-pkix-ocsp-
   basic response type.

   The value for response SHALL be the DER encoding of
   BasicOCSPResponse.

   BasicOCSPResponse       ::=3D SEQUENCE {
      tbsResponseData      ResponseData,
      signatureAlgorithm   AlgorithmIdentifier,
      signature            BIT STRING,
      certs                [0] EXPLICIT Certificates OPTIONAL }

   The value for signature SHALL be computed on the DER encoding of
   tbsResponseData.  The responder MAY include certificates that help
   the OCSP client verify the responder's signature in the certs field
   of BasicOCSPResponse.


   ResponseData ::=3D SEQUENCE {
      version              [0] EXPLICIT Version DEFAULT v1,
      responderID              ResponderID,
      producedAt               GeneralizedTime,
      responses                SEQUENCE OF SingleResponse,
      responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

   ResponderID ::=3D CHOICE {
      byName               [1] Name,
      byKey                [2] KeyHash }

   KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key
   -- (i.e. the SHA-1 hash of the value of the BIT STRING =
subjectPublicKey
   -- [excluding the tag, length and number of unused bits] of the
   -- responder's certificate).

   SingleResponse ::=3D SEQUENCE {
      certID                       CertID,
      certStatus                   CertStatus,
      thisUpdate                   GeneralizedTime,
      nextUpdate         [0]       EXPLICIT GeneralizedTime OPTIONAL,
      singleExtensions   [1]       EXPLICIT Extensions OPTIONAL }

   CertStatus ::=3D CHOICE {
       good        [0]     IMPLICIT NULL,
       revoked     [1]     IMPLICIT RevokedInfo,
       unknown     [2]     IMPLICIT UnknownInfo }

   RevokedInfo ::=3D SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

   UnknownInfo ::=3D NULL -- this can be replaced with an enumeration


4.2.2  Notes on OCSP Responses

4.2.2.1  Time

   The thisUpdate and nextUpdate fields define a recommended validity
   interval. This interval corresponds to the {thisUpdate, nextUpdate}
   interval in CRLs. Responses whose nextUpdate value is earlier than
   the local system time value SHOULD be considered unreliable.
   Responses whose thisUpdate time is later than the local system time
   SHOULD be considered unreliable. Responses where the nextUpdate
   value is not set is explained in more detail in Section 2.4).

   The producedAt time is the time at which this response was signed.

4.2.2.2  Authorized Responders

   The key that signs a certificate's status information need not be =
the
   same key that signed the certificate. It is necessary however to
   ensure that the entity signing this information is authorized to do
   so.  Therefore, a certificate's issuer MUST either sign the OCSP
   responses itself or it MUST explicitly designate this authority to
   another entity.  OCSP signing delegation SHALL be designated by the
   inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
   extension included in the OCSP response signer's certificate.  This
   certificate MUST be issued directly by the CA that issued the
   certificate in question.

   id-kp-OCSPSigning OBJECT IDENTIFIER ::=3D {id-kp 9}

   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing use of the id-kp-OCSPSigning value as
   described above. They MAY provide a means of locally configuring one
   or more OCSP signing authorities, and specifying the set of CAs for
   which each signing authority is trusted. They MUST reject the
   response if the certificate required to validate the signature on =
the
   response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-kp-OCSPSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question.

   Additional acceptance or rejection criteria may apply to either the
   response itself or to the certificate used to validate the signature
   on the response.

4.2.2.2.1  Revocation Checking of an Authorized Responder

   Since an Authorized OCSP responder provides status information for
   one or more CAs, OCSP clients need to know how to check that an
   authorized responder's certificate has not been revoked. CAs may
   choose to deal with this problem in one of three ways:

   - A CA may specify that an OCSP client can trust a responder for the
   lifetime of the responder's certificate. The CA does so by including
   the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical
   extension. The value of the extension should be NULL. CAs issuing
   such a certificate should realize that a compromise of the
   responder's key, is as serious as the compromise of a CA key used to
   sign CRLs, at least for the validity period of this certificate. =
CA's
   may choose to issue this type of certificate with a very short
   lifetime and renew it frequently.

   id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 5 }

   - A CA may specify how the responder's certificate be checked for
   revocation. This can be done using CRL Distribution Points if the
   check should be done using CRLs or CRL Distribution Points, or
   Authority Information Access if the check should be done in some
   other way. Details for specifying either of these two mechanisms are
   available in [RFC2459].

   - A CA may choose not to specify any method of revocation checking
   for the responder's certificate, in which case, it would be up to =
the
   OCSP client's local security policy to decide whether that
   certificate should be checked for revocation or not.

4.3  Mandatory and Optional Cryptographic Algorithms

   OCSP clients and responders MUST support the RSA signature
   algorithm. This algorithm is defined in RFC 2437 [RFC2437]. OCSP
   clients and responders MAY support the DSA signature algorithm. This
   algorithm is defined in FIPS Pub 186 [DSS].
   OCSP responders MUST support the SHA1 hashing algorithm. This
   algorithm is defined in FIPS Pub 180-1 [SHA1].

4.4  Extensions

   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.  For
   each extension, the definition indicates its syntax, processing
   performed by the OCSP Responder, and any extensions which are
   included in the corresponding response.

4.4.1  Nonce

   The nonce cryptographically binds a response to a request to
   prevent replay attacks. In a request, a nonce (if present) is
   included as one of the requestExtensions in requests, while in
   responses (if present) it is included as one of the
   responseExtensions. In both the request and the response, the nonce
   is identified by the object identifier id-pkix-ocsp-nonce, while
   the extnValue is the value of the nonce. If a nonce is included in
   a request, then the response MUST contain the same nonce. Responses
   without the same nonce MUST NOT be trusted.

   id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 2 }

4.4.2  CRL References

   It may be desirable for the OCSP responder to indicate the CRL on
   which a revoked or onHold certificate is found. This can be useful
   where OCSP is used between repositories, and also as an auditing
   mechanism. The CRL may be specified by a URL (the URL at which the
   CRL is available), a number (CRL number) or a time (the time at =
which
   the relevant CRL was created). These extensions will be specified as
   singleExtensions. The identifier for this extension will be id-pkix-
   ocsp-crl, while the value will be CrlID.

   id-pkix-ocsp-crl       OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 3 }

   CrlID ::=3D SEQUENCE {
      crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
      crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
      crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

   For the choice crlUrl, the IA5String will specify the URL at which
   the CRL is available. For crlNum, the INTEGER will specify the value
   of the CRL number extension of the relevant CRL. For crlTime, the
   GeneralizedTime will indicate the time at which the relevant CRL was
   issued.

4.4.3  Acceptable Response Types

   An OCSP client MAY wish to specify the kinds of response types it
   understands. To do so, it SHOULD use an extension with the OID id-
   pkix-ocsp-response, and the value AcceptableResponses.  This
   extension is included as one of the requestExtensions in requests.
   The OIDs included in AcceptableResponses are the OIDs of the various
   response types this client can accept (e.g., id-pkix-ocsp-basic).

   id-pkix-ocsp-response  OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 4 }

   AcceptableResponses ::=3D SEQUENCE OF OBJECT IDENTIFIER

   As noted in section 4.2.1, OCSP responders SHALL be capable of
   responding with responses of the id-pkix-ocsp-basic response type.
   Correspondingly, OCSP clients SHALL be capable of receiving and
   processing responses of the id-pkix-ocsp-basic response type.

4.4.4  Archive Cutoff

   An OCSP responder MAY choose to retain revocation information beyond
   a certificate's expiration. The date obtained by subtracting this
   retention interval value from the producedAt time in a response is
   defined as the certificate's "archive cutoff" date.

   OCSP-enabled applications would use an OCSP archive cutoff date to
   contribute to a proof that a digital signature was (or was not)
   reliable on the date it was produced even if the certificate needed
   to validate the signature has long since expired.

   OCSP servers that provide support for such historical reference
   SHOULD include an archive cutoff date extension in responses.  If
   included, this value SHALL be provided as an OCSP singleExtensions
   extension identified by id-pkix-ocsp-archive-cutoff and of syntax
   GeneralizedTime.

   id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::=3D { id-pkix-ocsp =
6 }

   ArchiveCutoff ::=3D GeneralizedTime

   To illustrate, if a server is operated with a 7-year retention
   interval policy and status was produced at time t1 then the value =
for
   ArchiveCutoff in the response would be (t1 - 7 years).

4.4.5  CRL Entry Extensions

   All the extensions specified as CRL Entry Extensions - in Section =
5.3
   of [RFC2459] - are also supported as singleExtensions.

4.4.6  Service Locator

   An OCSP server may be operated in a mode whereby the server receives
   a request and routes it to the OCSP server which is known to be
   authoritative for the identified certificate.  The serviceLocator
   request extension is defined for this purpose.  This extension is
   included as one of the singleRequestExtensions in requests.

   id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::=3D { id-pkix-ocsp =
7 }

   ServiceLocator ::=3D SEQUENCE {
       issuer    Name,
       locator   AuthorityInfoAccessSyntax OPTIONAL }

   Values for these fields are obtained from the corresponding fields =
in
   the subject certificate.

5.  Security Considerations

   For this service to be effective, certificate using systems must
   connect to the certificate status service provider. In the event =
such
   a connection cannot be obtained, certificate-using systems could
   implement CRL processing logic as a fall-back position.

   A denial of service vulnerability is evident with respect to a flood
   of queries. The production of a cryptographic signature =
significantly
   affects response generation cycle time, thereby exacerbating the
   situation. Unsigned error responses open up the protocol to another
   denial of service attack, where the attacker sends false error
   responses.

   The use of precomputed responses allows replay attacks in which an
   old (good) response is replayed prior to its expiration date but
   after the certificate has been revoked. Deployments of OCSP should
   carefully evaluate the benefit of precomputed responses against the
   probability of a replay attack and the costs associated with its
   successful execution. By placing a nonce in the request, clients
   can prevent replay attacks.

   Nonces should be random. If the nonce is generated in a non-random
   way, replay attacks MAY be possible.

   Requests do not contain the responder they are directed to. This
   allows an attacker to replay a request to any number of OCSP
   responders.

   The reliance of HTTP caching in some deployment scenarios may result
   in unexpected results if intermediate servers are incorrectly
   configured or are known to possess cache management faults.
   Implementors are advised to take the reliability of HTTP cache
   mechanisms into account when deploying OCSP over HTTP.



6.  References

   [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
             X.509 Public Key Infrastructure Certificate and CRL
             Profile", RFC 2459, January 1999.

   [HTTP]    Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
             Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", =
RFC
             2068, January 1997.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [URL]     Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
             Resource Locators (URL)", RFC 1738, December 1994.

   [X.690]   ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995,
             Information Technology - ASN.1 encoding rules:
             Specification of Basic Encoding Rules (BER), Canonical
             Encoding Rules (CER) and Distinguished Encoding Rules
             (DER).

   [SHA1]    National Institute of Standards and Technology.
             FIPS Pub 180-1: Secure Hash Standard.  17 April 1995.

   [RFC2437] Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0",
             RFC 2437, October 1998.

   [DSS]     National Institute of Standards and Technology.
             FIPS Pub 186: Digital Signature Standard.  19 May 1994.





7.  Authors' Addresses

   Michael Myers
   TraceRoute Security, Inc.

   EMail: [e-mail]


   Rich Ankney
   CertCo, LLC
   13506 King Charles Dr.
   Chantilly, VA  20151

   EMail: [e-mail]


   Ambarish Malpani
   ValiCert, Inc.
   1215 Terra Bella Ave.
   Mountain View, CA 94043

   Phone: [phone]
   EMail: [e-mail]


   Slava Galperin
   My CFO, Inc.
   1945 Charleston Road
   Mountain View, CA

   EMail: [e-mail]


   Carlisle Adams
   Entrust Technologies
   750 Heron Road, Suite E08
   Ottawa, Ontario
   K1V 1A7
   Canada

   EMail: [e-mail]





Appendix A.

A.1 OCSP over HTTP

   This section describes the formatting that will be done to the
   request and response to support HTTP.

A.1.1 Request

   HTTP based OCSP requests MUST use the POST method to submit their
   requests.  Where privacy is a requirement, OCSP transactions
   exchanged using HTTP MAY be protected using either TLS/SSL or some
   other lower layer protocol.

   An OCSP request using the POST method is constructed as follows: The
   Content-Type header has the value "application/ocsp-request" while
   the body of the message is the binary value of the DER encoding of
   the OCSPRequest.

A.1.2 Response

   An HTTP-based OCSP response is composed of the appropriate HTTP
   headers, followed by the binary value of the DER encoding of the
   OCSPResponse. The Content-Type header has the value
   "application/ocsp-response". The Content-Length header SHOULD =
specify
   the length of the response. Other HTTP headers MAY be present and =
MAY
   be ignored if not understood by the requestor.








Appendix B.  OCSP in ASN.1


PKIXOCSP {iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-ocsp(14)}


OCSP DEFINITIONS EXPLICIT TAGS::=3D

BEGIN

IMPORTS

      -- Directory Authentication Framework (X.509)
             Certificate, AlgorithmIdentifier, CRLReason
             FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                      module(1) authenticationFramework(7) 3 }


-- PKIX Certificate Extensions
             AuthorityInfoAccessSyntax
          FROM PKIX1Implicit88 {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                  id-mod(0) id-pkix1-implicit-88(2)}


          Name, GeneralName, CertificateSerialNumber, Extensions,
           id-kp, id-ad-ocsp
             FROM PKIX1Explicit88 {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                  id-mod(0) id-pkix1-explicit-88(1)};

OCSPRequest     ::=3D     SEQUENCE {
    tbsRequest                  TBSRequest,
    optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

TBSRequest      ::=3D     SEQUENCE {
    version             [0] EXPLICIT Version DEFAULT v1,
    requestorName       [1] EXPLICIT GeneralName OPTIONAL,
    requestList             SEQUENCE OF Request,
    requestExtensions   [2] EXPLICIT Extensions OPTIONAL }

Signature       ::=3D     SEQUENCE {
    signatureAlgorithm   AlgorithmIdentifier,
    signature            BIT STRING,
    certs                [0] EXPLICIT Certificates OPTIONAL }

Version  ::=3D  INTEGER  {  v1(0) }

Request ::=3D     SEQUENCE {
    reqCert                    CertID,
    singleRequestExtensions    [0] EXPLICIT Extensions OPTIONAL }

Certificates    ::=3D     SEQUENCE SIZE(1..MAX) of Certificate

CertID ::=3D SEQUENCE {
    hashAlgorithm            AlgorithmIdentifier,
    issuerNameHash     OCTET STRING, -- Hash of Issuer's DN
    issuerKeyHash      OCTET STRING, -- Hash of Issuers public key
    serialNumber       CertificateSerialNumber }

OCSPResponse ::=3D SEQUENCE {
   responseStatus         OCSPResponseStatus,
   responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

OCSPResponseStatus ::=3D ENUMERATED {
    successful            (0),      --Response has valid confirmations
    malformedRequest      (1),      --Illegal confirmation request
    internalError         (2),      --Internal error in issuer
    tryLater              (3),      --Try again later
                                    --(4) is not used
    sigRequired           (5),      --Must sign the request
    unauthorized          (6)       --Request unauthorized
}

ResponseBytes ::=3D       SEQUENCE {
    responseType   OBJECT IDENTIFIER,
    response       OCTET STRING }

BasicOCSPResponse       ::=3D SEQUENCE {
   tbsResponseData      ResponseData,
   signatureAlgorithm   AlgorithmIdentifier,
   signature            BIT STRING,
   certs                [0] EXPLICIT Certificates OPTIONAL }

ResponseData ::=3D SEQUENCE {
   version              [0] EXPLICIT Version DEFAULT v1,
   responderID              ResponderID,
   producedAt               GeneralizedTime,
   responses                SEQUENCE OF SingleResponse,
   responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

ResponderID ::=3D CHOICE {
   byName   [1] Name,
   byKey    [2] KeyHash }

KeyHash ::=3D OCTET STRING --SHA-1 hash of responder's public key
                         --(excluding the tag, length and number of =
unused
                         -- bits fields)

SingleResponse ::=3D SEQUENCE {
   certID                       CertID,
   certStatus                   CertStatus,
   thisUpdate                   GeneralizedTime,
   nextUpdate           [0]     EXPLICIT GeneralizedTime OPTIONAL,
   singleExtensions     [1]     EXPLICIT Extensions OPTIONAL }

CertStatus ::=3D CHOICE {
    good                [0]     IMPLICIT NULL,
    revoked             [1]     IMPLICIT RevokedInfo,
    unknown             [2]     IMPLICIT UnknownInfo }

RevokedInfo ::=3D SEQUENCE {
    revocationTime              GeneralizedTime,
    revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

UnknownInfo ::=3D NULL -- this can be replaced with an enumeration

ArchiveCutoff ::=3D GeneralizedTime

AcceptableResponses ::=3D SEQUENCE OF OBJECT IDENTIFIER

ServiceLocator ::=3D SEQUENCE {
    issuer    Name,
    locator   AuthorityInfoAccessSyntax }

-- Object Identifiers

id-kp-OCSPSigning            OBJECT IDENTIFIER ::=3D { id-kp 9 }
id-pkix-ocsp                 OBJECT IDENTIFIER ::=3D { id-ad-ocsp }
id-pkix-ocsp-basic           OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 1 }
id-pkix-ocsp-nonce           OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 2 }
id-pkix-ocsp-crl             OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 3 }
id-pkix-ocsp-response        OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 4 }
id-pkix-ocsp-nocheck         OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 5 }
id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 6 }
id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::=3D { id-pkix-ocsp 7 }


END




Appendix C. MIME registrations

C.1 application/ocsp-request

   To: [e-mail]
   Subject: Registration of MIME media type application/ocsp-request

   MIME media type name: application

   MIME subtype name: ocsp-request

   Required parameters: None

   Optional parameters: None

   Encoding considerations: binary

   Security considerations: Carries a  request for information. This
   request may optionally be cryptographically signed.

   Interoperability considerations: None

   Published specification: IETF PKIX Working Group Draft on Online
   Certificate Status Protocol - OCSP

   Applications which use this media type: OCSP clients

   Additional information:

      Magic number(s): None
      File extension(s): .ORQ
      Macintosh File Type Code(s): none

   Person & email address to contact for further information:
   Ambarish Malpani <[e-mail]>

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <[e-mail]>

C.2 application/ocsp-response

   To: [e-mail]
   Subject: Registration of MIME media type application/ocsp-response

   MIME media type name: application
   MIME subtype name: ocsp-response

   Required parameters: None

   Optional parameters: None
   Encoding considerations: binary

   Security considerations: Carries a cryptographically signed response

   Interoperability considerations: None

   Published specification: IETF PKIX Working Group Draft on Online
   Certificate Status Protocol - OCSP

   Applications which use this media type: OCSP servers

   Additional information:

   Magic number(s): None
   File extension(s): .ORS
   Macintosh File Type Code(s): none

   Person & email address to contact for further information:
   Ambarish Malpani <[e-mail]>

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <[e-mail]>


Appendix D. Changes

   This section contains the differences in this document from RFC 2560

   - Mention Appendix D in Section 1 and added an appendix D.
   - Added a paragraph in Section 1 equating a client with a requestor =
and
     server with responder
   - Section 2.2 - clarified the explanation of good, revoked and =
unknown
   - Added Section 2.8 requiring clients and responders to support HTTP
   - Added a note at the end of section 3.2, which allows a client to
     accept a response that provides statuses for only some of the
     certificates requested.
   - Clarified the issuerKeyHash in Section 4.1.1
   - Added "DER encoding of the" in the third paragraph Section 4.1.2
   - Section 4.2.1 - clarified that the signature is on the DER =
encoding
     of tbsResponseData (and not its hash)
   - Section 4.2.1 - specified the use of the certs field in
     BasicOCSPResponse
   - Section 4.2.1 - clarified how you compute KeyHash when providing
     the ResponderID byKey.
   - Section 4.2.2.2 - removed an extra quote in point 3
   - Section 4.3 - Made RSA mandatory. Also changed the references to
     point to the appropriate documents. Added the references to the
     References section
   - Section 4.4.1 - Clarified that a nonce in the request MUST be
   - included in the response for the response to be trusted.
   - Appendix A - A.1.1. - Got rid of support for GET - not sure that
     anybody does it. It is also unclear how a server would tell a
     client to ever use GET in the URL specified in the AIA
   - Add the module tag for the ASN.1 in OCSP
   - Made SEQUENCE OF Certificate OPTIONAL to SEQUENCE SIZE(1..MAX) of
     Certificate OPTIONAL in the ASN.1 defintions. The avoids the
     ambiguity of whether the optional sequence may be present, but
     with 0 elements. This was done by definining a new element called
     Certificates, which is used. Look at the defintion of both
     Signature and BasicOCSPResponse.
   - Clarified the meaning of nextUpdate being absent (Section 2.4)
   - Fixed typo where we referred to id-ad-ocspSigning, to reflect the
     correct OID - id-kp-OCSPSigning
   - Clarified criteria for response acceptance (Section 3.2)
   - Added a line in Section 5 indicating that nonces can be used to
     prevent prevent attacks using replays of precomputed responses
   - Added a paragraph in Section 5 requiring nonces to be unique for
     replay protection

Full Copyright Statement

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph =
are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




--Boundary_(ID_Vw+J6SAKb3Us0Sw9tOar+w)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VJriv00748 for ietf-pkix-bks; Thu, 31 Jan 2002 11:53:44 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VJrg300743 for <[e-mail]>; Thu, 31 Jan 2002 11:53:43 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101360b87f4f6e63ee@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Thu, 31 Jan 2002 11:53:46 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 5:11 PM +0100 1/31/02, Denis Pinkas wrote:
>1) The current document addresses only the verification of self-signed
>    certificates, but is subject to security attacks (i.e. substitution
>    of self-signed certificates) because only the hash of the public key
>    contained in the self-signed certificate is verified:

Correct. I have yet to hear of an interesting attack where Mallory 
has some good reason to substitute "Alice A" for "Alice B" on Bob's 
system when "Alice A" and "Alice B" are both self-signed.

>  this would mandate
>    that a CA is not allowed to issue more than one self-signed certificate
>    with the same public key in it,

Where in the document did it say this? CAs and non-CA self-signers 
are allowed to do whatever they want.

>  which is indeed a restriction that is
>    not acceptable.

Agree; that's why it doesn't say it.

>    So the document should be changed to consider the hash of the certificate
>    instead of only the hash of the public key (and of the algorithm
>    identifier).

You then make Mallory's job many orders of magnitude easier. Instead 
of having to create 2^79 key pairs, he only has to create 2^79 hashes 
looking for one that matches Alice's OKID. That doesn't seem like a 
good security choice, particularly because we can assume that it is 
more likely that people will work on hardware hash acceleration than 
they will on hardware key generation.

>    If we do so, then the "protocol" will also be usable for any type of
>    certificate, not only self-signed certificates.

Correct, but at the cost of making the protocol much easier to break.

>2) The abstract should rephrased as:
>
>    The Out-of-Band Key Identifier Protocol (OKID) is a user-friendly
>    out-of-band way to install certificates.

Disagree. This protocol does not install certificates. It helps with 
only one step of that process.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by above.proper.com (8.11.6/8.11.3) id g0VIcwQ28451 for ietf-pkix-bks; Thu, 31 Jan 2002 10:38:58 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VIct328445 for <[e-mail]>; Thu, 31 Jan 2002 10:38:56 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA22735; Thu, 31 Jan 2002 19:38:49 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Thu, 31 Jan 2002 19:38:49 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA26671; Thu, 31 Jan 2002 19:38:48 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA10021; Thu, 31 Jan 2002 19:38:48 +0100 (MET)
Date: Thu, 31 Jan 2002 19:38:48 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> You would like the following : when a client asks for a specific policy 
> he may get back a different one that is supposed to be "equivalent" 
> *in the opinion of the server*. 

No. I simply wanted an explanation why You have
changed the text in draft version 4,
and/or to remove in one way or another the current 
inconsistencies in the text since on one side it tell 
'SHOULD be identical' and on one side 'MUST return the same value'.

Below You gave the first indication of a response. 'because
You are not in favor.' So be it.  

IMO It is outside the protocol to interprete the meaning of
a possible different value in the policy. 

> 
> I wonder if this will be considered as equivalent in the opinion of the
> client as well. I am not in favor of supporting such a feature since it
> would open endless disputes. In addition, the client would not even be able
> to prove that he got the equivalent policy in response to another one 
> and thus would not be able to prove that the server is responsible for 
> a misuse.

What endless disputes? Among whom? A client can never 'prove' that
a response is not conformant to what he had requested for the simple
reason that a client cannot prove to someone else that he had send 
a particular request. 

Or, how can a client 'prove' or 'determine' that a response to a 
request without a policy is 'acceptable'?  






Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VHwl323977 for ietf-pkix-bks; Thu, 31 Jan 2002 09:58:47 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VHwk323972 for <[e-mail]>; Thu, 31 Jan 2002 09:58:46 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id TAA12268; Thu, 31 Jan 2002 19:00:12 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA15762; Thu, 31 Jan 2002 18:58:12 +0100
Message-ID: <[e-mail]>
Date: Thu, 31 Jan 2002 18:58:07 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: TSP interop update
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

This e-mail finally provides the motivation about your request changes 
about the sentence of the policy request and response.

Why didn't you say it sooner ? This would have save time and e-mails.

You would like the following : when a client asks for a specific policy 
he may get back a different one that is supposed to be "equivalent" 
*in the opinion of the server*. 

I wonder if this will be considered as equivalent in the opinion of the
client as well. I am not in favor of supporting such a feature since it
would open endless disputes. In addition, the client would not even be able
to prove that he got the equivalent policy in response to another one 
and thus would not be able to prove that the server is responsible for 
a misuse.

Denis


> > > Anyway:
> > >
> > > My question is not answered: Why had a change to force a policy been made in
> > > draft 4.
> >
> > Draft 3 was stating: "The reqPolicy field, if included, indicates the policy
> > under which the TimeStampToken should be provided."
> >
> > Draft 4 was stating: "The reqPolicy field, if included, indicates the policy
> > under which the TimeStampToken should be provided."
> 
> This is not the text I am refering to:
> 
> draft 3:
> "The policy field MUST indicate the TSAs policy under which the response
>  was produced.
> 
> draft 4:
> 
> "The policy field MUST indicate the TSAs policy under which the response was
>  produced. If a similar field was present in the TimeStampReq, then it MUST
>  have the same value, otherwise an error (badRequest) MUST be returned. "
> 
> I would have expected that the statement that You referenced would have
> been changed accordingly, something like:
> 
> "The reqPolicy field, if included, indicates the policy
>  under which the TimeStampToken SHALL be provided."
> 
> In draft 9 this line became:
> 
> "The reqPolicy field, if included, indicates the policy
>  under which the TimeStampToken SHOULD be provided."
> 
> > I do not see any difference, so question is meaningless.
> >
> > > There was no announcement, and it was quite easy to overlook this
> > > since in two other places requierments for policy had not been changed.
> > >
> > > I don't think that it is necessary to have an identical policy.
> >
> > It is simmple: if a client requests a policy and if the server supports
> > that policy, why should the server choose a different policy ?
> Because the policy may have been replaced by a newer one which is
> defined as compatible.
> 
> > Just to annoy the client ?
> 
> The text says already that the client MAY ignore the policy, and that
> it SHOULD check whether it is acceptable. This seems to be an indication
> to me that the initial intension was that a TSA can creat a different
> value.
> 
> TSA may change their policies and issue 'compatible ones' with a different
> id. Why should one annoy the client and ask for an upgrade?
> The possibility of not having a policy may not be possible because
> the TSA supports different sets/classes.
> 
> >
> > Denis
> Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VGBdk17319 for ietf-pkix-bks; Thu, 31 Jan 2002 08:11:39 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VGBZ317307; Thu, 31 Jan 2002 08:11:35 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA08596; Thu, 31 Jan 2002 17:13:01 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA17320; Thu, 31 Jan 2002 17:11:00 +0100
Message-ID: <[e-mail]>
Date: Thu, 31 Jan 2002 17:11:00 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Paul Hoffman <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

It is a good initiative that I welcomme.

However, I have strong reservations on this first draft.

1) The current document addresses only the verification of self-signed
   certificates, but is subject to security attacks (i.e. substitution 
   of self-signed certificates) because only the hash of the public key 
   contained in the self-signed certificate is verified: this would mandate 
   that a CA is not allowed to issue more than one self-signed certificate 
   with the same public key in it, which is indeed a restriction that is 
   not acceptable.

   So the document should be changed to consider the hash of the certificate
   instead of only the hash of the public key (and of the algorithm
   identifier).

   If we do so, then the "protocol" will also be usable for any type of
   certificate, not only self-signed certificates.

2) The abstract should rephrased as:

   The Out-of-Band Key Identifier Protocol (OKID) is a user-friendly
   out-of-band way to install certificates.


Denis 






 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Public-Key Infrastructure (X.509) Working Group of the IETF.
> 
>         Title           : Out-of-Band Key Identifier Protocol (OKID)
>         Author(s)       : P. Hoffman
>         Filename        : draft-ietf-pkix-okid-00.txt
>         Pages           :
>         Date            : 29-Jan-02
> 
> In general, certificates need not be communicated with communication or
> storage media that are integrity-secure or authentic. This is because
> certificates are digitally signed and users are expected to validate the
> signatures using configured trust anchors. However, distribution of
> trust anchor certificates, or distribution of self-signed end-entity
> certificates, requires a mechanism for establishing the authenticity of
> the public key contained in such certificates.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-okid-00.txt
> 
> To remove yourself from the IETF Announcement list, send a message to
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
>         "get draft-ietf-pkix-okid-00.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 
> Internet-Drafts can also be obtained by e-mail.
> 
> Send a message to:
>         [e-mail].
> In the body type:
>         "FILE /internet-drafts/draft-ietf-pkix-okid-00.txt".
> 
> NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
> 
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.
> 
>   ----------------------------------------------------------------------------
> Content-Type: text/plain
> Content-ID:     <[e-mail]>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VCrQ609368 for ietf-pkix-bks; Thu, 31 Jan 2002 04:53:26 -0800 (PST)
Received: from mail.utfors.se (mail.utfors.se [195.58.103.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VCrN309364 for <[e-mail]>; Thu, 31 Jan 2002 04:53:24 -0800 (PST)
Received: from arport ([62.119.75.13]) by mail.utfors.se (8.8.8/8.8.8) with SMTP id NAA03591; Thu, 31 Jan 2002 13:53:01 +0100 (MET)
Message-ID: <005c01c1aa56$1f72c850$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Roberto Opazo Gazmuri" <[e-mail]>, "PKIX \(Grupo de la IETF\)" <[e-mail]>, "Stefan Santesson" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>
References: <[e-mail]>
Subject: Re: Local regulations about PI's codification
Date: Thu, 31 Jan 2002 13:52:18 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Stefan,
Whatever the solution becomes, I don't want it to be bound to 3039 as there
are other certificate classes like organization-certificates that has the same
need.

The PI-draft as it stands today does not take this in account.

Anders

----- Original Message -----
From: "Stefan Santesson" <[e-mail]>
To: "Roberto Opazo Gazmuri" <[e-mail]>; "PKIX (Grupo de la IETF)" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>
Sent: Thursday, January 31, 2002 02:17
Subject: Re: Local regulations about PI's codification



Lets not mix technical solutions with legal concepts for assigning national
ID-codes.

I would suggest a vocabulary where we clearly separate technical concepts
as PI, Serial number (and other potential candidates) from national
concepts of civic registration codes for individuals and organizations.

The terminology used here implies that inclusion of a civic registration
code requires the PI solution, which is not true.
With regard to technical concepts I see mainly 2 solutions which I would
point out, might be one to much since they work very similar.

1) Serial number in the subject field. This field can hold any type of
registration code. If you want to define the semantics of this attribute
there is a solution to assign a semantics OID and name the registration
authority, defined in RFC 3039 section 3.2.5.1

2) a PI according to the PI draft, stored in subject Alt Name, where you
can define semantics and registration authority through an OID and attach
the identifier to it.

2 solutions to one problem.

I would prefer to reduce them to 1.

Maybe its time to evaluate and review RFC 3039 before we create a new CMC
versus CMP situation.
I have some defect reports noted on RFC 3039 that ought to be fixed anyway.

Just a thought.

/Stefan


At 17:41 2002-01-30 -0300, Roberto Opazo Gazmuri wrote:

>Hello,
>
>I want to thank the people ho answered my previous e-mail titled '"Subject
>Alternative Name" v/s "Subject/Serial Number"'. Now we have a little list of
>Local Solutions for the problem of putting a Permanent Identifier in a
>certificate. At the end of this e-mail I am sending you a summary.
>
>It gets the attention to see that there is only 1 equivalent solution
>(Sweden and Finland) and that gives Denis Pinkas a powerful base to say "I
>believe that it is time to progress the Permanent Identifier draft".
>
>The purpose of this e-mail is to put order in the information we are
>receiving and to ask you an effort to provide more information because the
>list of real examples is too short. Just 6 countries!
>
>What is going on in the States?
>
>And what about Spain?
>
>I offer my self to administrate the collected information and send to the
>list a new summary when new information available justifies that.
>
>I think we should not waste time looking at individual CA's solutions,
>because a local regulation is a much stronger reference and there are to
>many CA's out of control.
>
>Best regards,
>
>Opazo, Roberto ([e-mail])
>CEO - www.acepta.com
>Certification Authority for Chile
>
>This is the first summary and format proposition about this information...
>
>---------------------------
>
>Summary's Date: January 30, 2002.
>Local regulations about PI's codification
>
>
>1.- Australia
>PI: Australian business number (ABN), it is a PI for companies.
>Codification:
>   privateExtension(1.2.36.1.333.1) = ABN
>Local authority:
>   Australian Government
>IETF Information provider:
>   Richard Culshaw [[e-mail]]
>
>2.- Chile
>PI: Rol Unico Nacional (Run)
>Codification:
>   subjectAltName[i].otherName[1].RunOID = run
>Local authority:
>   Now: Service of Internal Taxes
>   Probably soon: The Ministry of Economy
>IETF Information provider:
>   Roberto Opazo [[e-mail]]
>
>3.- Finland
>PI: Person number (person-number)
>Codification:
>   subject.serialNumber= person-number
>Local authority:
>   ?
>IETF Information provider:
>   Anders Rundgren [[e-mail]]
>
>4.- Hong Kong
>PI: Hong Kong Identifier (HKID), the HKID is by law "private data".
>Codification:
>   subjectAltName[1].dNSName = SHA-1( RSA_PrivateKey( SHA-1( HKID ) ) )
>Local authority:
>   Government, Hongkong Post
>IETF Information provider:
>   Al Arsenault [[e-mail]]
>
>5.- Italy
>PI: Codice Fiscale (CodiceFiscale)
>Codification:
>   subject.CN = LastName/FirstName/CodiceFiscale/CertificateNumber
>Local authority:
>   ?
>IETF Information provider:
>   ARBIA Sig. Stefano [[e-mail]]
>
>6.- Sweden
>PI: person-number
>Codification:
>   subject.serialNumber= person-number
>Local authority:
>   The Swedish standard SS614331
>IETF Information provider:
>   Anders Rundgren [[e-mail]]
>   Henrik Ståhl [[e-mail]]




Received: by above.proper.com (8.11.6/8.11.3) id g0VC0hm04965 for ietf-pkix-bks; Thu, 31 Jan 2002 04:00:43 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VC0g304955 for <[e-mail]>; Thu, 31 Jan 2002 04:00:42 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23951; Thu, 31 Jan 2002 07:00:40 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Date: Thu, 31 Jan 2002 07:00:40 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Operational 
                          Protocols: Certificate Store Access via HTTP
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-pkix-certstore-http-02.txt
	Pages		: 
	Date		: 30-Jan-02
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories (although RFC 2585 covers fetching certificates via HTTP, this merely mentions that certificates may be fetched from a static URL, which doesn't provide a general-purpose interface to a certificate store). Additional mechanisms addressing PKIX operational requirements are specified in separate documents.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-certstore-http-02.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0VB1kJ02356 for ietf-pkix-bks; Thu, 31 Jan 2002 03:01:46 -0800 (PST)
Received: from mail.hackmasters.net ([217.133.235.63]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0VB1h302350 for <[e-mail]>; Thu, 31 Jan 2002 03:01:44 -0800 (PST)
Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id 05EA29289 for <[e-mail]>; Thu, 31 Jan 2002 12:05:50 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 31 Jan 2002 11:56:53 +0100
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: draft-ietf-pkix-pi
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------msFFD0E97B747BDD18140713F2"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------msFFD0E97B747BDD18140713F2
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi all,

I have some points I'd like to highlight about the PI. Current comments are
made against the http://www.imc.org/draft-ietf-pkix-pi.

First of all some general considerations. My personal point on the PI is
that this should be used only within the subjectAltName ext. and this to
prevent the Subject DN from ever growing and keep as human readable as
possible. I know that there could be established policies following the
Subject DN's but I support this option.

Let's get through the draft in order.

I would change the paragraph:

<< A permanent identifier is a name assigned by an organization, 
   unique within that organization, that singles out a particular 
   individual from all other individuals.  A CA which includes such 
   an identifier in a certificate is certifying that any different 
   public key certificate containing that identifier refers to the 
   same individual. >>


Adding a phrase to clearly state that the "public key certificate..."
is from the CA in subject, something like:

<< A permanent identifier is a name assigned by an organization, 
   unique within that organization, that singles out a particular 
   individual from all other individuals.  A CA which includes such 
   an identifier in a certificate is certifying that any different 
   public key certificate issued by that CA and containing that
   identifier refers to the same individual. >>

I would like to extend the structure of the PersonalIdentifier to
something like this:

   PermanentIdentifier ::=     SEQUENCE {
           assignerAuthority        GeneralName OPTIONAL,
           identifierDesc           Name,
           identifierValue          IdentifierValue }

   IdentifierValue ::= CHOICE {
           permanentId		[1]	    Name,
	   permanentIdHash	[2]	    IDHash }

   PermanentIdHash ::= SEQUENCE {
           identifierHash	    OCTET STRING,  --- original identifier's Hash
	   identifierHashAlgorithm  AlgorithmIdentifier }
           
(there can be errors as I am not a master in structure definition :-D )

This structure (if correct) could solve problems tied to different current
situations, indeed there is the possibility to hide the "real" assigned ID
using the hash value instead. Usage of the Hash instead of the "real" ID
is therefore clearly stated when used. (this could be required if the original
value carries sensible data like date of birth, etc... ).

The identifierDesc field is used to give a text identifier of the id used,
i.e. "RUN" or "ABN", depending on the description adopted by the
assignerAuthority
(I am not sure if this could be coded using different techniques, if so, please,
point it out - thanks). 

I'd also change the word "responsible" when talking about the
assignerAuthority some paragraph behind: this to state that this field
carries an indication not directly stated by the assignerAuthority's
subject (it is no liable for the contents of the field).

It could also be simply stripped off, something like:

<< The assignerAuthority field of this attribute, when present, 
   identifies the organization assigning the content of the identifier
   field. When the assignerAuthority field is missing, the assignee
   Authority is the CA itself and it is assumed  to be the issuer
   name of the certificate. >>

Some comments ? Denis ?

-- 

C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]               madwolf at cpan.org
                                                       madwolf at openca.org
http://www.openca.org                             madwolf at hackmasters.net
http://openca.sourceforge.net                    Mobile: [phone]
--------------msFFD0E97B747BDD18140713F2
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIF+gYJKoZIhvcNAQcCoIIF6zCCBecCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BFowggRWMIIDPqADAgECAgIDITANBgkqhkiG9w0BAQQFADBAMSAwHgYDVQQDExdDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYDVQQGEwJJVDAeFw0wMTAy
MjcxMzQ0NTRaFw0wMjAyMjcxMzQ0NTRaMIGFMSYwJAYJKoZIhvcNAQkBFhdtYWR3b2xmQGhh
Y2ttYXN0ZXJzLm5ldDEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExFDASBgNVBAsTC09w
ZW5DQSBVc2VyMRwwGgYDVQQKExNPcGVuQ0EgT3JnYW5pemF0aW9uMQswCQYDVQQGEwJJVDCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs7c/i7zt8oRbF/MO3/Xq1bWb2h3y5VdRsm0E
MT22pFX7yjaKp4pSF36NDPJb4ss6aqqGLSiyyI/Wy+7124JDOzXhY4S0XPbZ6MmLUy4vp3Ze
+jmgJNyO2j+BtRQarUaEno+JIUizU4pcEtUO4BaPkxRqaL02raR61i3+foCQb/MCAwEAAaOC
AZYwggGSMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAmBglg
hkgBhvhCAQ0EGRYXT3BlbkNBIFVzZXIgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFPtjrGNl7QbD
nNY0rT2UFmtDF8doMGgGA1UdIwRhMF+AFAtL08ix9MbKXM950at8v/yRSMd7oUSkQjBAMSAw
HgYDVQQDExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYD
VQQGEwJJVIIBADAJBgNVHREEAjAAMAkGA1UdEgQCMAAwNAYJYIZIAYb4QgEEBCcWJWh0dHBz
Oi8vd3d3Lm9wZW5jYS5vcmcvY2dpLWJpbi9nZXRjcmwwNAYJYIZIAYb4QgEDBCcWJWh0dHBz
Oi8vd3d3Lm9wZW5jYS5vcmcvY2dpLWJpbi9nZXRjcmwwMgYJYIZIAYb4QgEHBCUWI2h0dHBz
Oi8vd3d3Lm9wZW5jYS5vcmc6NDQ0My9yZW5ld2FsMA0GCSqGSIb3DQEBBAUAA4IBAQBbbzeN
MZcl2K68tfAzCD72PB+hnwBuFBebVwVg5vWNJh/Zu0y2HAzy5pv9EcqLwS/2d5lqhwzG6a2H
W0HrrPbKxaLdQ4bZzDLG6zUohXzlCH0l2sq4BVuQF/dLVY/Gj2T9azYE0Yf2pOVG1VCC7zCR
9EtXsM51MbHzgxvOpUZD9sti2Y7UHmwxpr8vYodNLGQgR0B4tyWgCo5/LWyRk+u+4S0fFLsl
FISFpqNsTtDQxRWvmDD8BZhH5OFMHgCN73Wsngq2Hopo7QeKR2Ghwc+cIZHtk2Huoaj059Nz
/WXixzezZm5j3G1JWAzHfLo17n+nDdbF+OBODEhhuSIIBMI+MYIBaDCCAWQCAQEwRjBAMSAw
HgYDVQQDExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYD
VQQGEwJJVAICAyEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwGwYJ
KoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUxDxcNMDIwMTMxMTA1NjUz
WjAjBgkqhkiG9w0BCQQxFgQUU5LN9/b15MvkCJBJsocYH7JQxrwwDQYJKoZIhvcNAQEBBQAE
gYBn2W3xCFu/fQnynajjOk3t0pTcGjmfixtHFtMScAZRwr4rlKIKKIPl+plkU02bWGOJy3UP
xuWhsKrEWOSVlmSsyspzCJgpn/DUrTMDuASuRTXecwB8qu09Bl8lQnn6Dm3P1wTuzTt7cJyS
9SWwZBgpHIng7kkzX1z56c5MUaSlYg==
--------------msFFD0E97B747BDD18140713F2--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0V1IRI16477 for ietf-pkix-bks; Wed, 30 Jan 2002 17:18:27 -0800 (PST)
Received: from exafix.addtrust.com ([212.112.175.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0V1IP316470 for <[e-mail]>; Wed, 30 Jan 2002 17:18:25 -0800 (PST)
Received: from stsIBMT20.addtrust.com ([213.64.1.172]) by exafix.addtrust.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 31 Jan 2002 02:18:01 +0100
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Thu, 31 Jan 2002 02:17:58 +0100
To: "Roberto Opazo Gazmuri" <[e-mail]>, "PKIX \(Grupo de la IETF\)" <[e-mail]>
From: Stefan Santesson <[e-mail]>
Subject: Re: Local regulations about PI's codification
Cc: Stephen Kent <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
X-OriginalArrivalTime: 31 Jan 2002 01:18:02.0163 (UTC) FILETIME=[20926030:01C1A9F5]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0V1IP316472
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Lets not mix technical solutions with legal concepts for assigning national 
ID-codes.

I would suggest a vocabulary where we clearly separate technical concepts 
as PI, Serial number (and other potential candidates) from national 
concepts of civic registration codes for individuals and organizations.

The terminology used here implies that inclusion of a civic registration 
code requires the PI solution, which is not true.
With regard to technical concepts I see mainly 2 solutions which I would 
point out, might be one to much since they work very similar.

1) Serial number in the subject field. This field can hold any type of 
registration code. If you want to define the semantics of this attribute 
there is a solution to assign a semantics OID and name the registration 
authority, defined in RFC 3039 section 3.2.5.1

2) a PI according to the PI draft, stored in subject Alt Name, where you 
can define semantics and registration authority through an OID and attach 
the identifier to it.

2 solutions to one problem.

I would prefer to reduce them to 1.

Maybe its time to evaluate and review RFC 3039 before we create a new CMC 
versus CMP situation.
I have some defect reports noted on RFC 3039 that ought to be fixed anyway.

Just a thought.

/Stefan


At 17:41 2002-01-30 -0300, Roberto Opazo Gazmuri wrote:

>Hello,
>
>I want to thank the people ho answered my previous e-mail titled ‘"Subject
>Alternative Name" v/s "Subject/Serial Number"’. Now we have a little list of
>Local Solutions for the problem of putting a Permanent Identifier in a
>certificate. At the end of this e-mail I am sending you a summary.
>
>It gets the attention to see that there is only 1 equivalent solution
>(Sweden and Finland) and that gives Denis Pinkas a powerful base to say “I
>believe that it is time to progress the Permanent Identifier draft”.
>
>The purpose of this e-mail is to put order in the information we are
>receiving and to ask you an effort to provide more information because the
>list of real examples is too short. Just 6 countries!
>
>What is going on in the States?
>
>And what about Spain?
>
>I offer my self to administrate the collected information and send to the
>list a new summary when new information available justifies that.
>
>I think we should not waste time looking at individual CA’s solutions,
>because a local regulation is a much stronger reference and there are to
>many CA’s out of control.
>
>Best regards,
>
>Opazo, Roberto ([e-mail])
>CEO - www.acepta.com
>Certification Authority for Chile
>
>This is the first summary and format proposition about this information...
>
>---------------------------
>
>Summary’s Date: January 30, 2002.
>Local regulations about PI’s codification
>
>
>1.- Australia
>PI: Australian business number (ABN), it is a PI for companies.
>Codification:
>   privateExtension(1.2.36.1.333.1) = ABN
>Local authority:
>   Australian Government
>IETF Information provider:
>   Richard Culshaw [[e-mail]]
>
>2.- Chile
>PI: Rol Unico Nacional (Run)
>Codification:
>   subjectAltName[i].otherName[1].RunOID = run
>Local authority:
>   Now: Service of Internal Taxes
>   Probably soon: The Ministry of Economy
>IETF Information provider:
>   Roberto Opazo [[e-mail]]
>
>3.- Finland
>PI: Person number (person-number)
>Codification:
>   subject.serialNumber= person-number
>Local authority:
>   ?
>IETF Information provider:
>   Anders Rundgren [[e-mail]]
>
>4.- Hong Kong
>PI: Hong Kong Identifier (HKID), the HKID is by law "private data".
>Codification:
>   subjectAltName[1].dNSName = SHA-1( RSA_PrivateKey( SHA-1( HKID ) ) )
>Local authority:
>   Government, Hongkong Post
>IETF Information provider:
>   Al Arsenault [[e-mail]]
>
>5.- Italy
>PI: Codice Fiscale (CodiceFiscale)
>Codification:
>   subject.CN = LastName/FirstName/CodiceFiscale/CertificateNumber
>Local authority:
>   ?
>IETF Information provider:
>   ARBIA Sig. Stefano [[e-mail]]
>
>6.- Sweden
>PI: person-number
>Codification:
>   subject.serialNumber= person-number
>Local authority:
>   The Swedish standard SS614331
>IETF Information provider:
>   Anders Rundgren [[e-mail]]
>   Henrik Ståhl [[e-mail]]



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UKkXE10368 for ietf-pkix-bks; Wed, 30 Jan 2002 12:46:33 -0800 (PST)
Received: from marte.ifxnw.cl (marte.ifxnw.cl [216.241.0.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UKkW310363 for <[e-mail]>; Wed, 30 Jan 2002 12:46:32 -0800 (PST)
Received: from ropazo (unverified [216.241.20.226]) by marte.ifxnw.cl (Rockliffe SMTPRA 3.4.7) with SMTP id <[e-mail]> for <[e-mail]>; Wed, 30 Jan 2002 17:47:35 -0400
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "PKIX \(Grupo de la IETF\)" <[e-mail]>
Subject: =?iso-8859-1?Q?Local_regulations_about_PI's_codification?=
Date: Wed, 30 Jan 2002 17:41:53 -0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: High
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,

I want to thank the people ho answered my previous e-mail titled ‘"Subject
Alternative Name" v/s "Subject/Serial Number"’. Now we have a little list of
Local Solutions for the problem of putting a Permanent Identifier in a
certificate. At the end of this e-mail I am sending you a summary.

It gets the attention to see that there is only 1 equivalent solution
(Sweden and Finland) and that gives Denis Pinkas a powerful base to say “I
believe that it is time to progress the Permanent Identifier draft”.

The purpose of this e-mail is to put order in the information we are
receiving and to ask you an effort to provide more information because the
list of real examples is too short. Just 6 countries!

What is going on in the States?

And what about Spain?

I offer my self to administrate the collected information and send to the
list a new summary when new information available justifies that.

I think we should not waste time looking at individual CA’s solutions,
because a local regulation is a much stronger reference and there are to
many CA’s out of control.

Best regards,

Opazo, Roberto ([e-mail])
CEO - www.acepta.com
Certification Authority for Chile

This is the first summary and format proposition about this information...

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

Summary’s Date: January 30, 2002.
Local regulations about PI’s codification


1.- Australia
PI: Australian business number (ABN), it is a PI for companies.
Codification:
  privateExtension(1.2.36.1.333.1) = ABN
Local authority:
  Australian Government
IETF Information provider:
  Richard Culshaw [[e-mail]]

2.- Chile
PI: Rol Unico Nacional (Run)
Codification:
  subjectAltName[i].otherName[1].RunOID = run
Local authority:
  Now: Service of Internal Taxes
  Probably soon: The Ministry of Economy
IETF Information provider:
  Roberto Opazo [[e-mail]]

3.- Finland
PI: Person number (person-number)
Codification:
  subject.serialNumber= person-number
Local authority:
  ?
IETF Information provider:
  Anders Rundgren [[e-mail]]

4.- Hong Kong
PI: Hong Kong Identifier (HKID), the HKID is by law "private data".
Codification:
  subjectAltName[1].dNSName = SHA-1( RSA_PrivateKey( SHA-1( HKID ) ) )
Local authority:
  Government, Hongkong Post
IETF Information provider:
  Al Arsenault [[e-mail]]

5.- Italy
PI: Codice Fiscale (CodiceFiscale)
Codification:
  subject.CN = LastName/FirstName/CodiceFiscale/CertificateNumber
Local authority:
  ?
IETF Information provider:
  ARBIA Sig. Stefano [[e-mail]]

6.- Sweden
PI: person-number
Codification:
  subject.serialNumber= person-number
Local authority:
  The Swedish standard SS614331
IETF Information provider:
  Anders Rundgren [[e-mail]]
  Henrik Ståhl [[e-mail]]



Received: by above.proper.com (8.11.6/8.11.3) id g0UIl9I07449 for ietf-pkix-bks; Wed, 30 Jan 2002 10:47:09 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UIl7307444 for <[e-mail]>; Wed, 30 Jan 2002 10:47:07 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101336b87defda3b6f@[165.227.249.20]>
In-Reply-To: <02f701c1a9bb$2395c180$6501a8c0@SJOSEPH>
References: <[e-mail]> <[e-mail]> <02f701c1a9bb$2395c180$6501a8c0@SJOSEPH>
Date: Wed, 30 Jan 2002 10:47:05 -0800
To: <[e-mail]>
From: Paul Hoffman / VPNC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 1:22 PM -0500 1/30/02, Al Arsenault wrote:
>     Do you (or Steve K., Russ or Stephen F. for that matter) know of any IPR
>issues with this?  In the WAP Forum, Entrust claimed that they had IPR (a
>patent application on file in the US) that covered this sort of thing.

I don't have any direct knowledge of any IPR. If Entrust has a patent 
or an application that might affect this, Carlisle Adams might be the 
best person to ask.

--Paul Hoffman, Director
--VPN Consortium


Received: by above.proper.com (8.11.6/8.11.3) id g0UIQbO06892 for ietf-pkix-bks; Wed, 30 Jan 2002 10:26:37 -0800 (PST)
Received: from femail16.sdc1.sfba.home.com (femail16.sdc1.sfba.home.com [24.0.95.143]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UIQb306888 for <[e-mail]>; Wed, 30 Jan 2002 10:26:37 -0800 (PST)
Received: from SJOSEPH ([68.55.160.145]) by femail16.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20020130182634.WXPG6250.femail16.sdc1.sfba.home.com@SJOSEPH>; Wed, 30 Jan 2002 10:26:34 -0800
Message-ID: <02f701c1a9bb$2395c180$6501a8c0@SJOSEPH>
From: "Al Arsenault" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Date: Wed, 30 Jan 2002 13:22:55 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

    Do you (or Steve K., Russ or Stephen F. for that matter) know of any IPR
issues with this?  In the WAP Forum, Entrust claimed that they had IPR (a
patent application on file in the US) that covered this sort of thing.

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.


----- Original Message -----
From: "Stephen Farrell" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, January 30, 2002 9:37 AM
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt


>
>
> Paul,
>
> There's a similar scheme in the WAP forum's WPKI spec ([1], at the
> end of section 7.1.3) that you might want to look at. I guess
> similarities between these two would be no harm, though I don't
> feel strongly that they should/must be the same.
>
> One feature of that spec is the inclusion of check-digits [2] so
> that the punters don't end up typing much after they've made an
> error and so that they don't hit the "mistrust" button just because
> of a typing error. I think this'd be useful to include, though
> of course it makes things a bit longer.
>
> Also - does your hash include the algorithm parameters & if not,
> is that ok?
>
> Only other comment is why is "protocol" in the title? Seems
> a bit strange, but heh...
>
> Regards,
> Stephen.
>
> [1]
http://www1.wapforum.org/tech/terms.asp?doc=WAP-217-WPKI-20010424-a.pdf
> [2] http://www.beachnet.com/~hstiles/cardtype.html
>
>
> --------------------------------------------------------------------------
---
> Baltimore Technologies plc will not be liable for direct,  special,
indirect
> or consequential  damages  arising  from  alteration of  the contents of
this
> message by a third party or as a result of any virus being passed on.
>
> This footnote confirms that this email message has been swept by
> Baltimore MIMEsweeper for Content Security threats, including
> computer viruses.
>    http://www.baltimore.com
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UICro06496 for ietf-pkix-bks; Wed, 30 Jan 2002 10:12:53 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UICp306488 for <[e-mail]>; Wed, 30 Jan 2002 10:12:52 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101334b87de49e9972@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>	 <[e-mail]> <p0510132cb87dbe2695f6@[165.227.249.20]> <[e-mail]>
Date: Wed, 30 Jan 2002 10:07:54 -0800
To: [e-mail]
From: Paul Hoffman / VPNC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 5:22 PM +0000 1/30/02, Stephen Farrell wrote:
>  > Sorry, but that link takes me to a page with a legal agreement that I
>>  cannot meet.
>
>Bummer. Never mind though - there really is a similar scheme behind
>the legal nonsense. Interestingly, the URL below [1] gives access to
>a remarkably similar document without having to read license crud.
>(Maybe that's a secret though:-)

We cannot use documents with these kinds of restrictions in the IETF. 
If you really want us to pursue this, we need to talk to the IETF's 
liaison to the WAP Forum.

But I don't think there is a reason to pursue this. I believe that 
the proposal I made (16 alphabetic characters broken into four groups 
of four) is significantly friendlier than the one that WAP is using 
(30 digits broken into five groups of six digits). Let me know if you 
disagree.

>Make every n-th digit a check-digit, that way s/w can stop the user
>more quickly.

Correct.

>  I hate to type a long random string only to find out
>after typing and checking 30 digits, that the 1st character was
>wrong. Does make strings longer though all right.

We are talking 18 characters, not 30, and the first two will be simple.

>Without a check digit the user has no way to distinguish the typo
>case from the bad public key value case.

Please look at where OKID is being used. If the user gets a bad 
public key value from the out-of-band communication, the user can 
query the sender of the OKID ("could you read me that again"). Given 
the essential impossibility to forge OKIDs, the user will know that 
either they have mistyped something or that they are under a very 
amazing attack.

>  I'd say that makes it more
>likely that the user hits the "mistrust" button needlessly. ("Hey,
>that public key you sent me is bad - it didn't match the okid I
>typed in - maybe you should turn it off too.")

That scenario won't happen. You can compute the OKID on any cert you 
have in front of you; the OKID is not part of the cert.

Do other people think that the value of adding check digits is worth 
the cost (making the OKIDs longer and therefore less friendly)? In 
order to keep the symmetry of groups of four characters, we could add 
four check digits, making the string 22 characters instead of 18. 
Personally, I think it isn't worth it, but two people here (one 
off-list) have said they like the idea.

>  > >Also - does your hash include the algorithm parameters & if not,
>>  >is that ok?
>>
>>  No it doesn't include it; the OKID document clearly says it is over
>>  the public key only. I was thinking about RSA keys. The algorithm
>>  parameters should also be hashed. I'll fix this in the next draft.
>
>Watch out for inherited parameters (from the superior CA cert).

OK, I'm no expert on DSA and Diffie-Hellman, but how does one get 
inherited parameters in a self-signed certificate?

>  Hard
>to see a good way to handle those.

Disallow certs that would have them.

>  Not sure if a "well known" curve
>value would be ok either - wouldn't the punter have to validate that
>oob as well, or is the probability of cheating so small in that case
>that we can ignore it?

A good question for the cryptographers.

--Paul Hoffman, Director
--VPN Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UHL3x05094 for ietf-pkix-bks; Wed, 30 Jan 2002 09:21:03 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UHL0305084; Wed, 30 Jan 2002 09:21:01 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g0UHL2U04674; Wed, 30 Jan 2002 17:21:02 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]>; Wed, 30 Jan 2002 17:16:28 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id RAA14229; Wed, 30 Jan 2002 17:20:57 GMT
Message-ID: <[e-mail]>
Date: Wed, 30 Jan 2002 17:22:03 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Paul Hoffman / IMC <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
References: <[e-mail]> <[e-mail]> <p0510132cb87dbe2695f6@[165.227.249.20]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

> Sorry, but that link takes me to a page with a legal agreement that I 
> cannot meet.

Bummer. Never mind though - there really is a similar scheme behind
the legal nonsense. Interestingly, the URL below [1] gives access to 
a remarkably similar document without having to read license crud. 
(Maybe that's a secret though:-)

> >One feature of that spec is the inclusion of check-digits [2] so
> >that the punters don't end up typing much after they've made an
> >error and so that they don't hit the "mistrust" button just because
> >of a typing error. I think this'd be useful to include, though
> >of course it makes things a bit longer.
> 
> Um, how does a check-digit help with either problem? 

Make every n-th digit a check-digit, that way s/w can stop the user
more quickly. I hate to type a long random string only to find out 
after typing and checking 30 digits, that the 1st character was 
wrong. Does make strings longer though all right.

Without a check digit the user has no way to distinguish the typo
case from the bad public key value case. I'd say that makes it more
likely that the user hits the "mistrust" button needlessly. ("Hey,
that public key you sent me is bad - it didn't match the okid I
typed in - maybe you should turn it off too.")

> >Also - does your hash include the algorithm parameters & if not,
> >is that ok?
> 
> No it doesn't include it; the OKID document clearly says it is over
> the public key only. I was thinking about RSA keys. The algorithm
> parameters should also be hashed. I'll fix this in the next draft.

Watch out for inherited parameters (from the superior CA cert). Hard
to see a good way to handle those. Not sure if a "well known" curve
value would be ok either - wouldn't the punter have to validate that
oob as well, or is the probability of cheating so small in that case
that we can ignore it?

Stephen.

[1] http://www1.wapforum.org/tech/documents/WAP-217-WPKI-20010424-a.pdf

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


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UHEmH04892 for ietf-pkix-bks; Wed, 30 Jan 2002 09:14:48 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UHEk304888 for <[e-mail]>; Wed, 30 Jan 2002 09:14:46 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA16863; Wed, 30 Jan 2002 18:14:40 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 30 Jan 2002 18:14:40 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA20949; Wed, 30 Jan 2002 18:14:39 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA09598; Wed, 30 Jan 2002 18:14:39 +0100 (MET)
Date: Wed, 30 Jan 2002 18:14:39 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > Anyway:
> > 
> > My question is not answered: Why had a change to force a policy been made in
> > draft 4. 
> 
> Draft 3 was stating: "The reqPolicy field, if included, indicates the policy
> under which the TimeStampToken should be provided."
> 
> Draft 4 was stating: "The reqPolicy field, if included, indicates the policy
> under which the TimeStampToken should be provided."

This is not the text I am refering to: 

draft 3:
"The policy field MUST indicate the TSAs policy under which the response
 was produced.  

draft 4:

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

I would have expected that the statement that You referenced would have
been changed accordingly, something like:

"The reqPolicy field, if included, indicates the policy
 under which the TimeStampToken SHALL be provided."

In draft 9 this line became: 

"The reqPolicy field, if included, indicates the policy
 under which the TimeStampToken SHOULD be provided."
 
> I do not see any difference, so question is meaningless. 
> 
> > There was no announcement, and it was quite easy to overlook this
> > since in two other places requierments for policy had not been changed.
> >
> > I don't think that it is necessary to have an identical policy.
> 
> It is simmple: if a client requests a policy and if the server supports
> that policy, why should the server choose a different policy ? 
Because the policy may have been replaced by a newer one which is
defined as compatible. 

> Just to annoy the client ?

The text says already that the client MAY ignore the policy, and that
it SHOULD check whether it is acceptable. This seems to be an indication
to me that the initial intension was that a TSA can creat a different
value. 

TSA may change their policies and issue 'compatible ones' with a different
id. Why should one annoy the client and ask for an upgrade? 
The possibility of not having a policy may not be possible because
the TSA supports different sets/classes.  

> 
> Denis
Peter


Received: by above.proper.com (8.11.6/8.11.3) id g0UGpPu04361 for ietf-pkix-bks; Wed, 30 Jan 2002 08:51:25 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UGpC304346; Wed, 30 Jan 2002 08:51:12 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510132cb87dbe2695f6@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: Wed, 30 Jan 2002 08:44:33 -0800
To: [e-mail], [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 2:37 PM +0000 1/30/02, Stephen Farrell wrote:
>Paul,
>
>There's a similar scheme in the WAP forum's WPKI spec ([1], at the
>end of section 7.1.3) that you might want to look at. I guess
>similarities between these two would be no harm, though I don't
>feel strongly that they should/must be the same.

Sorry, but that link takes me to a page with a legal agreement that I 
cannot meet. So, no, it is not appropriate to use their spec. If the 
WAP Forum decides to let people read and reference their documents 
without first making a legal agreement with them, I'll reconsider 
this. <sheesh>

>One feature of that spec is the inclusion of check-digits [2] so
>that the punters don't end up typing much after they've made an
>error and so that they don't hit the "mistrust" button just because
>of a typing error. I think this'd be useful to include, though
>of course it makes things a bit longer.

Um, how does a check-digit help with either problem? The check digit 
can say whether or not you typed in the rest of the string correctly, 
but it can't say what you should change if you typed it incorrectly. 
So it is just an extra character or two that would give a second kind 
of response: "you typed the rest of this wrong".

>Also - does your hash include the algorithm parameters & if not,
>is that ok?

No it doesn't include it; the OKID document clearly says it is over 
the public key only. I was thinking about RSA keys. The algorithm 
parameters should also be hashed. I'll fix this in the next draft.

>Only other comment is why is "protocol" in the title? Seems
>a bit strange, but heh...

Because it is a standard encoding for communication.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UGpFJ04352 for ietf-pkix-bks; Wed, 30 Jan 2002 08:51:15 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UGpD304348 for <[e-mail]>; Wed, 30 Jan 2002 08:51:13 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p0510132db87dd3b8a410@[165.227.249.20]>
In-Reply-To: <[e-mail]>
References: <8D7EC1912E25D411A32100D0B7695397E1B4E5@SCYGMXS01>										 <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 30 Jan 2002 08:51:09 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Cautionary Period Straw Poll
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 4:21 PM +0100 1/30/02, Denis Pinkas wrote:
>Once again, I am not advocating the handling of ANY validation rule at the
>client, but instead the handling of ALL the validation rules at the server,
>hence the solution indicated just above is only to illustrate the problem,
>but not the solution I would like to go with.

It is somewhat distressing to see one of the editors of a 
requirements document actively ignoring the consensus of the Working 
Group on what should and should not go in the requirements document. 
If someone writing a protocol that meets these requirements wants to 
extend the protocol, they can. But the WG has pretty much said "it is 
not a requirement" and the requirements document should reflect that.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by above.proper.com (8.11.6/8.11.3) id g0UGeup04147 for ietf-pkix-bks; Wed, 30 Jan 2002 08:40:56 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UGer304143 for <[e-mail]>; Wed, 30 Jan 2002 08:40:54 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA34664; Wed, 30 Jan 2002 17:42:13 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA16208; Wed, 30 Jan 2002 17:40:15 +0100
Message-ID: <[e-mail]>
Date: Wed, 30 Jan 2002 11:41:24 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: TSP interop update
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

> > >   "The reqPolicy field, if included, indicates the TSA policy under
> > >    which the TimeStampToken SHOULD be provided."
> >
> > If the server does not support the policy, we cannot force the server to
> > support it, and hence why SHALL cannot be simply substituted. In order
> > to be more explicit we could say:
> >
> >    The reqPolicy field, if included, indicates the TSA policy under
> >    which the TimeStampToken SHALL be issued (provided that policy is
> >    supported by the server).
> >
> Your sentence essentially contains just a substitution of SHOULD by SHALL.
> Your reasoning of why SHOULD cannot be replavced by SHALL doesn't
> make sense, since for example a TSA can always decide not to return a
> token simply because it doesn't like the client or 'time source not available'
> and there are still MUSTs for many othre cases like a nonce for example,
> you cannot "force" a TSA to return a Nonce of 1megaoctets, the text
> concerning nonce still says  'MUST be identical'.
> 
> Anyway:
> 
> My question is not answered: Why had a change to force a policy been made in
> draft 4. 

Draft 3 was stating: "The reqPolicy field, if included, indicates the policy
under which the TimeStampToken should be provided."

Draft 4 was stating: "The reqPolicy field, if included, indicates the policy
under which the TimeStampToken should be provided."

I do not see any difference, so question is meaningless. 

> There was no announcement, and it was quite easy to overlook this
> since in two other places requierments for policy had not been changed.
>
> I don't think that it is necessary to have an identical policy.

It is simmple: if a client requests a policy and if the server supports
that policy, why should the server choose a different policy ? 
Just to annoy the client ?

Denis




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UGeqW04142 for ietf-pkix-bks; Wed, 30 Jan 2002 08:40:52 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UGeo304138 for <[e-mail]>; Wed, 30 Jan 2002 08:40:50 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA32556; Wed, 30 Jan 2002 17:42:13 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA16210; Wed, 30 Jan 2002 17:40:16 +0100
Message-ID: <[e-mail]>
Date: Wed, 30 Jan 2002 16:21:04 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: Cautionary Period Straw Poll
References: <8D7EC1912E25D411A32100D0B7695397E1B4E5@SCYGMXS01> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Russ,

> Denis:
 
> >You counted me in the "Other response" category, and I am grateful for this,
> >... since the straw poll question was not correctly raised.
 
> I tried to be accurate.
 
> >Let us now see the implications, if the cautionary period is not known to
> >the server (which is what you wanted).

> >I believe that the DPV protocol has to be usable to verify the validity
> >of a certificate used in the context of a data-origin-authentication
> >with-integrity service. The client must be able to apply locally a
> >cautionary period.

> >Today we have a status which means:

> >    1) the certificate is valid according to the validation policy.

> >Since *all* the rules are not handled by the server, this status becomes
> >inappropriate. It should be changed into:

> >    1) the certificate is conditionally valid according to the validation
> >       policy.

> >In order to be able to apply *locally* an additional rule, i.e. the
> >cautionary period, the client needs additional information to support this
> >status.
 
> I disagree.  The certificate is valid; the is no need for a condition.
 
> The client must determine whether a valid certificate is sufficient for
> processing the signature.  I assume that we all agree that a valid
> certificate is necessary.  If there are other conditions beyond a valid
> certificate, then the client must take actions beyond asking the DPV server
> to determine whether those conditions have been met.

Do not forget that DPV servers are supposed to be a single place of inquiry
for thin clients. Anyway, the client is unable to take any action concerning
a cautionary period, unless it is made aware of "thisUpdate".
 
> In the case of cautionary period, the client will wait the appropriate
> amount of time, then the client will use DPV to determine whether the
> certificate is valid.  If so, the client must perform other checks,
> including signature verification.

It is impossible to know how long to wait, unless the client is aware of the
value of the field thisUpdate.
 
> >If the revocation status of the certificate under query is obtained using an
> >OCSP service, then thisUpdate MUST be returned.
 
> OCSP provides the status for one certificate.  DPV constructs a
> certification path and then validates it.  If OCSP is employed, it will be
> used for each certificate in the path.  It is not clear to me which
> thisUpdate is going to be useful to the client.

First, the one about the certificate under the query, usually a leaf
certificate. But you are right, theoritically, all the fields thisUpdate 
from the certification path would need to be considered. Handling the
definition of the cautionary period, IF ANY, at the server offers simplicity
and hides all this complexity.

I am not advocating the handling of ANY validation rule at the client, 
but instead the handling of ALL the validation rules at the server.
 
> If any of the OCSP responses include nextUpdate, it might be useful to
> return the earliest nextUpdate value from the set of responses. If CRLs (or
> delta CRLs) are used, the earliest nextUpdate value could be useful.
 
> >CONCLUSION

> >The "price to pay" to handle *locally* the cautionary period is thus:

> >   1) to change the current status "the certificate is valid"
> >      into "the certificate is conditionally".

> >   2) to return an additional parameter to copy the field "thisUpdate"
> >      obtained from an OCSP response, a base CRL or a delta CRL.
 
> I disagree with both of your conclusions for the reasons indicated above.

Once again, I am not advocating the handling of ANY validation rule at the
client, but instead the handling of ALL the validation rules at the server,
hence the solution indicated just above is only to illustrate the problem,
but not the solution I would like to go with. 

To this respect we both agree.  :-)


Denis

 
> Russ




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UEaCD29027 for ietf-pkix-bks; Wed, 30 Jan 2002 06:36:12 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UEaA329020 for <[e-mail]>; Wed, 30 Jan 2002 06:36:10 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g0UEaAU31090 for <[e-mail]>; Wed, 30 Jan 2002 14:36:10 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]> for <[e-mail]>; Wed, 30 Jan 2002 14:31:36 +0000
Received: from baltimore.ie (wks140-4.ie.baltimore.com [10.153.4.140]) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id OAA10249; Wed, 30 Jan 2002 14:36:07 GMT
Message-ID: <[e-mail]>
Date: Wed, 30 Jan 2002 14:37:14 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
References: <[e-mail]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Paul,

There's a similar scheme in the WAP forum's WPKI spec ([1], at the
end of section 7.1.3) that you might want to look at. I guess 
similarities between these two would be no harm, though I don't
feel strongly that they should/must be the same.

One feature of that spec is the inclusion of check-digits [2] so 
that the punters don't end up typing much after they've made an 
error and so that they don't hit the "mistrust" button just because 
of a typing error. I think this'd be useful to include, though
of course it makes things a bit longer.

Also - does your hash include the algorithm parameters & if not,
is that ok?

Only other comment is why is "protocol" in the title? Seems
a bit strange, but heh...

Regards,
Stephen.

[1] http://www1.wapforum.org/tech/terms.asp?doc=WAP-217-WPKI-20010424-a.pdf
[2] http://www.beachnet.com/~hstiles/cardtype.html


-----------------------------------------------------------------------------
Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
   http://www.baltimore.com



Received: by above.proper.com (8.11.6/8.11.3) id g0UEOIG28726 for ietf-pkix-bks; Wed, 30 Jan 2002 06:24:18 -0800 (PST)
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UEOG328722 for <[e-mail]>; Wed, 30 Jan 2002 06:24:16 -0800 (PST)
Received: from tsg1 ([12.81.71.112]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020130142406.OYVF13117.mtiwmhc24.worldnet.att.net@tsg1>; Wed, 30 Jan 2002 14:24:06 +0000
Message-ID: <00da01c1a999$c3ecefe0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>
References:  <[e-mail]> <p0510030ab87bbee859e8@[128.33.238.78]> <033d01c1a8d4$14b42d10$020aff0c@tsg1> <p05100305b87cc5ebae43@[10.1.15.165]>
Subject: Re: Space stamping protocol
Date: Wed, 30 Jan 2002 06:24:00 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen - Its time for you to be replaced as the WG Chair. Take this as an
official motion before the Group.

This WG above all others needs term limits on how long a WG Chair can sit on
it and I would like to propose that your time is up and that we need fresh
blood at the top.Perhaps from someone more adequately representing the rest
of the World since the WG now is chaired by you and Tim (A US Government
Employee). Maybe someone like Nick Pope or another. Ian Lloyd of the
OpenGroup would be a good choice as well. He is the Director of Security
Verticals within the OG and it would be very powerful for the IETF to get a
liaison with them as well since they own the UNIX Trademark and its
validation suites amongst other things.

Either way - its time for you to go on to some other role. You have been
this WG Chair for too long now.

TODD

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "Eric Norman" <[e-mail]>; <[e-mail]>
Sent: Tuesday, January 29, 2002 2:17 PM
Subject: Re: Space stamping protocol


> At 6:48 AM -0800 1/29/02, todd glassey wrote:
> >Actually Stephen I disagree. ***You*** may claim that this was done as a
> >political statement to enable the use of signature verification relative
to
> >a time stamp, but in fact - the only real value that timestamps have is
as
> >an evidentiary marque for after the fact non-repudiation.
>
> "Political statement?" No, it was the technical rationale that
> motivated pursuing this activity within PKIX.
>
> "after the fact non-repudiation?" as opposed to a priori repudiation?
> remember, Todd, clear expression helps make you point, verbosity
> obscrues it.
>
> >There is no other commercial use for them in PKI as the decision support
> >processes for "is this signature any good" are easier and cleaner to
> >implement as applications-ware rather than as network component.
>
> NR is typically viewed as an application layer service, and the TSP
> is an application layer protocol, so the comments immediately above
> seem irrelevant to this discussion.
>
> >Not that timestamps are not important - they are critical, but for audit
> >based proofing, i.e establishing a document's feature point's in time.
>
> There is a substantial body of technical literature describing the
> utility of time stamps in support of NR. The terminology you employ
> immediately above is largely absent from that literature.
>
> Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UDsiP28014 for ietf-pkix-bks; Wed, 30 Jan 2002 05:54:44 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0UDsg328009 for <[e-mail]>; Wed, 30 Jan 2002 05:54:42 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 30 Jan 2002 13:54:11 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA05997 for <[e-mail]>; Wed, 30 Jan 2002 08:54:43 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g0UDsgJ16961 for <[e-mail]>; Wed, 30 Jan 2002 08:54:42 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <DTB6Y3PX>; Wed, 30 Jan 2002 08:54:41 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.70]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DTB6Y3PW; Wed, 30 Jan 2002 08:54:38 -0500
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Wed, 30 Jan 2002 08:54:34 -0500
Subject: Re: Cautionary Period Straw Poll
In-Reply-To: <[e-mail]>
References: <8D7EC1912E25D411A32100D0B7695397E1B4E5@SCYGMXS01> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis:

>You counted me in the "Other response" category, and I am grateful for this,
>... since the straw poll question was not correctly raised.

I tried to be accurate.

>Let us now see the implications, if the cautionary period is not known to
>the server (which is what you wanted).
>
>I believe that the DPV protocol has to be usable to verify the validity
>of a certificate used in the context of a data-origin-authentication
>with-integrity service. The client must be able to apply locally a
>cautionary period.
>
>Today we have a status which means:
>
>    1) the certificate is valid according to the validation policy.
>
>Since *all* the rules are not handled by the server, this status becomes
>inappropriate. It should be changed into:
>
>    1) the certificate is conditionally valid according to the validation
>       policy.
>
>In order to be able to apply *locally* an additional rule, i.e. the
>cautionary period, the client needs additional information to support this
>status.

I disagree.  The certificate is valid; the is no need for a condition.

The client must determine whether a valid certificate is sufficient for 
processing the signature.  I assume that we all agree that a valid 
certificate is necessary.  If there are other conditions beyond a valid 
certificate, then the client must take actions beyond asking the DPV server 
to determine whether those conditions have been met.

In the case of cautionary period, the client will wait the appropriate 
amount of time, then the client will use DPV to determine whether the 
certificate is valid.  If so, the client must perform other checks, 
including signature verification.

>If the revocation status of the certificate under query is obtained using an
>OCSP service, then thisUpdate MUST be returned.

OCSP provides the status for one certificate.  DPV constructs a 
certification path and then validates it.  If OCSP is employed, it will be 
used for each certificate in the path.  It is not clear to me which 
thisUpdate is going to be useful to the client.

If any of the OCSP responses include nextUpdate, it might be useful to 
return the earliest nextUpdate value from the set of responses. If CRLs (or 
delta CRLs) are used, the earliest nextUpdate value could be useful.

>CONCLUSION
>
>The "price to pay" to handle *locally* the cautionary period is thus:
>
>   1) to change the current status "the certificate is valid"
>      into "the certificate is conditionally".
>
>   2) to return an additional parameter to copy the field "thisUpdate"
>      obtained from an OCSP response, a base CRL or a delta CRL.

I disagree with both of your conclusions for the reasons indicated above.

Russ


Received: by above.proper.com (8.11.6/8.11.3) id g0UC2HP18944 for ietf-pkix-bks; Wed, 30 Jan 2002 04:02:17 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UC2G318940 for <[e-mail]>; Wed, 30 Jan 2002 04:02:16 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15580; Wed, 30 Jan 2002 07:02:15 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-okid-00.txt
Date: Wed, 30 Jan 2002 07:02:15 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Out-of-Band Key Identifier Protocol (OKID)
	Author(s)	: P. Hoffman
	Filename	: draft-ietf-pkix-okid-00.txt
	Pages		: 
	Date		: 29-Jan-02
	
In general, certificates need not be communicated with communication or
storage media that are integrity-secure or authentic. This is because
certificates are digitally signed and users are expected to validate the
signatures using configured trust anchors. However, distribution of
trust anchor certificates, or distribution of self-signed end-entity
certificates, requires a mechanism for establishing the authenticity of
the public key contained in such certificates.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-okid-00.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g0UAJmr09490 for ietf-pkix-bks; Wed, 30 Jan 2002 02:19:48 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UAJj309480 for <[e-mail]>; Wed, 30 Jan 2002 02:19:46 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA15151; Wed, 30 Jan 2002 11:19:38 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 30 Jan 2002 11:19:38 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id LAA19738; Wed, 30 Jan 2002 11:19:37 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA09448; Wed, 30 Jan 2002 11:19:36 +0100 (MET)
Date: Wed, 30 Jan 2002 11:19:36 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > 
> >   "The reqPolicy field, if included, indicates the TSA policy under
> >    which the TimeStampToken SHOULD be provided."
> 
> If the server does not support the policy, we cannot force the server to
> support it, and hence why SHALL cannot be simply substituted. In order 
> to be more explicit we could say:
> 
>    The reqPolicy field, if included, indicates the TSA policy under 
>    which the TimeStampToken SHALL be issued (provided that policy is 
>    supported by the server).
> 
Your sentence essentially contains just a substitution of SHOULD by SHALL.
Your reasoning of why SHOULD cannot be replavced by SHALL doesn't
make sense, since for example a TSA can always decide not to return a 
token simply because it doesn't like the client or 'time source not available'
and there are still MUSTs for many othre cases like a nonce for example,
you cannot "force" a TSA to return a Nonce of 1megaoctets, the text 
concerning nonce still says  'MUST be identical'.  

Anyway:

My question is not answered: Why had a change to force a policy been made in
draft 4. There was no announcement, and it was quite easy to overlook this
since in two other places requierments for policy had not been changed.

I don't think that it is necessary to have an identical policy. 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0UA1Fk08527 for ietf-pkix-bks; Wed, 30 Jan 2002 02:01:15 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0UA1B308523 for <[e-mail]>; Wed, 30 Jan 2002 02:01:11 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA15104; Wed, 30 Jan 2002 11:01:04 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Wed, 30 Jan 2002 11:01:04 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id LAA19717; Wed, 30 Jan 2002 11:01:02 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA09441; Wed, 30 Jan 2002 11:01:02 +0100 (MET)
Date: Wed, 30 Jan 2002 11:01:02 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

>  
> If we transpose this sentence in the context of TSP then we should have:
> 
> A server MUST reject the request if it encounters a critical extension 
> it does not recognize and in that case SHALL return a failure
> (unacceptedExtension); however, non-critical extensions MAY be ignored, 
> if not recognized.

X509 has an additional requirement which was added in a defect report, 
i.e., if an extension is known, then the interpretation is independant
of the value of the critical bit. 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0U9EDI04599 for ietf-pkix-bks; Wed, 30 Jan 2002 01:14:13 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0U9EB304575 for <[e-mail]>; Wed, 30 Jan 2002 01:14:11 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA18258; Wed, 30 Jan 2002 10:15:28 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA11634; Wed, 30 Jan 2002 10:13:31 +0100
Message-ID: <[e-mail]>
Date: Wed, 30 Jan 2002 10:13:26 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: Cautionary Period Straw Poll
References: <8D7EC1912E25D411A32100D0B7695397E1B4E5@SCYGMXS01> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Dear co-editor,

:-)

You counted me in the "Other response" category, and I am grateful for this,
... since the straw poll question was not correctly raised.

In an e-mail sent on January 14, I said:

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

The basic question is how clients can take advantage of a DPV server in the
case where a cautionary period exists and in the context of a
non-repudiation service or a data-origin-authentication-with-integrity
service ?

There are two options whether :

1) the cautionary period has to be known by the client 
   (which is what your arguments mandate).

2) the cautionary period is known by the server 
   (which is what my arguments mandate).

In the context of a data-origin-authentication-with-integrity service,
clients must necessarilly know the purported date of the digital signature.

With option 1, clients must locally manage the cautionary period for each
supported policy and locally compare it either with the date of the
time-stamp or the date of the audit record, or the the purported date of the
digital signature. This makes management actions more difficult 
(and makes also thin clients fater) since if that period changes, 
local tables need to be updated in each client application.

With option 2, clients do not need to manage that information locally since
it is part of the policy supported by the server. They simply need to send 
to the server either the date of the time-stamp or the date of the audit
record, or the purported date of the digital signature.

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

Let us now see the implications, if the cautionary period is not known to
the server (which is what you wanted).

I believe that the DPV protocol has to be usable to verify the validity 
of a certificate used in the context of a data-origin-authentication 
with-integrity service. The client must be able to apply locally a
cautionary period.

Today we have a status which means:

   1) the certificate is valid according to the validation policy.

Since *all* the rules are not handled by the server, this status becomes
inappropriate. It should be changed into:

   1) the certificate is conditionally valid according to the validation
      policy.
 
In order to be able to apply *locally* an additional rule, i.e. the
cautionary period, the client needs additional information to support this
status.

If the revocation status of the certificate under query is obtained using an
OCSP service, then thisUpdate MUST be returned.

thisUpdate is the time at which the status being indicated is known to be
correct

If the revocation status of the certificate under query is obtained using a
base CRL, then thisUpdate MUST be returned.

thisUpdate indicates the issue date of the CRL.

If the revocation status of the certificate under query is obtained using a
base CRL and a delat CRL, then thisUpdate from the delta CRL MUST be
returned.

thisUpdate indicates the issue date of the delta-CRL.


CONCLUSION

The "price to pay" to handle *locally* the cautionary period is thus:

  1) to change the current status "the certificate is valid" 
     into "the certificate is conditionally".

  2) to return an additional parameter to copy the field "thisUpdate" 
     obtained from an OCSP response, a base CRL or a delta CRL.

Handling the cautionary period at the server would be simpler, with 
the major additional argument indicated in my e-mail from January 14:

"This makes management actions more difficult (and makes also thin clients
fater) since if that period changes, local tables need to be updated in each
client application." 

After reading this conclusion, it might be possible that some people would
like to change their vote, or that additional people would like to express
their opinion about option 1 and option 2.


Denis


> Here are the results of the Straw Poll.
> 
> Ought to support cautionary period: 2
>         Alfonso De Gregorio <[e-mail]>
>         Todd Glassey <[e-mail]>
> 
> Ought NOT support cautionary period: 14
>         Santosh Chokhani <[e-mail]>
>         Russ Housley <[e-mail]>
>         Ambarish Malpani <[e-mail]>
>         Sanjeev Shukla <[e-mail]>
>         Yuriy Dzambasow <[e-mail]>
>         Paul Hoffman <[e-mail]>
>         Peter Yee <[e-mail]>
>         Stephen Farrell <[e-mail]>
>         Alex Deacon <[e-mail]>
>         Al Arsenault <[e-mail]>
>         Rich Salz <[e-mail]>
>         Tom Gindin <[e-mail]>
>         Trevor Freeman <[e-mail]>
>         Michael Myers <[e-mail]>
>         Sean P. Turner <[e-mail]>
> 
> Other response: 2
>         Denis Pinkas <[e-mail]>
>         Peter Sylvester <[e-mail]>
> 
> While there are certainly many members of the mail list that did not share
> an opinion, the scale is clearly tilted toward the exclusion of cautionary
> period support from PKIX DPV requirements and protocols.
> 
> Russ



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0U8ir900505 for ietf-pkix-bks; Wed, 30 Jan 2002 00:44:53 -0800 (PST)
Received: from ms01.dh02.ictu.nl ([193.173.47.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0U8ip300497 for <[e-mail]>; Wed, 30 Jan 2002 00:44:51 -0800 (PST)
Received: from gw01.dh01.ictu.nl (unverified) by ms01.dh02.ictu.nl (Content Technologies SMTPRS 4.2.5) with ESMTP id <[e-mail]> for <[e-mail]>; Wed, 30 Jan 2002 09:33:25 +0100
content-class: urn:content-classes:message
Subject: dubble O
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Date: Wed, 30 Jan 2002 09:44:34 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.0.4712.0
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: dubble O
Thread-Index: AcGpalcU9M8weeVNQ2i50l+hnj6umg==
From: "Haaino Beljaars" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0U8iq300499
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi,

Can somebody tell me if the following hierachie is technical as well as
legally possible: DN:= C=nl, O = ABC, O = XYZ, OU = dep, CN = user

If not, in which RFC('s) is that defined?


Thank you,
Haaino


Received: by above.proper.com (8.11.6/8.11.3) id g0U6Vcb14437 for ietf-pkix-bks; Tue, 29 Jan 2002 22:31:38 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0U6VZ314433 for <[e-mail]>; Tue, 29 Jan 2002 22:31:36 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id TAA19172 for <[e-mail]>; Wed, 30 Jan 2002 19:31:28 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA404569 for [e-mail]; Wed, 30 Jan 2002 19:31:21 +1300 (NZDT) (sender [e-mail])
Date: Wed, 30 Jan 2002 19:31:21 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Brief comment on draft-ietf-pkix-new-part1-12.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I was just skimming through 4.2.1.5 Certificate Policies and noticed the text:

      An explicitText field includes the textual statement directly in
      the certificate.  The explicitText field is a string with a
      maximum size of 200 characters.

It's probably worth adding an implementation note here to say that this
restriction is fairly widely ignored, and that although the *correct* behaviour
is to only generate a maximum of 200 chars, implementations should expect to
see huge legal disclaimers of far more than 200 chars stuffed into this field
(or maybe just add a link to the X.509 style guide to the RFC as a whole :-).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TMIoQ04804 for ietf-pkix-bks; Tue, 29 Jan 2002 14:18:50 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TMIm304799 for <[e-mail]>; Tue, 29 Jan 2002 14:18:48 -0800 (PST)
Received: from [10.1.15.165] (SSH.BBN.COM [192.1.50.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA08463; Tue, 29 Jan 2002 17:18:27 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05100304b87cc58395e6@[10.1.15.165]>
In-Reply-To: <03df01c1a8e7$1764ac70$020aff0c@tsg1>
References:  <[e-mail]> <p0510030ab87bbee859e8@[128.33.238.78]> <033d01c1a8d4$14b42d10$020aff0c@tsg1> <03df01c1a8e7$1764ac70$020aff0c@tsg1>
Date: Tue, 29 Jan 2002 16:34:26 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Space stamping protocol
Cc: "todd glassey" <[e-mail]>, "Eric Norman" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 9:05 AM -0800 1/29/02, todd glassey wrote:
>Stephen,
>since you have such an aversion to my creating new terms without defining
>them first,  let me define this one:
>
>"Feature Points" - Characteristics by which an object, entity, or generic
>thing may be identified or characterized; and in this case it refers to the
>times when the document was created, received and opened or edited...
>
>Todd
>

Todd,

I object to neologisms and the use of words or phrases that have been 
arbitrarily capitalized to impart a sense of greater import, even 
when accompanied by definitions.

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g0TMIgA04796 for ietf-pkix-bks; Tue, 29 Jan 2002 14:18:42 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TMIe304792 for <[e-mail]>; Tue, 29 Jan 2002 14:18:40 -0800 (PST)
Received: from [10.1.15.165] (SSH.BBN.COM [192.1.50.70]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id RAA08468; Tue, 29 Jan 2002 17:18:28 -0500 (EST)
Mime-Version: 1.0
X-Sender: kent@127.0.0.1
Message-Id: <p05100305b87cc5ebae43@[10.1.15.165]>
In-Reply-To: <033d01c1a8d4$14b42d10$020aff0c@tsg1>
References:  <[e-mail]> <p0510030ab87bbee859e8@[128.33.238.78]> <033d01c1a8d4$14b42d10$020aff0c@tsg1>
Date: Tue, 29 Jan 2002 17:17:37 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Space stamping protocol
Cc: "Eric Norman" <[e-mail]>, <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 6:48 AM -0800 1/29/02, todd glassey wrote:
>Actually Stephen I disagree. ***You*** may claim that this was done as a
>political statement to enable the use of signature verification relative to
>a time stamp, but in fact - the only real value that timestamps have is as
>an evidentiary marque for after the fact non-repudiation.

"Political statement?" No, it was the technical rationale that 
motivated pursuing this activity within PKIX.

"after the fact non-repudiation?" as opposed to a priori repudiation? 
remember, Todd, clear expression helps make you point, verbosity 
obscrues it.

>There is no other commercial use for them in PKI as the decision support
>processes for "is this signature any good" are easier and cleaner to
>implement as applications-ware rather than as network component.

NR is typically viewed as an application layer service, and the TSP 
is an application layer protocol, so the comments immediately above 
seem irrelevant to this discussion.

>Not that timestamps are not important - they are critical, but for audit
>based proofing, i.e establishing a document's feature point's in time.

There is a substantial body of technical literature describing the 
utility of time stamps in support of NR. The terminology you employ 
immediately above is largely absent from that literature.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TH5Gu23986 for ietf-pkix-bks; Tue, 29 Jan 2002 09:05:16 -0800 (PST)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TH5F323978 for <[e-mail]>; Tue, 29 Jan 2002 09:05:15 -0800 (PST)
Received: from tsg1 ([12.81.86.45]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020129170510.WDWL28721.mtiwmhc25.worldnet.att.net@tsg1>; Tue, 29 Jan 2002 17:05:10 +0000
Message-ID: <03df01c1a8e7$1764ac70$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "todd glassey" <[e-mail]>, "Eric Norman" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References:  <[e-mail]> <p0510030ab87bbee859e8@[128.33.238.78]> <033d01c1a8d4$14b42d10$020aff0c@tsg1>
Subject: Re: Space stamping protocol
Date: Tue, 29 Jan 2002 09:05:00 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen,
since you have such an aversion to my creating new terms without defining
them first,  let me define this one:

"Feature Points" - Characteristics by which an object, entity, or generic
thing may be identified or characterized; and in this case it refers to the
times when the document was created, received and opened or edited...

Todd

----- Original Message -----
From: "todd glassey" <[e-mail]>
To: "Eric Norman" <[e-mail]>; "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, January 29, 2002 6:48 AM
Subject: Re: Space stamping protocol


>
> Actually Stephen I disagree. ***You*** may claim that this was done as a
> political statement to enable the use of signature verification relative
to
> a time stamp, but in fact - the only real value that timestamps have is as
> an evidentiary marque for after the fact non-repudiation.
>
> There is no other commercial use for them in PKI as the decision support
> processes for "is this signature any good" are easier and cleaner to
> implement as applications-ware rather than as network component.
>
> Not that timestamps are not important - they are critical, but for audit
> based proofing, i.e establishing a document's feature point's in time.
>
> Todd
> ----- Original Message -----
> From: "Stephen Kent" <[e-mail]>
> To: "Eric Norman" <[e-mail]>
> Cc: <[e-mail]>
> Sent: Monday, January 28, 2002 6:54 PM
> Subject: Re: Space stamping protocol
>
>
> >
> > At 3:41 PM -0600 1/23/02, Eric Norman wrote:
> > >So, we have a need for time stamping services and the associated
> > >protocols.
> > >
> > >Can we use GPS satellites and receivers to provide a space stamping
> > >service?
> > >
> > >It might be useful for the nuclear launch scenario or alibis.
> > >
> > >Eric Norman
> >
> > PKIX adopted a time stamping protocol not because it is an
> > infrastructure service in support of non-repudiation, which is a
> > common function for PKIs.  A "space stamping" protocol would not seem
> > to offer a service which is intrinsically related to PKI, and thus
> > would not seem to be a suitable PKIX work item.
> >
> > Steve
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TFjRk21890 for ietf-pkix-bks; Tue, 29 Jan 2002 07:45:27 -0800 (PST)
Received: from mail.hackmasters.net ([217.133.235.63]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TFjP321884 for <[e-mail]>; Tue, 29 Jan 2002 07:45:25 -0800 (PST)
Received: from hackmasters.net (galadriel.mpnet.hackmasters.net [10.5.122.180]) by mail.hackmasters.net (Postfix) with ESMTP id 38E149289 for <[e-mail]>; Tue, 29 Jan 2002 16:49:11 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 29 Jan 2002 16:40:34 +0100
From: Massimiliano Pala <[e-mail]>
Organization: OpenCA
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.2.19 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
References: <[e-mail]> <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0DB229BAA849EB7C0949BF8E"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

--------------ms0DB229BAA849EB7C0949BF8E
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:
> 
> To the list and the co-chairs,
> 
> >From the discussion on the list, due to the lack of a standard, some CAs
> have defined private extensions to support the concept of a permanent
> identifier.

I agree with Denis that a solution have to be found. As we have verified
many countries have the need to identify, using a permanent identifier,
the user: this is highlighted when dealing with public administrations
(at least according to my experiences).

I am in favor to review (I have to read it more carefully and a new
version is needed as it is outdated, isn't it ?) and progress the 
http://www.imc.org/draft-ietf-pkix-pi as pointed out by Denis.

I suggest it to be pushed on the standard track instead of publishing
it as an informational RFC, but I am not against any solution that will
be proposed, I am interested in having a clear resolution of the issue
ASAP.


C'you,

	Massimiliano Pala

--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]               madwolf at cpan.org
                                                       madwolf at openca.org
http://www.openca.org                             madwolf at hackmasters.net
http://openca.sourceforge.net                    Mobile: [phone]
--------------ms0DB229BAA849EB7C0949BF8E
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIF+gYJKoZIhvcNAQcCoIIF6zCCBecCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BFowggRWMIIDPqADAgECAgIDITANBgkqhkiG9w0BAQQFADBAMSAwHgYDVQQDExdDZXJ0aWZp
Y2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYDVQQGEwJJVDAeFw0wMTAy
MjcxMzQ0NTRaFw0wMjAyMjcxMzQ0NTRaMIGFMSYwJAYJKoZIhvcNAQkBFhdtYWR3b2xmQGhh
Y2ttYXN0ZXJzLm5ldDEaMBgGA1UEAxMRTWFzc2ltaWxpYW5vIFBhbGExFDASBgNVBAsTC09w
ZW5DQSBVc2VyMRwwGgYDVQQKExNPcGVuQ0EgT3JnYW5pemF0aW9uMQswCQYDVQQGEwJJVDCB
nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAs7c/i7zt8oRbF/MO3/Xq1bWb2h3y5VdRsm0E
MT22pFX7yjaKp4pSF36NDPJb4ss6aqqGLSiyyI/Wy+7124JDOzXhY4S0XPbZ6MmLUy4vp3Ze
+jmgJNyO2j+BtRQarUaEno+JIUizU4pcEtUO4BaPkxRqaL02raR61i3+foCQb/MCAwEAAaOC
AZYwggGSMAkGA1UdEwQCMAAwEQYJYIZIAYb4QgEBBAQDAgWgMAsGA1UdDwQEAwIF4DAmBglg
hkgBhvhCAQ0EGRYXT3BlbkNBIFVzZXIgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFPtjrGNl7QbD
nNY0rT2UFmtDF8doMGgGA1UdIwRhMF+AFAtL08ix9MbKXM950at8v/yRSMd7oUSkQjBAMSAw
HgYDVQQDExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYD
VQQGEwJJVIIBADAJBgNVHREEAjAAMAkGA1UdEgQCMAAwNAYJYIZIAYb4QgEEBCcWJWh0dHBz
Oi8vd3d3Lm9wZW5jYS5vcmcvY2dpLWJpbi9nZXRjcmwwNAYJYIZIAYb4QgEDBCcWJWh0dHBz
Oi8vd3d3Lm9wZW5jYS5vcmcvY2dpLWJpbi9nZXRjcmwwMgYJYIZIAYb4QgEHBCUWI2h0dHBz
Oi8vd3d3Lm9wZW5jYS5vcmc6NDQ0My9yZW5ld2FsMA0GCSqGSIb3DQEBBAUAA4IBAQBbbzeN
MZcl2K68tfAzCD72PB+hnwBuFBebVwVg5vWNJh/Zu0y2HAzy5pv9EcqLwS/2d5lqhwzG6a2H
W0HrrPbKxaLdQ4bZzDLG6zUohXzlCH0l2sq4BVuQF/dLVY/Gj2T9azYE0Yf2pOVG1VCC7zCR
9EtXsM51MbHzgxvOpUZD9sti2Y7UHmwxpr8vYodNLGQgR0B4tyWgCo5/LWyRk+u+4S0fFLsl
FISFpqNsTtDQxRWvmDD8BZhH5OFMHgCN73Wsngq2Hopo7QeKR2Ghwc+cIZHtk2Huoaj059Nz
/WXixzezZm5j3G1JWAzHfLo17n+nDdbF+OBODEhhuSIIBMI+MYIBaDCCAWQCAQEwRjBAMSAw
HgYDVQQDExdDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEPMA0GA1UEChMGT3BlbkNBMQswCQYD
VQQGEwJJVAICAyEwCQYFKw4DAhoFAKB6MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwGwYJ
KoZIhvcNAQkPMQ4wDDAKBggqhkiG9w0DBzAcBgkqhkiG9w0BCQUxDxcNMDIwMTI5MTU0MDM0
WjAjBgkqhkiG9w0BCQQxFgQUlL5N5jD+z3XagDTHhbJqvkrOgL8wDQYJKoZIhvcNAQEBBQAE
gYCw+jmgYVO+xBU2jlI+q8oZuZkqIsjXFKJ+Oshj0/M0iwHmq8wiHD1j/7QQ/YZ7Zit8Dbx0
EOI8NWeSs3XYw7W7Nsr17hfRRSgIuC9A0PXZI/oQpycHeawiBfIF3T8w6XqWMH5RVn8JPMVW
iXrLKi6CV4fdthGt2T8/hzP4hFv7HQ==
--------------ms0DB229BAA849EB7C0949BF8E--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TEnJx18420 for ietf-pkix-bks; Tue, 29 Jan 2002 06:49:19 -0800 (PST)
Received: from mtiwmhc21.worldnet.att.net (mtiwmhc21.worldnet.att.net [204.127.131.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TEnE318412 for <[e-mail]>; Tue, 29 Jan 2002 06:49:18 -0800 (PST)
Received: from tsg1 ([12.81.86.45]) by mtiwmhc21.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020129144905.EBKJ5540.mtiwmhc21.worldnet.att.net@tsg1>; Tue, 29 Jan 2002 14:49:05 +0000
Message-ID: <033d01c1a8d4$14b42d10$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Eric Norman" <[e-mail]>, "Stephen Kent" <[e-mail]>
Cc: <[e-mail]>
References:  <[e-mail]> <p0510030ab87bbee859e8@[128.33.238.78]>
Subject: Re: Space stamping protocol
Date: Tue, 29 Jan 2002 06:48:56 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Actually Stephen I disagree. ***You*** may claim that this was done as a
political statement to enable the use of signature verification relative to
a time stamp, but in fact - the only real value that timestamps have is as
an evidentiary marque for after the fact non-repudiation.

There is no other commercial use for them in PKI as the decision support
processes for "is this signature any good" are easier and cleaner to
implement as applications-ware rather than as network component.

Not that timestamps are not important - they are critical, but for audit
based proofing, i.e establishing a document's feature point's in time.

Todd
----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: "Eric Norman" <[e-mail]>
Cc: <[e-mail]>
Sent: Monday, January 28, 2002 6:54 PM
Subject: Re: Space stamping protocol


>
> At 3:41 PM -0600 1/23/02, Eric Norman wrote:
> >So, we have a need for time stamping services and the associated
> >protocols.
> >
> >Can we use GPS satellites and receivers to provide a space stamping
> >service?
> >
> >It might be useful for the nuclear launch scenario or alibis.
> >
> >Eric Norman
>
> PKIX adopted a time stamping protocol not because it is an
> infrastructure service in support of non-repudiation, which is a
> common function for PKIs.  A "space stamping" protocol would not seem
> to offer a service which is intrinsically related to PKI, and thus
> would not seem to be a suitable PKIX work item.
>
> Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0TDQiV14112 for ietf-pkix-bks; Tue, 29 Jan 2002 05:26:44 -0800 (PST)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0TDQh314106 for <[e-mail]>; Tue, 29 Jan 2002 05:26:43 -0800 (PST)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.6/XCERT) with ESMTP id g0TDQai05381 for <[e-mail]>; Tue, 29 Jan 2002 05:26:36 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.6/XCERT) with ESMTP id g0TDQaw22569 for <[e-mail]>; Tue, 29 Jan 2002 05:26:36 -0800 (PST)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <VVXY55M3>; Tue, 29 Jan 2002 05:29:12 -0800
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.83]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DTB6X6NN; Tue, 29 Jan 2002 08:23:21 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Tue, 29 Jan 2002 08:17:35 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: Cautionary Period Straw Poll
In-Reply-To: <[e-mail]>
References: <8D7EC1912E25D411A32100D0B7695397E1B4E5@SCYGMXS01>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Here are the results of the Straw Poll.

Ought to support cautionary period: 2
	Alfonso De Gregorio <[e-mail]>
	Todd Glassey <[e-mail]>
	
Ought NOT support cautionary period: 14
	Santosh Chokhani <[e-mail]>
	Russ Housley <[e-mail]>
	Ambarish Malpani <[e-mail]>
	Sanjeev Shukla <[e-mail]>
	Yuriy Dzambasow <[e-mail]>
	Paul Hoffman <[e-mail]>
	Peter Yee <[e-mail]>
	Stephen Farrell <[e-mail]>
	Alex Deacon <[e-mail]>
	Al Arsenault <[e-mail]>
	Rich Salz <[e-mail]>
	Tom Gindin <[e-mail]>
	Trevor Freeman <[e-mail]>
	Michael Myers <[e-mail]>
	Sean P. Turner <[e-mail]>

Other response: 2
	Denis Pinkas <[e-mail]>
	Peter Sylvester <[e-mail]>

While there are certainly many members of the mail list that did not share 
an opinion, the scale is clearly tilted toward the exclusion of cautionary 
period support from PKIX DPV requirements and protocols.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0T8hrm19648 for ietf-pkix-bks; Tue, 29 Jan 2002 00:43:53 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0T8hp319639 for <[e-mail]>; Tue, 29 Jan 2002 00:43:51 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA20414; Tue, 29 Jan 2002 09:43:44 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA17536; Tue, 29 Jan 2002 09:41:49 +0100
Message-ID: <[e-mail]>
Date: Tue, 29 Jan 2002 09:41:49 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "PKIX (Grupo de la IETF)" <[e-mail]>, Stephen Kent <[e-mail]>, Tim Polk <[e-mail]>
CC: Roberto Opazo Gazmuri <[e-mail]>
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0T8hq319644
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

To the list and the co-chairs,

>From the discussion on the list, due to the lack of a standard, some CAs
have defined private extensions to support the concept of a permanent
identifier.

The two cases advertised to the list are the following:

1) The Australian Government wanted to put the ABN (Australian Business
   Number) (a social security type number for companies) into certificates. 
   They looked into it and decided the best place for it was in a private
   extension. It has its own OID: 1.2.36.1.333.1 and what follows this 
   OID is the 11 or 12 digits ABN number,

2) It was very clear for as that Chile was going to need an OID for the RUN. 
   We registered 1.3.6.1.4.1.8321 as an OID for Chile and reserved 
   1.3.6.1.4.1.8321.1 to be used for RUN. 

In order to avoid/limit the proliferation of such private extensions, or
avoid the use of the serialNumber attribute in a way that is not conformant
to the standards, I believe that it is time to progess the Permanent
Identifier draft (http://www.imc.org/draft-ietf-pkix-pi) that has been
dormant for nearly two years.

The single question is whether this document should be progressed on the
standard track or issued as an informational RFC. I would like to hear the
opinion of the co-chairs of this topic, then I will re-issue the document. 
I think that the standard track would be more appropriate.

Denis

 
> Thanks a lot, I respond between lines...
> 
> >
> > The next two questions are for you:
> >
> > 1) if two certificates *from two different CAs* contain the same RUN
> >    (Rol Unico Nacional) is your intention to be able to say that it is
> >    the same person ?
> 
> Yes, any CA accredited in Chile MUST follow certification practices in order
> to validate de Chilean Unique Identifier (RUN) of each individual certified.
> 
> >
> > 2) after having taken a look at http://www.imc.org/draft-ietf-pkix-pi,
> >    would you think more appropriate in your case to support the notion
> >    of permanent identifier in the DN or in the Subject Alternative Name ?
> >
> 
> I continue thinking It is better to use Subject Alternative Name. After
> reading frc 2459 it was very clear for as that Chile was going to need an
> OID for the RUN. We registered 1.3.6.1.4.1.8321 as an OID for Chile and
> reserve 1.3.6.1.4.1.8321.1  to be used for RUN. Now, any CA to be accredited
> for de government taxes department MUST use it. Here is my certificate as
> example:
> 
> http://varios.acepta.com/ietf/roberto.opazo.cer
> 
> It seems very close with de Unique Identifier recommendations.
> 
> Now some comments for the future RFC...
> 
> I like the argument “you can not take any advantage about one unique
> identifier in the DN”. I think this could be mentioned in “Introduction”.
> 
> Other situation that could be mentioned is “Individuals can have many
> Permanent Identifier and many RP can work with one of then, but others RP
> could be interested in others. For example, the national security code v/s
> the passport number. If people have to administrate more than one
> certificate, usability problems start. So we need to use User Alternative
> Names”.
> 
> In the definition part, I think the rfc should start at the General Names
> syntax of the User Alternative Name, other case it is not clear the manner
> for certificate codification. And also, I do not understand why not to use
> the choice “other name” for Permanent Identifier.
> 
> >
> > Denis
> >
> 
> Best regards,
> 
> Roberto


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0T3U0I28703 for ietf-pkix-bks; Mon, 28 Jan 2002 19:30:00 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0T3Tx328688 for <[e-mail]>; Mon, 28 Jan 2002 19:29:59 -0800 (PST)
Received: from [128.33.238.105] (TC105.BBN.COM [128.33.238.105]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id WAA15772; Mon, 28 Jan 2002 22:29:34 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail] (Unverified)
Message-Id: <p0510030ab87bbee859e8@[128.33.238.78]>
In-Reply-To:  <[e-mail]>
References:  <[e-mail]>
Date: Mon, 28 Jan 2002 21:54:54 -0500
To: Eric Norman <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Space stamping protocol
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

At 3:41 PM -0600 1/23/02, Eric Norman wrote:
>So, we have a need for time stamping services and the associated
>protocols.
>
>Can we use GPS satellites and receivers to provide a space stamping
>service?
>
>It might be useful for the nuclear launch scenario or alibis.
>
>Eric Norman

PKIX adopted a time stamping protocol not because it is an 
infrastructure service in support of non-repudiation, which is a 
common function for PKIs.  A "space stamping" protocol would not seem 
to offer a service which is intrinsically related to PKI, and thus 
would not seem to be a suitable PKIX work item.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0T3K7T28441 for ietf-pkix-bks; Mon, 28 Jan 2002 19:20:07 -0800 (PST)
Received: from marte.ifxnw.cl (marte.ifxnw.cl [216.241.0.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0T3K5328436 for <[e-mail]>; Mon, 28 Jan 2002 19:20:05 -0800 (PST)
Received: from ropazo (unverified [216.241.20.226]) by marte.ifxnw.cl (Rockliffe SMTPRA 3.4.7) with SMTP id <[e-mail]>; Tue, 29 Jan 2002 00:21:10 -0400
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: "PKIX \(Grupo de la IETF\)" <[e-mail]>
Subject: RE: "Subject Alternative Name" v/s "Subject/Serial Number"
Date: Tue, 29 Jan 2002 00:15:34 -0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: High
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanks a lot, I respond between lines...

>
> The next two questions are for you:
>
> 1) if two certificates *from two different CAs* contain the same RUN
>    (Rol Unico Nacional) is your intention to be able to say that it is
>    the same person ?

Yes, any CA accredited in Chile MUST follow certification practices in order
to validate de Chilean Unique Identifier (RUN) of each individual certified.

>
> 2) after having taken a look at http://www.imc.org/draft-ietf-pkix-pi,
>    would you think more appropriate in your case to support the notion
>    of permanent identifier in the DN or in the Subject Alternative Name ?
>

I continue thinking It is better to use Subject Alternative Name. After
reading frc 2459 it was very clear for as that Chile was going to need an
OID for the RUN. We registered 1.3.6.1.4.1.8321 as an OID for Chile and
reserve 1.3.6.1.4.1.8321.1  to be used for RUN. Now, any CA to be accredited
for de government taxes department MUST use it. Here is my certificate as
example:

http://varios.acepta.com/ietf/roberto.opazo.cer

It seems very close with de Unique Identifier recommendations.

Now some comments for the future RFC...

I like the argument “you can not take any advantage about one unique
identifier in the DN”. I think this could be mentioned in “Introduction”.

Other situation that could be mentioned is “Individuals can have many
Permanent Identifier and many RP can work with one of then, but others RP
could be interested in others. For example, the national security code v/s
the passport number. If people have to administrate more than one
certificate, usability problems start. So we need to use User Alternative
Names”.

In the definition part, I think the rfc should start at the General Names
syntax of the User Alternative Name, other case it is not clear the manner
for certificate codification. And also, I do not understand why not to use
the choice “other name” for Permanent Identifier.

>
> Denis
>

Best regards,

Roberto



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SMWv921333 for ietf-pkix-bks; Mon, 28 Jan 2002 14:32:57 -0800 (PST)
Received: from esmddns01.esign.com.au ([203.58.177.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SMWs321325 for <[e-mail]>; Mon, 28 Jan 2002 14:32:55 -0800 (PST)
Received: from esmcex01.esign.com.au (not verified[192.168.1.12]) by esmddns01.esign.com.au with MailMarshal (4,0,9,0)  id <B00003b454>; Tue, 29 Jan 2002 09:32:45 +1100
Received: by esmcex01 with Internet Mail Service (5.5.2650.21) id <DZV3TK5X>; Tue, 29 Jan 2002 09:32:45 +1100
Message-ID: <B2B00EE4690ED611857100C00D016FCD5145@esmcex01>
From: Richard Culshaw <[e-mail]>
To: "'Roberto Opazo Gazmuri'" <[e-mail]>, "Ietf-Pkix (E-mail)" <[e-mail]>
Subject: RE: "Subject Alternative Name" v/s "Subject/Serial Number"
Date: Tue, 29 Jan 2002 09:32:44 +1100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi all,

what happened in Australia was this,

the Australian Government wanted to put the ABN (Australian business number)
(a social security type number for companies) into certificates.  They
looked into it and decided the best place for it was in a private extension.
It has its own OID:
1.2.36.1.333.1 and what follows this OID is the 11 or 12 digit ABN number,

it is simple for applications to parse the certificate and find the ABN
number located within.



Regards,

Richard Culshaw 


-----Original Message-----
From: Roberto Opazo Gazmuri [mailto:[e-mail]]
Sent: Sunday, 27 January 2002 8:32 AM
To: PKIX (Grupo de la IETF)
Subject: "Subject Alternative Name" v/s "Subject/Serial Number"
Importance: High



Hi, my name is Roberto Opazo, this is my first mail sent to the group.

In Chile we have finished approving the law of electronic signature and we
are initiating conversations to define the regulation that must complement
this law. A central subject of the discussion is how information of the
national unique roll, called RUN (Rol Unico Nacional) should be included in
certificates. That is a number only associate to each citizen in all the
country. It is a comparable identifier to the social security number
insurance in the U.S.A. but its use is but spread, since most of the
Chileans they obtain his RUN when being born and practically all the
computer science applications of the country use it to identify the users.
An important precedent in our country about the form to include this
identifier in a certificate is a resolution of the Service of Internal Taxes
that it establishes that the extension "Subject Alternative Name " is due to
use. The organization who I represent (Acepta.com) is promotional of this
form of codification. Nevertheless, a local CA, who uses technology of RSA
Labs argues that this is difficult to codify and difficult to read. They are
in favor to use the field "Subject" on some form. I would like to request
help with the following doubts:

* It seems to be reasonable to place a RUN in the "Subject"?

* In individual, could be used the attribute "Serial Number" of the field
"Subject" for this?

* Where I can find examples of certificates which they use the extension
"Subject Alternative Name"?

* Where I can find normative what exist of other countries that have solved
east kind of problem?

Thank you very much by its aid.

As it is my first mail to the group, them control a small presentation...

I am founding and Acepta.com's CEO, a CA developed in Chile using OpenSSL.
We were first in obtaining the accreditation on the part of the Service of
Internal Taxes of the Country on March 2001 (only 2 CAs are on this position
at this time). We have actively collaborated in the development of an
operational model to use electronic invoice that soon will begin to work and
I believe that it will leave more to Chile like one of the advanced
countries in the use of PKI, as much by the penetration in the Internet
users, like by the real value contributed by the technology.

Greetings,

Opazo, Roberto
CEO - www.acepta.com
Certification Authority for Chile


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SI6lB14368 for ietf-pkix-bks; Mon, 28 Jan 2002 10:06:47 -0800 (PST)
Received: from mail-out.secaron.de (druss.secaron.de [195.145.99.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SI6j314363 for <[e-mail]>; Mon, 28 Jan 2002 10:06:45 -0800 (PST)
Received: by mail-out.secaron.de (Postfix, from userid 0) id 53C6451F2B; Mon, 28 Jan 2002 19:06:41 +0100 (MET)
Received: from druss.secaron.de (localhost [127.0.0.1]) by mail-out.secaron.de (Postfix) with ESMTP id E635E325D1; Mon, 28 Jan 2002 19:06:40 +0100 (MET)
Received: from marvin.munich.secaron.de (marvin.munich.secaron.de [192.168.1.20]) by druss.secaron.de (Postfix) with ESMTP id 57B764AC5F; Mon, 28 Jan 2002 19:06:40 +0100 (MET)
Received: from MUCDEV101 ([192.168.2.101]) by marvin.munich.secaron.de (Lotus Domino Release 5.0.9a) with SMTP id 2002012819063964:2360 ; Mon, 28 Jan 2002 19:06:39 +0100 
From: "Florian Oelmaier" <[e-mail]>
To: <[e-mail]>
Cc: "Denis Pinkas" <[e-mail]>
Subject: RE: OCSP extensions
Date: Mon, 28 Jan 2002 19:03:53 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <[e-mail]>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-MIMETrack: Itemize by SMTP Server on Marvin/Secaron(Release 5.0.9a |January 7, 2002) at 01/28/2002 07:06:39 PM, Serialize by Router on Marvin/Secaron(Release 5.0.9a |January 7, 2002) at 01/28/2002 07:06:40 PM, Serialize complete at 01/28/2002 07:06:40 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This proposal for clarification would be great. It is wholeheartly welcomed
here.

--
Dipl.Inf. Florian Oelmaier
Head of Development
syTrust S.A.


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Monday, January 28, 2002 3:29 PM
> To: Ambarish Malpani
> Cc: 'Florian Oelmaier'; [e-mail]
> Subject: Re: OCSP extensions
>
>
> Ambarish,
>
> The current text is the following:
>
>    The nonce cryptographically binds a request and a response to prevent
>    replay attacks. The nonce is included as one of the requestExtensions
>    in requests, while in responses it would be included as one of the
>    responseExtensions. In both the request and the response, the nonce
>    will be identified by the object identifier id-pkix-ocsp-nonce, while
>    the extnValue is the value of the nonce.
>
> If the nonce is not used, then the only field to prevent replay attacks is
> the use of the field producedAt. However the text does not
> explain what kind
> of processing should be done with that field from a client point of view.
>
> At the end of section "4.2.2.1 Time" it would be appropriate to add after:
>
>    The producedAt time is the time at which this response was signed.
>
> The following sentence:
>
> "When replay attack protection is required, a client MUST check that the
> producedAt time is close to the local current time, otherwise
> when no local
> clock is available, then, it SHALL use a nonce (see section 4.4.1)."
>
> Then in the security considerations section we should provide some warning
> when using the producedAt time in the context of 2.5.
>
> " When pre-produce signed responses are used by the servers, the field
> producedAt time is not necessarily a time close to the time of
> the request.
> So unless this field is checked to be close to the current time, replay
> attacks are possible."
>
> Denis
>
>
> > Hi Florian,
> >
> >     Interesting point of view. However, we are at the stage of
> > progressing OCSP from a Proposed to a Draft Standard.
> >
> > If the standard as it currently stands is not broken, I would
> > prefer leaving the meaning of fields as they currently are.
> >
> > What you are proposing is a legitimate extension, but quite
> > different in semantics from the nonce as defined in OCSP.
> >
> > What might make sense, is to come up with a separate draft of
> > useful OCSP extensions, run that through the standards process
> > and merge it with the OCSP spec when both reach the same level
> > of acceptance. A list of "standard" OCSP extensions has been
> > on my TODO list for some time now - so if you like, we can work
> > on such a draft together.
> >
> > Regards,
> > Ambarish
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                650.567.5457
> > ValiCert, Inc.                                  [e-mail]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> > > -----Original Message-----
> > > From: Florian Oelmaier [mailto:[e-mail]]
> > > Sent: Monday, January 21, 2002 4:08 AM
> > > To: Santosh Chokhani; Yuriy Dzambasow; Ambarish Malpani;
> > > 'Deacon, Alex';
> > > [e-mail]
> > > Subject: RE: OCSP RFC and OCSP version 2 ID
> > >
> > >
> > > Hello Santosh,
> > >
> > > I would like to add some comments to your suggestion b)
> > >
> > > >
> > > > b.  If the request has a nonce extension, the response must have
> > > > the nonce extension with the same value as the request.
> > > >
> > >
> > > Although I appreciate this change as it improves the security of the
> > > protocol, I have a point that I want you to see clearly
> > > before making this
> > > change.
> > >
> > > As the client most probably knows nothing about the
> > > Validation-System behind
> > > a PKI (except the IP of the OCSP-Responder, he has to contact) it is
> > > advisable for the client to always include a nonce into his request
> > > ("well-behaving client"). With "well-behaving clients" and
> > > the proposed
> > > change of the RfC we will face problems with these scenarios:
> > >
> > > Scenario 1: Setup of a Responder that pre-produces answers as
> > > specified in
> > > 2.5 of RfC 2560.
> > >
> > > Scenario 2: Setup of a PKI that uses HTTP-Caching as given
> > > for example in
> > > A.1.1 of RfC 2560.
> > >
> > > Scenario 3: Some PKIs use a Root-Responder architecture with
> > > various other
> > > responders relaying to this root responder and caching his
> > > answer for a
> > > certain period of time. [Although I disregard such an
> > > architecture, it is
> > > used today]
> > >
> > > These problems may lead to clients not using nonce per
> > > default. If a client
> > > does not use a nonce, it is vulnerable to replay-attacks.
> > >
> > > Today an OCSP-Responder can decide if he wants to expose himself to
> > > replay-attacks by generating answers without nonces. That means if a
> > > responder generates only ONE response without nonce it is
> > > vulnerable. On the
> > > other hand, if an OCSP-responder includes a nonce in every
> > > response ever
> > > generated in his lifetime, regardless of a nonce in the
> > > request, it is NOT
> > > vulnerable to replay-attacks (at least not to "well-behaving
> > > clients").
> > >
> > > Therefore I would suggest the following change to clarify the
> > > RfC instead of
> > > the proposed change:
> > >
> > > "Every client MUST include a nonce into his request. If a
> > > nonce is included
> > > in the response, the client MUST match it to the nonce of the request.
> > > Although imposing a security problem, a client MAY trust
> > > OCSP-responses
> > > without nonce."
> > >
> > > and
> > >
> > > "To prevent replay-attaks an OCSP-responder SHOULD include a
> > > nonce in every
> > > response."
> > >
> > > Rationale:
> > > - Responders can choose between security and functionality
> > > - Clients can detect Responders that chose functionality
> > >
> > > --
> > > Dipl.Inf. Florian Oelmaier
> > > syTrust S.A.
> > >
> > >
>
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SGw4612538 for ietf-pkix-bks; Mon, 28 Jan 2002 08:58:04 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SGw3312523 for <[e-mail]>; Mon, 28 Jan 2002 08:58:03 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA29210; Mon, 28 Jan 2002 17:59:25 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA12624; Mon, 28 Jan 2002 17:57:31 +0100
Message-ID: <[e-mail]>
Date: Mon, 28 Jan 2002 16:25:40 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: TSP interop update
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

> Hello,
 
> During some messages exchanged in a small group of TSA testers the
> following 'problem' had been discovered:
> 
> Draft 4 of RFC 3161 had a new requirement for the value of the
> policy in the TST:
> 
> "The policy field MUST indicate the TSAs policy under which the response was
>  produced. If a similar field was present in the TimeStampReq, then it MUST
>  have the same value, otherwise an error (badRequest) MUST be returned."
> 
> Which finally became:
> 
>   "The policy field MUST indicate the TSA's policy under which the
>    response was produced.  If a similar field was present in the
>    TimeStampReq, then it MUST have the same value, otherwise an error
>    (unacceptedPolicy) MUST be returned."

BadRequest is when the request is malformed. Here the request is well formed
but the policy is not supported (unacceptedPolicy) and thus is not accepted.
This was the reason for that change.
 
> I have not been able to determine why this change in draft 4 had been
> made. maybe I have overlooked the archives but as far as I know there
> was no summary of changes text from 3->4.
> 
> Other parts of the standard that are related to the
> policy have not been changed:
> 
>   "The reqPolicy field, if included, indicates the TSA policy under
>    which the TimeStampToken SHOULD be provided."

If the server does not support the policy, we cannot force the server to
support it, and hence why SHALL cannot be simply substituted. In order 
to be more explicit we could say:

   The reqPolicy field, if included, indicates the TSA policy under 
   which the TimeStampToken SHALL be issued (provided that policy is 
   supported by the server).


Denis


> (Note that in version 3 of the draft the SHOULD was 'should')
> 
> "The client application SHOULD check the policy field to determine
> whether or not the policy under which the token was issued is acceptable
> for the application.  The client MAY ignore this field if that is
> acceptable for the intended application."
> 
> IMO these two statements do not correspond to changed text of 'MUST be
> identical'. (cf treatment of nocne and messagedigest)
> 
> There are two possible ways:
> 
> - The 'MUST have the same value' is intended (why please??)
> 
>   Then the SHOULDs in the other two paragraphs should be changed
>   to MUST similar to other requirements for example for the
>   messagedigest or nonce.
> 
>   example potential text:
> 
>   "The reqPolicy field, if included, indicates the TSA policy under
>    which the TimeStampToken MUST be provided."
> 
> "If the client application has provided a policy identifier, it MUST
>  check whether the policy field returned is identical.
>  If not, the client application { SHOULD/MAY ??} check the value
>  in order to determine whether or not the policy under which the
>  token was issued is acceptable for the application.
>  The client MAY ignore this field if that is acceptable for the
>  intended application."
> 
>  What does "MAY ignore mean?"
> 
> - The change in 3->4 is not necessary and the two other paragraphs
>   containing 'SHOULD check" etc in RFC 3161 define the intended meaning.
> 
> Peter



Received: by above.proper.com (8.11.6/8.11.3) id g0SGw4P12537 for ietf-pkix-bks; Mon, 28 Jan 2002 08:58:04 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SGw2312517 for <[e-mail]>; Mon, 28 Jan 2002 08:58:02 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA12122; Mon, 28 Jan 2002 17:59:25 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA12622; Mon, 28 Jan 2002 17:57:30 +0100
Message-ID: <[e-mail]>
Date: Mon, 28 Jan 2002 15:48:38 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: TSP interop update
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

> > So the standard will be modified to consider the criticality flag.

> This sentence may be misleading.
 
> Do we follow X509's latest version, or is it allowed
> to have some behaviour as in 2459 for the extendedkeyusage.

The current text is in TSP as follows:

   If an extension, whether it is marked critical or not critical, is
   used by a requester but is not recognized by a time-stamping server,
   the server SHALL not issue a token and SHALL return a failure
   (unacceptedExtension).

<draft-ietf-pkix-new-part1-12.txt> states in section 4.2:

 A certificate using system MUST reject the certificate if it encounters
 a critical extension it does not recognize; however, a non-critical
 extension MAY be ignored if it is not recognized. 
 
If we transpose this sentence in the context of TSP then we should have:

A server MUST reject the request if it encounters a critical extension 
it does not recognize and in that case SHALL return a failure
(unacceptedExtension); however, non-critical extensions MAY be ignored, 
if not recognized.

This new sentence is thus proposed to replace the current text mentioned 
at the top of this e-mail.

Denis


> > > My understanding is that extension processing follows
> > > those described for certificate extensions.
> Which have recently be changed in X509.
> 
> I suggest something like:
> 
>   If an extension is known it is treated independantly of
>   the value of the criticality bit.
>   Otherwise, i.e., if the extension is not known,
>   and the criticality flag is set, the request is
>   rejected.
>   Otherwise, i.e. when the criticality flag is false
>   the extension is simply ignored.
>   The definition of an extension MUST NOT indicate
>   different treatment depending on the criticality bit.
> 
>




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SGw4912532 for ietf-pkix-bks; Mon, 28 Jan 2002 08:58:04 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SGw2312515 for <[e-mail]>; Mon, 28 Jan 2002 08:58:02 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA29208; Mon, 28 Jan 2002 17:59:23 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA12618; Mon, 28 Jan 2002 17:57:29 +0100
Message-ID: <[e-mail]>
Date: Mon, 28 Jan 2002 14:09:31 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Roberto Opazo Gazmuri <[e-mail]>
CC: "PKIX (Grupo de la IETF)" <[e-mail]>
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0SGw3312520
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Hi, my name is Roberto Opazo, this is my first mail sent to the group.
 
> In Chile we have finished approving the law of electronic signature and we
> are initiating conversations to define the regulation that must complement
> this law. A central subject of the discussion is how information of the
> national unique roll, called RUN (Rol Unico Nacional) should be included in
> certificates. That is a number only associate to each citizen in all the
> country. It is a comparable identifier to the social security number
> insurance in the U.S.A. but its use is but spread, since most of the
> Chileans they obtain his RUN when being born and practically all the
> computer science applications of the country use it to identify the users.
> An important precedent in our country about the form to include this
> identifier in a certificate is a resolution of the Service of Internal Taxes
> that it establishes that the extension "Subject Alternative Name " is due to
> use. The organization who I represent (Acepta.com) is promotional of this
> form of codification. Nevertheless, a local CA, who uses technology of RSA
> Labs argues that this is difficult to codify and difficult to read. They are
> in favor to use the field "Subject" on some form. I would like to request
> help with the following doubts:
 
> * It seems to be reasonable to place a RUN in the "Subject"?

Today, there is no attribute in the "subject" that has a semantics that, by
itself, tells that this attribute is unique. The only meaning is that the
*set of* attributes shall be unique. 

RFC 3039 states the following:

   The serialNumber attribute type SHALL, when present, be used to
   differentiate between names where the subject field would otherwise
   be identical.  This attribute has no defined semantics beyond
   ensuring uniqueness of subject names.  It MAY contain a number or
   code assigned by the CA or an identifier assigned by a government or
   civil authority.  It is the CA's responsibility to ensure that the
   serialNumber is sufficient to resolve any subject name collisions.

So if you place the "National Unique Roll" (NUR) in the subject field 
it will certainly allow you to make a difference between two persons 
that have the same family and first name, but you cannot take 
advantage of the fact that this attribute is indeed unique.

 
> * In individual, could be used the attribute "Serial Number" of the field
> "Subject" for this?

As indicated above, the serialNumber atribute does not have the property of
uniqueness by itself. So it can help you to establish the global uniqueness
of the name, as long as no application uses the serialNumber attibute alone.
This means that, e.g. it is not allowed to use ACL entries that contains the
serialNumber attribute alone, instead ACL entries must contain all the
attributes contained in the DN from the certificate to which an access is to
be granted.

> * Where I can find examples of certificates which they use the extension
> "Subject Alternative Name"?

Such extensions are used as soon as Distinguished Names are not being used.
I let tother people from the mailing list to provide examples.

> * Where I can find normative what exist of other countries that have solved
> east kind of problem?

There exists a draft document that addresses this issue. Although expired,
it is yet available on the IETF web server. Take a look at:
http://www.imc.org/draft-ietf-pkix-pi

It defines a specific extension in the Subject Alternative Name to support
Permnanent Identifiers. Since certificates can have an empty subject name,
it is necessary to allow the support of the concept of permanent identifier
as part of the subject Alternative Name. 

However, at the light of different conversations that took place, I would
think that it might be appropriate at this time to define new attributes
that could be included in the subject DN to support the notion of Permanent
identifier.

The next two questions are for you: 

1) if two certificates *from two different CAs* contain the same RUN 
   (Rol Unico Nacional) is your intention to be able to say that it is 
   the same person ?

2) after having taken a look at http://www.imc.org/draft-ietf-pkix-pi, 
   would you think more appropriate in your case to support the notion 
   of permanent identifier in the DN or in the Subject Alternative Name ?


Denis


> Thank you very much by its aid.
> 
> As it is my first mail to the group, them control a small presentation...
> 
> I am founding and Acepta.com’s CEO, a CA developed in Chile using OpenSSL.
> We were first in obtaining the accreditation on the part of the Service of
> Internal Taxes of the Country on March 2001 (only 2 CAs are on this position
> at this time). We have actively collaborated in the development of an
> operational model to use electronic invoice that soon will begin to work and
> I believe that it will leave more to Chile like one of the advanced
> countries in the use of PKI, as much by the penetration in the Internet
> users, like by the real value contributed by the technology.
> 
> Greetings,
> 
> Opazo, Roberto
> CEO – www.acepta.com
> Certification Authority for Chile




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0SGw4m12536 for ietf-pkix-bks; Mon, 28 Jan 2002 08:58:04 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SGw2312519 for <[e-mail]>; Mon, 28 Jan 2002 08:58:02 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA10328; Mon, 28 Jan 2002 17:59:24 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA12620; Mon, 28 Jan 2002 17:57:29 +0100
Message-ID: <[e-mail]>
Date: Mon, 28 Jan 2002 15:29:03 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'Florian Oelmaier'" <[e-mail]>, [e-mail]
Subject: Re: OCSP extensions
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Ambarish,

The current text is the following:

   The nonce cryptographically binds a request and a response to prevent
   replay attacks. The nonce is included as one of the requestExtensions
   in requests, while in responses it would be included as one of the
   responseExtensions. In both the request and the response, the nonce
   will be identified by the object identifier id-pkix-ocsp-nonce, while
   the extnValue is the value of the nonce.

If the nonce is not used, then the only field to prevent replay attacks is
the use of the field producedAt. However the text does not explain what kind
of processing should be done with that field from a client point of view.

At the end of section "4.2.2.1 Time" it would be appropriate to add after:

   The producedAt time is the time at which this response was signed.

The following sentence:

"When replay attack protection is required, a client MUST check that the
producedAt time is close to the local current time, otherwise when no local
clock is available, then, it SHALL use a nonce (see section 4.4.1)."

Then in the security considerations section we should provide some warning
when using the producedAt time in the context of 2.5.

" When pre-produce signed responses are used by the servers, the field
producedAt time is not necessarily a time close to the time of the request.
So unless this field is checked to be close to the current time, replay
attacks are possible."  

Denis

 
> Hi Florian,
> 
>     Interesting point of view. However, we are at the stage of
> progressing OCSP from a Proposed to a Draft Standard.
> 
> If the standard as it currently stands is not broken, I would
> prefer leaving the meaning of fields as they currently are.
> 
> What you are proposing is a legitimate extension, but quite
> different in semantics from the nonce as defined in OCSP.
> 
> What might make sense, is to come up with a separate draft of
> useful OCSP extensions, run that through the standards process
> and merge it with the OCSP spec when both reach the same level
> of acceptance. A list of "standard" OCSP extensions has been
> on my TODO list for some time now - so if you like, we can work
> on such a draft together.
> 
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> > -----Original Message-----
> > From: Florian Oelmaier [mailto:[e-mail]]
> > Sent: Monday, January 21, 2002 4:08 AM
> > To: Santosh Chokhani; Yuriy Dzambasow; Ambarish Malpani;
> > 'Deacon, Alex';
> > [e-mail]
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> > Hello Santosh,
> >
> > I would like to add some comments to your suggestion b)
> >
> > >
> > > b.  If the request has a nonce extension, the response must have
> > > the nonce extension with the same value as the request.
> > >
> >
> > Although I appreciate this change as it improves the security of the
> > protocol, I have a point that I want you to see clearly
> > before making this
> > change.
> >
> > As the client most probably knows nothing about the
> > Validation-System behind
> > a PKI (except the IP of the OCSP-Responder, he has to contact) it is
> > advisable for the client to always include a nonce into his request
> > ("well-behaving client"). With "well-behaving clients" and
> > the proposed
> > change of the RfC we will face problems with these scenarios:
> >
> > Scenario 1: Setup of a Responder that pre-produces answers as
> > specified in
> > 2.5 of RfC 2560.
> >
> > Scenario 2: Setup of a PKI that uses HTTP-Caching as given
> > for example in
> > A.1.1 of RfC 2560.
> >
> > Scenario 3: Some PKIs use a Root-Responder architecture with
> > various other
> > responders relaying to this root responder and caching his
> > answer for a
> > certain period of time. [Although I disregard such an
> > architecture, it is
> > used today]
> >
> > These problems may lead to clients not using nonce per
> > default. If a client
> > does not use a nonce, it is vulnerable to replay-attacks.
> >
> > Today an OCSP-Responder can decide if he wants to expose himself to
> > replay-attacks by generating answers without nonces. That means if a
> > responder generates only ONE response without nonce it is
> > vulnerable. On the
> > other hand, if an OCSP-responder includes a nonce in every
> > response ever
> > generated in his lifetime, regardless of a nonce in the
> > request, it is NOT
> > vulnerable to replay-attacks (at least not to "well-behaving
> > clients").
> >
> > Therefore I would suggest the following change to clarify the
> > RfC instead of
> > the proposed change:
> >
> > "Every client MUST include a nonce into his request. If a
> > nonce is included
> > in the response, the client MUST match it to the nonce of the request.
> > Although imposing a security problem, a client MAY trust
> > OCSP-responses
> > without nonce."
> >
> > and
> >
> > "To prevent replay-attaks an OCSP-responder SHOULD include a
> > nonce in every
> > response."
> >
> > Rationale:
> > - Responders can choose between security and functionality
> > - Clients can detect Responders that chose functionality
> >
> > --
> > Dipl.Inf. Florian Oelmaier
> > syTrust S.A.
> >
> >




Received: by above.proper.com (8.11.6/8.11.3) id g0SA5g115152 for ietf-pkix-bks; Mon, 28 Jan 2002 02:05:42 -0800 (PST)
Received: from svart.tajt.se (svart.tajt.se [195.178.183.135]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0SA5d315142 for <[e-mail]>; Mon, 28 Jan 2002 02:05:39 -0800 (PST)
Received: from tajt.se (bacchus.tajt.se [195.178.183.129]) by svart.tajt.se (8.12.1/8.12.1/Debian -5) with ESMTP id g0SA4odC011564 for <[e-mail]>; Mon, 28 Jan 2002 11:04:50 +0100
Message-ID: <[e-mail]>
Date: Mon, 28 Jan 2002 11:04:53 +0100
From: Tomas Gustavsson <[e-mail]>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120
X-Accept-Language: en-us
MIME-Version: 1.0
To: [e-mail]
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

And in the meantime meantime, we were actually hoping the trend with 
stuffing anything into the DN would be over soon...


> The Swedish standard SS614331 describes the content of
> certificates used in "electronic ID" smart cards. It
> suggests that the national identity number be put in the
> subject name field, as a serial number. Thus, a Swedish
> citizen could have a certificate with a name of the form:
> 
> C=SE,surname=Anders,givenName=Johansson,serialNumber=691228-0378




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0S9TWX07189 for ietf-pkix-bks; Mon, 28 Jan 2002 01:29:32 -0800 (PST)
Received: from mail.utfors.se (mail.utfors.se [195.58.103.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0S9TU307184 for <[e-mail]>; Mon, 28 Jan 2002 01:29:30 -0800 (PST)
Received: from arport ([62.119.75.13]) by mail.utfors.se (8.8.8/8.8.8) with SMTP id KAA16876; Mon, 28 Jan 2002 10:29:02 +0100 (MET)
Message-ID: <002d01c1a7de$21ec09e0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Roberto Opazo Gazmuri" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "Peter Gutmann" <[e-mail]>
References: <[e-mail]>
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Date: Mon, 28 Jan 2002 10:28:21 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Thanx Peter,
That was a truly elaborate scheme! 

In what way is this better than the brutally simple solution used in Finland,
where a proxy-number stored in serialNumber, is mapped by the authorities
that has access to a CA-maintained mapping directory, to get the personal
(more or less secret) id?

In particular, does this scheme offer a permanent identifier also for non
"HKID-permitted" RPs? I does not seem like that.  That was maybe a
part of the design not to?

Actually, I don't understand how a "HKID-permitted" RPs can
extract the HKID without asking the CA for help.  If that's the case,
even the hashed HKID seems redundant, as each certificate must
anyway be "recorded" together with its associated HKID?
 
Doesn't the client side need special SW to perform the signing of
HKIDs?

Regarding Al's comment that certificates are public, this is not entirely true,
as at least in Sweden, certificates are not stored for general access.  I.e.
certificates are (at least theoretically), only transferred to trusted parties
of the subject.

Anders

----- Original Message ----- 
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>; <[e-mail]>
Sent: Monday, January 28, 2002 05:05
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"



"Al Arsenault" <[e-mail]> writes:

>The Government of Hong Kong wanted to include the Hong Kong Identifier (HKID,
>a unique string assigned to each authorized resident of the SAR) in
>certificates.  But, the HKID is by law "private data"; its use or disclosure
>outside of carefully delineated circumstances is a violation of law. So
>putting the ID in the certificate was a non-starter - certificates are public
>data.
>
>So how did they do it?  Check out
>
>http://www.hongkongpost.gov.hk/5digital/dc4_fr.html
>
>Specifically, the details are given in footnote 6 on page 48  of the 27 August
>2001 CPS.

And to save everyone else having to chase this down as well, it's:

The subscriber's HKID number (hkid_number - including the check digit) will be
stored in the certificate in the form of a hash value of the HKID number
(cert_hkid_hash) which has been signed by the private key of the subscriber:-
cert_

hkid_hash = SHA-1 ( RSAprivatekey, sha-1 ( hkid_number ) )

where the SHA-1 is a hash function and RSA is the signing function

For key generation by subscribers, hkid_number will be signed at the
subscriber's browser. For Central Key Generation, hkid_number will be signed
during the key generation process at HKPost premises. The signed HKID Number -
RSAprivatekey, sha-1 ( hkid_number ) - will be passed to the Hongkong Post CA
system through a secure channel. Upon verification of subscriber data at CA
system side, the CA system will create a hash of the signed HKID number - SHA-1
( RSAprivatekey, sha-1 ( hkid_number ) ). The hash value will then be put into
the designated extension field (DNSname) of the certificate being generated.

Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g0S463i13122 for ietf-pkix-bks; Sun, 27 Jan 2002 20:06:03 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0S461313117 for <[e-mail]>; Sun, 27 Jan 2002 20:06:01 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id RAA21190; Mon, 28 Jan 2002 17:05:54 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA347785; Mon, 28 Jan 2002 17:05:54 +1300 (NZDT) (sender [e-mail])
Date: Mon, 28 Jan 2002 17:05:54 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Al Arsenault" <[e-mail]> writes:

>The Government of Hong Kong wanted to include the Hong Kong Identifier (HKID,
>a unique string assigned to each authorized resident of the SAR) in
>certificates.  But, the HKID is by law "private data"; its use or disclosure
>outside of carefully delineated circumstances is a violation of law. So
>putting the ID in the certificate was a non-starter - certificates are public
>data.
>
>So how did they do it?  Check out
>
>http://www.hongkongpost.gov.hk/5digital/dc4_fr.html
>
>Specifically, the details are given in footnote 6 on page 48  of the 27 August
>2001 CPS.

And to save everyone else having to chase this down as well, it's:

The subscriber’s HKID number (hkid_number - including the check digit) will be
stored in the certificate in the form of a hash value of the HKID number
(cert_hkid_hash) which has been signed by the private key of the subscriber:-
cert_

hkid_hash = SHA-1 ( RSAprivatekey, sha-1 ( hkid_number ) )

where the SHA-1 is a hash function and RSA is the signing function

For key generation by subscribers, hkid_number will be signed at the
subscriber’s browser. For Central Key Generation, hkid_number will be signed
during the key generation process at HKPost premises. The signed HKID Number -
RSAprivatekey, sha-1 ( hkid_number ) - will be passed to the Hongkong Post CA
system through a secure channel. Upon verification of subscriber data at CA
system side, the CA system will create a hash of the signed HKID number - SHA-1
( RSAprivatekey, sha-1 ( hkid_number ) ). The hash value will then be put into
the designated extension field (DNSname) of the certificate being generated.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0S2H8n26460 for ietf-pkix-bks; Sun, 27 Jan 2002 18:17:08 -0800 (PST)
Received: from femail16.sdc1.sfba.home.com (femail16.sdc1.sfba.home.com [24.0.95.143]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0S2H8326456 for <[e-mail]>; Sun, 27 Jan 2002 18:17:08 -0800 (PST)
Received: from SJOSEPH ([68.55.160.145]) by femail16.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20020128021711.XZQL22224.femail16.sdc1.sfba.home.com@SJOSEPH>; Sun, 27 Jan 2002 18:17:11 -0800
Message-ID: <007a01c1a7a1$6739d0a0$6501a8c0@SJOSEPH>
From: "Al Arsenault" <[e-mail]>
To: =?iso-8859-1?Q?Henrik_St=E5hl?= <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Date: Sun, 27 Jan 2002 21:13:39 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

And for something completely different: :-)

The Government of Hong Kong wanted to include the Hong Kong Identifier
(HKID, a unique string assigned to each authorized resident of the SAR) in
certificates.  But, the HKID is by law "private data"; its use or disclosure
outside of carefully delineated circumstances is a violation of law. So
putting the ID in the certificate was a non-starter - certificates are
public data.

So how did they do it?  Check out

http://www.hongkongpost.gov.hk/5digital/dc4_fr.html

Specifically, the details are given in footnote 6 on page 48  of the 27
August 2001 CPS.

(Disclaimer: I had nothing to do with developing that solution, I just wind
up using it.  There are lots of interesting issues with this solution -
probably enough to fill a book - but I point it out as an example of a
Government attempting to solve the type of problem about which Roberto
asked.)

        Al Arsenault
        Chief Security Architect
        Diversinet Corp.


----- Original Message -----
From: "Henrik Ståhl" <[e-mail]>
To: <[e-mail]>
Sent: Sunday, January 27, 2002 3:31 PM
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"


>
> Hello Roberto,
>
> The Swedish standard SS614331 describes the content of
> certificates used in "electronic ID" smart cards. It
> suggests that the national identity number be put in the
> subject name field, as a serial number. Thus, a Swedish
> citizen could have a certificate with a name of the form:
>
> C=SE,surname=Anders,givenName=Johansson,serialNumber=691228-0378
>
> The only widespread uses I have seen for the subjectAltName
> extension has been in S/MIMEv3, where the e-mail address
> of the subject is stored as a rfc822Name, and in some
> IPSEC certificates, where the IP address is stored
> there. While it would maybe be logical for a SSL server
> certificate to have the URI in subjectAltName, all
> implementations I have seen instead uses the common
> name part of the subject name to store the name of the
> server.
>
> If you would like a copy of the standards document,
> or a few example certificates, I would be happy to
> provide you with them.
>
> Henrik Ståhl
> Omegapoint AB



Received: by above.proper.com (8.11.6/8.11.3) id g0RKVO205584 for ietf-pkix-bks; Sun, 27 Jan 2002 12:31:24 -0800 (PST)
Received: from smtp2.chello.se (smtp2.chello.se [193.150.195.11]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0RKVM305580 for <[e-mail]>; Sun, 27 Jan 2002 12:31:23 -0800 (PST)
Received: from omegapoint.se ([213.89.255.106]) by smtp2.chello.se (InterMail vK.4.03.00.00 201-232-121 license d2583c0617b67bae473a44216fd3d32d) with ESMTP id <[e-mail]> for <[e-mail]>; Sun, 27 Jan 2002 21:31:14 +0100
Message-ID: <[e-mail]>
Date: Sun, 27 Jan 2002 21:31:18 +0100
From: Henrik =?iso-8859-1?Q?St=E5hl?= <[e-mail]>
Organization: Omegapoint AB
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Roberto,

The Swedish standard SS614331 describes the content of
certificates used in "electronic ID" smart cards. It
suggests that the national identity number be put in the
subject name field, as a serial number. Thus, a Swedish
citizen could have a certificate with a name of the form:

C=SE,surname=Anders,givenName=Johansson,serialNumber=691228-0378

The only widespread uses I have seen for the subjectAltName
extension has been in S/MIMEv3, where the e-mail address
of the subject is stored as a rfc822Name, and in some
IPSEC certificates, where the IP address is stored
there. While it would maybe be logical for a SSL server
certificate to have the URI in subjectAltName, all
implementations I have seen instead uses the common
name part of the subject name to store the name of the
server.

If you would like a copy of the standards document,
or a few example certificates, I would be happy to
provide you with them.

Henrik Ståhl
Omegapoint AB


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0R8o7m26883 for ietf-pkix-bks; Sun, 27 Jan 2002 00:50:07 -0800 (PST)
Received: from maile.telia.com (maile.telia.com [194.22.190.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0R8o5326875 for <[e-mail]>; Sun, 27 Jan 2002 00:50:06 -0800 (PST)
Received: from arport (t6o69p98.telia.com [213.64.110.218]) by maile.telia.com (8.11.6/8.11.6) with SMTP id g0R8nos20215; Sun, 27 Jan 2002 09:49:52 +0100 (CET)
Message-ID: <001301c1a70f$7e721bc0$0500a8c0@arport>
From: "Anders Rundgren" <[e-mail]>
To: "Roberto Opazo Gazmuri" <[e-mail]>, "PKIX \(Grupo de la IETF\)" <[e-mail]>
References: <[e-mail]>
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Date: Sun, 27 Jan 2002 09:49:10 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Roberto,

I can give you some information on how some other CAs have handled
this.  In the Nordics (Sweden + Finland) we have a unique code called
person-number that we indeed put into certificates.  According the
Qualified Certificate (RFC3039) profile you can use serialNumber
for holding such identifiers which is the case of the Swedish and Finnish
certificates.  To use SubjectAltName is also possible but less
often featured.  VeriSign use a private such extension for keeping
DUNS (Duns & Bradstreet) numbers in Web-server certificates
which is the same thing as person-numbers but for companies.
But no web-browsers etc. understand this extension, so it will
be listed in hex-code, and since it is not standard either,
few even know that this information is there!

PKIX has a now expired effort addressing the s.c. "permanent identifier"
problem, but right now serialNumber looks like the right solution.

An interesting side discussion: The person-numbers in
SE+FI contains information like date of birth and gender which
is fine when used together with authorities as they already have
this information.  However, this makes the certificates less
"popular" within organizations where you may not want to
expose date of birth all the time.  Therefore Finland created
a "proxy" number that of course still is unique but contains
no information.  Although none of these PKIs have gotten
very far, I believe the Finish solution is recommendable.

Regards
Anders Rundgren
X-OBI

----- Original Message ----- 
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "PKIX (Grupo de la IETF)" <[e-mail]>
Sent: Saturday, January 26, 2002 22:31
Subject: "Subject Alternative Name" v/s "Subject/Serial Number"



Hi, my name is Roberto Opazo, this is my first mail sent to the group.

In Chile we have finished approving the law of electronic signature and we
are initiating conversations to define the regulation that must complement
this law. A central subject of the discussion is how information of the
national unique roll, called RUN (Rol Unico Nacional) should be included in
certificates. That is a number only associate to each citizen in all the
country. It is a comparable identifier to the social security number
insurance in the U.S.A. but its use is but spread, since most of the
Chileans they obtain his RUN when being born and practically all the
computer science applications of the country use it to identify the users.
An important precedent in our country about the form to include this
identifier in a certificate is a resolution of the Service of Internal Taxes
that it establishes that the extension "Subject Alternative Name " is due to
use. The organization who I represent (Acepta.com) is promotional of this
form of codification. Nevertheless, a local CA, who uses technology of RSA
Labs argues that this is difficult to codify and difficult to read. They are
in favor to use the field "Subject" on some form. I would like to request
help with the following doubts:

* It seems to be reasonable to place a RUN in the "Subject"?

* In individual, could be used the attribute "Serial Number" of the field
"Subject" for this?

* Where I can find examples of certificates which they use the extension
"Subject Alternative Name"?

* Where I can find normative what exist of other countries that have solved
east kind of problem?

Thank you very much by its aid.

As it is my first mail to the group, them control a small presentation...

I am founding and Acepta.com's CEO, a CA developed in Chile using OpenSSL.
We were first in obtaining the accreditation on the part of the Service of
Internal Taxes of the Country on March 2001 (only 2 CAs are on this position
at this time). We have actively collaborated in the development of an
operational model to use electronic invoice that soon will begin to work and
I believe that it will leave more to Chile like one of the advanced
countries in the use of PKI, as much by the penetration in the Internet
users, like by the real value contributed by the technology.

Greetings,

Opazo, Roberto
CEO - www.acepta.com
Certification Authority for Chile




Received: by above.proper.com (8.11.6/8.11.3) id g0QLaOr26377 for ietf-pkix-bks; Sat, 26 Jan 2002 13:36:24 -0800 (PST)
Received: from marte.ifxnw.cl (marte.ifxnw.cl [216.241.0.152]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0QLaM326372 for <[e-mail]>; Sat, 26 Jan 2002 13:36:22 -0800 (PST)
Received: from ropazo (unverified [216.241.20.226]) by marte.ifxnw.cl (Rockliffe SMTPRA 3.4.7) with SMTP id <[e-mail]> for <[e-mail]>; Sat, 26 Jan 2002 18:37:21 -0400
From: "Roberto Opazo Gazmuri" <[e-mail]>
To: "PKIX \(Grupo de la IETF\)" <[e-mail]>
Subject: "Subject Alternative Name" v/s "Subject/Serial Number"
Date: Sat, 26 Jan 2002 18:31:48 -0300
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 1 (Highest)
X-MSMail-Priority: High
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Importance: High
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi, my name is Roberto Opazo, this is my first mail sent to the group.

In Chile we have finished approving the law of electronic signature and we
are initiating conversations to define the regulation that must complement
this law. A central subject of the discussion is how information of the
national unique roll, called RUN (Rol Unico Nacional) should be included in
certificates. That is a number only associate to each citizen in all the
country. It is a comparable identifier to the social security number
insurance in the U.S.A. but its use is but spread, since most of the
Chileans they obtain his RUN when being born and practically all the
computer science applications of the country use it to identify the users.
An important precedent in our country about the form to include this
identifier in a certificate is a resolution of the Service of Internal Taxes
that it establishes that the extension "Subject Alternative Name " is due to
use. The organization who I represent (Acepta.com) is promotional of this
form of codification. Nevertheless, a local CA, who uses technology of RSA
Labs argues that this is difficult to codify and difficult to read. They are
in favor to use the field "Subject" on some form. I would like to request
help with the following doubts:

* It seems to be reasonable to place a RUN in the "Subject"?

* In individual, could be used the attribute "Serial Number" of the field
"Subject" for this?

* Where I can find examples of certificates which they use the extension
"Subject Alternative Name"?

* Where I can find normative what exist of other countries that have solved
east kind of problem?

Thank you very much by its aid.

As it is my first mail to the group, them control a small presentation...

I am founding and Acepta.com’s CEO, a CA developed in Chile using OpenSSL.
We were first in obtaining the accreditation on the part of the Service of
Internal Taxes of the Country on March 2001 (only 2 CAs are on this position
at this time). We have actively collaborated in the development of an
operational model to use electronic invoice that soon will begin to work and
I believe that it will leave more to Chile like one of the advanced
countries in the use of PKI, as much by the penetration in the Internet
users, like by the real value contributed by the technology.

Greetings,

Opazo, Roberto
CEO – www.acepta.com
Certification Authority for Chile



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PMpHS22894 for ietf-pkix-bks; Fri, 25 Jan 2002 14:51:17 -0800 (PST)
Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PMp6322889 for <[e-mail]>; Fri, 25 Jan 2002 14:51:06 -0800 (PST)
Received: from fwd02.sul.t-online.de  by mailout09.sul.t-online.com with smtp  id 16UFBY-0002pQ-0C; Fri, 25 Jan 2002 23:51:04 +0100
Received: from junker.stroeder.com (520010731148-0001@[62.224.169.42]) by fmrl02.sul.t-online.com with esmtp id 16UFBY-0ZXyzYC; Fri, 25 Jan 2002 23:51:04 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id DC7C0157117; Fri, 25 Jan 2002 16:46:31 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 25 Jan 2002 16:46:31 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: Infinite loop: See loop, infinite
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter Gutmann wrote:
> 
> Found in a certificate which someone sent me:
> 
> 7968 30  177:     SEQUENCE {
> 7971 06    3:       OBJECT IDENTIFIER subjectAltName (2 5 29 17)
> 7976 04  169:       OCTET STRING, encapsulates {
> 7979 30  166:           SEQUENCE {
> 7982 86  163:             [6] 'ldap://ldap.infocamere.it/cn%3DTUMEDEI%2FANGELO%'
>             :                 '2FTMDNGL60A20D704Q%2F2001111345465%2Cou%3DCertif'
>             :                 'icati%20di%20Firma%2Co%3DInfoCamere%20SCpA%2Cc%3'
>             :                 'DIT?usercertificate'
>             :             }
>             :           }
>             :       }
> 
> (the LDAP URL points back to the certificate which contains it).  In other
> words to resolve the certificate altName, you go to the LDAP server and fetch
> the certificate, which contains an altName, ...
> 
> I wonder what the semantics of such an item are?

Semantics of URLs in subjectAltName and issuerAltName are not
well-defined anyway.

> (This is even more amusing than the wonderful Windows-produced certs with URLs
>  like "file://\\bobs_win2K_box\blah.cer", which are going to be really useful
>  to the world at large).

Well, that's a funny example. But file:-URLs might make sense within
an organization.

Ciao, Michael.


Received: by above.proper.com (8.11.6/8.11.3) id g0PLmTG21352 for ietf-pkix-bks; Fri, 25 Jan 2002 13:48:29 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PLmR321348 for <[e-mail]>; Fri, 25 Jan 2002 13:48:27 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 25 Jan 2002 13:48:20 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 25 Jan 2002 13:48:19 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <DS53B0R0>; Fri, 25 Jan 2002 13:48:19 -0800
Content-return: allowed
Date: Fri, 25 Jan 2002 13:48:18 -0800
From: Peter Williams <[e-mail]>
Subject: RE: Infinite loop: See loop, infinite
To: "'[e-mail] '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="iso-8859-1"
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

http://www.ubiqx.org/cifs/index.html

Once the SMB URL form gets to RFC, the file:// should
probably change to smb://

On an MS platform, the platform which was
the target of the jibe, file: is logically
the same as smb: anyway.

if the win2k or even better the .net CA server
from Microsoft put smb://<ip-address>/foo.cer then
(a) we will get the SMB/NMB browsing and
browser elections, to enable cert repository discovery 
and location for free, with auto determination 
of which is the most reliable repository mirror
(b) end-end authentication of each SMB message without
needing IPSEC support for the validation protocols
built over SMB
(c) the ip-address means we overcome the naming
scoping limitations of netbios, but we still dont
need to rely on global DNS or VeriSign control of name
registration, etc. IP addresses are names
in their own right, remember, and are routable using
source-IP controls, and IP forwarding nets.
(d) on actual windows client platforms worldwide, users can 
bind in parallel to multiple repositories with different credentials, 
when the repository is located using IP address name
rather than a netbios name.

I think they are going in the right direction: potentially,
using net mechanisms to assist with discovery and location
of PKI objects. Its a well proven technology... for
peer-peer networking of private domains, security,
certification, or otherwise.

Peter.

-----Original Message-----
From: Hallam-Baker, Phillip
To: [e-mail]; [e-mail]
Sent: 1/25/02 7:49 AM
Subject: RE: Infinite loop: See loop, infinite

> (This is even more amusing than the wonderful 
> Windows-produced certs with URLs
>  like "file://\\bobs_win2K_box\blah.cer", which are going to 
> be really useful
>  to the world at large).

Come now, limiting the ability to make use of a certificate to
a specific domain is something a lot of people have been asking
for.

There have been many exotic schemes that are a lot less reliable.
Kinda like the various cryptographic exotica to provide someone's
definition of anonymity which can often be addressed at far lower
cost using something like a one time use certificate.

		Phill

 <<Phillip Hallam-Baker (E-mail).vcf>> 


Received: by above.proper.com (8.11.6/8.11.3) id g0PIYGU16556 for ietf-pkix-bks; Fri, 25 Jan 2002 10:34:16 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PIYE316550 for <[e-mail]>; Fri, 25 Jan 2002 10:34:14 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA29375 for <[e-mail]>; Fri, 25 Jan 2002 19:34:15 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 25 Jan 2002 19:34:15 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA05906 for <[e-mail]>; Fri, 25 Jan 2002 19:34:14 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA07783 for [e-mail]; Fri, 25 Jan 2002 19:34:13 +0100 (MET)
Date: Fri, 25 Jan 2002 19:34:13 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: TSP interop update
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello,



During some messages exchanged in a small group of TSA testers the
following 'problem' had been discovered:

Draft 4 of RFC 3161 had a new requirement for the value of the
policy in the TST: 

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

Which finally became:

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

I have not been able to determine why this change in draft 4 had been
made. maybe I have overlooked the archives but as far as I know there
was no summary of changes text from 3->4.

Other parts of the standard that are related to the
policy have not been changed:

  "The reqPolicy field, if included, indicates the TSA policy under
   which the TimeStampToken SHOULD be provided."  

(Note that in version 3 of the draft the SHOULD was 'should')

"The client application SHOULD check the policy field to determine
whether or not the policy under which the token was issued is acceptable
for the application.  The client MAY ignore this field if that is
acceptable for the intended application."


IMO these two statements do not correspond to changed text of 'MUST be
identical'. (cf treatment of nocne and messagedigest)

There are two possible ways: 

- The 'MUST have the same value' is intended (why please??)
  
  Then the SHOULDs in the other two paragraphs should be changed
  to MUST similar to other requirements for example for the
  messagedigest or nonce. 

  example potential text: 

  "The reqPolicy field, if included, indicates the TSA policy under
   which the TimeStampToken MUST be provided."  

"If the client application has provided a policy identifier, it MUST 
 check whether the policy field returned is identical. 
 If not, the client application { SHOULD/MAY ??} check the value
 in order to determine whether or not the policy under which the 
 token was issued is acceptable for the application.  
 The client MAY ignore this field if that is acceptable for the
 intended application."

 What does "MAY ignore mean?"


- The change in 3->4 is not necessary and the two other paragraphs 
  containing 'SHOULD check" etc in RFC 3161 define the intended meaning. 


Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PI6W615733 for ietf-pkix-bks; Fri, 25 Jan 2002 10:06:32 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PI6U315729 for <[e-mail]>; Fri, 25 Jan 2002 10:06:30 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA29206; Fri, 25 Jan 2002 19:06:30 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 25 Jan 2002 19:06:30 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA05791; Fri, 25 Jan 2002 19:06:29 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA07769; Fri, 25 Jan 2002 19:06:29 +0100 (MET)
Date: Fri, 25 Jan 2002 19:06:29 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: TSP interop update
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> 
> So the standard will be modified to consider the criticality flag.
This sentence may be misleading.

Do we follow X509's latest version, or is it allowed
to have some behaviour as in 2459 for the extendedkeyusage.

> > 
> > My understanding is that extension processing follows
> > those described for certificate extensions.
Which have recently be changed in X509. 

I suggest something like:

  If an extension is known it is treated independantly of
  the value of the criticality bit.
  Otherwise, i.e., if the extension is not known, 
  and the criticality flag is set, the request is
  rejected.
  Otherwise, i.e. when the criticality flag is false
  the extension is simply ignored.
  The definition of an extension MUST NOT indicate
  different treatment depending on the criticality bit.
  
  




Received: by above.proper.com (8.11.6/8.11.3) id g0PGkwH13294 for ietf-pkix-bks; Fri, 25 Jan 2002 08:46:58 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PGkv313290 for <[e-mail]>; Fri, 25 Jan 2002 08:46:57 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA23580; Fri, 25 Jan 2002 17:48:16 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA16798; Fri, 25 Jan 2002 17:46:22 +0100
Message-ID: <[e-mail]>
Date: Fri, 25 Jan 2002 17:44:42 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Phil Griffin <[e-mail]>
CC: Peter Gutmann <[e-mail]>, [e-mail], [e-mail]
Subject: Re: TSP interop update
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Phil,

Thank you for your prompt response.

So the standard will be modified to consider the criticality flag.
If anyone opposes, it is time to speak now.

Denis

 
> Denis,
> 
> The ISO 18014-2 Independent Tokens work in JTC 1/SC 27
> does define and use extensions in part two. At least
> one of these is required to be critical. There is a
> key usage extension and one that indicates that a
> MAC is used.
> 
> My understanding is that extension processing follows
> those described for certificate extensions.
> 
> Phil Griffin
> 
> Denis Pinkas wrote:
> >
> > Peter,
> >
> > > >so I think that if the TSA doesn't understand the _semantics_ (not the syntax)
> > > >of the extension it "SHALL not issue a token and SHALL return a failure
> > > >(unacceptedExtension)."
> > >
> > > That just confirms my previous point: The RFC never explains what to do with
> > > any extension you find, therefore the semantics of all extensions are unknown
> > > (in the context of the RFC), therefore any request with extensions has to be
> > > rejected.  You could get away with this if the critical flag had been left with
> > > its standard meaning (so you could submit noncritical extensions and things
> > > would work properly), but by both overriding it and not defining the semantics
> > > for any extensions the RFC creates a situation where all extensions have to be
> > > rejected.
> >
> > I am trying to catch the messages exchanged. I share your view on that
> > point.
> >
> > It is a good catch.
> >
> > I believe that the standard should be modified to consider the criticality
> > flag. However, I have not checked whether this change would have an impact
> > or no impact on the ISO standard being prepared by SC27/WG 2.
> >
> > Any opinion from a member of that group ?
> >
> > Denis
> >
> > > Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PGgrC13180 for ietf-pkix-bks; Fri, 25 Jan 2002 08:42:53 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PGgp313175 for <[e-mail]>; Fri, 25 Jan 2002 08:42:52 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id FAA01387; Sat, 26 Jan 2002 05:42:09 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id FAA290017; Sat, 26 Jan 2002 05:42:04 +1300 (NZDT) (sender [e-mail])
Date: Sat, 26 Jan 2002 05:42:04 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail]
Subject: RE: Infinite loop: See loop, infinite
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

"Hallam-Baker, Phillip" <[e-mail]> writes:
>>(This is even more amusing than the wonderful Windows-produced certs with URLs
>> like "file://\\bobs_win2K_box\blah.cer", which are going to be really useful
>> to the world at large).
>
>Come now, limiting the ability to make use of a certificate to a specific
>domain is something a lot of people have been asking for.

But the point was that these aren't being deployed in a limited domain, they're
appearing in things like S/MIME signatures.  Putting a field which can only be
used on a local network in a cert which is distributed worldwide seems somewhat
counterproductive (although cAKeyCertIndexPair, which only makes sense to the
specific machine which created the cert, is even sillier).

Peter.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PGaRq13038 for ietf-pkix-bks; Fri, 25 Jan 2002 08:36:27 -0800 (PST)
Received: from hall.mail.mindspring.net (hall.mail.mindspring.net [207.69.200.60]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PGaQ313034 for <[e-mail]>; Fri, 25 Jan 2002 08:36:26 -0800 (PST)
Received: from 209-162-48-9.thegrid.net ([209.162.48.9] helo=ASN-1.com) by hall.mail.mindspring.net with esmtp (Exim 3.33 #1) id 16U9KF-0004Kp-00; Fri, 25 Jan 2002 11:35:40 -0500
Message-ID: <[e-mail]>
Date: Fri, 25 Jan 2002 11:32:34 -0500
From: Phil Griffin <[e-mail]>
Organization: Griffin Consulting - http://ASN-1.com
X-Mailer: Mozilla 4.73 [en]C-{C-UDP; EBM-SONY1}  (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: Peter Gutmann <[e-mail]>, [e-mail], [e-mail]
Subject: Re: TSP interop update
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

The ISO 18014-2 Independent Tokens work in JTC 1/SC 27
does define and use extensions in part two. At least
one of these is required to be critical. There is a
key usage extension and one that indicates that a 
MAC is used.

My understanding is that extension processing follows
those described for certificate extensions.

Phil Griffin




Denis Pinkas wrote:
> 
> Peter,
> 
> > >so I think that if the TSA doesn't understand the _semantics_ (not the syntax)
> > >of the extension it "SHALL not issue a token and SHALL return a failure
> > >(unacceptedExtension)."
> >
> > That just confirms my previous point: The RFC never explains what to do with
> > any extension you find, therefore the semantics of all extensions are unknown
> > (in the context of the RFC), therefore any request with extensions has to be
> > rejected.  You could get away with this if the critical flag had been left with
> > its standard meaning (so you could submit noncritical extensions and things
> > would work properly), but by both overriding it and not defining the semantics
> > for any extensions the RFC creates a situation where all extensions have to be
> > rejected.
> 
> I am trying to catch the messages exchanged. I share your view on that
> point.
> 
> It is a good catch.
> 
> I believe that the standard should be modified to consider the criticality
> flag. However, I have not checked whether this change would have an impact
> or no impact on the ISO standard being prepared by SC27/WG 2.
> 
> Any opinion from a member of that group ?
> 
> Denis
> 
> > Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0PFnM511641 for ietf-pkix-bks; Fri, 25 Jan 2002 07:49:22 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PFnL311637 for <[e-mail]>; Fri, 25 Jan 2002 07:49:21 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g0PFjkR23576; Fri, 25 Jan 2002 07:45:46 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <Y2Y14CDM>; Fri, 25 Jan 2002 07:50:06 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: Infinite loop: See loop, infinite
Date: Fri, 25 Jan 2002 07:49:51 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1A5B7.ECDE62C0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C1A5B7.ECDE62C0
Content-Type: text/plain;
	charset="iso-8859-1"

> (This is even more amusing than the wonderful 
> Windows-produced certs with URLs
>  like "file://\\bobs_win2K_box\blah.cer", which are going to 
> be really useful
>  to the world at large).

Come now, limiting the ability to make use of a certificate to
a specific domain is something a lot of people have been asking
for.

There have been many exotic schemes that are a lot less reliable.
Kinda like the various cryptographic exotica to provide someone's
definition of anonymity which can often be addressed at far lower
cost using something like a one time use certificate.

		Phill


------_=_NextPart_000_01C1A5B7.ECDE62C0
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C1A5B7.ECDE62C0--


Received: by above.proper.com (8.11.6/8.11.3) id g0PEXV706230 for ietf-pkix-bks; Fri, 25 Jan 2002 06:33:31 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PEXT306223 for <[e-mail]>; Fri, 25 Jan 2002 06:33:29 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA22416; Fri, 25 Jan 2002 15:34:48 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA18560; Fri, 25 Jan 2002 15:32:53 +0100
Message-ID: <[e-mail]>
Date: Fri, 25 Jan 2002 15:31:14 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: TSP interop update
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Peter,

> >so I think that if the TSA doesn't understand the _semantics_ (not the syntax)
> >of the extension it "SHALL not issue a token and SHALL return a failure
> >(unacceptedExtension)."
> 
> That just confirms my previous point: The RFC never explains what to do with
> any extension you find, therefore the semantics of all extensions are unknown
> (in the context of the RFC), therefore any request with extensions has to be
> rejected.  You could get away with this if the critical flag had been left with
> its standard meaning (so you could submit noncritical extensions and things
> would work properly), but by both overriding it and not defining the semantics
> for any extensions the RFC creates a situation where all extensions have to be
> rejected.

I am trying to catch the messages exchanged. I share your view on that
point.

It is a good catch.

I believe that the standard should be modified to consider the criticality
flag. However, I have not checked whether this change would have an impact
or no impact on the ISO standard being prepared by SC27/WG 2.

Any opinion from a member of that group ?

Denis 
 
> Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g0PAVQr20923 for ietf-pkix-bks; Fri, 25 Jan 2002 02:31:26 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0PAVM320900 for <[e-mail]>; Fri, 25 Jan 2002 02:31:24 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id XAA29832 for <[e-mail]>; Fri, 25 Jan 2002 23:31:16 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id XAA283488 for [e-mail]; Fri, 25 Jan 2002 23:31:15 +1300 (NZDT) (sender [e-mail])
Date: Fri, 25 Jan 2002 23:31:15 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Infinite loop: See loop, infinite
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Found in a certificate which someone sent me:

7968 30  177:     SEQUENCE {
7971 06    3:       OBJECT IDENTIFIER subjectAltName (2 5 29 17)
7976 04  169:       OCTET STRING, encapsulates {
7979 30  166:           SEQUENCE {
7982 86  163:             [6] 'ldap://ldap.infocamere.it/cn%3DTUMEDEI%2FANGELO%'
            :                 '2FTMDNGL60A20D704Q%2F2001111345465%2Cou%3DCertif'
            :                 'icati%20di%20Firma%2Co%3DInfoCamere%20SCpA%2Cc%3'
            :                 'DIT?usercertificate'
            :             }
            :           }
            :       }

(the LDAP URL points back to the certificate which contains it).  In other
words to resolve the certificate altName, you go to the LDAP server and fetch
the certificate, which contains an altName, ...

I wonder what the semantics of such an item are?

(This is even more amusing than the wonderful Windows-produced certs with URLs
 like "file://\\bobs_win2K_box\blah.cer", which are going to be really useful
 to the world at large).

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g0OI9iC02425 for ietf-pkix-bks; Thu, 24 Jan 2002 10:09:44 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0OI9h302421 for <[e-mail]>; Thu, 24 Jan 2002 10:09:43 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 24 Jan 2002 10:09:40 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 24 Jan 2002 10:09:39 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <DS53B5DM>; Thu, 24 Jan 2002 10:09:39 -0800
Content-return: allowed
Date: Thu, 24 Jan 2002 10:09:38 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: RFC 2560 question
To: "'Sven Heiberg'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Sven,
    You are right - that is a typo.

I hadn't seen that comment before, therefore it wasn't addressed
earlier.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Sven Heiberg [mailto:[e-mail]]
> Sent: Thursday, January 24, 2002 5:45 AM
> To: [e-mail]
> Subject: RFC 2560 question
> 
> 
> 
> 
> Hello
> 
> I have a simple question about RFC 2560. I suspect that there 
> is a typo in 
> the RFC. I looked through the archives and encounterd two 
> letters that had 
> the same question I'm having. Unfortunately the question was 
> not answered, 
> at least I could not find the answer from the archives.
> 
> Question:
> 
> In RFC 2560 section 4.2.2.2 (Authorized responders) it is told:
> 
> "OCSP signing delegation SHALL be designated by the inclusion of 
> id-kp-OCSPSigning in an extendedKeyUsage certificate 
> extension included in 
> the OCSP response signer's certificate."
> 
> Few lines ahead one can read:
> 
> "Systems or applications that rely on OCSP responses MUST be 
> capable of 
> detecting and enforcing use of the id-ad-ocspSigning value as 
> described 
> above."
> 
> This happens to be the first place in the RFC where the 
> id-ad-ocspSigning 
> object identifier gets mentioned. From the context I get the 
> feeling that 
> one has meant id-kp-OCSPSigning instead.
> 
> Is this typo? Should one read id-kp-OCSPSigning instead 
> id-ad-ocspSigning?
> 
> 	Sven Heiberg
> 


Received: by above.proper.com (8.11.6/8.11.3) id g0ODiuR14602 for ietf-pkix-bks; Thu, 24 Jan 2002 05:44:56 -0800 (PST)
Received: from tartu.cyber.ee (tartu.cyber.ee [193.40.6.68]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ODir314595 for <[e-mail]>; Thu, 24 Jan 2002 05:44:53 -0800 (PST)
Received: Message by Barricade tartu.cyber.ee  with ESMTP id g0ODbnL18533 for <[e-mail]>; Thu, 24 Jan 2002 15:37:49 +0200
Received: from localhost (sven@localhost) by ondatra.tartu-labor (8.11.6/8.11.6) with ESMTP id g0ODisD18957 for <[e-mail]>; Thu, 24 Jan 2002 15:44:54 +0200
Date: Thu, 24 Jan 2002 15:44:53 +0200 (EET)
From: Sven Heiberg <[e-mail]>
To: [e-mail]
Subject: RFC 2560 question
Message-ID: <[e-mail]-labor>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello

I have a simple question about RFC 2560. I suspect that there is a typo in 
the RFC. I looked through the archives and encounterd two letters that had 
the same question I'm having. Unfortunately the question was not answered, 
at least I could not find the answer from the archives.

Question:

In RFC 2560 section 4.2.2.2 (Authorized responders) it is told:

"OCSP signing delegation SHALL be designated by the inclusion of 
id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in 
the OCSP response signer's certificate."

Few lines ahead one can read:

"Systems or applications that rely on OCSP responses MUST be capable of 
detecting and enforcing use of the id-ad-ocspSigning value as described 
above."

This happens to be the first place in the RFC where the id-ad-ocspSigning 
object identifier gets mentioned. From the context I get the feeling that 
one has meant id-kp-OCSPSigning instead.

Is this typo? Should one read id-kp-OCSPSigning instead id-ad-ocspSigning?

	Sven Heiberg



Received: by above.proper.com (8.11.6/8.11.3) id g0NNZLd14548 for ietf-pkix-bks; Wed, 23 Jan 2002 15:35:21 -0800 (PST)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NNZJ314544 for <[e-mail]>; Wed, 23 Jan 2002 15:35:19 -0800 (PST)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.6/XCERT) with ESMTP id g0NNZEi15166; Wed, 23 Jan 2002 15:35:14 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.6/XCERT) with ESMTP id g0NNZDw14569; Wed, 23 Jan 2002 15:35:13 -0800 (PST)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <VVXYZ010>; Wed, 23 Jan 2002 15:37:46 -0800
Message-ID: <[e-mail]>
From: "McCutcheon, Mark" <[e-mail]>
To: "'Eric Norman'" <[e-mail]>, [e-mail]
Subject: RE: Space stamping protocol
Date: Wed, 23 Jan 2002 15:37:46 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Prof. Denning has been there, done that...  ;^)

http://www.cs.georgetown.edu/~denning/infosec/Grounding.txt

> -----Original Message-----
> From: Eric Norman [mailto:[e-mail]]
> Sent: Wednesday, January 23, 2002 1:41 PM
> To: [e-mail]
> Subject: Space stamping protocol
> 
> So, we have a need for time stamping services and
> the associated protocols.
> 
> Can we use GPS satellites and receivers to provide
> a space stamping service?
> 
> It might be useful for the nuclear launch scenario
> or alibis.
> 
> 
> Eric Norman
> 
> 		"I may be just a butterfly,
> 		 but watch out if I flap my wings".
> 
> 
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0NNVbD14355 for ietf-pkix-bks; Wed, 23 Jan 2002 15:31:37 -0800 (PST)
Received: from mtiwmhc26.worldnet.att.net (mtiwmhc26.worldnet.att.net [204.127.131.51]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NNVZ314351 for <[e-mail]>; Wed, 23 Jan 2002 15:31:35 -0800 (PST)
Received: from tsg1 ([12.81.72.49]) by mtiwmhc26.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020123233127.HUZA13869.mtiwmhc26.worldnet.att.net@tsg1>; Wed, 23 Jan 2002 23:31:27 +0000
Message-ID: <003a01c1a466$0a7d2e40$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Eric Norman" <[e-mail]>, <[e-mail]>
Cc: "Michael McNeil" <[e-mail]>
References: <[e-mail]>
Subject: Re: Space stamping protocol
Date: Wed, 23 Jan 2002 15:31:09 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Eric,
The BERT Token was the first attempt at this and didn't fair to well here
with this crowd. BERT put in place a time and space encoding scheme that we
called TimeAndSpace96. It disclosed a full set of time data and location
data representation structures as the core of the BERT event representation
token.

The idea ultimately was that the TSA was to be made interoperable on other
Token Structures and so it would support the use of our proposed 4-D
logging/representation nomenclature. perhaps its time to finally file this
draft for the use of extended (BERT-II) tokens with the TSA... Hmmmm

Todd Glassey

----- Original Message -----
From: "Eric Norman" <[e-mail]>
To: <[e-mail]>
Sent: Wednesday, January 23, 2002 1:41 PM
Subject: Space stamping protocol


>
>
> So, we have a need for time stamping services and the associated
> protocols.
>
> Can we use GPS satellites and receivers to provide a space stamping
> service?
>
> It might be useful for the nuclear launch scenario or alibis.
>
>
> Eric Norman
>
> "I may be just a butterfly,
> but watch out if I flap my wings".
>
>
>



Received: by above.proper.com (8.11.6/8.11.3) id g0NLfOG12044 for ietf-pkix-bks; Wed, 23 Jan 2002 13:41:24 -0800 (PST)
Received: from imap1.doit.wisc.edu (imap1.doit.wisc.edu [144.92.9.75]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0NLfN312040 for <[e-mail]>; Wed, 23 Jan 2002 13:41:23 -0800 (PST)
Received: from [128.104.19.109] (HELO holstein.doit.wisc.edu) by imap1.doit.wisc.edu (CommuniGate Pro SMTP 3.3) with ESMTP id 12985451 for [e-mail]; Wed, 23 Jan 2002 15:41:25 -0600
Date: Wed, 23 Jan 2002 15:41:25 -0600 (CST)
From: Eric Norman <[e-mail]>
To: [e-mail]
Subject: Space stamping protocol
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

So, we have a need for time stamping services and the associated
protocols.

Can we use GPS satellites and receivers to provide a space stamping
service?

It might be useful for the nuclear launch scenario or alibis.


Eric Norman

		"I may be just a butterfly,
		 but watch out if I flap my wings".





Received: by above.proper.com (8.11.6/8.11.3) id g0MCZcX08062 for ietf-pkix-bks; Tue, 22 Jan 2002 04:35:38 -0800 (PST)
Received: from tweety (pool-151-200-26-46.res.east.verizon.net [151.200.26.46]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0MCZZ308052 for <[e-mail]>; Tue, 22 Jan 2002 04:35:35 -0800 (PST)
Received: from [192.168.0.12] by tweety (ArGoSoft Mail Server, Version 1.61 (1.6.1.9)); Tue, 22 Jan 2002 07:23:15 -0500
Message-ID: <[e-mail]>
Date: Tue, 22 Jan 2002 07:23:13 -0500
From: "Sean P. Turner" <[e-mail]>
Organization: IECA, Inc.
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Cautionary Period Straw Poll
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

I believe that DPV protocols developed by the PKIX working group ought not
include support for a cautionary period.

I believe this because of the reasons stated by Ambarish (1/11/2002 at 12:48),
Russ (1/16/2002 at 9:24), Yuriy (in this thread), Rich (in this thread), and Al
(in this thread).

spt




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LLu4518820 for ietf-pkix-bks; Mon, 21 Jan 2002 13:56:04 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LLu3318816 for <[e-mail]>; Mon, 21 Jan 2002 13:56:03 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <DM273LMJ>; Mon, 21 Jan 2002 16:56:01 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B765@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: [e-mail]
Subject: RE: SCVP Version 6
Date: Mon, 21 Jan 2002 16:54:41 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A2C6.3AB5ECB0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1A2C6.3AB5ECB0
Content-Type: text/plain;
	charset="iso-8859-1"

I hate to inundate the authors and the community, but two additional
questions come to my mind while reviewing this ID.
 
1.  Should there be guidance on what the form of proof of revocation status
would be?
 
2.  Should there be a guidance on what thisUpdate and nextUpdate should be?
It seems that these fields are related to revocation and hence:
        a.  It seems that the thisUpdate for a certificate should be
earliest of thisUpdate for the revocation information relevant to the
certification path.
        b.  The nextUpdate is a bit more dicey.  It could be earliest of all
nextUpdate relevant to the certification path.  But, one could argue that it
should be latest of all since that is when we will know about all the
certificates.  In the latter case, if any value is missing, nextUpdate
should not be asserted by the server.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Monday, January 21, 2002 3:05 PM
To: [e-mail]
Subject: SCVP Version 6



While reviewing SCVP, a question comes to my mind.  My interpretation of the
document and ASN.1 is that the following items are associated with the
entire request as opposed to a specific certificate in the request:

*	type of check 

*	want back 

*	policy ID 

*	configuration identifier 


Now, the errors associated with these items are associated with "reply" for
each certificate as opposed to the entire "response".  Is there a reason for
that or should these errors be moved to "response"?

Also, the RFC sections are leveled.  They should be hierarchically
organized. 

Raccoon Eyes
Santosh Chokhani 
CygnaCom Solutions, Inc. 
7927 Jones Branch Drive, Suite 100 West 
McLean, VA 22102 
[e-mail] 
[phone]  [phone] (fax) 
www.cygnacom.com 

Entrust CygnaCom 





------_=_NextPart_001_01C1A2C6.3AB5ECB0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>SCVP Version 6</TITLE>

<META content="MSHTML 5.50.4912.300" name=GENERATOR></HEAD>
<BODY>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN class=082124921-21012002>I hate 
to inundate the authors and the community, but two additional questions come to 
my mind while reviewing this ID.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=082124921-21012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=082124921-21012002>1.&nbsp; Should there be guidance on what the form of 
proof of revocation status would be?</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=082124921-21012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=082124921-21012002>2.&nbsp; Should there be a guidance on what thisUpdate 
and nextUpdate should be?&nbsp; It seems that these fields are related to 
revocation and hence:</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=082124921-21012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a.&nbsp; It 
seems that the thisUpdate for a certificate should be earliest of thisUpdate for 
the revocation information relevant to the certification 
path.</SPAN></FONT></DIV>
<DIV><FONT face=Arial color=#0000ff size=2><SPAN 
class=082124921-21012002>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; b.&nbsp; The 
nextUpdate is a bit more dicey.&nbsp; It could be earliest of 
all&nbsp;nextUpdate relevant to the certification path.&nbsp; But, one could 
argue that it should be latest of all since that is when we will know about all 
the certificates.&nbsp; In the latter case, if any value is missing, nextUpdate 
should not be asserted by the server.</SPAN></FONT></DIV>
<BLOCKQUOTE>
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
  [mailto:[e-mail]]<BR><B>Sent:</B> Monday, January 21, 2002 3:05 
  PM<BR><B>To:</B> [e-mail]<BR><B>Subject:</B> SCVP Version 
  6<BR><BR></FONT></DIV>
  <P><FONT face=Arial size=2>While reviewing SCVP, a question comes to my 
  mind.&nbsp; My interpretation of the document and ASN.1 is that the following 
  items are associated with the entire request as opposed to a specific 
  certificate in the request:</FONT></P>
  <UL>
    <UL>
      <LI><FONT face=Arial size=2>type of check</FONT> 
      <LI><FONT face=Arial size=2>want back</FONT> 
      <LI><FONT face=Arial size=2>policy ID</FONT> 
      <LI><FONT face=Arial size=2>configuration identifier</FONT> 
<BR></LI></UL></UL>
  <P><FONT face=Arial size=2>Now, the errors associated with these items are 
  associated with "reply" for each certificate as opposed to the entire 
  "response".&nbsp; Is there a reason for that or should these errors be moved 
  to "response"?</FONT></P>
  <P><FONT face=Arial size=2>Also, the RFC sections are leveled.&nbsp; They 
  should be hierarchically organized.</FONT> </P>
  <P><B><FONT face=Arial size=2>Raccoon</FONT></B><FONT face=Arial 
  size=2></FONT><B> <FONT face=Arial color=#808000 
  size=2>Eyes</FONT></B><BR><FONT face=Arial size=2>Santosh Chokhani</FONT> 
  <BR><FONT face=Arial size=2>CygnaCom Solutions, Inc.</FONT> <BR><FONT 
  face=Arial size=2>7927 Jones Branch Drive, Suite 100 West</FONT> <BR><FONT 
  face=Arial size=2>McLean, VA 22102</FONT> <BR><FONT face=Arial 
  size=2>[e-mail]</FONT> <BR><FONT face=Arial size=2>(703) 
  270-3520&nbsp; [phone] (fax)</FONT> <BR><FONT face=Arial 
  size=2>www.cygnacom.com</FONT> </P>
  <P><FONT face=Arial size=2>Entrust CygnaCom</FONT> 
<BR></P><BR><BR></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C1A2C6.3AB5ECB0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LK5rE15642 for ietf-pkix-bks; Mon, 21 Jan 2002 12:05:53 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LK5q315638 for <[e-mail]>; Mon, 21 Jan 2002 12:05:53 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <DM273JWF>; Mon, 21 Jan 2002 15:05:50 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B748@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: [e-mail]
Subject: SCVP Version 6
Date: Mon, 21 Jan 2002 15:04:30 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A2B6.D62C4E60"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1A2B6.D62C4E60
Content-Type: text/plain;
	charset="iso-8859-1"

While reviewing SCVP, a question comes to my mind.  My interpretation of the
document and ASN.1 is that the following items are associated with the
entire request as opposed to a specific certificate in the request:

*	type of check
*	want back
*	policy ID
*	configuration identifier

Now, the errors associated with these items are associated with "reply" for
each certificate as opposed to the entire "response".  Is there a reason for
that or should these errors be moved to "response"?

Also, the RFC sections are leveled.  They should be hierarchically
organized.

Raccoon Eyes
Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 West
McLean, VA 22102
[e-mail]
[phone]  [phone] (fax)
www.cygnacom.com

Entrust CygnaCom





------_=_NextPart_001_01C1A2B6.D62C4E60
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>SCVP Version 6</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">While reviewing SCVP, a question comes =
to my mind.&nbsp; My interpretation of the document and ASN.1 is that =
the following items are associated with the entire request as opposed =
to a specific certificate in the request:</FONT></P>
<UL>
<UL><LI><FONT SIZE=3D2 FACE=3D"Arial">type of check</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">want back</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">policy ID</FONT></LI>
<LI><FONT SIZE=3D2 FACE=3D"Arial">configuration identifier</FONT></LI>
<BR>
</UL></UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">Now, the errors associated with these =
items are associated with &quot;reply&quot; for each certificate as =
opposed to the entire &quot;response&quot;.&nbsp; Is there a reason for =
that or should these errors be moved to =
&quot;response&quot;?</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Also, the RFC sections are =
leveled.&nbsp; They should be hierarchically organized.</FONT>
</P>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Raccoon</FONT></B><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT><B> <FONT COLOR=3D"#808000" SIZE=3D2 =
FACE=3D"Arial">Eyes</FONT></B><BR>
<FONT SIZE=3D2 FACE=3D"Arial">Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">CygnaCom Solutions, Inc.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">7927 Jones Branch Drive, Suite 100 =
West</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">McLean, VA 22102</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[e-mail]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[phone]&nbsp; [phone] =
(fax)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">www.cygnacom.com</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Entrust CygnaCom</FONT>
<BR>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C1A2B6.D62C4E60--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LHZqk12092 for ietf-pkix-bks; Mon, 21 Jan 2002 09:35:52 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LHZp312088 for <[e-mail]>; Mon, 21 Jan 2002 09:35:51 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Mon, 21 Jan 2002 09:35:48 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Mon, 21 Jan 2002 09:35:48 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <C2FYX29K>; Mon, 21 Jan 2002 09:35:47 -0800
Content-return: allowed
Date: Mon, 21 Jan 2002 09:35:40 -0800
From: Ambarish Malpani <[e-mail]>
Subject: OCSP extensions
To: "'Florian Oelmaier'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hi Florian,

    Interesting point of view. However, we are at the stage of
progressing OCSP from a Proposed to a Draft Standard.

If the standard as it currently stands is not broken, I would
prefer leaving the meaning of fields as they currently are.

What you are proposing is a legitimate extension, but quite
different in semantics from the nonce as defined in OCSP.

What might make sense, is to come up with a separate draft of
useful OCSP extensions, run that through the standards process
and merge it with the OCSP spec when both reach the same level
of acceptance. A list of "standard" OCSP extensions has been
on my TODO list for some time now - so if you like, we can work
on such a draft together.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Florian Oelmaier [mailto:[e-mail]]
> Sent: Monday, January 21, 2002 4:08 AM
> To: Santosh Chokhani; Yuriy Dzambasow; Ambarish Malpani; 
> 'Deacon, Alex';
> [e-mail]
> Subject: RE: OCSP RFC and OCSP version 2 ID
> 
> 
> Hello Santosh,
> 
> I would like to add some comments to your suggestion b)
> 
> >
> > b.  If the request has a nonce extension, the response must have
> > the nonce extension with the same value as the request.
> >
> 
> Although I appreciate this change as it improves the security of the
> protocol, I have a point that I want you to see clearly 
> before making this
> change.
> 
> As the client most probably knows nothing about the 
> Validation-System behind
> a PKI (except the IP of the OCSP-Responder, he has to contact) it is
> advisable for the client to always include a nonce into his request
> ("well-behaving client"). With "well-behaving clients" and 
> the proposed
> change of the RfC we will face problems with these scenarios:
> 
> Scenario 1: Setup of a Responder that pre-produces answers as 
> specified in
> 2.5 of RfC 2560.
> 
> Scenario 2: Setup of a PKI that uses HTTP-Caching as given 
> for example in
> A.1.1 of RfC 2560.
> 
> Scenario 3: Some PKIs use a Root-Responder architecture with 
> various other
> responders relaying to this root responder and caching his 
> answer for a
> certain period of time. [Although I disregard such an 
> architecture, it is
> used today]
> 
> These problems may lead to clients not using nonce per 
> default. If a client
> does not use a nonce, it is vulnerable to replay-attacks.
> 
> Today an OCSP-Responder can decide if he wants to expose himself to
> replay-attacks by generating answers without nonces. That means if a
> responder generates only ONE response without nonce it is 
> vulnerable. On the
> other hand, if an OCSP-responder includes a nonce in every 
> response ever
> generated in his lifetime, regardless of a nonce in the 
> request, it is NOT
> vulnerable to replay-attacks (at least not to "well-behaving 
> clients").
> 
> Therefore I would suggest the following change to clarify the 
> RfC instead of
> the proposed change:
> 
> "Every client MUST include a nonce into his request. If a 
> nonce is included
> in the response, the client MUST match it to the nonce of the request.
> Although imposing a security problem, a client MAY trust 
> OCSP-responses
> without nonce."
> 
> and
> 
> "To prevent replay-attaks an OCSP-responder SHOULD include a 
> nonce in every
> response."
> 
> Rationale:
> - Responders can choose between security and functionality
> - Clients can detect Responders that chose functionality
> 
> --
> Dipl.Inf. Florian Oelmaier
> syTrust S.A.
> 
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LDnOH29914 for ietf-pkix-bks; Mon, 21 Jan 2002 05:49:24 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LDnN329909 for <[e-mail]>; Mon, 21 Jan 2002 05:49:23 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <DM273DF2>; Mon, 21 Jan 2002 08:49:08 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B705@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: Florian Oelmaier <[e-mail]>, Santosh Chokhani <[e-mail]>, Yuriy Dzambasow <[e-mail]>, Ambarish Malpani <[e-mail]>, "'Deacon, Alex'" <[e-mail]>, [e-mail]
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Mon, 21 Jan 2002 08:47:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A282.37269C50"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C1A282.37269C50
Content-Type: text/plain;
	charset="iso-8859-1"

I think nonce is an extension and  we can not force it.

Please note that thisUpdate and producedAt can also be used to detect the
freshness of the response.  After all, with thisUpdate, the OCSP becomes as
current as CRL and producedAt (depending on the responder implementation) is
always as good or better.

Thus, I think there will not be much support for a mandatory nonce.

-----Original Message-----
From: Florian Oelmaier [mailto:[e-mail]]
Sent: Monday, January 21, 2002 7:08 AM
To: Santosh Chokhani; Yuriy Dzambasow; Ambarish Malpani; 'Deacon, Alex';
[e-mail]
Subject: RE: OCSP RFC and OCSP version 2 ID


Hello Santosh,

I would like to add some comments to your suggestion b)

>
> b.  If the request has a nonce extension, the response must have
> the nonce extension with the same value as the request.
>

Although I appreciate this change as it improves the security of the
protocol, I have a point that I want you to see clearly before making this
change.

As the client most probably knows nothing about the Validation-System behind
a PKI (except the IP of the OCSP-Responder, he has to contact) it is
advisable for the client to always include a nonce into his request
("well-behaving client"). With "well-behaving clients" and the proposed
change of the RfC we will face problems with these scenarios:

Scenario 1: Setup of a Responder that pre-produces answers as specified in
2.5 of RfC 2560.

Scenario 2: Setup of a PKI that uses HTTP-Caching as given for example in
A.1.1 of RfC 2560.

Scenario 3: Some PKIs use a Root-Responder architecture with various other
responders relaying to this root responder and caching his answer for a
certain period of time. [Although I disregard such an architecture, it is
used today]

These problems may lead to clients not using nonce per default. If a client
does not use a nonce, it is vulnerable to replay-attacks.

Today an OCSP-Responder can decide if he wants to expose himself to
replay-attacks by generating answers without nonces. That means if a
responder generates only ONE response without nonce it is vulnerable. On the
other hand, if an OCSP-responder includes a nonce in every response ever
generated in his lifetime, regardless of a nonce in the request, it is NOT
vulnerable to replay-attacks (at least not to "well-behaving clients").

Therefore I would suggest the following change to clarify the RfC instead of
the proposed change:

"Every client MUST include a nonce into his request. If a nonce is included
in the response, the client MUST match it to the nonce of the request.
Although imposing a security problem, a client MAY trust OCSP-responses
without nonce."

and

"To prevent replay-attaks an OCSP-responder SHOULD include a nonce in every
response."

Rationale:
- Responders can choose between security and functionality
- Clients can detect Responders that chose functionality

--
Dipl.Inf. Florian Oelmaier
syTrust S.A.


------_=_NextPart_001_01C1A282.37269C50
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I think nonce is an extension and&nbsp; we can not =
force it.</FONT>
</P>

<P><FONT SIZE=3D2>Please note that thisUpdate and producedAt can also =
be used to detect the freshness of the response.&nbsp; After all, with =
thisUpdate, the OCSP becomes as current as CRL and producedAt =
(depending on the responder implementation) is always as good or =
better.</FONT></P>

<P><FONT SIZE=3D2>Thus, I think there will not be much support for a =
mandatory nonce.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Florian Oelmaier [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</F=
ONT>
<BR><FONT SIZE=3D2>Sent: Monday, January 21, 2002 7:08 AM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani; Yuriy Dzambasow; Ambarish =
Malpani; 'Deacon, Alex';</FONT>
<BR><FONT SIZE=3D2>[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hello Santosh,</FONT>
</P>

<P><FONT SIZE=3D2>I would like to add some comments to your suggestion =
b)</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; b.&nbsp; If the request has a nonce extension, =
the response must have</FONT>
<BR><FONT SIZE=3D2>&gt; the nonce extension with the same value as the =
request.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

<P><FONT SIZE=3D2>Although I appreciate this change as it improves the =
security of the</FONT>
<BR><FONT SIZE=3D2>protocol, I have a point that I want you to see =
clearly before making this</FONT>
<BR><FONT SIZE=3D2>change.</FONT>
</P>

<P><FONT SIZE=3D2>As the client most probably knows nothing about the =
Validation-System behind</FONT>
<BR><FONT SIZE=3D2>a PKI (except the IP of the OCSP-Responder, he has =
to contact) it is</FONT>
<BR><FONT SIZE=3D2>advisable for the client to always include a nonce =
into his request</FONT>
<BR><FONT SIZE=3D2>(&quot;well-behaving client&quot;). With =
&quot;well-behaving clients&quot; and the proposed</FONT>
<BR><FONT SIZE=3D2>change of the RfC we will face problems with these =
scenarios:</FONT>
</P>

<P><FONT SIZE=3D2>Scenario 1: Setup of a Responder that pre-produces =
answers as specified in</FONT>
<BR><FONT SIZE=3D2>2.5 of RfC 2560.</FONT>
</P>

<P><FONT SIZE=3D2>Scenario 2: Setup of a PKI that uses HTTP-Caching as =
given for example in</FONT>
<BR><FONT SIZE=3D2>A.1.1 of RfC 2560.</FONT>
</P>

<P><FONT SIZE=3D2>Scenario 3: Some PKIs use a Root-Responder =
architecture with various other</FONT>
<BR><FONT SIZE=3D2>responders relaying to this root responder and =
caching his answer for a</FONT>
<BR><FONT SIZE=3D2>certain period of time. [Although I disregard such =
an architecture, it is</FONT>
<BR><FONT SIZE=3D2>used today]</FONT>
</P>

<P><FONT SIZE=3D2>These problems may lead to clients not using nonce =
per default. If a client</FONT>
<BR><FONT SIZE=3D2>does not use a nonce, it is vulnerable to =
replay-attacks.</FONT>
</P>

<P><FONT SIZE=3D2>Today an OCSP-Responder can decide if he wants to =
expose himself to</FONT>
<BR><FONT SIZE=3D2>replay-attacks by generating answers without nonces. =
That means if a</FONT>
<BR><FONT SIZE=3D2>responder generates only ONE response without nonce =
it is vulnerable. On the</FONT>
<BR><FONT SIZE=3D2>other hand, if an OCSP-responder includes a nonce in =
every response ever</FONT>
<BR><FONT SIZE=3D2>generated in his lifetime, regardless of a nonce in =
the request, it is NOT</FONT>
<BR><FONT SIZE=3D2>vulnerable to replay-attacks (at least not to =
&quot;well-behaving clients&quot;).</FONT>
</P>

<P><FONT SIZE=3D2>Therefore I would suggest the following change to =
clarify the RfC instead of</FONT>
<BR><FONT SIZE=3D2>the proposed change:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;Every client MUST include a nonce into his =
request. If a nonce is included</FONT>
<BR><FONT SIZE=3D2>in the response, the client MUST match it to the =
nonce of the request.</FONT>
<BR><FONT SIZE=3D2>Although imposing a security problem, a client MAY =
trust OCSP-responses</FONT>
<BR><FONT SIZE=3D2>without nonce.&quot;</FONT>
</P>

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

<P><FONT SIZE=3D2>&quot;To prevent replay-attaks an OCSP-responder =
SHOULD include a nonce in every</FONT>
<BR><FONT SIZE=3D2>response.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Rationale:</FONT>
<BR><FONT SIZE=3D2>- Responders can choose between security and =
functionality</FONT>
<BR><FONT SIZE=3D2>- Clients can detect Responders that chose =
functionality</FONT>
</P>

<P><FONT SIZE=3D2>--</FONT>
<BR><FONT SIZE=3D2>Dipl.Inf. Florian Oelmaier</FONT>
<BR><FONT SIZE=3D2>syTrust S.A.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1A282.37269C50--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LC9jg24294 for ietf-pkix-bks; Mon, 21 Jan 2002 04:09:45 -0800 (PST)
Received: from druss.secaron.de (druss.secaron.de [195.145.99.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LC9h324289 for <[e-mail]>; Mon, 21 Jan 2002 04:09:43 -0800 (PST)
Received: by druss.secaron.de (Postfix, from userid 0) id E401551F1E; Mon, 21 Jan 2002 13:09:37 +0100 (MET)
Received: from marvin.munich.secaron.de (localhost [127.0.0.1]) by druss.secaron.de (Postfix) with ESMTP id 7A2B23256F; Mon, 21 Jan 2002 13:09:37 +0100 (MET)
Received: from MUCDEV101 ([192.168.2.101]) by marvin.munich.secaron.de (Lotus Domino Release 5.0.9) with SMTP id 2002012113093713:16346 ; Mon, 21 Jan 2002 13:09:37 +0100 
From: "Florian Oelmaier" <[e-mail]>
To: "Santosh Chokhani" <[e-mail]>, "Yuriy Dzambasow" <[e-mail]>, "Ambarish Malpani" <[e-mail]>, "'Deacon, Alex'" <[e-mail]>, <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Mon, 21 Jan 2002 13:07:57 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <8D7EC1912E25D411A32100D0B7695397E1B691@SCYGMXS01>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
X-MIMETrack: Itemize by SMTP Server on Marvin/Secaron(Release 5.0.9 |November 16, 2001) at 01/21/2002 01:09:37 PM, Serialize by Router on Marvin/Secaron(Release 5.0.9 |November 16, 2001) at 01/21/2002 01:09:37 PM, Serialize complete at 01/21/2002 01:09:37 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Hello Santosh,

I would like to add some comments to your suggestion b)

>
> b.  If the request has a nonce extension, the response must have
> the nonce extension with the same value as the request.
>

Although I appreciate this change as it improves the security of the
protocol, I have a point that I want you to see clearly before making this
change.

As the client most probably knows nothing about the Validation-System behind
a PKI (except the IP of the OCSP-Responder, he has to contact) it is
advisable for the client to always include a nonce into his request
("well-behaving client"). With "well-behaving clients" and the proposed
change of the RfC we will face problems with these scenarios:

Scenario 1: Setup of a Responder that pre-produces answers as specified in
2.5 of RfC 2560.

Scenario 2: Setup of a PKI that uses HTTP-Caching as given for example in
A.1.1 of RfC 2560.

Scenario 3: Some PKIs use a Root-Responder architecture with various other
responders relaying to this root responder and caching his answer for a
certain period of time. [Although I disregard such an architecture, it is
used today]

These problems may lead to clients not using nonce per default. If a client
does not use a nonce, it is vulnerable to replay-attacks.

Today an OCSP-Responder can decide if he wants to expose himself to
replay-attacks by generating answers without nonces. That means if a
responder generates only ONE response without nonce it is vulnerable. On the
other hand, if an OCSP-responder includes a nonce in every response ever
generated in his lifetime, regardless of a nonce in the request, it is NOT
vulnerable to replay-attacks (at least not to "well-behaving clients").

Therefore I would suggest the following change to clarify the RfC instead of
the proposed change:

"Every client MUST include a nonce into his request. If a nonce is included
in the response, the client MUST match it to the nonce of the request.
Although imposing a security problem, a client MAY trust OCSP-responses
without nonce."

and

"To prevent replay-attaks an OCSP-responder SHOULD include a nonce in every
response."

Rationale:
- Responders can choose between security and functionality
- Clients can detect Responders that chose functionality

--
Dipl.Inf. Florian Oelmaier
syTrust S.A.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0LBlYu23301 for ietf-pkix-bks; Mon, 21 Jan 2002 03:47:34 -0800 (PST)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LBlU323297 for <[e-mail]>; Mon, 21 Jan 2002 03:47:31 -0800 (PST)
Received: from tho.andxor.com (tho.andxor.it [195.223.2.222]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id MAA14815; Mon, 21 Jan 2002 12:47:29 +0100 (CET) (envelope-from [e-mail])
Received: (from tho@localhost) by tho.andxor.com (8.11.6/8.11.6) id g0LCotV31847; Mon, 21 Jan 2002 12:50:55 GMT (envelope-from tho)
Date: Mon, 21 Jan 2002 12:50:55 +0000
From: tho <[e-mail]>
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: TSP interop update
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Sat, Jan 19, 2002 at 01:56:44PM +1300
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> Peter Gutmann wrote:
>
> The RFC never explains what to do with any extension you find, therefore the
> semantics of all extensions are unknown (in the context of the RFC),
> therefore any request with extensions has to be rejected.

yes, in the context of the RFC, which wants to be the framework, not the
complete specification of all future extensions of the protocol.


At the state of art from a client perspective we have that if I add an 
extension to my TimeStampReq which is not supported by the this TSA and I 
receive back an `unacceptedExtension' rejection, I have two choices (both not 
so unpractical):

a) if the extension is not essential to me, strip off the extension and try 
   again with this TSA

b) if I consider that extension vital for me, try with another TSA 

unfortunately the client has to pay an extra round trip in case (a) which could
be saved by restoring the standard meaning of the critical flag. 

This is the only real disadvantage that I can see.

ciao, tho
--


Received: by above.proper.com (8.11.6/8.11.3) id g0LAB2d11717 for ietf-pkix-bks; Mon, 21 Jan 2002 02:11:02 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0LAB0311713 for <[e-mail]>; Mon, 21 Jan 2002 02:11:00 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03828; Mon, 21 Jan 2002 05:10:46 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-12.txt
Date: Mon, 21 Jan 2002 05:10:45 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure Certificate 
                          and CRL Profile
	Author(s)	: R. Housley, W. Ford, W. Polk, D. Solo
	Filename	: draft-ietf-pkix-new-part1-12.txt
	Pages		: 129
	Date		: 18-Jan-02
	
This memo profiles the X.509 v3 certificate and X.509 v2 CRL for use
in the Internet.  An overview of the approach and model are provided
as an introduction.  The X.509 v3 certificate format is described in
detail, with additional information regarding the format and
semantics of Internet name forms.  Standard certificate extensions
are described and two Internet-specific extensions are defined.  A
set of required certificate extensions is specified.  The X.509 v2
CRL format is described in detail, and required extensions are
defined.  An algorithm for X.509 certificate path validation is
described.  An ASN.1 module and examples are provided in the
appendices.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-new-part1-12.txt

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

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

--OtherAccess--

--NextPart--




Received: by above.proper.com (8.11.6/8.11.3) id g0KLiCY01571 for ietf-pkix-bks; Sun, 20 Jan 2002 13:44:12 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0KLiA301566 for <[e-mail]>; Sun, 20 Jan 2002 13:44:10 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g0KLiBg25774 for <[e-mail]>; Sun, 20 Jan 2002 13:44:11 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: Cautionary Period Straw Poll
Date: Sun, 20 Jan 2002 13:41:58 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The DPD/DPV protocols being developed by the PKIX working group
ought NOT include support for a cautionary period.

Mike



Received: by above.proper.com (8.11.6/8.11.3) id g0KHnfe27215 for ietf-pkix-bks; Sun, 20 Jan 2002 09:49:41 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0KHnc327211 for <[e-mail]>; Sun, 20 Jan 2002 09:49:39 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA05302; Sun, 20 Jan 2002 18:49:31 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Sun, 20 Jan 2002 18:49:32 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA14224; Sun, 20 Jan 2002 18:49:30 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA05784; Sun, 20 Jan 2002 18:49:30 +0100 (MET)
Date: Sun, 20 Jan 2002 18:49:30 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Cautionary Period -- STRAW POLL
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Since I assume that there is some confusion about what
cautionary period means, my vote is 'BLANK' suggesting
that the following interpretation of 'cautionary period' 
be treated somehow: 

Reflecting the timeliness of the information based on
information obtained via CRLs or OCSP or others to the 
client in order to avoid client to dig them around 
themselves. 

The requirement for expression a cautionary period MUST
not lead to a particular configuration parameter of
a DPV server.  



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0JGUb300111 for ietf-pkix-bks; Sat, 19 Jan 2002 08:30:37 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0JGUa300107 for <[e-mail]>; Sat, 19 Jan 2002 08:30:36 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id DCF539406; Sat, 19 Jan 2002 17:30:37 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZKPQVKY2; Sat, 19 Jan 2002 17:30:37 +0100
Message-ID: <[e-mail]>
Date: Sat, 19 Jan 2002 17:32:23 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: draft-ietf-pkix-dpv-dpd-00.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Denis,
<p>I carefully read draft-ietf-pkix-dpv-dpd-00.txt because we are
<br>probably going to use it in order to build such a PKI server.
<br>I noticed some typos in the draft and would like to suggest some
<br>changes.
<p>Best regards - Petra
<p>chapter 5.2. Detailed Protocol
<blockquote TYPE=CITE>
<pre>&nbsp; The terms imported from elsewhere are: Extensions,
&nbsp;&nbsp; CertificateSerialNumber, SubjectPublicKeyInfo, Name,
&nbsp;&nbsp; AlgorithmIdentifier, CRLReason, CompleteCertificateRefs,&nbsp;
&nbsp;&nbsp; CompleteRevocationRefs.</pre>
</blockquote>
Three more terms need to be imported:
<br>&nbsp;&nbsp;&nbsp;&nbsp; OtherCertID, CertificateValues, RevocationValues
<br>&nbsp;
<p>chapter 5.2.1. Request
<blockquote TYPE=CITE>
<pre>&nbsp; ValPolicyID :: = CHOICE {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; policybyOId&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OBJECT IDENTIFIER,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; policybyURN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; NAME }</pre>
</blockquote>
What is the ASN.1 term "NAME"?&nbsp; I only know Name, which is
<br>a Distinguished Name. Anyhow, I'd suggest to use a GeneralName
<br>instead of NAME:
<br>&nbsp;&nbsp;&nbsp; policybyURN&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
GeneralName
<br>&nbsp;
<blockquote TYPE=CITE>
<pre>The value for valPolicyHash SHALL be computed on the&nbsp;&nbsp;
hash of the DER encoding of ValidationPolicyDef when ...</pre>
</blockquote>
I guess you meant:
<br>... DER encoding of ValPolicyDef, don't you?
<br>&nbsp;
<blockquote TYPE=CITE>
<pre>ValPolLocations :: = SEQUENCE OF Name</pre>
</blockquote>
Again, I'd suggest to use a GeneralName:
<br>ValPolLocations :: = SEQUENCE OF GeneralName
<br>&nbsp;
<blockquote TYPE=CITE>
<pre>PathValues :: = SEQUENCE {
&nbsp;&nbsp;&nbsp;&nbsp; certificateValues&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CertificateValues,
&nbsp;&nbsp;&nbsp;&nbsp; revocationValues&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RevocationValues }</pre>
</blockquote>
Move the definition to chapter 5.2.2.&nbsp; Response Syntax
<br>where it is used.
<br>&nbsp;
<blockquote TYPE=CITE>
<pre>validationPolicyRef is a reference to the validation&nbsp;
policy to be used.</pre>
</blockquote>
I guess, it should be:
<br>valPolicyRef is a reference to ...
<p>Later on in the same paragraph:
<blockquote TYPE=CITE>
<pre>... It is composed of an OID or a URN, the hash&nbsp;
algorithm to be used to compute the hash value of&nbsp;
the policy and the hash value of the policy.</pre>
</blockquote>
add at the end of the sentence:
<br>and optionally the locations where the policy may be retrieved from.
<br>&nbsp;
<p>chapter 5.2.2.&nbsp; Response Syntax
<blockquote TYPE=CITE>
<pre>The value for returnedRefsHash SHALL be computed&nbsp;
on the hash of the DER encoding of CertPathRefs.</pre>
</blockquote>
Just a typo. I think it should be:
<br>The value for pathReferencesHash SHALL ...
<p>To make it easier to understand you could add at the end of the sentence:
<br>... CertPathRefs which are part of the DPVResponse.
<p>The same for the next sentence:
<blockquote TYPE=CITE>
<pre>The value for returnedValuesHash SHALL be computed&nbsp;
on the hash of the DER encoding of CertPathValues</pre>
</blockquote>
The value for pathValuesHash SHALL ...
<br>Again you could add at the end of the sentence:
<br>... CertPathValues which are part of the DPVResponse.
<br>&nbsp;
<blockquote TYPE=CITE>
<pre>pathReferencesHash is a hash computed over the references of the path&nbsp;
(both the references of the certificates used and the references of&nbsp;
the revocation information used). It may also include a sequence of&nbsp;
time-stamps, if this has been requested in the request. Since only&nbsp;
the hash is included in the signature, this allows to keep signatures&nbsp;
short and does not mandate to know the values of the references of the&nbsp;
path to verify the dPVResponseStatus from the response.</pre>
</blockquote>
... this allows to keep the whole response short and ...
<p>The same for the next paragrah!
<br>&nbsp;
<blockquote TYPE=CITE>
<pre>requestExtensions is a way to allow additional elements to be&nbsp;
added later on, if needed.</pre>
</blockquote>
responseExtensions is a way...
<br>&nbsp;
<p>chapter 6.2. Detailed Protocol
<p>One more terms needs to be imported:
<br>&nbsp;&nbsp;&nbsp;&nbsp; OtherCertID
<br>&nbsp;
<p>chapter 8.2. Response
<blockquote TYPE=CITE>
<pre>TbsDefResponse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::= SEQUENCE {
&nbsp;&nbsp;&nbsp; tbsResponseData&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; VPDefResponseData,
&nbsp;&nbsp;&nbsp; signatureAlgorithm&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; AlgorithmIdentifier&nbsp;&nbsp; OPTIONAL,
&nbsp;&nbsp;&nbsp; signature&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; BIT STRING&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPTIONAL,
&nbsp;&nbsp;&nbsp; certs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [0]&nbsp;&nbsp;&nbsp;&nbsp; EXPLICIT SEQUENCE OF Certificate
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; OPTIONAL }</pre>
</blockquote>

<p><br>It should be:
<br>&nbsp;&nbsp; TbsVPDefResponse&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ::=
SEQUENCE {
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;</html>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0J0val08814 for ietf-pkix-bks; Fri, 18 Jan 2002 16:57:36 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0J0vX308810 for <[e-mail]>; Fri, 18 Jan 2002 16:57:34 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id NAA15363; Sat, 19 Jan 2002 13:56:44 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id NAA503383; Sat, 19 Jan 2002 13:56:44 +1300 (NZDT) (sender [e-mail])
Date: Sat, 19 Jan 2002 13:56:44 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

tho <[e-mail]> writes:

>so I think that if the TSA doesn't understand the _semantics_ (not the syntax)
>of the extension it "SHALL not issue a token and SHALL return a failure
>(unacceptedExtension)."

That just confirms my previous point: The RFC never explains what to do with
any extension you find, therefore the semantics of all extensions are unknown
(in the context of the RFC), therefore any request with extensions has to be
rejected.  You could get away with this if the critical flag had been left with
its standard meaning (so you could submit noncritical extensions and things
would work properly), but by both overriding it and not defining the semantics
for any extensions the RFC creates a situation where all extensions have to be
rejected.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0J0nlA08580 for ietf-pkix-bks; Fri, 18 Jan 2002 16:49:47 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0J0nj308575 for <[e-mail]>; Fri, 18 Jan 2002 16:49:45 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id NAA15262; Sat, 19 Jan 2002 13:49:37 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id NAA502837; Sat, 19 Jan 2002 13:49:37 +1300 (NZDT) (sender [e-mail])
Date: Sat, 19 Jan 2002 13:49:37 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Jean-Marc Desperrier <[e-mail]> writes:
>Peter Gutmann wrote:
>>The RFC doesn't
>>specify any particular extensions which you have to (MUST/SHALL/SHOULD) handle
>>and says the critical bit is ignored (in violation of RFC 2459), so it looks
>>like accepting/ignoring anything that you "recognise" is fine.
>
>The text in the RFC sounds a lot more like any extension should be handled as
>if it had the critical flag, and the request rejected if you don't know
>exactly the meaning of the extension.

But "know exactly the meaning of the extension" is never defined.  If I get a
request with a subjectAltName (which my TSA did during interop tests) then
although I know perfectly well what a subjectAltName is I have no idea what I'm
supposed to do with it when I see it in the request.  Do I reject it or accept
it?  Since the RFC never defines any extensions which must be handled, all
extensions can be regarded as being unrecognised in the context of the RFC.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IItfh01440 for ietf-pkix-bks; Fri, 18 Jan 2002 10:55:41 -0800 (PST)
Received: from mail.dit.upm.es (IDENT:[e-mail] [138.4.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IItc301436 for <[e-mail]>; Fri, 18 Jan 2002 10:55:38 -0800 (PST)
Received: from jungla.dit.upm.es (IDENT:[e-mail] [138.4.5.11]) by mail.dit.upm.es (8.11.6/8.9.3) with ESMTP id g0IItSb24330; Fri, 18 Jan 2002 19:55:28 +0100
Received: from dit.upm.es (toro-2.dit.upm.es [138.4.21.2]) by jungla.dit.upm.es (8.11.6/8.9.3) with ESMTP id g0IIt8o16630; Fri, 18 Jan 2002 19:55:09 +0100
Message-ID: <[e-mail]>
Date: Fri, 18 Jan 2002 19:55:09 +0100
From: "=?iso-8859-1?Q?Jos=E9?= A. =?iso-8859-1?Q?Ma=F1as?=" <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Win95; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: TSP interop update
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I am not sure about the aim of 3161,
but I know a bit more of the history.

The agreement between ietf and ISO regarding
time-stamping protocols was to use ietf's as default,
and use extensions to requiere different mechanisms
(e.g. linked tokens), additional parameters, ...

The aim is to allow for co-existence of time-stampers.
If a TSA understands N protocols, and there is a new N+1 protocol,
that uses new extensions or new values in extensions,
there are two cases:
1/ the old TSA may ignore non-critical
extensions addressed to the new protocol, and do its best,
and
2/ the old TSA should stop processing upon critical extensions 
that it does not understand.

So, the requester may specify whether it is critical or not
(for its business case) that the TSA understands the extension and
behaves accordingly.

pp


Peter Sylvester wrote:
> 
> >
> > Peter Gutmann wrote:
> > > Actually this raises an interesting point, the TSP RFC says that extensions
> > > are handled just like RFC 2459 except when they're not.  In particular it
> 
> I really like the ways you say this :-)
> 
> It was in version 3 of the draft that extensions were added, and in version 4
> the following text was added:
> 
> Version 3:
>    "The extensions field is a generic way to add additional information to
>    the request in the future. EXTENSIONS is defined in [RFC 2459]."
> 
> Version 4:
>    "The extensions field is a generic way to add additional information to
>    the request in the future. EXTENSIONS is defined in [RFC 2459]. If an
>    extension, whether it is marked critical or not critical, is used
>    by a requester but is not recognized by a time stamping server, the
>    server SHALL not issue a token and return a failure (badRequest)."
> 
> RFC 3161:
>    "The extensions field is a generic way to add additional information
>    to the request in the future.  Extensions is defined in [RFC 2459].
>    If an extension, whether it is marked critical or not critical, is
>    used by a requester but is not recognized by a time-stamping server,
>    the server SHALL not issue a token and SHALL return a failure
>    (unacceptedExtension)."
> 
> Well, now, what happened between September and October 1999 (V3 -> V4)
> 
> There were some messages, at least one concerning a RESPONSE, what does a
> time stamp with an extension mean that has no critical bit.
> 
> One can also interprete the actual text for the response also that all TSAs
> MUST by definition able to interprete all possible extensions, and the
> default implementation is to create such an error. :-)
> 
> Unless I have overlooked something, I do not see an explanation
> or announce for this change. Maybe the editors can comment ??
> 
> I tend to think that the change this additional requirement, i.e.,
> the  change from 3 -> 4 is not necessary.
> 
> Peter Sylvester


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IIeW801177 for ietf-pkix-bks; Fri, 18 Jan 2002 10:40:32 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IIeV301173 for <[e-mail]>; Fri, 18 Jan 2002 10:40:31 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <DGD1F4X8>; Fri, 18 Jan 2002 13:40:28 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B6A0@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: Denis Pinkas <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: Ambarish Malpani <[e-mail]>, [e-mail]
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Fri, 18 Jan 2002 13:39:12 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A04F.6CA0E9B0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C1A04F.6CA0E9B0
Content-Type: text/plain

Denis Please comments in-line.

-----Original Message-----
From: Denis Pinkas [mailto:[e-mail]]
Sent: Friday, January 18, 2002 12:45 PM
To: Santosh Chokhani
Cc: Ambarish Malpani; [e-mail]
Subject: Re: OCSP RFC and OCSP version 2 ID



Santosh,

Before leaving my office for nearly a week ...

> All:
> 
> Last might Ambarish and I had a discussion on the OCSP RFC.  We agreed
> that the following modifications need to be made.  Unless Ambarish has
> some new concerns based on further reflection, here are the proposed
> changes.  Please note that the changes to Section 3.2 have not been
> discussed with the list, but I have had them on mind ever since I started
> analyzing the RFC this week.  I am sure Ambarish will polish this
> language.
> 
> 1.  The absence of nextUpdate means that the client should not cache the
> response.  

I find it somewhat surprising to see that now we speak of "caching the
response" which is local mater (a client may have no cache at all, so in
that case what is the interpretation ?) and has nothing to do with the
original topic which was how a client shall interpret the response when
nextUpdate is missing.

[What I am saying is that the OCSP responder does not make advertise the
nextUpdate, either because it does not know or because the field is
meaningless since the response is real-time.  What the client does is, its
problem.  The cache item may not go in the RFC.  It was provided as
background]

> The server may do this either because real-time response is
> available all the time or the server itself does not have advise (e.g.,
> absence of nextUpdate in CRL) from the CA as to when the newer revocation
> information will be available.

We do not care why a server "may" do this, we care to understand what that
means for the client.

[What it means to client is that it does not have nextUpdate.  Thus, if the
client needs real-time or reasonably current information, it needs to
contact the responder each time and use thisUpdate to determine the
freshness of the response]
 
> 2.  The following additional rules should be added in Section 3.2 for the
> OCSP client to validate the response.
> 
>         a.  productedAt should be reasonably close to current time.

What does this mean ? a few seconds ? or a few minutes ? or a few hours ? 
This is uncheckable by a client. Why should we add now this requirement ?

We are now too far from the original proposal made by Ambarish. 
Let is come back to it:

[If you look at Section 3.2, we need these rules in order to deal with
replay detection.  Please note that producedAt is always > = thisUpdate.
The language for producedAt should be similar to that for thisUpdate.]

"If nextUpdate is not set, the responder is indicating that it
doesn't know when newer information will be available and so, if
a client wants status information on the certificate in question
at a future date, it should come back and ask the server again."

I would also add :

"Note: the Certificate Practice Statement and the Certificate Disclosure
Statement may provide more information about when newer status information
information will be available." 

[I do not see a particular benefit to citing a policy document in a
protocol]

Regards,

Denis


Note: Do not conclude that silence from me, means an agreement, since, 
as indicated at the top of this e-mail, I will not be in my office most of
next week.


>         b.  If the request has a nonce extension, the response must have
> the nonce extension with the same value as the request.
> 
> -----Original Message-----
> From: Yuriy Dzambasow [mailto:[e-mail]]
> Sent: Friday, January 18, 2002 9:22 AM
> To: Ambarish Malpani; 'Deacon, Alex'; 'Santosh Chokhani';
> [e-mail]
> Subject: Re: OCSP RFC and OCSP version 2 ID
> 
> Hi Ambarish,
> 
> Thank you for clarifying this.  I agree with your three potential
> questions
> and your three responses.  Regarding item 3, I believe this should be
> addressed through policy and practices, and not controlled through OCSP.
> 
> Yuriy
> 
> ----- Original Message -----
> From: "Ambarish Malpani" <[e-mail]>
> To: "'Deacon, Alex'" <[e-mail]>; "'Santosh Chokhani'"
> <[e-mail]>; <[e-mail]>
> Sent: Thursday, January 17, 2002 3:13 PM
> Subject: RE: OCSP RFC and OCSP version 2 ID
> 
> >
> >
> > Here is how I see it:
> >
> > There are 3 potential questions:
> > 1. How current is your information (on which you based this response)
> > 2. How long can/should I keep/cache/rely on this information.
> > 3. How current will your information be if I ask you in the future.
> >
> > 1. is answered by thisUpdate
> > 2. is answered by nextUpdate (where a client can still decide to
> > ignore the nextUpdate field the next time it wants to know
> > the status of this certificate)
> > 3. is not dealt with by the RFC. I am not sure we need to deal with
> > it. The only case that I can think of it being used, is where
> > a client can go to multiple responders and is trying to figure
> > out which one it should normally use (like they do with DNS).
> > I don't think people are close to dealing with that level of
> > complexity with OCSP.
> >
> > Hope this helps clarify the questions.
> >
> > A
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                650.567.5457
> > ValiCert, Inc.                                  [e-mail]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Deacon, Alex [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 11:37 AM
> > To: 'Santosh Chokhani'; Ambarish Malpani; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> > OK...you guys have lost me now.  What was wrong with not including the
> > nextUpdate field to specify that the server is providing real time info
> and
> > that the client should ask the server each time it needs the current
> status?
> > If a responder is providing real time status info, it can (or will)
> never
> > know when newer status info will be available as it is impossible to
> know
> > when a certificate will be revoked/suspended in advance.
> >
> > Alex
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 11:23 AM
> > To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> > I guess today is my day (every day is my day) to make errors, deeper
> > reflections and second guessing.
> >
> > I guess what I am saying is as follows.  Do the relying parties need to
> know
> > that the responder provides real-time revocation information?  Having
> > thisUpdate=NOW may not prove that since this could be simply
> coincidence.
> A
> > pattern of responses may create statistical certainty.
> >
> > So, after all this, this question remains.  Please do not construe my
> emails
> > to mean that I am saying the feature is required.  I am simply posing
> the
> > question and proposing an approach if the feature is required.
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 2:08 PM
> > To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> > Upon further reflection, I think thisUpdate DOES take care of it.
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 2:01 PM
> > To: Ambarish Malpani; Santosh Chokhani; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> > Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
> > response is available all the time.
> >
> > I am trying to account for situations when the response is real-time (or
> 
> > near real-time).
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 1:56 PM
> > To: 'Santosh Chokhani'; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> >
> > Santosh, why doesn't thisUpdate meet that need?
> >
> > A
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                650.567.5457
> > ValiCert, Inc.                                  [e-mail]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 10:31 AM
> > To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> > I agree with what Ambarish and Carlisle are saying.
> > I have one addition question though.  Should the standard provide a
> > capability to the relying parties (OCSP clients) that the current
> revocation
> > information is always available. If people agree that it should, given
> the
> > proposed meaning of nextUpdate, the additional capability can be handled
> 
> via
> > a SingleResponse extension.
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 11:53 AM
> > To: 'Denis Pinkas'; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> >
> >
> > Hi Denis,
> >     Information about how up to date the information is, is
> > already present in the thisUpdate field in the response.
> > So, for example, if you *know* that you have information that is
> > current as of 5 seconds ago, you can set that field appropriately.
> > Does this meet your needs?
> > Regards,
> > Ambarish
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                650.567.5457
> > ValiCert, Inc.                                  [e-mail]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> >
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[e-mail]]
> > > Sent: Thursday, January 17, 2002 8:50 AM
> > > To: Ambarish Malpani
> > > Cc: 'Santosh Chokhani'; '[e-mail] '
> > > Subject: Re: OCSP RFC and OCSP version 2 ID
> > >
> > >
> > > Ambarish,
> > >
> > > > Hi Santosh,
> > > >     Give me some time.... :-)
> > > >
> > > > I agree with your first analysis:
> > > >
> > > > "If nextUpdate is not set, the responder is indicating that newer
> > > > revocation information is available all the time"
> > > >
> > > > Actually, they way I would prefer to state it would be something
> > > > like:
> > >
> > > > "If nextUpdate is not set, the responder is indicating that it
> > > > doesn't know when newer information will be available and so, if
> > > > a client wants status information on the certificate in question
> > > > at a future date, it should come back and ask the server again."
> > >
> > > I like your proposal, since this means that when using the
> > > on-line protocol
> > > it is not possible to know. Now we could add a sentence that says:
> > >
> > > "However, the Certificate Practice Statement and the
> > > Certificate Disclosure
> > > Statement may provide more information about the refreshment
> > > conditions of
> > > the status information."
> > >
> > > Denis
> > >
> > > > This is my personal opinion. If the group agrees, I am happy to
> > > > modify the document to reflect this point of view.
> > > >
> > > > Regards,
> > > > Ambarish
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > Ambarish Malpani
> > > > Architect
> > > 650.567.5457
> > > > ValiCert, Inc.
> > > [e-mail]
> > > > 339 N. Bernardo Ave.
> > http://www.valicert.com
> > > Mountain View, CA 94043
> > >
> > > -----Original Message-----
> > > From: Santosh Chokhani [mailto:[e-mail]]
> > > Sent: Wednesday, January 16, 2002 11:50 AM
> > > To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> > > Cc: '[e-mail] '
> > > Subject: RE: OCSP RFC and OCSP version 2 ID
> > >
> > > Why aren't the authors responding to this contradiction in the RFC and
> 
> > > carried out in the ID?
> > > -----Original Message-----
> > > From: Peter Williams [mailto:[e-mail]]
> > > Sent: Wednesday, January 16, 2002 2:41 PM
> > > To: 'Denis Pinkas '; 'Santosh Chokhani '
> > > Cc: '[e-mail] '
> > > Subject: RE: OCSP RFC and OCSP version 2 ID
> > >
> > > Denis,
> > > You refer to an assumed  "main mechanism" in your note. Speaking
> > factually,
> > > to hopefully guide you, sensibly:-
> > > The main [reference] mechanism(s) at, and shortly after,
> > > the time of writing OCSP IDs included:-
> > > (1) VeriSign, who used an oracle database-based repository to feed
> data
> > > to OCSP deamons acting in cached and interactive, direct-trust
> > > mode; CRLs were not involved. OCSP proxing/multiplexing interactive
> > > direct-trust mode was  added, shortly after standarization, for a
> > > defense customer bridging multiple certification domains.
> > > (2) ValiCert, who used direct CRLs to feed data to direct/indirect
> OCSP
> > > deamons. Indirect CRLs and CRLDPs support was added slightly after
> > > the architects had harmonized their work.
> > > Both mechanisms evolved further, outside of IETF and
> > > in vendor forums, particularly in the area of: application
> > > integration, CRLDPs and delta-CRL data sources, proxying
> > > transaction semantics and response resigning, data freshness
> > > signalling, and OCSP client interaction with X.509 and
> > > PKIX-style path processing and X.509 applications such as
> > > SSLv3/https and MTA-based automatic xmldsig signature
> > > verification on B2B and banking protocol XML streams.
> > > Historically, this work essentially re-designed the standardized
> > > features of the "distributed authentication model" of
> > > X.500 1988, for OCSP-borne queries.
> > > Currently, VeriSign's current work in W3C also
> > > reflects alot of the understanding on the required
> > > semantics of realtime trust models.
> > > Peter.
> > > -----Original Message-----
> > > From: Denis Pinkas
> > > To: Santosh Chokhani
> > > Cc: [e-mail]
> > > Sent: 1/16/02 12:04 AM
> > > Subject: Re: OCSP RFC and OCSP version 2 ID
> > > At the time the document was written, the main mechanism to feed the
> > > information to the OCSP server was to use CRLs. So it seems sensible
> to
> > > think that these fields are copied from a CRL.
> > >
> >

------_=_NextPart_001_01C1A04F.6CA0E9B0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Denis Please comments in-line.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Friday, January 18, 2002 12:45 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: Ambarish Malpani; [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Santosh,</FONT>
</P>

<P><FONT SIZE=3D2>Before leaving my office for nearly a week ...</FONT>
</P>

<P><FONT SIZE=3D2>&gt; All:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Last might Ambarish and I had a discussion on =
the OCSP RFC.&nbsp; We agreed</FONT>
<BR><FONT SIZE=3D2>&gt; that the following modifications need to be =
made.&nbsp; Unless Ambarish has</FONT>
<BR><FONT SIZE=3D2>&gt; some new concerns based on further reflection, =
here are the proposed</FONT>
<BR><FONT SIZE=3D2>&gt; changes.&nbsp; Please note that the changes to =
Section 3.2 have not been</FONT>
<BR><FONT SIZE=3D2>&gt; discussed with the list, but I have had them on =
mind ever since I started</FONT>
<BR><FONT SIZE=3D2>&gt; analyzing the RFC this week.&nbsp; I am sure =
Ambarish will polish this</FONT>
<BR><FONT SIZE=3D2>&gt; language.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; 1.&nbsp; The absence of nextUpdate means that =
the client should not cache the</FONT>
<BR><FONT SIZE=3D2>&gt; response.&nbsp; </FONT>
</P>

<P><FONT SIZE=3D2>I find it somewhat surprising to see that now we =
speak of &quot;caching the</FONT>
<BR><FONT SIZE=3D2>response&quot; which is local mater (a client may =
have no cache at all, so in</FONT>
<BR><FONT SIZE=3D2>that case what is the interpretation ?) and has =
nothing to do with the</FONT>
<BR><FONT SIZE=3D2>original topic which was how a client shall =
interpret the response when</FONT>
<BR><FONT SIZE=3D2>nextUpdate is missing.</FONT>
</P>

<P><FONT SIZE=3D2>[What I am saying is that the OCSP responder does not =
make advertise the nextUpdate, either because it does not know or =
because the field is meaningless since the response is real-time.&nbsp; =
What the client does is, its problem.&nbsp; The cache item may not go =
in the RFC.&nbsp; It was provided as&nbsp; background]</FONT></P>

<P><FONT SIZE=3D2>&gt; The server may do this either because real-time =
response is</FONT>
<BR><FONT SIZE=3D2>&gt; available all the time or the server itself =
does not have advise (e.g.,</FONT>
<BR><FONT SIZE=3D2>&gt; absence of nextUpdate in CRL) from the CA as to =
when the newer revocation</FONT>
<BR><FONT SIZE=3D2>&gt; information will be available.</FONT>
</P>

<P><FONT SIZE=3D2>We do not care why a server &quot;may&quot; do this, =
we care to understand what that</FONT>
<BR><FONT SIZE=3D2>means for the client.</FONT>
</P>

<P><FONT SIZE=3D2>[What it means to client is that it does not have =
nextUpdate.&nbsp; Thus, if the client needs real-time or reasonably =
current information, it needs to contact the responder each time and =
use thisUpdate to determine the freshness of the response]</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; 2.&nbsp; The following additional rules should =
be added in Section 3.2 for the</FONT>
<BR><FONT SIZE=3D2>&gt; OCSP client to validate the response.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
a.&nbsp; productedAt should be reasonably close to current time.</FONT>
</P>

<P><FONT SIZE=3D2>What does this mean ? a few seconds ? or a few =
minutes ? or a few hours ? </FONT>
<BR><FONT SIZE=3D2>This is uncheckable by a client. Why should we add =
now this requirement ?</FONT>
</P>

<P><FONT SIZE=3D2>We are now too far from the original proposal made by =
Ambarish. </FONT>
<BR><FONT SIZE=3D2>Let is come back to it:</FONT>
</P>

<P><FONT SIZE=3D2>[If you look at Section 3.2, we need these rules in =
order to deal with replay detection.&nbsp; Please note that producedAt =
is always &gt; =3D thisUpdate.&nbsp; The language for producedAt should =
be similar to that for thisUpdate.]</FONT></P>

<P><FONT SIZE=3D2>&quot;If nextUpdate is not set, the responder is =
indicating that it</FONT>
<BR><FONT SIZE=3D2>doesn't know when newer information will be =
available and so, if</FONT>
<BR><FONT SIZE=3D2>a client wants status information on the certificate =
in question</FONT>
<BR><FONT SIZE=3D2>at a future date, it should come back and ask the =
server again.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>I would also add :</FONT>
</P>

<P><FONT SIZE=3D2>&quot;Note: the Certificate Practice Statement and =
the Certificate Disclosure</FONT>
<BR><FONT SIZE=3D2>Statement may provide more information about when =
newer status information</FONT>
<BR><FONT SIZE=3D2>information will be available.&quot; </FONT>
</P>

<P><FONT SIZE=3D2>[I do not see a particular benefit to citing a policy =
document in a protocol]</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
</P>

<P><FONT SIZE=3D2>Denis</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Note: Do not conclude that silence from me, means an =
agreement, since, </FONT>
<BR><FONT SIZE=3D2>as indicated at the top of this e-mail, I will not =
be in my office most of</FONT>
<BR><FONT SIZE=3D2>next week.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
b.&nbsp; If the request has a nonce extension, the response must =
have</FONT>
<BR><FONT SIZE=3D2>&gt; the nonce extension with the same value as the =
request.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Yuriy Dzambasow [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>&gt; Sent: Friday, January 18, 2002 9:22 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Ambarish Malpani; 'Deacon, Alex'; 'Santosh =
Chokhani';</FONT>
<BR><FONT SIZE=3D2>&gt; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hi Ambarish,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Thank you for clarifying this.&nbsp; I agree =
with your three potential</FONT>
<BR><FONT SIZE=3D2>&gt; questions</FONT>
<BR><FONT SIZE=3D2>&gt; and your three responses.&nbsp; Regarding item =
3, I believe this should be</FONT>
<BR><FONT SIZE=3D2>&gt; addressed through policy and practices, and not =
controlled through OCSP.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Yuriy</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; ----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>&gt; From: &quot;Ambarish Malpani&quot; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; To: &quot;'Deacon, Alex'&quot; =
&lt;[e-mail]&gt;; &quot;'Santosh Chokhani'&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;[e-mail]&gt;; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 17, 2002 3:13 PM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Here is how I see it:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; There are 3 potential questions:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1. How current is your information (on =
which you based this response)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2. How long can/should I keep/cache/rely =
on this information.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 3. How current will your information be if =
I ask you in the future.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 1. is answered by thisUpdate</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 2. is answered by nextUpdate (where a =
client can still decide to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ignore the nextUpdate field the next time =
it wants to know</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the status of this certificate)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 3. is not dealt with by the RFC. I am not =
sure we need to deal with</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it. The only case that I can think of it =
being used, is where</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; a client can go to multiple responders and =
is trying to figure</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; out which one it should normally use (like =
they do with DNS).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I don't think people are close to dealing =
with that level of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; complexity with OCSP.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hope this helps clarify the =
questions.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; A</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Deacon, Alex [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, January 17, 2002 11:37 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: 'Santosh Chokhani'; Ambarish Malpani; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; OK...you guys have lost me now.&nbsp; What =
was wrong with not including the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; nextUpdate field to specify that the =
server is providing real time info</FONT>
<BR><FONT SIZE=3D2>&gt; and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that the client should ask the server each =
time it needs the current</FONT>
<BR><FONT SIZE=3D2>&gt; status?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If a responder is providing real time =
status info, it can (or will)</FONT>
<BR><FONT SIZE=3D2>&gt; never</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; know when newer status info will be =
available as it is impossible to</FONT>
<BR><FONT SIZE=3D2>&gt; know</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; when a certificate will be =
revoked/suspended in advance.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Alex</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, January 17, 2002 11:23 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Santosh Chokhani; Ambarish Malpani; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I guess today is my day (every day is my =
day) to make errors, deeper</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; reflections and second guessing.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I guess what I am saying is as =
follows.&nbsp; Do the relying parties need to</FONT>
<BR><FONT SIZE=3D2>&gt; know</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; that the responder provides real-time =
revocation information?&nbsp; Having</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; thisUpdate=3DNOW may not prove that since =
this could be simply</FONT>
<BR><FONT SIZE=3D2>&gt; coincidence.</FONT>
<BR><FONT SIZE=3D2>&gt; A</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; pattern of responses may create =
statistical certainty.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; So, after all this, this question =
remains.&nbsp; Please do not construe my</FONT>
<BR><FONT SIZE=3D2>&gt; emails</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to mean that I am saying the feature is =
required.&nbsp; I am simply posing</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; question and proposing an approach if the =
feature is required.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, January 17, 2002 2:08 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Santosh Chokhani; Ambarish Malpani; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Upon further reflection, I think =
thisUpdate DOES take care of it.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, January 17, 2002 2:01 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Ambarish Malpani; Santosh Chokhani; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ambarish: Are you suggesting that when =
thisUpdate=3DnextUpdate that means</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; response is available all the time.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I am trying to account for situations when =
the response is real-time (or</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; near real-time).</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Ambarish Malpani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, January 17, 2002 1:56 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: 'Santosh Chokhani'; '[e-mail] =
'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Santosh, why doesn't thisUpdate meet that =
need?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; A</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, January 17, 2002 10:31 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Ambarish Malpani; 'Denis Pinkas'; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I agree with what Ambarish and Carlisle =
are saying.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I have one addition question though.&nbsp; =
Should the standard provide a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; capability to the relying parties (OCSP =
clients) that the current</FONT>
<BR><FONT SIZE=3D2>&gt; revocation</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; information is always available. If people =
agree that it should, given</FONT>
<BR><FONT SIZE=3D2>&gt; the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; proposed meaning of nextUpdate, the =
additional capability can be handled</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; via</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; a SingleResponse extension.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Ambarish Malpani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, January 17, 2002 11:53 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: 'Denis Pinkas'; '[e-mail] =
'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi Denis,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Information about =
how up to date the information is, is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; already present in the thisUpdate field in =
the response.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; So, for example, if you *know* that you =
have information that is</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; current as of 5 seconds ago, you can set =
that field appropriately.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Does this meet your needs?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ambarish</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Thursday, January 17, 2002 8:50 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: 'Santosh Chokhani'; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: Re: OCSP RFC and OCSP =
version 2 ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Ambarish,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Hi Santosh,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Give me =
some time.... :-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; I agree with your first =
analysis:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &quot;If nextUpdate is not set, =
the responder is indicating that newer</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; revocation information is =
available all the time&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Actually, they way I would =
prefer to state it would be something</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; like:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; &quot;If nextUpdate is not set, =
the responder is indicating that it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; doesn't know when newer =
information will be available and so, if</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; a client wants status =
information on the certificate in question</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; at a future date, it should come =
back and ask the server again.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I like your proposal, since this =
means that when using the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; on-line protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; it is not possible to know. Now we =
could add a sentence that says:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &quot;However, the Certificate =
Practice Statement and the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Certificate Disclosure</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Statement may provide more =
information about the refreshment</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; conditions of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the status information.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Denis</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; This is my personal opinion. If =
the group agrees, I am happy to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; modify the document to reflect =
this point of view.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Ambarish</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; Architect</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; ValiCert, Inc.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; 339 N. Bernardo Ave.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Wednesday, January 16, 2002 =
11:50 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: Peter Williams; 'Denis Pinkas '; =
Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: RE: OCSP RFC and OCSP =
version 2 ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Why aren't the authors responding to =
this contradiction in the RFC and</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; carried out in the ID?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Peter Williams [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: Wednesday, January 16, 2002 =
2:41 PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: 'Denis Pinkas '; 'Santosh =
Chokhani '</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: RE: OCSP RFC and OCSP =
version 2 ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Denis,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; You refer to an assumed&nbsp; =
&quot;main mechanism&quot; in your note. Speaking</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; factually,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; to hopefully guide you, =
sensibly:-</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; The main [reference] mechanism(s) at, =
and shortly after,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the time of writing OCSP IDs =
included:-</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; (1) VeriSign, who used an oracle =
database-based repository to feed</FONT>
<BR><FONT SIZE=3D2>&gt; data</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; to OCSP deamons acting in cached and =
interactive, direct-trust</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; mode; CRLs were not involved. OCSP =
proxing/multiplexing interactive</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; direct-trust mode was&nbsp; added, =
shortly after standarization, for a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; defense customer bridging multiple =
certification domains.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; (2) ValiCert, who used direct CRLs to =
feed data to direct/indirect</FONT>
<BR><FONT SIZE=3D2>&gt; OCSP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; deamons. Indirect CRLs and CRLDPs =
support was added slightly after</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; the architects had harmonized their =
work.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Both mechanisms evolved further, =
outside of IETF and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; in vendor forums, particularly in the =
area of: application</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; integration, CRLDPs and delta-CRL =
data sources, proxying</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; transaction semantics and response =
resigning, data freshness</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; signalling, and OCSP client =
interaction with X.509 and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; PKIX-style path processing and X.509 =
applications such as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; SSLv3/https and MTA-based automatic =
xmldsig signature</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; verification on B2B and banking =
protocol XML streams.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Historically, this work essentially =
re-designed the standardized</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; features of the &quot;distributed =
authentication model&quot; of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; X.500 1988, for OCSP-borne =
queries.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Currently, VeriSign's current work in =
W3C also</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; reflects alot of the understanding on =
the required</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; semantics of realtime trust =
models.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Peter.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; From: Denis Pinkas</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Sent: 1/16/02 12:04 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Subject: Re: OCSP RFC and OCSP =
version 2 ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; At the time the document was written, =
the main mechanism to feed the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; information to the OCSP server was to =
use CRLs. So it seems sensible</FONT>
<BR><FONT SIZE=3D2>&gt; to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; think that these fields are copied =
from a CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1A04F.6CA0E9B0--


Received: by above.proper.com (8.11.6/8.11.3) id g0IIL3K00771 for ietf-pkix-bks; Fri, 18 Jan 2002 10:21:03 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IIL0300764 for <[e-mail]>; Fri, 18 Jan 2002 10:21:01 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id TAA01225 for <[e-mail]>; Fri, 18 Jan 2002 19:21:01 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 18 Jan 2002 19:21:02 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id TAA09596 for <[e-mail]>; Fri, 18 Jan 2002 19:21:00 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id TAA05044 for [e-mail]; Fri, 18 Jan 2002 19:21:00 +0100 (MET)
Date: Fri, 18 Jan 2002 19:21:00 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: meeting minutes and DPV-DPV req draft
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi,

I propose that the following excerpt from the minutes be included
in the introduction of the DPV-DPD text if this is the
common understanding of the group. As far as I understand,
the text reflects the presentation of Denis.

"Separate validation and discovery policies are used to control these 
respective functions at a server. Management of the policies is 
separate, and can be effected via separate protocols or locally 
(directly).
This architecture allows for simple requests and responses, 
because it removes specification of the policy from these 
messages, and this is consistent with the motivations for DPV/DPD, 
based on use by constrained clients."

Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IHsiO29880 for ietf-pkix-bks; Fri, 18 Jan 2002 09:54:44 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IHsh329876 for <[e-mail]>; Fri, 18 Jan 2002 09:54:43 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 18 Jan 2002 09:54:39 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Fri, 18 Jan 2002 09:54:39 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <C2FYXCLW>; Fri, 18 Jan 2002 09:54:34 -0800
Content-return: allowed
Date: Fri, 18 Jan 2002 09:54:26 -0800
From: Peter Williams <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'[e-mail] '" <[e-mail]>
Cc: "''Santosh Chokhani' '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="iso-8859-1"
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Santosh finally asked a valid and proper question: how is 
revocation-notice freshess information handled by OCSP clients 
(such as a DPV server)

So far, the list's analysis has established that the reliability
of X.509 revocation-notices at use-time is, in part, handled by 
a technical signal, and in another part policy, as enforced by 
clients.

OCSP used certificate-based policy mechanisms
to signal validation-policy. For example

(a) add to the Bridge-CA-style 
assurance policy oid in the relevant CA cert (pertinent to
the OCSP responder) another cert policy oid to signal 
validation-semantics to the cert path processing
module and the PKI application that decides how to use a
chain.

(b) When the OCSP client 
application uses a cert chain to process an EE cert supporting an 
OCSP response signature, the OCSP client UA  get to impose the full 
X.509 cert processing logic: require certain cert policy oids (2: a
Federal assurance level, and an application-specific validation
policy controlling the accuracy of revocation-notices) and qualifiers.

While architecturally correct, the example method described above 
is rarely used in practice. (Why this is so is an interesting 
design question, for another time and place.)

In DPV we get to use protocol-based validation policy signals,
rather than rely on certificate-based mechanisms for
communicating and controlling policy to applications using
revocation-notices.

Id recommend that, in the context of DPV, we not only specify
message formats and handling semantics, but we also specify
one particular validation policy: one that qualifies the policy
of a DPV server using an OCSP server to access revocation-notices, and
be able to assert to the DPV client via a DPV-style 
validation policy "IETF-CRL" that this means the OCSP source 
was equivalent to the DPV server using the current CRL from the 
CA directly.

In this way, we establish in public standards one of the 
important baselines to,  finally, relate the reliability of OCSP 
to CRLs from the PKI-application's perspective. As a DPV server 
is only a simple "remote" path processing 
engine that supports application logic coresident with
the DPV-client, it is fitting to treat the DPV validation policy signal
to a DPV client as a signal to the co-resident PKI application 
indicaating the reliability of the validation infrastructure 
supplying the revocation notices.

Peter.
-----Original Message-----
From: Yuriy Dzambasow
To: Ambarish Malpani; 'Deacon, Alex'; 'Santosh Chokhani'; [e-mail]
Sent: 1/18/02 6:21 AM
Subject: Re: OCSP RFC and OCSP version 2 ID


Hi Ambarish,

Thank you for clarifying this.  I agree with your three potential
questions
and your three responses.  Regarding item 3, I believe this should be
addressed through policy and practices, and not controlled through OCSP.

Yuriy
 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IHmqi29763 for ietf-pkix-bks; Fri, 18 Jan 2002 09:48:52 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IHmp329759 for <[e-mail]>; Fri, 18 Jan 2002 09:48:51 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA11184; Fri, 18 Jan 2002 18:50:03 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA14918; Fri, 18 Jan 2002 18:48:16 +0100
Message-ID: <[e-mail]>
Date: Fri, 18 Jan 2002 18:44:47 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: Ambarish Malpani <[e-mail]>, [e-mail]
Subject: Re: OCSP RFC and OCSP version 2 ID
References: <8D7EC1912E25D411A32100D0B7695397E1B691@SCYGMXS01>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Santosh,

Before leaving my office for nearly a week ...

> All:
> 
> Last might Ambarish and I had a discussion on the OCSP RFC.  We agreed
> that the following modifications need to be made.  Unless Ambarish has
> some new concerns based on further reflection, here are the proposed
> changes.  Please note that the changes to Section 3.2 have not been
> discussed with the list, but I have had them on mind ever since I started
> analyzing the RFC this week.  I am sure Ambarish will polish this
> language.
> 
> 1.  The absence of nextUpdate means that the client should not cache the
> response.  

I find it somewhat surprising to see that now we speak of "caching the
response" which is local mater (a client may have no cache at all, so in
that case what is the interpretation ?) and has nothing to do with the
original topic which was how a client shall interpret the response when
nextUpdate is missing.

> The server may do this either because real-time response is
> available all the time or the server itself does not have advise (e.g.,
> absence of nextUpdate in CRL) from the CA as to when the newer revocation
> information will be available.

We do not care why a server "may" do this, we care to understand what that
means for the client.
 
> 2.  The following additional rules should be added in Section 3.2 for the
> OCSP client to validate the response.
> 
>         a.  productedAt should be reasonably close to current time.

What does this mean ? a few seconds ? or a few minutes ? or a few hours ? 
This is uncheckable by a client. Why should we add now this requirement ?

We are now too far from the original proposal made by Ambarish. 
Let is come back to it:

"If nextUpdate is not set, the responder is indicating that it
doesn't know when newer information will be available and so, if
a client wants status information on the certificate in question
at a future date, it should come back and ask the server again."

I would also add :

"Note: the Certificate Practice Statement and the Certificate Disclosure
Statement may provide more information about when newer status information
information will be available." 

Regards,

Denis


Note: Do not conclude that silence from me, means an agreement, since, 
as indicated at the top of this e-mail, I will not be in my office most of
next week.


>         b.  If the request has a nonce extension, the response must have
> the nonce extension with the same value as the request.
> 
> -----Original Message-----
> From: Yuriy Dzambasow [mailto:[e-mail]]
> Sent: Friday, January 18, 2002 9:22 AM
> To: Ambarish Malpani; 'Deacon, Alex'; 'Santosh Chokhani';
> [e-mail]
> Subject: Re: OCSP RFC and OCSP version 2 ID
> 
> Hi Ambarish,
> 
> Thank you for clarifying this.  I agree with your three potential
> questions
> and your three responses.  Regarding item 3, I believe this should be
> addressed through policy and practices, and not controlled through OCSP.
> 
> Yuriy
> 
> ----- Original Message -----
> From: "Ambarish Malpani" <[e-mail]>
> To: "'Deacon, Alex'" <[e-mail]>; "'Santosh Chokhani'"
> <[e-mail]>; <[e-mail]>
> Sent: Thursday, January 17, 2002 3:13 PM
> Subject: RE: OCSP RFC and OCSP version 2 ID
> 
> >
> >
> > Here is how I see it:
> >
> > There are 3 potential questions:
> > 1. How current is your information (on which you based this response)
> > 2. How long can/should I keep/cache/rely on this information.
> > 3. How current will your information be if I ask you in the future.
> >
> > 1. is answered by thisUpdate
> > 2. is answered by nextUpdate (where a client can still decide to
> > ignore the nextUpdate field the next time it wants to know
> > the status of this certificate)
> > 3. is not dealt with by the RFC. I am not sure we need to deal with
> > it. The only case that I can think of it being used, is where
> > a client can go to multiple responders and is trying to figure
> > out which one it should normally use (like they do with DNS).
> > I don't think people are close to dealing with that level of
> > complexity with OCSP.
> >
> > Hope this helps clarify the questions.
> >
> > A
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                650.567.5457
> > ValiCert, Inc.                                  [e-mail]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Deacon, Alex [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 11:37 AM
> > To: 'Santosh Chokhani'; Ambarish Malpani; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> > OK...you guys have lost me now.  What was wrong with not including the
> > nextUpdate field to specify that the server is providing real time info
> and
> > that the client should ask the server each time it needs the current
> status?
> > If a responder is providing real time status info, it can (or will)
> never
> > know when newer status info will be available as it is impossible to
> know
> > when a certificate will be revoked/suspended in advance.
> >
> > Alex
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 11:23 AM
> > To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> > I guess today is my day (every day is my day) to make errors, deeper
> > reflections and second guessing.
> >
> > I guess what I am saying is as follows.  Do the relying parties need to
> know
> > that the responder provides real-time revocation information?  Having
> > thisUpdate=NOW may not prove that since this could be simply
> coincidence.
> A
> > pattern of responses may create statistical certainty.
> >
> > So, after all this, this question remains.  Please do not construe my
> emails
> > to mean that I am saying the feature is required.  I am simply posing
> the
> > question and proposing an approach if the feature is required.
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 2:08 PM
> > To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> > Upon further reflection, I think thisUpdate DOES take care of it.
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 2:01 PM
> > To: Ambarish Malpani; Santosh Chokhani; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> > Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
> > response is available all the time.
> >
> > I am trying to account for situations when the response is real-time (or
> 
> > near real-time).
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 1:56 PM
> > To: 'Santosh Chokhani'; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> >
> > Santosh, why doesn't thisUpdate meet that need?
> >
> > A
> >
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                650.567.5457
> > ValiCert, Inc.                                  [e-mail]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 10:31 AM
> > To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> > I agree with what Ambarish and Carlisle are saying.
> > I have one addition question though.  Should the standard provide a
> > capability to the relying parties (OCSP clients) that the current
> revocation
> > information is always available. If people agree that it should, given
> the
> > proposed meaning of nextUpdate, the additional capability can be handled
> 
> via
> > a SingleResponse extension.
> > -----Original Message-----
> > From: Ambarish Malpani [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 11:53 AM
> > To: 'Denis Pinkas'; '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> >
> >
> >
> > Hi Denis,
> >     Information about how up to date the information is, is
> > already present in the thisUpdate field in the response.
> > So, for example, if you *know* that you have information that is
> > current as of 5 seconds ago, you can set that field appropriately.
> > Does this meet your needs?
> > Regards,
> > Ambarish
> > ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                650.567.5457
> > ValiCert, Inc.                                  [e-mail]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> >
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[e-mail]]
> > > Sent: Thursday, January 17, 2002 8:50 AM
> > > To: Ambarish Malpani
> > > Cc: 'Santosh Chokhani'; '[e-mail] '
> > > Subject: Re: OCSP RFC and OCSP version 2 ID
> > >
> > >
> > > Ambarish,
> > >
> > > > Hi Santosh,
> > > >     Give me some time.... :-)
> > > >
> > > > I agree with your first analysis:
> > > >
> > > > "If nextUpdate is not set, the responder is indicating that newer
> > > > revocation information is available all the time"
> > > >
> > > > Actually, they way I would prefer to state it would be something
> > > > like:
> > >
> > > > "If nextUpdate is not set, the responder is indicating that it
> > > > doesn't know when newer information will be available and so, if
> > > > a client wants status information on the certificate in question
> > > > at a future date, it should come back and ask the server again."
> > >
> > > I like your proposal, since this means that when using the
> > > on-line protocol
> > > it is not possible to know. Now we could add a sentence that says:
> > >
> > > "However, the Certificate Practice Statement and the
> > > Certificate Disclosure
> > > Statement may provide more information about the refreshment
> > > conditions of
> > > the status information."
> > >
> > > Denis
> > >
> > > > This is my personal opinion. If the group agrees, I am happy to
> > > > modify the document to reflect this point of view.
> > > >
> > > > Regards,
> > > > Ambarish
> > > >
> > > >
> > > ---------------------------------------------------------------------
> > > > Ambarish Malpani
> > > > Architect
> > > 650.567.5457
> > > > ValiCert, Inc.
> > > [e-mail]
> > > > 339 N. Bernardo Ave.
> > http://www.valicert.com
> > > Mountain View, CA 94043
> > >
> > > -----Original Message-----
> > > From: Santosh Chokhani [mailto:[e-mail]]
> > > Sent: Wednesday, January 16, 2002 11:50 AM
> > > To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> > > Cc: '[e-mail] '
> > > Subject: RE: OCSP RFC and OCSP version 2 ID
> > >
> > > Why aren't the authors responding to this contradiction in the RFC and
> 
> > > carried out in the ID?
> > > -----Original Message-----
> > > From: Peter Williams [mailto:[e-mail]]
> > > Sent: Wednesday, January 16, 2002 2:41 PM
> > > To: 'Denis Pinkas '; 'Santosh Chokhani '
> > > Cc: '[e-mail] '
> > > Subject: RE: OCSP RFC and OCSP version 2 ID
> > >
> > > Denis,
> > > You refer to an assumed  "main mechanism" in your note. Speaking
> > factually,
> > > to hopefully guide you, sensibly:-
> > > The main [reference] mechanism(s) at, and shortly after,
> > > the time of writing OCSP IDs included:-
> > > (1) VeriSign, who used an oracle database-based repository to feed
> data
> > > to OCSP deamons acting in cached and interactive, direct-trust
> > > mode; CRLs were not involved. OCSP proxing/multiplexing interactive
> > > direct-trust mode was  added, shortly after standarization, for a
> > > defense customer bridging multiple certification domains.
> > > (2) ValiCert, who used direct CRLs to feed data to direct/indirect
> OCSP
> > > deamons. Indirect CRLs and CRLDPs support was added slightly after
> > > the architects had harmonized their work.
> > > Both mechanisms evolved further, outside of IETF and
> > > in vendor forums, particularly in the area of: application
> > > integration, CRLDPs and delta-CRL data sources, proxying
> > > transaction semantics and response resigning, data freshness
> > > signalling, and OCSP client interaction with X.509 and
> > > PKIX-style path processing and X.509 applications such as
> > > SSLv3/https and MTA-based automatic xmldsig signature
> > > verification on B2B and banking protocol XML streams.
> > > Historically, this work essentially re-designed the standardized
> > > features of the "distributed authentication model" of
> > > X.500 1988, for OCSP-borne queries.
> > > Currently, VeriSign's current work in W3C also
> > > reflects alot of the understanding on the required
> > > semantics of realtime trust models.
> > > Peter.
> > > -----Original Message-----
> > > From: Denis Pinkas
> > > To: Santosh Chokhani
> > > Cc: [e-mail]
> > > Sent: 1/16/02 12:04 AM
> > > Subject: Re: OCSP RFC and OCSP version 2 ID
> > > At the time the document was written, the main mechanism to feed the
> > > information to the OCSP server was to use CRLs. So it seems sensible
> to
> > > think that these fields are copied from a CRL.
> > >
> >


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IHiwD29690 for ietf-pkix-bks; Fri, 18 Jan 2002 09:44:58 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IHiv329686 for <[e-mail]>; Fri, 18 Jan 2002 09:44:57 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA14738; Fri, 18 Jan 2002 18:46:06 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA17308; Fri, 18 Jan 2002 18:44:18 +0100
Message-ID: <[e-mail]>
Date: Fri, 18 Jan 2002 18:40:51 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Peter Sylvester <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP RFC and OCSP version 2 ID
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter,

Good comment !

Thank you !

Denis


> I find it somewhat surprising to see at the same time a
> discussion to clarify how to provide OCSP information about timeliness
> in the response, which I one interpret as nothing else
> as one possible input to determine a 'cautionary period'
> and at the same time not believing that a certificate
> status protocol could not be able to provide in an easy way
> a consolidated view of this like:
> 
> Client ask:  'Is this good now'.
> Server says: 'is was good at now -5'
>              | 'It is good, last time I check was n minutes ago.'
> 
> Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IGrWc28520 for ietf-pkix-bks; Fri, 18 Jan 2002 08:53:32 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IGrV328516 for <[e-mail]>; Fri, 18 Jan 2002 08:53:31 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <DGD1FT1V>; Fri, 18 Jan 2002 11:53:27 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B691@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: Yuriy Dzambasow <[e-mail]>, Ambarish Malpani <[e-mail]>, "'Deacon, Alex'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, [e-mail]
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Fri, 18 Jan 2002 11:52:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A040.793804B0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C1A040.793804B0
Content-Type: text/plain;
	charset="iso-8859-1"

All:

Last might Ambarish and I had a discussion on the OCSP RFC.  We agreed that
the following modifications need to be made.  Unless Ambarish has some new
concerns based on further reflection, here are the proposed changes.  Please
note that the changes to Section 3.2 have not been discussed with the list,
but I have had them on mind ever since I started analyzing the RFC this
week.  I am sure Ambarish will polish this language.

1.  The absence of nextUpdate means that the client should not cache the
response.  The server may do this either because real-time response is
available all the time or the server itself does not have advise (e.g.,
absence of nextUpdate in CRL) from the CA as to when the newer revocation
information will be available.

2.  The following additional rules should be added in Section 3.2 for the
OCSP client to validate the response.

	a.  productedAt should be reasonably close to current time.
	b.  If the request has a nonce extension, the response must have the
nonce extension with the same value as the request.

-----Original Message-----
From: Yuriy Dzambasow [mailto:[e-mail]]
Sent: Friday, January 18, 2002 9:22 AM
To: Ambarish Malpani; 'Deacon, Alex'; 'Santosh Chokhani';
[e-mail]
Subject: Re: OCSP RFC and OCSP version 2 ID



Hi Ambarish,

Thank you for clarifying this.  I agree with your three potential questions
and your three responses.  Regarding item 3, I believe this should be
addressed through policy and practices, and not controlled through OCSP.

Yuriy

----- Original Message -----
From: "Ambarish Malpani" <[e-mail]>
To: "'Deacon, Alex'" <[e-mail]>; "'Santosh Chokhani'"
<[e-mail]>; <[e-mail]>
Sent: Thursday, January 17, 2002 3:13 PM
Subject: RE: OCSP RFC and OCSP version 2 ID


>
>
> Here is how I see it:
>
> There are 3 potential questions:
> 1. How current is your information (on which you based this response)
> 2. How long can/should I keep/cache/rely on this information.
> 3. How current will your information be if I ask you in the future.
>
> 1. is answered by thisUpdate
> 2. is answered by nextUpdate (where a client can still decide to
> ignore the nextUpdate field the next time it wants to know
> the status of this certificate)
> 3. is not dealt with by the RFC. I am not sure we need to deal with
> it. The only case that I can think of it being used, is where
> a client can go to multiple responders and is trying to figure
> out which one it should normally use (like they do with DNS).
> I don't think people are close to dealing with that level of
> complexity with OCSP.
>
> Hope this helps clarify the questions.
>
> A
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
> -----Original Message-----
> From: Deacon, Alex [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 11:37 AM
> To: 'Santosh Chokhani'; Ambarish Malpani; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
> OK...you guys have lost me now.  What was wrong with not including the
> nextUpdate field to specify that the server is providing real time info
and
> that the client should ask the server each time it needs the current
status?
> If a responder is providing real time status info, it can (or will) never
> know when newer status info will be available as it is impossible to know
> when a certificate will be revoked/suspended in advance.
>
> Alex
>
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 11:23 AM
> To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
> I guess today is my day (every day is my day) to make errors, deeper
> reflections and second guessing.
>
> I guess what I am saying is as follows.  Do the relying parties need to
know
> that the responder provides real-time revocation information?  Having
> thisUpdate=NOW may not prove that since this could be simply coincidence.
A
> pattern of responses may create statistical certainty.
>
> So, after all this, this question remains.  Please do not construe my
emails
> to mean that I am saying the feature is required.  I am simply posing the
> question and proposing an approach if the feature is required.
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 2:08 PM
> To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
> Upon further reflection, I think thisUpdate DOES take care of it.
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 2:01 PM
> To: Ambarish Malpani; Santosh Chokhani; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
> Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
> response is available all the time.
>
> I am trying to account for situations when the response is real-time (or
> near real-time).
> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 1:56 PM
> To: 'Santosh Chokhani'; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
>
> Santosh, why doesn't thisUpdate meet that need?
>
> A
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 10:31 AM
> To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
> I agree with what Ambarish and Carlisle are saying.
> I have one addition question though.  Should the standard provide a
> capability to the relying parties (OCSP clients) that the current
revocation
> information is always available. If people agree that it should, given the
> proposed meaning of nextUpdate, the additional capability can be handled
via
> a SingleResponse extension.
> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 11:53 AM
> To: 'Denis Pinkas'; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
>
>
> Hi Denis,
>     Information about how up to date the information is, is
> already present in the thisUpdate field in the response.
> So, for example, if you *know* that you have information that is
> current as of 5 seconds ago, you can set that field appropriately.
> Does this meet your needs?
> Regards,
> Ambarish
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 8:50 AM
> > To: Ambarish Malpani
> > Cc: 'Santosh Chokhani'; '[e-mail] '
> > Subject: Re: OCSP RFC and OCSP version 2 ID
> >
> >
> > Ambarish,
> >
> > > Hi Santosh,
> > >     Give me some time.... :-)
> > >
> > > I agree with your first analysis:
> > >
> > > "If nextUpdate is not set, the responder is indicating that newer
> > > revocation information is available all the time"
> > >
> > > Actually, they way I would prefer to state it would be something
> > > like:
> >
> > > "If nextUpdate is not set, the responder is indicating that it
> > > doesn't know when newer information will be available and so, if
> > > a client wants status information on the certificate in question
> > > at a future date, it should come back and ask the server again."
> >
> > I like your proposal, since this means that when using the
> > on-line protocol
> > it is not possible to know. Now we could add a sentence that says:
> >
> > "However, the Certificate Practice Statement and the
> > Certificate Disclosure
> > Statement may provide more information about the refreshment
> > conditions of
> > the status information."
> >
> > Denis
> >
> > > This is my personal opinion. If the group agrees, I am happy to
> > > modify the document to reflect this point of view.
> > >
> > > Regards,
> > > Ambarish
> > >
> > >
> > ---------------------------------------------------------------------
> > > Ambarish Malpani
> > > Architect
> > 650.567.5457
> > > ValiCert, Inc.
> > [e-mail]
> > > 339 N. Bernardo Ave.
> http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Wednesday, January 16, 2002 11:50 AM
> > To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> > Cc: '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> > Why aren't the authors responding to this contradiction in the RFC and
> > carried out in the ID?
> > -----Original Message-----
> > From: Peter Williams [mailto:[e-mail]]
> > Sent: Wednesday, January 16, 2002 2:41 PM
> > To: 'Denis Pinkas '; 'Santosh Chokhani '
> > Cc: '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> > Denis,
> > You refer to an assumed  "main mechanism" in your note. Speaking
> factually,
> > to hopefully guide you, sensibly:-
> > The main [reference] mechanism(s) at, and shortly after,
> > the time of writing OCSP IDs included:-
> > (1) VeriSign, who used an oracle database-based repository to feed data
> > to OCSP deamons acting in cached and interactive, direct-trust
> > mode; CRLs were not involved. OCSP proxing/multiplexing interactive
> > direct-trust mode was  added, shortly after standarization, for a
> > defense customer bridging multiple certification domains.
> > (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP
> > deamons. Indirect CRLs and CRLDPs support was added slightly after
> > the architects had harmonized their work.
> > Both mechanisms evolved further, outside of IETF and
> > in vendor forums, particularly in the area of: application
> > integration, CRLDPs and delta-CRL data sources, proxying
> > transaction semantics and response resigning, data freshness
> > signalling, and OCSP client interaction with X.509 and
> > PKIX-style path processing and X.509 applications such as
> > SSLv3/https and MTA-based automatic xmldsig signature
> > verification on B2B and banking protocol XML streams.
> > Historically, this work essentially re-designed the standardized
> > features of the "distributed authentication model" of
> > X.500 1988, for OCSP-borne queries.
> > Currently, VeriSign's current work in W3C also
> > reflects alot of the understanding on the required
> > semantics of realtime trust models.
> > Peter.
> > -----Original Message-----
> > From: Denis Pinkas
> > To: Santosh Chokhani
> > Cc: [e-mail]
> > Sent: 1/16/02 12:04 AM
> > Subject: Re: OCSP RFC and OCSP version 2 ID
> > At the time the document was written, the main mechanism to feed the
> > information to the OCSP server was to use CRLs. So it seems sensible to
> > think that these fields are copied from a CRL.
> >
>

------_=_NextPart_001_01C1A040.793804B0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>All:</FONT>
</P>

<P><FONT SIZE=3D2>Last might Ambarish and I had a discussion on the =
OCSP RFC.&nbsp; We agreed that the following modifications need to be =
made.&nbsp; Unless Ambarish has some new concerns based on further =
reflection, here are the proposed changes.&nbsp; Please note that the =
changes to Section 3.2 have not been discussed with the list, but I =
have had them on mind ever since I started analyzing the RFC this =
week.&nbsp; I am sure Ambarish will polish this language.</FONT></P>

<P><FONT SIZE=3D2>1.&nbsp; The absence of nextUpdate means that the =
client should not cache the response.&nbsp; The server may do this =
either because real-time response is available all the time or the =
server itself does not have advise (e.g., absence of nextUpdate in CRL) =
from the CA as to when the newer revocation information will be =
available.</FONT></P>

<P><FONT SIZE=3D2>2.&nbsp; The following additional rules should be =
added in Section 3.2 for the OCSP client to validate the =
response.</FONT>
</P>

<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a.&nbsp; =
productedAt should be reasonably close to current time.</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>b.&nbsp; =
If the request has a nonce extension, the response must have the nonce =
extension with the same value as the request.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Yuriy Dzambasow [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>=

<BR><FONT SIZE=3D2>Sent: Friday, January 18, 2002 9:22 AM</FONT>
<BR><FONT SIZE=3D2>To: Ambarish Malpani; 'Deacon, Alex'; 'Santosh =
Chokhani';</FONT>
<BR><FONT SIZE=3D2>[e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Re: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi Ambarish,</FONT>
</P>

<P><FONT SIZE=3D2>Thank you for clarifying this.&nbsp; I agree with =
your three potential questions</FONT>
<BR><FONT SIZE=3D2>and your three responses.&nbsp; Regarding item 3, I =
believe this should be</FONT>
<BR><FONT SIZE=3D2>addressed through policy and practices, and not =
controlled through OCSP.</FONT>
</P>

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

<P><FONT SIZE=3D2>----- Original Message -----</FONT>
<BR><FONT SIZE=3D2>From: &quot;Ambarish Malpani&quot; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>To: &quot;'Deacon, Alex'&quot; =
&lt;[e-mail]&gt;; &quot;'Santosh Chokhani'&quot;</FONT>
<BR><FONT SIZE=3D2>&lt;[e-mail]&gt;; =
&lt;[e-mail]&gt;</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 3:13 PM</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Here is how I see it:</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; There are 3 potential questions:</FONT>
<BR><FONT SIZE=3D2>&gt; 1. How current is your information (on which =
you based this response)</FONT>
<BR><FONT SIZE=3D2>&gt; 2. How long can/should I keep/cache/rely on =
this information.</FONT>
<BR><FONT SIZE=3D2>&gt; 3. How current will your information be if I =
ask you in the future.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; 1. is answered by thisUpdate</FONT>
<BR><FONT SIZE=3D2>&gt; 2. is answered by nextUpdate (where a client =
can still decide to</FONT>
<BR><FONT SIZE=3D2>&gt; ignore the nextUpdate field the next time it =
wants to know</FONT>
<BR><FONT SIZE=3D2>&gt; the status of this certificate)</FONT>
<BR><FONT SIZE=3D2>&gt; 3. is not dealt with by the RFC. I am not sure =
we need to deal with</FONT>
<BR><FONT SIZE=3D2>&gt; it. The only case that I can think of it being =
used, is where</FONT>
<BR><FONT SIZE=3D2>&gt; a client can go to multiple responders and is =
trying to figure</FONT>
<BR><FONT SIZE=3D2>&gt; out which one it should normally use (like they =
do with DNS).</FONT>
<BR><FONT SIZE=3D2>&gt; I don't think people are close to dealing with =
that level of</FONT>
<BR><FONT SIZE=3D2>&gt; complexity with OCSP.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Hope this helps clarify the questions.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; A</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; 339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Deacon, Alex [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 17, 2002 11:37 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Santosh Chokhani'; Ambarish Malpani; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; OK...you guys have lost me now.&nbsp; What was =
wrong with not including the</FONT>
<BR><FONT SIZE=3D2>&gt; nextUpdate field to specify that the server is =
providing real time info</FONT>
<BR><FONT SIZE=3D2>and</FONT>
<BR><FONT SIZE=3D2>&gt; that the client should ask the server each time =
it needs the current</FONT>
<BR><FONT SIZE=3D2>status?</FONT>
<BR><FONT SIZE=3D2>&gt; If a responder is providing real time status =
info, it can (or will) never</FONT>
<BR><FONT SIZE=3D2>&gt; know when newer status info will be available =
as it is impossible to know</FONT>
<BR><FONT SIZE=3D2>&gt; when a certificate will be revoked/suspended in =
advance.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Alex</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 17, 2002 11:23 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Santosh Chokhani; Ambarish Malpani; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I guess today is my day (every day is my day) =
to make errors, deeper</FONT>
<BR><FONT SIZE=3D2>&gt; reflections and second guessing.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I guess what I am saying is as follows.&nbsp; =
Do the relying parties need to</FONT>
<BR><FONT SIZE=3D2>know</FONT>
<BR><FONT SIZE=3D2>&gt; that the responder provides real-time =
revocation information?&nbsp; Having</FONT>
<BR><FONT SIZE=3D2>&gt; thisUpdate=3DNOW may not prove that since this =
could be simply coincidence.</FONT>
<BR><FONT SIZE=3D2>A</FONT>
<BR><FONT SIZE=3D2>&gt; pattern of responses may create statistical =
certainty.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; So, after all this, this question =
remains.&nbsp; Please do not construe my</FONT>
<BR><FONT SIZE=3D2>emails</FONT>
<BR><FONT SIZE=3D2>&gt; to mean that I am saying the feature is =
required.&nbsp; I am simply posing the</FONT>
<BR><FONT SIZE=3D2>&gt; question and proposing an approach if the =
feature is required.</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 17, 2002 2:08 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Santosh Chokhani; Ambarish Malpani; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Upon further reflection, I think thisUpdate =
DOES take care of it.</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 17, 2002 2:01 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Ambarish Malpani; Santosh Chokhani; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Ambarish: Are you suggesting that when =
thisUpdate=3DnextUpdate that means</FONT>
<BR><FONT SIZE=3D2>&gt; response is available all the time.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I am trying to account for situations when the =
response is real-time (or</FONT>
<BR><FONT SIZE=3D2>&gt; near real-time).</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Ambarish Malpani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 17, 2002 1:56 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Santosh Chokhani'; '[e-mail] =
'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Santosh, why doesn't thisUpdate meet that =
need?</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; A</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; 339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 17, 2002 10:31 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Ambarish Malpani; 'Denis Pinkas'; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; I agree with what Ambarish and Carlisle are =
saying.</FONT>
<BR><FONT SIZE=3D2>&gt; I have one addition question though.&nbsp; =
Should the standard provide a</FONT>
<BR><FONT SIZE=3D2>&gt; capability to the relying parties (OCSP =
clients) that the current</FONT>
<BR><FONT SIZE=3D2>revocation</FONT>
<BR><FONT SIZE=3D2>&gt; information is always available. If people =
agree that it should, given the</FONT>
<BR><FONT SIZE=3D2>&gt; proposed meaning of nextUpdate, the additional =
capability can be handled</FONT>
<BR><FONT SIZE=3D2>via</FONT>
<BR><FONT SIZE=3D2>&gt; a SingleResponse extension.</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Ambarish Malpani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 17, 2002 11:53 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Denis Pinkas'; '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; Hi Denis,</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp;&nbsp;&nbsp;&nbsp; Information about how =
up to date the information is, is</FONT>
<BR><FONT SIZE=3D2>&gt; already present in the thisUpdate field in the =
response.</FONT>
<BR><FONT SIZE=3D2>&gt; So, for example, if you *know* that you have =
information that is</FONT>
<BR><FONT SIZE=3D2>&gt; current as of 5 seconds ago, you can set that =
field appropriately.</FONT>
<BR><FONT SIZE=3D2>&gt; Does this meet your needs?</FONT>
<BR><FONT SIZE=3D2>&gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; Ambarish</FONT>
<BR><FONT SIZE=3D2>&gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; 339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Thursday, January 17, 2002 8:50 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: 'Santosh Chokhani'; '[e-mail] =
'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ambarish,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Hi Santosh,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Give me some =
time.... :-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; I agree with your first =
analysis:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &quot;If nextUpdate is not set, the =
responder is indicating that newer</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; revocation information is available =
all the time&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Actually, they way I would prefer to =
state it would be something</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; like:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &quot;If nextUpdate is not set, the =
responder is indicating that it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; doesn't know when newer information =
will be available and so, if</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; a client wants status information on =
the certificate in question</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; at a future date, it should come back =
and ask the server again.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I like your proposal, since this means =
that when using the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; on-line protocol</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; it is not possible to know. Now we could =
add a sentence that says:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;However, the Certificate Practice =
Statement and the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Certificate Disclosure</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Statement may provide more information =
about the refreshment</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; conditions of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the status information.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Denis</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; This is my personal opinion. If the =
group agrees, I am happy to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; modify the document to reflect this =
point of view.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Ambarish</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; Architect</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; ValiCert, Inc.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; 339 N. Bernardo Ave.</FONT>
<BR><FONT SIZE=3D2>&gt; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Wednesday, January 16, 2002 11:50 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Peter Williams; 'Denis Pinkas '; =
Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Why aren't the authors responding to this =
contradiction in the RFC and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; carried out in the ID?</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Peter Williams [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: Wednesday, January 16, 2002 2:41 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: 'Denis Pinkas '; 'Santosh Chokhani =
'</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Denis,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; You refer to an assumed&nbsp; &quot;main =
mechanism&quot; in your note. Speaking</FONT>
<BR><FONT SIZE=3D2>&gt; factually,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to hopefully guide you, sensibly:-</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The main [reference] mechanism(s) at, and =
shortly after,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the time of writing OCSP IDs =
included:-</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (1) VeriSign, who used an oracle =
database-based repository to feed data</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; to OCSP deamons acting in cached and =
interactive, direct-trust</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; mode; CRLs were not involved. OCSP =
proxing/multiplexing interactive</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; direct-trust mode was&nbsp; added, shortly =
after standarization, for a</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; defense customer bridging multiple =
certification domains.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; (2) ValiCert, who used direct CRLs to feed =
data to direct/indirect OCSP</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; deamons. Indirect CRLs and CRLDPs support =
was added slightly after</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; the architects had harmonized their =
work.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Both mechanisms evolved further, outside =
of IETF and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in vendor forums, particularly in the area =
of: application</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; integration, CRLDPs and delta-CRL data =
sources, proxying</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; transaction semantics and response =
resigning, data freshness</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; signalling, and OCSP client interaction =
with X.509 and</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; PKIX-style path processing and X.509 =
applications such as</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; SSLv3/https and MTA-based automatic =
xmldsig signature</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; verification on B2B and banking protocol =
XML streams.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Historically, this work essentially =
re-designed the standardized</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; features of the &quot;distributed =
authentication model&quot; of</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; X.500 1988, for OCSP-borne queries.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Currently, VeriSign's current work in W3C =
also</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; reflects alot of the understanding on the =
required</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; semantics of realtime trust models.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Peter.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; From: Denis Pinkas</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Sent: 1/16/02 12:04 AM</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Subject: Re: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; At the time the document was written, the =
main mechanism to feed the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; information to the OCSP server was to use =
CRLs. So it seems sensible to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; think that these fields are copied from a =
CRL.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C1A040.793804B0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IGrEq28508 for ietf-pkix-bks; Fri, 18 Jan 2002 08:53:14 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IGrB328503 for <[e-mail]>; Fri, 18 Jan 2002 08:53:12 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA00801 for <[e-mail]>; Fri, 18 Jan 2002 17:53:12 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 18 Jan 2002 17:53:12 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA09280 for <[e-mail]>; Fri, 18 Jan 2002 17:53:11 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA05011 for [e-mail]; Fri, 18 Jan 2002 17:53:11 +0100 (MET)
Date: Fri, 18 Jan 2002 17:53:11 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: RE: OCSP RFC and OCSP version 2 ID
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I find it somewhat surprising to see at the same time a 
discussion to clarify how to provide OCSP information about timeliness
in the response, which I one interpret as nothing else
as one possible input to determine a 'cautionary period' 
and at the same time not believing that a certificate
status protocol could not be able to provide in an easy way
a consolidated view of this like: 

Client ask:  'Is this good now'.
Server says: 'is was good at now -5' 
             | 'It is good, last time I check was n minutes ago.' 


Peter





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IF9cp25979 for ietf-pkix-bks; Fri, 18 Jan 2002 07:09:38 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IF9a325974 for <[e-mail]>; Fri, 18 Jan 2002 07:09:36 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id QAA00114; Fri, 18 Jan 2002 16:09:29 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 18 Jan 2002 16:09:29 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id QAA08789; Fri, 18 Jan 2002 16:09:25 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id QAA04991; Fri, 18 Jan 2002 16:09:25 +0100 (MET)
Date: Fri, 18 Jan 2002 16:09:25 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP interop update
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> 
> Peter Gutmann wrote:
> > Actually this raises an interesting point, the TSP RFC says that extensions 
> > are handled just like RFC 2459 except when they're not.  In particular it 

I really like the ways you say this :-)

It was in version 3 of the draft that extensions were added, and in version 4
the following text was added:

Version 3:
   "The extensions field is a generic way to add additional information to
   the request in the future. EXTENSIONS is defined in [RFC 2459]."

Version 4:
   "The extensions field is a generic way to add additional information to 
   the request in the future. EXTENSIONS is defined in [RFC 2459]. If an 
   extension, whether it is marked critical or not critical, is used 
   by a requester but is not recognized by a time stamping server, the 
   server SHALL not issue a token and return a failure (badRequest)."

RFC 3161:
   "The extensions field is a generic way to add additional information
   to the request in the future.  Extensions is defined in [RFC 2459].
   If an extension, whether it is marked critical or not critical, is
   used by a requester but is not recognized by a time-stamping server,
   the server SHALL not issue a token and SHALL return a failure
   (unacceptedExtension)."

Well, now, what happened between September and October 1999 (V3 -> V4)

There were some messages, at least one concerning a RESPONSE, what does a
time stamp with an extension mean that has no critical bit. 

One can also interprete the actual text for the response also that all TSAs
MUST by definition able to interprete all possible extensions, and the
default implementation is to create such an error. :-) 

Unless I have overlooked something, I do not see an explanation
or announce for this change. Maybe the editors can comment ??

I tend to think that the change this additional requirement, i.e.,
the  change from 3 -> 4 is not necessary.

Peter Sylvester



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IEmfW25610 for ietf-pkix-bks; Fri, 18 Jan 2002 06:48:41 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IEme325606 for <[e-mail]>; Fri, 18 Jan 2002 06:48:40 -0800 (PST)
Received: from [128.33.238.36] (TC036.BBN.COM [128.33.238.36]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA02185 for <[e-mail]>; Fri, 18 Jan 2002 09:48:33 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100301b86de599a056@[128.33.238.69]>
Date: Fri, 18 Jan 2002 09:48:56 -0500
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: meeting minutes
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Folks,

Due to a communication problem between Tim and me, we failed to 
distribute the minutes to the list for comment, as is our usual 
practice.  We did manage to submit them to the Secretariat, just in 
time, and the slides from presentations also were submitted.  We 
apologize for this procedural error.  Herewith are tghe minutes as 
submitted to the Secretariat earlier this week:

--------

PKIX WG Meeting 12/11/01

Edited by Steve Kent

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

The PKIX WG met once during the 52nd IETF. A total of approximately 112
individuals participated in the meeting.


Tim Polk began with a review of the agenda. Two brief presentations 
on non-working group IDs were added to the end, if time permits.

Document Status Overview
	The PKIX Certificate and CRL Profile 
(draft-ietf-pkix-ipki-new-part1-11.txt), and the companion Algorithms 
document (draft-ietf-pkix-ipki-pkalgs-05.txt), have been approved by 
the IESG and is in the RFC Editor's queue. Russ Housley (RSA) 
provided more detailed discussion of the changes between these 
documents and their predecessors. Two documents, the PKIX Roadmap & 
Policy Framework, have been revised and are ready for republication 
as Informational RFCs. Three RFCs are ready for progression to Draft 
Standard status: CRMF, CMP, and OCSP(v1). CMC is expected to follow 
soon. (See slides)

Interoperability Testing - Jim Schaad (Soaring Hawk Consulting)
	Jim has constructed a matrix to document interoperability 
requirements re new-part-1. Paul Hoffman (IMC) noted that the 
requirements for progression to Draft seem to require that ALL 
options be show to be interoperable, not just the MUSTs. The 
co-chairs will seek clarification of this issue with the Security ADs.

Implementation Experience - Steve Hanna (Sun)
	Implementation experience illustrates that path validation is 
very complex.  This experience argues for ways to minimize the need 
for developers to create their own, additional implementations, e.g., 
use of DPV, use of libraries (e.g., Getronics or JSE).  Use of a 
certificate path API, in this case based on Java, also can help, and 
that is being pursued through the Java Community Process. The API 
allows for customization validation checks. Initial implementation by 
Sun does not support all the (optional) features in the final version 
of new-part-1, due to need to freeze code prior to finalization of 
that document. Steve suggests changing PKIX path validation algorithm 
to prohibit loops and ignore self-signed certificates, consistent 
with X.509 comments and a recent defect report. (See slides)

Attribute Certificate Profile - Steve Farrell (Baltimore)
	In RFC editor's queue, awaiting publication of new-part-1. No 
word yet re implementation experience for this profile.

DPV/DPD Requirements Draft - Denis Pinkas (Integris)
		This document, draft-ietf-pkix-dpd-dpv-req-00.txt, 
has been published as an ID after considerable discussion on the 
list. (Delegated digital signature validation is a separate document, 
which will be pursued separately, as noted below). Separate 
validation and discovery policies are used to control these 
respective functions at a server. Management of the policies is 
separate, and can be effected via separate protocols or locally 
(directly). This architecture allows for simple requests and 
responses, because it removes specification of the policy from these 
messages, and this is consistent with the motivations for DPV/DPD, 
based on use by constrained clients. Note use of "cautionary period" 
parameters to accommodate delays inherent in revocation mechanisms, 
both OCSP and CRLs. This approach is not a panacea, but it does 
provide a set of useful policy controls. (See slides)


DPV Protocol Draft (SCVP) - Russ Housley (RSA)
	Russ and Ambarish are working to revise SCVP to make it 
compliant with the requirements document. Discussion during the 
meeting argues for a separate document to deal with the management 
protocol, vs. the request/response protocol. Questions remain re the 
use of extensions, and their criticality. Also not yet clear how to 
reference a certificate that is not passed in the request. Issuer 
name and serial number is a poor choice for searching today, although 
it may be OK in the future for LDAP. Also not clear whether it is 
necessary to include this added complexity, for possibly minor 
bandwidth savings. Defer attribute certificate support for now. 
Another open issue is how to authenticate messages between client and 
server, which may be different for DPV vs. DPD. Finally, should SCVP 
be extended to support DPD, as well as DPV? (See slides)


Proxy Draft - Doug Engert (Argonne Labs)
	Work is continuing on this draft. A number of questions have 
been raised on the list and are being resolved. Implementations will 
be developed in 2002, as part of the Globus project.  (See slides)

Delegated Signature Validation Denis Pinkas (Integris)
	This document, draft-ietf-pkix-dsv-req-00.txt, represents a 
separate set of requirements for delegated signature validation, 
analogous to the DPV/DPD requirements work reported earlier. The 
document defines requirements for signature validation policies, and 
a request/response protocol that supports initial interaction with a 
DSV, as well as re-validation and later validation by a distinct 
third party (a different DSV server), all in support of 
non-repudiation. Note the extended time frame for DSV vs. DPD/DPV, 
i.e., DSV may often take place much later, long after a transaction, 
and after certificates associated with the transaction have expired. 
Some discussion of whether this is an appropriate new work item, 
which will be brought to the list. Agreement to keep this separate 
from DPV/DPD work. (See slides)


Supplemental Algorithms - Ari Singer (NTRU)
	This document, draft-ietf-pkix-pkalgs-supp-00.txt, describes 
additional algorithms that may be used with PKIX data (e.g., 
certificates and CRLs) and protocols, including extended DSA and SHA, 
as well as better ASN.1 for NTRU algorithms. (See slides)


LDAP documents David Chadwick (Univ. Salford)
	This LDAP v3 document, draft-ietf-pkix-ldap-v3-04.txt, has 
not changed, but since LDAP v2 is moving to historical, which 
suggests moving text from the v2 document into this document, to 
replace references to the v2 document. Ready to go to last call, 
pending resolution of this issue (reference to historical document 
vs, copying text from that document). The schema and matching rules 
document, draft-ietf-pkix-ldap-schema-02.txt, has changed from the 
previous version, adding PKI schema, changing syntax for assertions, 
and including component matching rules for attribute certificates. 
Several open issues remain to be resolved. Plan to resolve these 
issues and go for last call after summer IETF meeting. (See slides)


Policy Requirements for Time Stamping - Denis Pinkas (Integris)
	This is a proposal to take an existing ETSI document and 
publish it as an informational RFC. It is analogous to the CA policy 
RFC, and is linked to previous PKIX work, i.e., RFC 3616. Will bring 
the question to the PKIX list. (See slides)


RFC 3161 Interoperability Testing - Denis Pinkas (Integris)
	Mailing list exchanges indicate there are at least 7 
implementations available now, and this is a first step in gathering 
interoperability info pursuant to progress from Proposed to Draft 
Standard status.


Missing Link for Large PKIs- Denis Pinkas (Integris)
	This brief discussion explored the question of how one binds 
a key to a person, in the physical world. Suggestion is to develop an 
Informational RFC on this topic. Will bring this to the list. (See 
slides)


NIST Activities - Tim Polk (NIST)
	NIST, ICSA, and others interested in developing a profile for 
PKI support for IPsec. Also, a PKI R&D workshop sponsored by NIST and 
others, April 2002, at NIST.


Non-PKIX Work Items

DNS for Certificate Distribution - Simon Josephson (RSA)
	This (personal, not PKIX) document describes how to use 
DNESEC to provide a secure means of publishing and acquiring 
self-signed certificates stored there. Could be used for short-lived 
certificates or for root certificates. (See slides)


Certificate Request for Wireless Environments - Jaeho Yoon (Korean 
Information Security Agency)
	This (personal, not PKIX) document describes a proposal for a 
certificate retrieval protocol for use in wireless environments.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IEMRw25161 for ietf-pkix-bks; Fri, 18 Jan 2002 06:22:27 -0800 (PST)
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IEMO325156 for <[e-mail]>; Fri, 18 Jan 2002 06:22:24 -0800 (PST)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g0IEMKY26441; Fri, 18 Jan 2002 07:22:20 -0700 (MST)
Received: from host66160 ([216.133.92.162]) by smtp.digsigtrust.com with SMTP id g0IEKN026389; Fri, 18 Jan 2002 07:20:23 -0700 (MST)
Message-ID: <004f01c1a02b$820220e0$[e-mail]>
Reply-To: "Yuriy Dzambasow" <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: "Ambarish Malpani" <[e-mail]>, "'Deacon, Alex'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: Re: OCSP RFC and OCSP version 2 ID
Date: Fri, 18 Jan 2002 09:21:59 -0500
Organization: Digital Signature Trust
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi Ambarish,

Thank you for clarifying this.  I agree with your three potential questions
and your three responses.  Regarding item 3, I believe this should be
addressed through policy and practices, and not controlled through OCSP.

Yuriy

----- Original Message -----
From: "Ambarish Malpani" <[e-mail]>
To: "'Deacon, Alex'" <[e-mail]>; "'Santosh Chokhani'"
<[e-mail]>; <[e-mail]>
Sent: Thursday, January 17, 2002 3:13 PM
Subject: RE: OCSP RFC and OCSP version 2 ID


>
>
> Here is how I see it:
>
> There are 3 potential questions:
> 1. How current is your information (on which you based this response)
> 2. How long can/should I keep/cache/rely on this information.
> 3. How current will your information be if I ask you in the future.
>
> 1. is answered by thisUpdate
> 2. is answered by nextUpdate (where a client can still decide to
> ignore the nextUpdate field the next time it wants to know
> the status of this certificate)
> 3. is not dealt with by the RFC. I am not sure we need to deal with
> it. The only case that I can think of it being used, is where
> a client can go to multiple responders and is trying to figure
> out which one it should normally use (like they do with DNS).
> I don't think people are close to dealing with that level of
> complexity with OCSP.
>
> Hope this helps clarify the questions.
>
> A
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
> -----Original Message-----
> From: Deacon, Alex [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 11:37 AM
> To: 'Santosh Chokhani'; Ambarish Malpani; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
> OK...you guys have lost me now.  What was wrong with not including the
> nextUpdate field to specify that the server is providing real time info
and
> that the client should ask the server each time it needs the current
status?
> If a responder is providing real time status info, it can (or will) never
> know when newer status info will be available as it is impossible to know
> when a certificate will be revoked/suspended in advance.
>
> Alex
>
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 11:23 AM
> To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
> I guess today is my day (every day is my day) to make errors, deeper
> reflections and second guessing.
>
> I guess what I am saying is as follows.  Do the relying parties need to
know
> that the responder provides real-time revocation information?  Having
> thisUpdate=NOW may not prove that since this could be simply coincidence.
A
> pattern of responses may create statistical certainty.
>
> So, after all this, this question remains.  Please do not construe my
emails
> to mean that I am saying the feature is required.  I am simply posing the
> question and proposing an approach if the feature is required.
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 2:08 PM
> To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
> Upon further reflection, I think thisUpdate DOES take care of it.
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 2:01 PM
> To: Ambarish Malpani; Santosh Chokhani; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
> Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
> response is available all the time.
>
> I am trying to account for situations when the response is real-time (or
> near real-time).
> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 1:56 PM
> To: 'Santosh Chokhani'; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
>
> Santosh, why doesn't thisUpdate meet that need?
>
> A
>
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 10:31 AM
> To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
> I agree with what Ambarish and Carlisle are saying.
> I have one addition question though.  Should the standard provide a
> capability to the relying parties (OCSP clients) that the current
revocation
> information is always available. If people agree that it should, given the
> proposed meaning of nextUpdate, the additional capability can be handled
via
> a SingleResponse extension.
> -----Original Message-----
> From: Ambarish Malpani [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 11:53 AM
> To: 'Denis Pinkas'; '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
>
>
>
>
> Hi Denis,
>     Information about how up to date the information is, is
> already present in the thisUpdate field in the response.
> So, for example, if you *know* that you have information that is
> current as of 5 seconds ago, you can set that field appropriately.
> Does this meet your needs?
> Regards,
> Ambarish
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[e-mail]]
> > Sent: Thursday, January 17, 2002 8:50 AM
> > To: Ambarish Malpani
> > Cc: 'Santosh Chokhani'; '[e-mail] '
> > Subject: Re: OCSP RFC and OCSP version 2 ID
> >
> >
> > Ambarish,
> >
> > > Hi Santosh,
> > >     Give me some time.... :-)
> > >
> > > I agree with your first analysis:
> > >
> > > "If nextUpdate is not set, the responder is indicating that newer
> > > revocation information is available all the time"
> > >
> > > Actually, they way I would prefer to state it would be something
> > > like:
> >
> > > "If nextUpdate is not set, the responder is indicating that it
> > > doesn't know when newer information will be available and so, if
> > > a client wants status information on the certificate in question
> > > at a future date, it should come back and ask the server again."
> >
> > I like your proposal, since this means that when using the
> > on-line protocol
> > it is not possible to know. Now we could add a sentence that says:
> >
> > "However, the Certificate Practice Statement and the
> > Certificate Disclosure
> > Statement may provide more information about the refreshment
> > conditions of
> > the status information."
> >
> > Denis
> >
> > > This is my personal opinion. If the group agrees, I am happy to
> > > modify the document to reflect this point of view.
> > >
> > > Regards,
> > > Ambarish
> > >
> > >
> > ---------------------------------------------------------------------
> > > Ambarish Malpani
> > > Architect
> > 650.567.5457
> > > ValiCert, Inc.
> > [e-mail]
> > > 339 N. Bernardo Ave.
> http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[e-mail]]
> > Sent: Wednesday, January 16, 2002 11:50 AM
> > To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> > Cc: '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> > Why aren't the authors responding to this contradiction in the RFC and
> > carried out in the ID?
> > -----Original Message-----
> > From: Peter Williams [mailto:[e-mail]]
> > Sent: Wednesday, January 16, 2002 2:41 PM
> > To: 'Denis Pinkas '; 'Santosh Chokhani '
> > Cc: '[e-mail] '
> > Subject: RE: OCSP RFC and OCSP version 2 ID
> >
> > Denis,
> > You refer to an assumed  "main mechanism" in your note. Speaking
> factually,
> > to hopefully guide you, sensibly:-
> > The main [reference] mechanism(s) at, and shortly after,
> > the time of writing OCSP IDs included:-
> > (1) VeriSign, who used an oracle database-based repository to feed data
> > to OCSP deamons acting in cached and interactive, direct-trust
> > mode; CRLs were not involved. OCSP proxing/multiplexing interactive
> > direct-trust mode was  added, shortly after standarization, for a
> > defense customer bridging multiple certification domains.
> > (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP
> > deamons. Indirect CRLs and CRLDPs support was added slightly after
> > the architects had harmonized their work.
> > Both mechanisms evolved further, outside of IETF and
> > in vendor forums, particularly in the area of: application
> > integration, CRLDPs and delta-CRL data sources, proxying
> > transaction semantics and response resigning, data freshness
> > signalling, and OCSP client interaction with X.509 and
> > PKIX-style path processing and X.509 applications such as
> > SSLv3/https and MTA-based automatic xmldsig signature
> > verification on B2B and banking protocol XML streams.
> > Historically, this work essentially re-designed the standardized
> > features of the "distributed authentication model" of
> > X.500 1988, for OCSP-borne queries.
> > Currently, VeriSign's current work in W3C also
> > reflects alot of the understanding on the required
> > semantics of realtime trust models.
> > Peter.
> > -----Original Message-----
> > From: Denis Pinkas
> > To: Santosh Chokhani
> > Cc: [e-mail]
> > Sent: 1/16/02 12:04 AM
> > Subject: Re: OCSP RFC and OCSP version 2 ID
> > At the time the document was written, the main mechanism to feed the
> > information to the OCSP server was to use CRLs. So it seems sensible to
> > think that these fields are copied from a CRL.
> >
>



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0IAX0312326 for ietf-pkix-bks; Fri, 18 Jan 2002 02:33:00 -0800 (PST)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0IAWu312314 for <[e-mail]>; Fri, 18 Jan 2002 02:32:57 -0800 (PST)
Received: from tho.andxor.com (tho.andxor.it [195.223.2.222]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id LAA99512; Fri, 18 Jan 2002 11:32:54 +0100 (CET) (envelope-from [e-mail])
Received: (from tho@localhost) by tho.andxor.com (8.11.6/8.11.6) id g0IBa0622622; Fri, 18 Jan 2002 11:36:00 GMT (envelope-from tho)
Date: Fri, 18 Jan 2002 11:36:00 +0000
From: tho <[e-mail]>
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: TSP interop update
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Jan 18, 2002 at 04:51:05PM +1300
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Gutmann wrote:
> Actually this raises an interesting point, the TSP RFC says that extensions 
> are handled just like RFC 2459 except when they're not.  In particular it 
> says you should reject all extensions which you don't recognise.  This can be
> interpreted to mean anything, at the moment I reject all extensions which 
> don't seem to make any sense in a request (which means almost all of them), 
> however taking the interpretation of "recognise" -> "it's valid ASN.1 and has
> an OID" then I could just as easily accept any extensions (or ignore them).  
> What are other people doing?  I'll probably change the code to follow the 
> "be generous with ..." rule of thumb, which means I'll ignore extensions.  
> The RFC doesn't specify any particular extensions which you have to 
> (MUST/SHALL/SHOULD) handle and says the critical bit is ignored (in violation
> of RFC 2459), so it looks like accepting/ignoring anything that you 
> "recognise" is fine.

from rfc3161:

   "The extensions field is a generic way to add additional information
    to the request in the future"

this seems to mean that the primary use of the extension field is expanding
the semantics of the tsp protocol. 

so I think that if the TSA doesn't understand the _semantics_ (not the syntax)
of the extension it "SHALL not issue a token and SHALL return a failure
(unacceptedExtension)." 

ciao, tho
--


Received: by above.proper.com (8.11.6/8.11.3) id g0I9TDI03655 for ietf-pkix-bks; Fri, 18 Jan 2002 01:29:13 -0800 (PST)
Received: from carbone.certplus.com ([195.101.88.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I9TC303651 for <[e-mail]>; Fri, 18 Jan 2002 01:29:12 -0800 (PST)
Received: from certplus.com ([192.168.212.27]) by carbone.certplus.com with Microsoft SMTPSVC(5.0.2195.2966); Fri, 18 Jan 2002 10:25:00 +0100
Message-ID: <[e-mail]>
Date: Fri, 18 Jan 2002 10:25:10 +0100
From: Jean-Marc Desperrier <[e-mail]>
Organization: Certplus
X-Mailer: Mozilla 4.75 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: TSP interop update
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 18 Jan 2002 09:25:00.0965 (UTC) FILETIME=[00F6FD50:01C1A002]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Gutmann wrote:

> The RFC doesn't
> specify any particular extensions which you have to (MUST/SHALL/SHOULD) handle
> and says the critical bit is ignored (in violation of RFC 2459), so it looks
> like accepting/ignoring anything that you "recognise" is fine.

The text in the RFC sounds a lot more like any extension should be handled as if it
had the critical flag, and the request rejected if you don't know exactly the
meaning of the extension.



Received: by above.proper.com (8.11.6/8.11.3) id g0I3sSW08219 for ietf-pkix-bks; Thu, 17 Jan 2002 19:54:28 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0I3sQ308215 for <[e-mail]>; Thu, 17 Jan 2002 19:54:26 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id QAA25746; Fri, 18 Jan 2002 16:51:06 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA465571; Fri, 18 Jan 2002 16:51:05 +1300 (NZDT) (sender [e-mail])
Date: Fri, 18 Jan 2002 16:51:05 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  TSP interop update
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Joe Morgan <[e-mail]> writes:

>Just a quick update on our progress with TSP interop testing.

Actually this raises an interesting point, the TSP RFC says that extensions are
handled just like RFC 2459 except when they're not.  In particular it says you
should reject all extensions which you don't recognise.  This can be
interpreted to mean anything, at the moment I reject all extensions which don't
seem to make any sense in a request (which means almost all of them), however
taking the interpretation of "recognise" -> "it's valid ASN.1 and has an OID"
then I could just as easily accept any extensions (or ignore them).  What are
other people doing?  I'll probably change the code to follow the "be generous
with ..." rule of thumb, which means I'll ignore extensions.  The RFC doesn't
specify any particular extensions which you have to (MUST/SHALL/SHOULD) handle
and says the critical bit is ignored (in violation of RFC 2459), so it looks
like accepting/ignoring anything that you "recognise" is fine.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g0HN3RF00868 for ietf-pkix-bks; Thu, 17 Jan 2002 15:03:27 -0800 (PST)
Received: from mail1.microsoft.com (mail1.microsoft.com [131.107.3.125]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HN3P300861 for <[e-mail]>; Thu, 17 Jan 2002 15:03:25 -0800 (PST)
Received: from inet-vrs-01.redmond.corp.microsoft.com ([157.54.8.27]) by mail1.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Thu, 17 Jan 2002 15:03:22 -0800
Received: from 157.54.5.25 by inet-vrs-01.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 17 Jan 2002 15:03:21 -0800
Received: from red-imc-04.redmond.corp.microsoft.com ([157.54.2.168]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Jan 2002 15:03:21 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-04.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 17 Jan 2002 15:03:21 -0800
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Thu, 17 Jan 2002 15:01:15 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6132.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: Cautionary Period Straw Poll
Date: Thu, 17 Jan 2002 15:01:16 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Cautionary Period Straw Poll
Thread-Index: AcGfqyeHkcVvlza1QBy9caGmGC9Ldw==
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 17 Jan 2002 23:01:15.0430 (UTC) FILETIME=[DD9B8C60:01C19FAA]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0HN3P300862
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I believe that DPV protocols developed by the PKIX working group ought
not include support for a cautionary period.

Trevor


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HKSB726291 for ietf-pkix-bks; Thu, 17 Jan 2002 12:28:11 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HKSA326287 for <[e-mail]>; Thu, 17 Jan 2002 12:28:10 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <D1BG83HZ>; Thu, 17 Jan 2002 15:28:07 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B648@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: Ambarish Malpani <[e-mail]>, "'Deacon, Alex'" <[e-mail]>, Santosh Chokhani <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 15:26:52 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19F95.4CA5C3C0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C19F95.4CA5C3C0
Content-Type: text/plain;
	charset="iso-8859-1"

Ambarish:

I can buy that.  Item 3 is not so cut and dried.  It can imagine when the
server wants to say, do not cache the information and come to me each time
for the latest.  The client may need to know that and service needs a way to
adverstise that.

Again, I am not saying that RFC should address this.  I am just bringing up
the potential need.  Of course, client can do this on its own for any high
value transaction and not cache.

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 3:14 PM
To: 'Deacon, Alex'; 'Santosh Chokhani'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID




Here is how I see it:

There are 3 potential questions:
1. How current is your information (on which you based this response)
2. How long can/should I keep/cache/rely on this information.
3. How current will your information be if I ask you in the future.

1. is answered by thisUpdate
2. is answered by nextUpdate (where a client can still decide to
	ignore the nextUpdate field the next time it wants to know
	the status of this certificate)
3. is not dealt with by the RFC. I am not sure we need to deal with
	it. The only case that I can think of it being used, is where
	a client can go to multiple responders and is trying to figure
	out which one it should normally use (like they do with DNS).
	I don't think people are close to dealing with that level of
	complexity with OCSP.

Hope this helps clarify the questions.

A

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Deacon, Alex [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 11:37 AM
To: 'Santosh Chokhani'; Ambarish Malpani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


OK...you guys have lost me now.  What was wrong with not including the
nextUpdate field to specify that the server is providing real time info and
that the client should ask the server each time it needs the current status?
If a responder is providing real time status info, it can (or will) never
know when newer status info will be available as it is impossible to know
when a certificate will be revoked/suspended in advance. 
 
Alex
 
-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 11:23 AM
To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


I guess today is my day (every day is my day) to make errors, deeper
reflections and second guessing.
 
I guess what I am saying is as follows.  Do the relying parties need to know
that the responder provides real-time revocation information?  Having
thisUpdate=NOW may not prove that since this could be simply coincidence.  A
pattern of responses may create statistical certainty.
 
So, after all this, this question remains.  Please do not construe my emails
to mean that I am saying the feature is required.  I am simply posing the
question and proposing an approach if the feature is required.
-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 2:08 PM
To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Upon further reflection, I think thisUpdate DOES take care of it.
-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
response is available all the time.
 
I am trying to account for situations when the response is real-time (or
near real-time).
-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID



Santosh, why doesn't thisUpdate meet that need?
 
A

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


I agree with what Ambarish and Carlisle are saying. 
I have one addition question though.  Should the standard provide a
capability to the relying parties (OCSP clients) that the current revocation
information is always available. If people agree that it should, given the
proposed meaning of nextUpdate, the additional capability can be handled via
a SingleResponse extension.
-----Original Message----- 
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; '[e-mail] ' 
Subject: RE: OCSP RFC and OCSP version 2 ID 




Hi Denis, 
    Information about how up to date the information is, is 
already present in the thisUpdate field in the response. 
So, for example, if you *know* that you have information that is 
current as of 5 seconds ago, you can set that field appropriately. 
Does this meet your needs? 
Regards, 
Ambarish 
--------------------------------------------------------------------- 
Ambarish Malpani 
Architect                                                650.567.5457 
ValiCert, Inc.                                  [e-mail] 
339 N. Bernardo Ave.                          http://www.valicert.com 
Mountain View, CA 94043 


> -----Original Message----- 
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; '[e-mail] ' 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> 
> 
> Ambarish, 
> 
> > Hi Santosh, 
> >     Give me some time.... :-) 
> > 
> > I agree with your first analysis: 
> > 
> > "If nextUpdate is not set, the responder is indicating that newer 
> > revocation information is available all the time" 
> > 
> > Actually, they way I would prefer to state it would be something 
> > like: 
> 
> > "If nextUpdate is not set, the responder is indicating that it 
> > doesn't know when newer information will be available and so, if 
> > a client wants status information on the certificate in question 
> > at a future date, it should come back and ask the server again." 
> 
> I like your proposal, since this means that when using the 
> on-line protocol 
> it is not possible to know. Now we could add a sentence that says: 
> 
> "However, the Certificate Practice Statement and the 
> Certificate Disclosure 
> Statement may provide more information about the refreshment 
> conditions of 
> the status information." 
>  
> Denis 
> 
> > This is my personal opinion. If the group agrees, I am happy to 
> > modify the document to reflect this point of view. 
> > 
> > Regards, 
> > Ambarish 
> > 
> > 
> --------------------------------------------------------------------- 
> > Ambarish Malpani 
> > Architect                                                
> 650.567.5457 
> > ValiCert, Inc.                                  
> [e-mail] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com 
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [mailto:[e-mail]] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Why aren't the authors responding to this contradiction in the RFC and 
> carried out in the ID? 
> -----Original Message----- 
> From: Peter Williams [mailto:[e-mail]] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Denis, 
> You refer to an assumed  "main mechanism" in your note. Speaking 
factually, 
> to hopefully guide you, sensibly:- 
> The main [reference] mechanism(s) at, and shortly after, 
> the time of writing OCSP IDs included:- 
> (1) VeriSign, who used an oracle database-based repository to feed data 
> to OCSP deamons acting in cached and interactive, direct-trust 
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive 
> direct-trust mode was  added, shortly after standarization, for a 
> defense customer bridging multiple certification domains. 
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP 
> deamons. Indirect CRLs and CRLDPs support was added slightly after 
> the architects had harmonized their work. 
> Both mechanisms evolved further, outside of IETF and 
> in vendor forums, particularly in the area of: application 
> integration, CRLDPs and delta-CRL data sources, proxying 
> transaction semantics and response resigning, data freshness 
> signalling, and OCSP client interaction with X.509 and 
> PKIX-style path processing and X.509 applications such as 
> SSLv3/https and MTA-based automatic xmldsig signature 
> verification on B2B and banking protocol XML streams. 
> Historically, this work essentially re-designed the standardized 
> features of the "distributed authentication model" of 
> X.500 1988, for OCSP-borne queries. 
> Currently, VeriSign's current work in W3C also 
> reflects alot of the understanding on the required 
> semantics of realtime trust models. 
> Peter. 
> -----Original Message----- 
> From: Denis Pinkas 
> To: Santosh Chokhani 
> Cc: [e-mail] 
> Sent: 1/16/02 12:04 AM 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> At the time the document was written, the main mechanism to feed the 
> information to the OCSP server was to use CRLs. So it seems sensible to 
> think that these fields are copied from a CRL. 
> 

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ambarish:</FONT>
</P>

<P><FONT SIZE=3D2>I can buy that.&nbsp; Item 3 is not so cut and =
dried.&nbsp; It can imagine when the server wants to say, do not cache =
the information and come to me each time for the latest.&nbsp; The =
client may need to know that and service needs a way to adverstise =
that.</FONT></P>

<P><FONT SIZE=3D2>Again, I am not saying that RFC should address =
this.&nbsp; I am just bringing up the potential need.&nbsp; Of course, =
client can do this on its own for any high value transaction and not =
cache.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ambarish Malpani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 3:14 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Deacon, Alex'; 'Santosh Chokhani'; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Here is how I see it:</FONT>
</P>

<P><FONT SIZE=3D2>There are 3 potential questions:</FONT>
<BR><FONT SIZE=3D2>1. How current is your information (on which you =
based this response)</FONT>
<BR><FONT SIZE=3D2>2. How long can/should I keep/cache/rely on this =
information.</FONT>
<BR><FONT SIZE=3D2>3. How current will your information be if I ask you =
in the future.</FONT>
</P>

<P><FONT SIZE=3D2>1. is answered by thisUpdate</FONT>
<BR><FONT SIZE=3D2>2. is answered by nextUpdate (where a client can =
still decide to</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>ignore =
the nextUpdate field the next time it wants to know</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>the =
status of this certificate)</FONT>
<BR><FONT SIZE=3D2>3. is not dealt with by the RFC. I am not sure we =
need to deal with</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>it. The =
only case that I can think of it being used, is where</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>a client =
can go to multiple responders and is trying to figure</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>out which =
one it should normally use (like they do with DNS).</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2>I don't =
think people are close to dealing with that level of</FONT>
<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT =
SIZE=3D2>complexity with OCSP.</FONT>
</P>

<P><FONT SIZE=3D2>Hope this helps clarify the questions.</FONT>
</P>

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

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
------</FONT>
<BR><FONT SIZE=3D2>Ambarish Malpani</FONT>
<BR><FONT =
SIZE=3D2>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>Mountain View, CA 94043</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Deacon, Alex [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 11:37 AM</FONT>
<BR><FONT SIZE=3D2>To: 'Santosh Chokhani'; Ambarish Malpani; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>OK...you guys have lost me now.&nbsp; What was wrong =
with not including the</FONT>
<BR><FONT SIZE=3D2>nextUpdate field to specify that the server is =
providing real time info and</FONT>
<BR><FONT SIZE=3D2>that the client should ask the server each time it =
needs the current status?</FONT>
<BR><FONT SIZE=3D2>If a responder is providing real time status info, =
it can (or will) never</FONT>
<BR><FONT SIZE=3D2>know when newer status info will be available as it =
is impossible to know</FONT>
<BR><FONT SIZE=3D2>when a certificate will be revoked/suspended in =
advance. </FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>Alex</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 11:23 AM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani; Ambarish Malpani; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I guess today is my day (every day is my day) to make =
errors, deeper</FONT>
<BR><FONT SIZE=3D2>reflections and second guessing.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>I guess what I am saying is as follows.&nbsp; Do the =
relying parties need to know</FONT>
<BR><FONT SIZE=3D2>that the responder provides real-time revocation =
information?&nbsp; Having</FONT>
<BR><FONT SIZE=3D2>thisUpdate=3DNOW may not prove that since this could =
be simply coincidence.&nbsp; A</FONT>
<BR><FONT SIZE=3D2>pattern of responses may create statistical =
certainty.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>So, after all this, this question remains.&nbsp; =
Please do not construe my emails</FONT>
<BR><FONT SIZE=3D2>to mean that I am saying the feature is =
required.&nbsp; I am simply posing the</FONT>
<BR><FONT SIZE=3D2>question and proposing an approach if the feature is =
required.</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 2:08 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani; Ambarish Malpani; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Upon further reflection, I think thisUpdate DOES take =
care of it.</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 2:01 PM</FONT>
<BR><FONT SIZE=3D2>To: Ambarish Malpani; Santosh Chokhani; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Ambarish: Are you suggesting that when =
thisUpdate=3DnextUpdate that means</FONT>
<BR><FONT SIZE=3D2>response is available all the time.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>I am trying to account for situations when the =
response is real-time (or</FONT>
<BR><FONT SIZE=3D2>near real-time).</FONT>
<BR><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ambarish Malpani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 1:56 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Santosh Chokhani'; '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>Santosh, why doesn't thisUpdate meet that =
need?</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>A</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
------</FONT>
<BR><FONT SIZE=3D2>Ambarish Malpani</FONT>
<BR><FONT =
SIZE=3D2>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>Mountain View, CA 94043</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 10:31 AM</FONT>
<BR><FONT SIZE=3D2>To: Ambarish Malpani; 'Denis Pinkas'; =
'[e-mail] '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>I agree with what Ambarish and Carlisle are saying. =
</FONT>
<BR><FONT SIZE=3D2>I have one addition question though.&nbsp; Should =
the standard provide a</FONT>
<BR><FONT SIZE=3D2>capability to the relying parties (OCSP clients) =
that the current revocation</FONT>
<BR><FONT SIZE=3D2>information is always available. If people agree =
that it should, given the</FONT>
<BR><FONT SIZE=3D2>proposed meaning of nextUpdate, the additional =
capability can be handled via</FONT>
<BR><FONT SIZE=3D2>a SingleResponse extension.</FONT>
<BR><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Ambarish Malpani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 11:53 AM </FONT>
<BR><FONT SIZE=3D2>To: 'Denis Pinkas'; '[e-mail] ' </FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID </FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi Denis, </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Information about how up to date =
the information is, is </FONT>
<BR><FONT SIZE=3D2>already present in the thisUpdate field in the =
response. </FONT>
<BR><FONT SIZE=3D2>So, for example, if you *know* that you have =
information that is </FONT>
<BR><FONT SIZE=3D2>current as of 5 seconds ago, you can set that field =
appropriately. </FONT>
<BR><FONT SIZE=3D2>Does this meet your needs? </FONT>
<BR><FONT SIZE=3D2>Regards, </FONT>
<BR><FONT SIZE=3D2>Ambarish </FONT>
<BR><FONT =
SIZE=3D2>---------------------------------------------------------------=
------ </FONT>
<BR><FONT SIZE=3D2>Ambarish Malpani </FONT>
<BR><FONT =
SIZE=3D2>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; 650.567.5457 </FONT>
<BR><FONT SIZE=3D2>ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail] </FONT>
<BR><FONT SIZE=3D2>339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A> </FONT>
<BR><FONT SIZE=3D2>Mountain View, CA 94043 </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] =
</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 17, 2002 8:50 AM =
</FONT>
<BR><FONT SIZE=3D2>&gt; To: Ambarish Malpani </FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Santosh Chokhani'; '[e-mail] ' =
</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: OCSP RFC and OCSP version 2 ID =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Ambarish, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi Santosh, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Give me some =
time.... :-) </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I agree with your first analysis: </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;If nextUpdate is not set, the =
responder is indicating that newer </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; revocation information is available all =
the time&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Actually, they way I would prefer to state =
it would be something </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; like: </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;If nextUpdate is not set, the =
responder is indicating that it </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; doesn't know when newer information will =
be available and so, if </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; a client wants status information on the =
certificate in question </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; at a future date, it should come back and =
ask the server again.&quot; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I like your proposal, since this means that =
when using the </FONT>
<BR><FONT SIZE=3D2>&gt; on-line protocol </FONT>
<BR><FONT SIZE=3D2>&gt; it is not possible to know. Now we could add a =
sentence that says: </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;However, the Certificate Practice =
Statement and the </FONT>
<BR><FONT SIZE=3D2>&gt; Certificate Disclosure </FONT>
<BR><FONT SIZE=3D2>&gt; Statement may provide more information about =
the refreshment </FONT>
<BR><FONT SIZE=3D2>&gt; conditions of </FONT>
<BR><FONT SIZE=3D2>&gt; the status information.&quot; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This is my personal opinion. If the group =
agrees, I am happy to </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; modify the document to reflect this point =
of view. </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regards, </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ambarish </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
--------------------------------------------------------------------- =
</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ambarish Malpani </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; </FONT>
<BR><FONT SIZE=3D2>&gt; 650.567.5457 </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; [e-mail] </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A> </FONT>
<BR><FONT SIZE=3D2>&gt; Mountain View, CA 94043 </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] =
</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, January 16, 2002 11:50 AM =
</FONT>
<BR><FONT SIZE=3D2>&gt; To: Peter Williams; 'Denis Pinkas '; Santosh =
Chokhani </FONT>
<BR><FONT SIZE=3D2>&gt; Cc: '[e-mail] ' </FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 ID =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Why aren't the authors responding to this =
contradiction in the RFC and </FONT>
<BR><FONT SIZE=3D2>&gt; carried out in the ID? </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; From: Peter Williams [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] =
</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, January 16, 2002 2:41 PM =
</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Denis Pinkas '; 'Santosh Chokhani ' =
</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: '[e-mail] ' </FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 ID =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis, </FONT>
<BR><FONT SIZE=3D2>&gt; You refer to an assumed&nbsp; &quot;main =
mechanism&quot; in your note. Speaking </FONT>
<BR><FONT SIZE=3D2>factually, </FONT>
<BR><FONT SIZE=3D2>&gt; to hopefully guide you, sensibly:- </FONT>
<BR><FONT SIZE=3D2>&gt; The main [reference] mechanism(s) at, and =
shortly after, </FONT>
<BR><FONT SIZE=3D2>&gt; the time of writing OCSP IDs included:- </FONT>
<BR><FONT SIZE=3D2>&gt; (1) VeriSign, who used an oracle database-based =
repository to feed data </FONT>
<BR><FONT SIZE=3D2>&gt; to OCSP deamons acting in cached and =
interactive, direct-trust </FONT>
<BR><FONT SIZE=3D2>&gt; mode; CRLs were not involved. OCSP =
proxing/multiplexing interactive </FONT>
<BR><FONT SIZE=3D2>&gt; direct-trust mode was&nbsp; added, shortly =
after standarization, for a </FONT>
<BR><FONT SIZE=3D2>&gt; defense customer bridging multiple =
certification domains. </FONT>
<BR><FONT SIZE=3D2>&gt; (2) ValiCert, who used direct CRLs to feed data =
to direct/indirect OCSP </FONT>
<BR><FONT SIZE=3D2>&gt; deamons. Indirect CRLs and CRLDPs support was =
added slightly after </FONT>
<BR><FONT SIZE=3D2>&gt; the architects had harmonized their work. =
</FONT>
<BR><FONT SIZE=3D2>&gt; Both mechanisms evolved further, outside of =
IETF and </FONT>
<BR><FONT SIZE=3D2>&gt; in vendor forums, particularly in the area of: =
application </FONT>
<BR><FONT SIZE=3D2>&gt; integration, CRLDPs and delta-CRL data sources, =
proxying </FONT>
<BR><FONT SIZE=3D2>&gt; transaction semantics and response resigning, =
data freshness </FONT>
<BR><FONT SIZE=3D2>&gt; signalling, and OCSP client interaction with =
X.509 and </FONT>
<BR><FONT SIZE=3D2>&gt; PKIX-style path processing and X.509 =
applications such as </FONT>
<BR><FONT SIZE=3D2>&gt; SSLv3/https and MTA-based automatic xmldsig =
signature </FONT>
<BR><FONT SIZE=3D2>&gt; verification on B2B and banking protocol XML =
streams. </FONT>
<BR><FONT SIZE=3D2>&gt; Historically, this work essentially re-designed =
the standardized </FONT>
<BR><FONT SIZE=3D2>&gt; features of the &quot;distributed =
authentication model&quot; of </FONT>
<BR><FONT SIZE=3D2>&gt; X.500 1988, for OCSP-borne queries. </FONT>
<BR><FONT SIZE=3D2>&gt; Currently, VeriSign's current work in W3C also =
</FONT>
<BR><FONT SIZE=3D2>&gt; reflects alot of the understanding on the =
required </FONT>
<BR><FONT SIZE=3D2>&gt; semantics of realtime trust models. </FONT>
<BR><FONT SIZE=3D2>&gt; Peter. </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message----- </FONT>
<BR><FONT SIZE=3D2>&gt; From: Denis Pinkas </FONT>
<BR><FONT SIZE=3D2>&gt; To: Santosh Chokhani </FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [e-mail] </FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 1/16/02 12:04 AM </FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: OCSP RFC and OCSP version 2 ID =
</FONT>
<BR><FONT SIZE=3D2>&gt; At the time the document was written, the main =
mechanism to feed the </FONT>
<BR><FONT SIZE=3D2>&gt; information to the OCSP server was to use CRLs. =
So it seems sensible to </FONT>
<BR><FONT SIZE=3D2>&gt; think that these fields are copied from a CRL. =
</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19F95.4CA5C3C0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HKDiM26020 for ietf-pkix-bks; Thu, 17 Jan 2002 12:13:44 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HKDh326013 for <[e-mail]>; Thu, 17 Jan 2002 12:13:43 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 17 Jan 2002 12:13:44 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 17 Jan 2002 12:13:44 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <C2FYW9YR>; Thu, 17 Jan 2002 12:13:41 -0800
Content-return: allowed
Date: Thu, 17 Jan 2002 12:13:32 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'Deacon, Alex'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Here is how I see it:

There are 3 potential questions:
1. How current is your information (on which you based this response)
2. How long can/should I keep/cache/rely on this information.
3. How current will your information be if I ask you in the future.

1. is answered by thisUpdate
2. is answered by nextUpdate (where a client can still decide to
	ignore the nextUpdate field the next time it wants to know
	the status of this certificate)
3. is not dealt with by the RFC. I am not sure we need to deal with
	it. The only case that I can think of it being used, is where
	a client can go to multiple responders and is trying to figure
	out which one it should normally use (like they do with DNS).
	I don't think people are close to dealing with that level of
	complexity with OCSP.

Hope this helps clarify the questions.

A

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Deacon, Alex [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 11:37 AM
To: 'Santosh Chokhani'; Ambarish Malpani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


OK...you guys have lost me now.  What was wrong with not including the
nextUpdate field to specify that the server is providing real time info and
that the client should ask the server each time it needs the current status?
If a responder is providing real time status info, it can (or will) never
know when newer status info will be available as it is impossible to know
when a certificate will be revoked/suspended in advance. 
 
Alex
 
-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 11:23 AM
To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


I guess today is my day (every day is my day) to make errors, deeper
reflections and second guessing.
 
I guess what I am saying is as follows.  Do the relying parties need to know
that the responder provides real-time revocation information?  Having
thisUpdate=NOW may not prove that since this could be simply coincidence.  A
pattern of responses may create statistical certainty.
 
So, after all this, this question remains.  Please do not construe my emails
to mean that I am saying the feature is required.  I am simply posing the
question and proposing an approach if the feature is required.
-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 2:08 PM
To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Upon further reflection, I think thisUpdate DOES take care of it.
-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
response is available all the time.
 
I am trying to account for situations when the response is real-time (or
near real-time).
-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID



Santosh, why doesn't thisUpdate meet that need?
 
A

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


I agree with what Ambarish and Carlisle are saying. 
I have one addition question though.  Should the standard provide a
capability to the relying parties (OCSP clients) that the current revocation
information is always available. If people agree that it should, given the
proposed meaning of nextUpdate, the additional capability can be handled via
a SingleResponse extension.
-----Original Message----- 
From: Ambarish Malpani [mailto:[e-mail]] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; '[e-mail] ' 
Subject: RE: OCSP RFC and OCSP version 2 ID 




Hi Denis, 
    Information about how up to date the information is, is 
already present in the thisUpdate field in the response. 
So, for example, if you *know* that you have information that is 
current as of 5 seconds ago, you can set that field appropriately. 
Does this meet your needs? 
Regards, 
Ambarish 
--------------------------------------------------------------------- 
Ambarish Malpani 
Architect                                                650.567.5457 
ValiCert, Inc.                                  [e-mail] 
339 N. Bernardo Ave.                          http://www.valicert.com 
Mountain View, CA 94043 


> -----Original Message----- 
> From: Denis Pinkas [mailto:[e-mail]] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; '[e-mail] ' 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> 
> 
> Ambarish, 
> 
> > Hi Santosh, 
> >     Give me some time.... :-) 
> > 
> > I agree with your first analysis: 
> > 
> > "If nextUpdate is not set, the responder is indicating that newer 
> > revocation information is available all the time" 
> > 
> > Actually, they way I would prefer to state it would be something 
> > like: 
> 
> > "If nextUpdate is not set, the responder is indicating that it 
> > doesn't know when newer information will be available and so, if 
> > a client wants status information on the certificate in question 
> > at a future date, it should come back and ask the server again." 
> 
> I like your proposal, since this means that when using the 
> on-line protocol 
> it is not possible to know. Now we could add a sentence that says: 
> 
> "However, the Certificate Practice Statement and the 
> Certificate Disclosure 
> Statement may provide more information about the refreshment 
> conditions of 
> the status information." 
>  
> Denis 
> 
> > This is my personal opinion. If the group agrees, I am happy to 
> > modify the document to reflect this point of view. 
> > 
> > Regards, 
> > Ambarish 
> > 
> > 
> --------------------------------------------------------------------- 
> > Ambarish Malpani 
> > Architect                                                
> 650.567.5457 
> > ValiCert, Inc.                                  
> [e-mail] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com 
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [mailto:[e-mail]] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Why aren't the authors responding to this contradiction in the RFC and 
> carried out in the ID? 
> -----Original Message----- 
> From: Peter Williams [mailto:[e-mail]] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Denis, 
> You refer to an assumed  "main mechanism" in your note. Speaking 
factually, 
> to hopefully guide you, sensibly:- 
> The main [reference] mechanism(s) at, and shortly after, 
> the time of writing OCSP IDs included:- 
> (1) VeriSign, who used an oracle database-based repository to feed data 
> to OCSP deamons acting in cached and interactive, direct-trust 
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive 
> direct-trust mode was  added, shortly after standarization, for a 
> defense customer bridging multiple certification domains. 
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP 
> deamons. Indirect CRLs and CRLDPs support was added slightly after 
> the architects had harmonized their work. 
> Both mechanisms evolved further, outside of IETF and 
> in vendor forums, particularly in the area of: application 
> integration, CRLDPs and delta-CRL data sources, proxying 
> transaction semantics and response resigning, data freshness 
> signalling, and OCSP client interaction with X.509 and 
> PKIX-style path processing and X.509 applications such as 
> SSLv3/https and MTA-based automatic xmldsig signature 
> verification on B2B and banking protocol XML streams. 
> Historically, this work essentially re-designed the standardized 
> features of the "distributed authentication model" of 
> X.500 1988, for OCSP-borne queries. 
> Currently, VeriSign's current work in W3C also 
> reflects alot of the understanding on the required 
> semantics of realtime trust models. 
> Peter. 
> -----Original Message----- 
> From: Denis Pinkas 
> To: Santosh Chokhani 
> Cc: [e-mail] 
> Sent: 1/16/02 12:04 AM 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> At the time the document was written, the main mechanism to feed the 
> information to the OCSP server was to use CRLs. So it seems sensible to 
> think that these fields are copied from a CRL. 
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HJfrd25042 for ietf-pkix-bks; Thu, 17 Jan 2002 11:41:53 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HJfp325038 for <[e-mail]>; Thu, 17 Jan 2002 11:41:51 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <D1BG8NNL>; Thu, 17 Jan 2002 14:41:48 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B636@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: "Deacon, Alex" <[e-mail]>, Santosh Chokhani <[e-mail]>, Ambarish Malpani <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 14:40:34 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19F8E.D47A1EB0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C19F8E.D47A1EB0
Content-Type: text/plain;
	charset="iso-8859-1"

Because, if we use that semantics, and the server does not get nextUpdate
from the CA CRL, what will it do?
 
By the way, since 2459 and son of 2459 require nextUpdate to be present, I
do not have a problem with this interpretation.  It will mean a compliant
OCSP responder can not take CRL from a CA that is not compliant with 2459.
 
I just want the issue resolved and contradiction in the RFC removed.

-----Original Message-----
From: Deacon, Alex [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 2:37 PM
To: 'Santosh Chokhani'; Ambarish Malpani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


OK...you guys have lost me now.  What was wrong with not including the
nextUpdate field to specify that the server is providing real time info and
that the client should ask the server each time it needs the current status?
If a responder is providing real time status info, it can (or will) never
know when newer status info will be available as it is impossible to know
when a certificate will be revoked/suspended in advance. 
 
Alex
 

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 11:23 AM
To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


I guess today is my day (every day is my day) to make errors, deeper
reflections and second guessing.
 
I guess what I am saying is as follows.  Do the relying parties need to know
that the responder provides real-time revocation information?  Having
thisUpdate=NOW may not prove that since this could be simply coincidence.  A
pattern of responses may create statistical certainty.
 
So, after all this, this question remains.  Please do not construe my emails
to mean that I am saying the feature is required.  I am simply posing the
question and proposing an approach if the feature is required.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 2:08 PM
To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Upon further reflection, I think thisUpdate DOES take care of it.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
response is available all the time.
 
I am trying to account for situations when the response is real-time (or
near real-time).

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


 
Santosh, why doesn't thisUpdate meet that need?
 
A
 

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID



I agree with what Ambarish and Carlisle are saying. 

I have one addition question though.  Should the standard provide a
capability to the relying parties (OCSP clients) that the current revocation
information is always available. If people agree that it should, given the
proposed meaning of nextUpdate, the additional capability can be handled via
a SingleResponse extension.

-----Original Message----- 
From: Ambarish Malpani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; '[e-mail] ' 
Subject: RE: OCSP RFC and OCSP version 2 ID 




Hi Denis, 
    Information about how up to date the information is, is 
already present in the thisUpdate field in the response. 

So, for example, if you *know* that you have information that is 
current as of 5 seconds ago, you can set that field appropriately. 

Does this meet your needs? 

Regards, 
Ambarish 

--------------------------------------------------------------------- 
Ambarish Malpani 
Architect                                                650.567.5457 
ValiCert, Inc.                                  [e-mail] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 


> -----Original Message----- 
> From: Denis Pinkas [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; '[e-mail] ' 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> 
> 
> Ambarish, 
> 
> > Hi Santosh, 
> >     Give me some time.... :-) 
> > 
> > I agree with your first analysis: 
> > 
> > "If nextUpdate is not set, the responder is indicating that newer 
> > revocation information is available all the time" 
> > 
> > Actually, they way I would prefer to state it would be something 
> > like: 
> 
> > "If nextUpdate is not set, the responder is indicating that it 
> > doesn't know when newer information will be available and so, if 
> > a client wants status information on the certificate in question 
> > at a future date, it should come back and ask the server again." 
> 
> I like your proposal, since this means that when using the 
> on-line protocol 
> it is not possible to know. Now we could add a sentence that says: 
> 
> "However, the Certificate Practice Statement and the 
> Certificate Disclosure 
> Statement may provide more information about the refreshment 
> conditions of 
> the status information." 
>  
> Denis 
> 
> > This is my personal opinion. If the group agrees, I am happy to 
> > modify the document to reflect this point of view. 
> > 
> > Regards, 
> > Ambarish 
> > 
> > 
> --------------------------------------------------------------------- 
> > Ambarish Malpani 
> > Architect                                                
> 650.567.5457 
> > ValiCert, Inc.                                  
> [e-mail] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Why aren't the authors responding to this contradiction in the RFC and 
> carried out in the ID? 
> -----Original Message----- 
> From: Peter Williams [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Denis, 
> You refer to an assumed  "main mechanism" in your note. Speaking 
factually, 
> to hopefully guide you, sensibly:- 
> The main [reference] mechanism(s) at, and shortly after, 
> the time of writing OCSP IDs included:- 
> (1) VeriSign, who used an oracle database-based repository to feed data 
> to OCSP deamons acting in cached and interactive, direct-trust 
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive 
> direct-trust mode was  added, shortly after standarization, for a 
> defense customer bridging multiple certification domains. 
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP 
> deamons. Indirect CRLs and CRLDPs support was added slightly after 
> the architects had harmonized their work. 
> Both mechanisms evolved further, outside of IETF and 
> in vendor forums, particularly in the area of: application 
> integration, CRLDPs and delta-CRL data sources, proxying 
> transaction semantics and response resigning, data freshness 
> signalling, and OCSP client interaction with X.509 and 
> PKIX-style path processing and X.509 applications such as 
> SSLv3/https and MTA-based automatic xmldsig signature 
> verification on B2B and banking protocol XML streams. 
> Historically, this work essentially re-designed the standardized 
> features of the "distributed authentication model" of 
> X.500 1988, for OCSP-borne queries. 
> Currently, VeriSign's current work in W3C also 
> reflects alot of the understanding on the required 
> semantics of realtime trust models. 
> Peter. 
> -----Original Message----- 
> From: Denis Pinkas 
> To: Santosh Chokhani 
> Cc: [e-mail] 
> Sent: 1/16/02 12:04 AM 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> At the time the document was written, the main mechanism to feed the 
> information to the OCSP server was to use CRLs. So it seems sensible to 
> think that these fields are copied from a CRL. 
> 


------_=_NextPart_001_01C19F8E.D47A1EB0
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>

<META content="MSHTML 5.50.4912.300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=045193919-17012002><FONT face=Arial color=#0000ff 
size=2>Because, if we use that semantics, and the server does not get nextUpdate 
from the CA CRL, what will it do?</FONT></SPAN></DIV>
<DIV><SPAN class=045193919-17012002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=045193919-17012002><FONT face=Arial color=#0000ff size=2>By the 
way, since 2459 and son of 2459 require nextUpdate to be present, I do not have 
a problem with this interpretation.&nbsp; It will mean a compliant OCSP 
responder can not take CRL from a CA that is not compliant with 
2459.</FONT></SPAN></DIV>
<DIV><SPAN class=045193919-17012002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=045193919-17012002><FONT face=Arial color=#0000ff size=2>I just 
want the issue resolved and contradiction in the RFC 
removed.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Deacon, Alex 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 2002 2:37 
  PM<BR><B>To:</B> 'Santosh Chokhani'; Ambarish Malpani; '[e-mail] 
  '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 ID<BR><BR></FONT></DIV>
  <DIV><SPAN class=870082919-17012002><FONT face="Courier New" size=2>OK...you 
  guys have lost me now.&nbsp; What was wrong with not including the nextUpdate 
  field to specify that the server is providing real time info and that the 
  client should ask the server each time it needs the current status?&nbsp; If a 
  responder is providing real time status info, it can (or will) never know when 
  newer status info will be available as it is impossible to know when a 
  certificate will be revoked/suspended in advance.&nbsp;</FONT></SPAN></DIV>
  <DIV><SPAN class=870082919-17012002><FONT face="Courier New" 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=870082919-17012002><FONT face="Courier New" 
  size=2>Alex</FONT></SPAN></DIV>
  <DIV><SPAN class=870082919-17012002><FONT face="Courier New" 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <BLOCKQUOTE dir=ltr 
  style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
    [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 2002 
    11:23 AM<BR><B>To:</B> Santosh Chokhani; Ambarish Malpani; 
    '[e-mail] '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 
    ID<BR><BR></FONT></DIV>
    <DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff size=2>I 
    guess today is my day (every day is my day) to make errors, deeper 
    reflections and second guessing.</FONT></SPAN></DIV>
    <DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff size=2>I 
    guess what I am saying is as follows.&nbsp; Do the relying parties need to 
    know that the responder provides real-time revocation information?&nbsp; 
    Having thisUpdate=NOW may not prove that since this could be simply 
    coincidence.&nbsp; A pattern of responses may create statistical 
    certainty.</FONT></SPAN></DIV>
    <DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff 
    size=2>So, after all this, this question remains.&nbsp; Please do not 
    construe my emails to mean that I am saying the feature is required.&nbsp; I 
    am simply posing the question and proposing an approach if the feature is 
    required.</FONT></SPAN></DIV>
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
      [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 2002 
      2:08 PM<BR><B>To:</B> Santosh Chokhani; Ambarish Malpani; 
      '[e-mail] '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 
      ID<BR><BR></FONT></DIV>
      <DIV><SPAN class=242550819-17012002><FONT face=Arial color=#0000ff 
      size=2>Upon further reflection, I think thisUpdate DOES take care of 
      it.</FONT></SPAN></DIV>
      <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
        <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
        size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
        [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 
        2002 2:01 PM<BR><B>To:</B> Ambarish Malpani; Santosh Chokhani; 
        '[e-mail] '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 
        ID<BR><BR></FONT></DIV>
        <DIV><SPAN class=179530019-17012002><FONT face=Arial color=#0000ff 
        size=2>Ambarish: Are you suggesting that when thisUpdate=nextUpdate that 
        means response is available all the time.</FONT></SPAN></DIV>
        <DIV><SPAN class=179530019-17012002><FONT face=Arial color=#0000ff 
        size=2></FONT></SPAN>&nbsp;</DIV>
        <DIV><SPAN class=179530019-17012002><FONT face=Arial color=#0000ff 
        size=2>I am trying to account for situations when the response is 
        real-time (or near real-time).</FONT></SPAN></DIV>
        <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
          <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
          size=2>-----Original Message-----<BR><B>From:</B> Ambarish Malpani 
          [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 
          2002 1:56 PM<BR><B>To:</B> 'Santosh Chokhani'; '[e-mail] 
          '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 
          ID<BR><BR></FONT></DIV>
          <DIV>&nbsp;</DIV>
          <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
          class=289555818-17012002>Santosh, why doesn't thisUpdate meet that 
          need?</SPAN></FONT></DIV>
          <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
          class=289555818-17012002></SPAN></FONT>&nbsp;</DIV>
          <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
          class=289555818-17012002>A</SPAN></FONT></DIV>
          <DIV>&nbsp;</DIV>
          <P><FONT 
          size=2>---------------------------------------------------------------------<BR>Ambarish 
          Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          650.567.5457<BR>ValiCert, 
          Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          [e-mail]<BR>339 N. Bernardo 
          Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          <A target=_blank 
          href="http://www.valicert.com/">http://www.valicert.com</A><BR>Mountain 
          View, CA 94043<BR></FONT></P>
          <BLOCKQUOTE 
          style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
            <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
            size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
            [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 
            2002 10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas'; 
            '[e-mail] '<BR><B>Subject:</B> RE: OCSP RFC and OCSP 
            version 2 ID<BR><BR></DIV></FONT>
            <P><FONT size=2>I agree with what Ambarish and Carlisle are 
            saying.</FONT> </P>
            <P><FONT size=2>I have one addition question though.&nbsp; Should 
            the standard provide a capability to the relying parties (OCSP 
            clients) that the current revocation information is always 
            available. If people agree that it should, given the proposed 
            meaning of nextUpdate, the additional capability can be handled via 
            a SingleResponse extension.</FONT></P>
            <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT 
            size=2>From: Ambarish Malpani [<A 
            href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
            <BR><FONT size=2>Sent: Thursday, January 17, 2002 11:53 AM</FONT> 
            <BR><FONT size=2>To: 'Denis Pinkas'; '[e-mail] '</FONT> 
            <BR><FONT size=2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> 
            </P><BR><BR><BR>
            <P><FONT size=2>Hi Denis,</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; 
            Information about how up to date the information is, is</FONT> 
            <BR><FONT size=2>already present in the thisUpdate field in the 
            response.</FONT> </P>
            <P><FONT size=2>So, for example, if you *know* that you have 
            information that is</FONT> <BR><FONT size=2>current as of 5 seconds 
            ago, you can set that field appropriately.</FONT> </P>
            <P><FONT size=2>Does this meet your needs?</FONT> </P>
            <P><FONT size=2>Regards,</FONT> <BR><FONT size=2>Ambarish</FONT> 
</P>
            <P><FONT 
            size=2>---------------------------------------------------------------------</FONT> 
            <BR><FONT size=2>Ambarish Malpani</FONT> <BR><FONT 
            size=2>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
            650.567.5457</FONT> <BR><FONT size=2>ValiCert, 
            Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
            [e-mail]</FONT> <BR><FONT size=2>339 N. Bernardo 
            Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
            <A target=_blank 
            href="http://www.valicert.com">http://www.valicert.com</A></FONT> 
            <BR><FONT size=2>Mountain View, CA 94043</FONT> </P><BR>
            <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
            size=2>&gt; From: Denis Pinkas [<A 
            href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
            <BR><FONT size=2>&gt; Sent: Thursday, January 17, 2002 8:50 
            AM</FONT> <BR><FONT size=2>&gt; To: Ambarish Malpani</FONT> 
            <BR><FONT size=2>&gt; Cc: 'Santosh Chokhani'; '[e-mail] 
            '</FONT> <BR><FONT size=2>&gt; Subject: Re: OCSP RFC and OCSP 
            version 2 ID</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
            size=2>&gt; </FONT><BR><FONT size=2>&gt; Ambarish,</FONT> <BR><FONT 
            size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; Hi Santosh,</FONT> 
            <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Give me some 
            time.... :-)</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
            size=2>&gt; &gt; I agree with your first analysis:</FONT> <BR><FONT 
            size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; "If nextUpdate is 
            not set, the responder is indicating that newer</FONT> <BR><FONT 
            size=2>&gt; &gt; revocation information is available all the 
            time"</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
            &gt; Actually, they way I would prefer to state it would be 
            something</FONT> <BR><FONT size=2>&gt; &gt; like:</FONT> <BR><FONT 
            size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; "If nextUpdate is not 
            set, the responder is indicating that it</FONT> <BR><FONT 
            size=2>&gt; &gt; doesn't know when newer information will be 
            available and so, if</FONT> <BR><FONT size=2>&gt; &gt; a client 
            wants status information on the certificate in question</FONT> 
            <BR><FONT size=2>&gt; &gt; at a future date, it should come back and 
            ask the server again."</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
            size=2>&gt; I like your proposal, since this means that when using 
            the </FONT><BR><FONT size=2>&gt; on-line protocol </FONT><BR><FONT 
            size=2>&gt; it is not possible to know. Now we could add a sentence 
            that says:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
            "However, the Certificate Practice Statement and the 
            </FONT><BR><FONT size=2>&gt; Certificate Disclosure</FONT> <BR><FONT 
            size=2>&gt; Statement may provide more information about the 
            refreshment </FONT><BR><FONT size=2>&gt; conditions of</FONT> 
            <BR><FONT size=2>&gt; the status information."</FONT> <BR><FONT 
            size=2>&gt;&nbsp; </FONT><BR><FONT size=2>&gt; Denis</FONT> 
            <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; This is my 
            personal opinion. If the group agrees, I am happy to</FONT> 
            <BR><FONT size=2>&gt; &gt; modify the document to reflect this point 
            of view.</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
            size=2>&gt; &gt; Regards,</FONT> <BR><FONT size=2>&gt; &gt; 
            Ambarish</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT 
            size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
            ---------------------------------------------------------------------</FONT> 
            <BR><FONT size=2>&gt; &gt; Ambarish Malpani</FONT> <BR><FONT 
            size=2>&gt; &gt; 
            Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
            </FONT><BR><FONT size=2>&gt; 650.567.5457</FONT> <BR><FONT 
            size=2>&gt; &gt; ValiCert, 
            Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
            </FONT><BR><FONT size=2>&gt; [e-mail]</FONT> <BR><FONT 
            size=2>&gt; &gt; 339 N. Bernardo 
            Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
            </FONT><BR><FONT size=2><A target=_blank 
            href="http://www.valicert.com">http://www.valicert.com</A></FONT> 
            <BR><FONT size=2>&gt; Mountain View, CA 94043</FONT> <BR><FONT 
            size=2>&gt; </FONT><BR><FONT size=2>&gt; -----Original 
            Message-----</FONT> <BR><FONT size=2>&gt; From: Santosh Chokhani [<A 
            href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
            <BR><FONT size=2>&gt; Sent: Wednesday, January 16, 2002 11:50 
            AM</FONT> <BR><FONT size=2>&gt; To: Peter Williams; 'Denis Pinkas '; 
            Santosh Chokhani</FONT> <BR><FONT size=2>&gt; Cc: '[e-mail] 
            '</FONT> <BR><FONT size=2>&gt; Subject: RE: OCSP RFC and OCSP 
            version 2 ID</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
            size=2>&gt; Why aren't the authors responding to this contradiction 
            in the RFC and</FONT> <BR><FONT size=2>&gt; carried out in the 
            ID?</FONT> <BR><FONT size=2>&gt; -----Original Message-----</FONT> 
            <BR><FONT size=2>&gt; From: Peter Williams [<A 
            href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
            <BR><FONT size=2>&gt; Sent: Wednesday, January 16, 2002 2:41 
            PM</FONT> <BR><FONT size=2>&gt; To: 'Denis Pinkas '; 'Santosh 
            Chokhani '</FONT> <BR><FONT size=2>&gt; Cc: '[e-mail] 
            '</FONT> <BR><FONT size=2>&gt; Subject: RE: OCSP RFC and OCSP 
            version 2 ID</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
            size=2>&gt; Denis,</FONT> <BR><FONT size=2>&gt; You refer to an 
            assumed&nbsp; "main mechanism" in your note. Speaking</FONT> 
            <BR><FONT size=2>factually,</FONT> <BR><FONT size=2>&gt; to 
            hopefully guide you, sensibly:-</FONT> <BR><FONT size=2>&gt; The 
            main [reference] mechanism(s) at, and shortly after,</FONT> 
            <BR><FONT size=2>&gt; the time of writing OCSP IDs included:-</FONT> 
            <BR><FONT size=2>&gt; (1) VeriSign, who used an oracle 
            database-based repository to feed data</FONT> <BR><FONT size=2>&gt; 
            to OCSP deamons acting in cached and interactive, 
            direct-trust</FONT> <BR><FONT size=2>&gt; mode; CRLs were not 
            involved. OCSP proxing/multiplexing interactive</FONT> <BR><FONT 
            size=2>&gt; direct-trust mode was&nbsp; added, shortly after 
            standarization, for a</FONT> <BR><FONT size=2>&gt; defense customer 
            bridging multiple certification domains.</FONT> <BR><FONT 
            size=2>&gt; (2) ValiCert, who used direct CRLs to feed data to 
            direct/indirect OCSP</FONT> <BR><FONT size=2>&gt; deamons. Indirect 
            CRLs and CRLDPs support was added slightly after</FONT> <BR><FONT 
            size=2>&gt; the architects had harmonized their work.</FONT> 
            <BR><FONT size=2>&gt; Both mechanisms evolved further, outside of 
            IETF and</FONT> <BR><FONT size=2>&gt; in vendor forums, particularly 
            in the area of: application</FONT> <BR><FONT size=2>&gt; 
            integration, CRLDPs and delta-CRL data sources, proxying</FONT> 
            <BR><FONT size=2>&gt; transaction semantics and response resigning, 
            data freshness</FONT> <BR><FONT size=2>&gt; signalling, and OCSP 
            client interaction with X.509 and</FONT> <BR><FONT size=2>&gt; 
            PKIX-style path processing and X.509 applications such as</FONT> 
            <BR><FONT size=2>&gt; SSLv3/https and MTA-based automatic xmldsig 
            signature</FONT> <BR><FONT size=2>&gt; verification on B2B and 
            banking protocol XML streams.</FONT> <BR><FONT size=2>&gt; 
            Historically, this work essentially re-designed the 
            standardized</FONT> <BR><FONT size=2>&gt; features of the 
            "distributed authentication model" of</FONT> <BR><FONT size=2>&gt; 
            X.500 1988, for OCSP-borne queries.</FONT> <BR><FONT size=2>&gt; 
            Currently, VeriSign's current work in W3C also</FONT> <BR><FONT 
            size=2>&gt; reflects alot of the understanding on the 
            required</FONT> <BR><FONT size=2>&gt; semantics of realtime trust 
            models.</FONT> <BR><FONT size=2>&gt; Peter.</FONT> <BR><FONT 
            size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
            From: Denis Pinkas</FONT> <BR><FONT size=2>&gt; To: Santosh 
            Chokhani</FONT> <BR><FONT size=2>&gt; Cc: [e-mail]</FONT> 
            <BR><FONT size=2>&gt; Sent: 1/16/02 12:04 AM</FONT> <BR><FONT 
            size=2>&gt; Subject: Re: OCSP RFC and OCSP version 2 ID</FONT> 
            <BR><FONT size=2>&gt; At the time the document was written, the main 
            mechanism to feed the</FONT> <BR><FONT size=2>&gt; information to 
            the OCSP server was to use CRLs. So it seems sensible to</FONT> 
            <BR><FONT size=2>&gt; think that these fields are copied from a 
            CRL.</FONT> <BR><FONT size=2>&gt;</FONT> 
      </P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C19F8E.D47A1EB0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HJcXW24950 for ietf-pkix-bks; Thu, 17 Jan 2002 11:38:33 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HJcR324942 for <[e-mail]>; Thu, 17 Jan 2002 11:38:27 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g0HJZ4R04044; Thu, 17 Jan 2002 11:35:04 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <Y2Y12AXC>; Thu, 17 Jan 2002 11:39:19 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Santosh Chokhani'" <[e-mail]>, Ambarish Malpani <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 11:37:24 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19F8E.637D1A00"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C19F8E.637D1A00
Content-Type: text/plain;
	charset="iso-8859-1"

OK...you guys have lost me now.  What was wrong with not including the
nextUpdate field to specify that the server is providing real time info and
that the client should ask the server each time it needs the current status?
If a responder is providing real time status info, it can (or will) never
know when newer status info will be available as it is impossible to know
when a certificate will be revoked/suspended in advance. 
 
Alex
 

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 11:23 AM
To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


I guess today is my day (every day is my day) to make errors, deeper
reflections and second guessing.
 
I guess what I am saying is as follows.  Do the relying parties need to know
that the responder provides real-time revocation information?  Having
thisUpdate=NOW may not prove that since this could be simply coincidence.  A
pattern of responses may create statistical certainty.
 
So, after all this, this question remains.  Please do not construe my emails
to mean that I am saying the feature is required.  I am simply posing the
question and proposing an approach if the feature is required.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 2:08 PM
To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Upon further reflection, I think thisUpdate DOES take care of it.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
response is available all the time.
 
I am trying to account for situations when the response is real-time (or
near real-time).

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


 
Santosh, why doesn't thisUpdate meet that need?
 
A
 

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID



I agree with what Ambarish and Carlisle are saying. 

I have one addition question though.  Should the standard provide a
capability to the relying parties (OCSP clients) that the current revocation
information is always available. If people agree that it should, given the
proposed meaning of nextUpdate, the additional capability can be handled via
a SingleResponse extension.

-----Original Message----- 
From: Ambarish Malpani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; '[e-mail] ' 
Subject: RE: OCSP RFC and OCSP version 2 ID 




Hi Denis, 
    Information about how up to date the information is, is 
already present in the thisUpdate field in the response. 

So, for example, if you *know* that you have information that is 
current as of 5 seconds ago, you can set that field appropriately. 

Does this meet your needs? 

Regards, 
Ambarish 

--------------------------------------------------------------------- 
Ambarish Malpani 
Architect                                                650.567.5457 
ValiCert, Inc.                                  [e-mail] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 


> -----Original Message----- 
> From: Denis Pinkas [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; '[e-mail] ' 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> 
> 
> Ambarish, 
> 
> > Hi Santosh, 
> >     Give me some time.... :-) 
> > 
> > I agree with your first analysis: 
> > 
> > "If nextUpdate is not set, the responder is indicating that newer 
> > revocation information is available all the time" 
> > 
> > Actually, they way I would prefer to state it would be something 
> > like: 
> 
> > "If nextUpdate is not set, the responder is indicating that it 
> > doesn't know when newer information will be available and so, if 
> > a client wants status information on the certificate in question 
> > at a future date, it should come back and ask the server again." 
> 
> I like your proposal, since this means that when using the 
> on-line protocol 
> it is not possible to know. Now we could add a sentence that says: 
> 
> "However, the Certificate Practice Statement and the 
> Certificate Disclosure 
> Statement may provide more information about the refreshment 
> conditions of 
> the status information." 
>  
> Denis 
> 
> > This is my personal opinion. If the group agrees, I am happy to 
> > modify the document to reflect this point of view. 
> > 
> > Regards, 
> > Ambarish 
> > 
> > 
> --------------------------------------------------------------------- 
> > Ambarish Malpani 
> > Architect                                                
> 650.567.5457 
> > ValiCert, Inc.                                  
> [e-mail] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Why aren't the authors responding to this contradiction in the RFC and 
> carried out in the ID? 
> -----Original Message----- 
> From: Peter Williams [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Denis, 
> You refer to an assumed  "main mechanism" in your note. Speaking 
factually, 
> to hopefully guide you, sensibly:- 
> The main [reference] mechanism(s) at, and shortly after, 
> the time of writing OCSP IDs included:- 
> (1) VeriSign, who used an oracle database-based repository to feed data 
> to OCSP deamons acting in cached and interactive, direct-trust 
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive 
> direct-trust mode was  added, shortly after standarization, for a 
> defense customer bridging multiple certification domains. 
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP 
> deamons. Indirect CRLs and CRLDPs support was added slightly after 
> the architects had harmonized their work. 
> Both mechanisms evolved further, outside of IETF and 
> in vendor forums, particularly in the area of: application 
> integration, CRLDPs and delta-CRL data sources, proxying 
> transaction semantics and response resigning, data freshness 
> signalling, and OCSP client interaction with X.509 and 
> PKIX-style path processing and X.509 applications such as 
> SSLv3/https and MTA-based automatic xmldsig signature 
> verification on B2B and banking protocol XML streams. 
> Historically, this work essentially re-designed the standardized 
> features of the "distributed authentication model" of 
> X.500 1988, for OCSP-borne queries. 
> Currently, VeriSign's current work in W3C also 
> reflects alot of the understanding on the required 
> semantics of realtime trust models. 
> Peter. 
> -----Original Message----- 
> From: Denis Pinkas 
> To: Santosh Chokhani 
> Cc: [e-mail] 
> Sent: 1/16/02 12:04 AM 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> At the time the document was written, the main mechanism to feed the 
> information to the OCSP server was to use CRLs. So it seems sensible to 
> think that these fields are copied from a CRL. 
> 


------_=_NextPart_001_01C19F8E.637D1A00
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>

<META content="MSHTML 6.00.2600.0" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=870082919-17012002><FONT face="Courier New" size=2>OK...you 
guys have lost me now.&nbsp; What was wrong with not including the nextUpdate 
field to specify that the server is providing real time info and that the client 
should ask the server each time it needs the current status?&nbsp; If a 
responder is providing real time status info, it can (or will) never know when 
newer status info will be available as it is impossible to know when a 
certificate will be revoked/suspended in advance.&nbsp;</FONT></SPAN></DIV>
<DIV><SPAN class=870082919-17012002><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=870082919-17012002><FONT face="Courier New" 
size=2>Alex</FONT></SPAN></DIV>
<DIV><SPAN class=870082919-17012002><FONT face="Courier New" 
size=2></FONT></SPAN>&nbsp;</DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 2002 
  11:23 AM<BR><B>To:</B> Santosh Chokhani; Ambarish Malpani; '[e-mail] 
  '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 ID<BR><BR></FONT></DIV>
  <DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff size=2>I 
  guess today is my day (every day is my day) to make errors, deeper reflections 
  and second guessing.</FONT></SPAN></DIV>
  <DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff size=2>I 
  guess what I am saying is as follows.&nbsp; Do the relying parties need to 
  know that the responder provides real-time revocation information?&nbsp; 
  Having thisUpdate=NOW may not prove that since this could be simply 
  coincidence.&nbsp; A pattern of responses may create statistical 
  certainty.</FONT></SPAN></DIV>
  <DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff 
  size=2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff size=2>So, 
  after all this, this question remains.&nbsp; Please do not construe my emails 
  to mean that I am saying the feature is required.&nbsp; I am simply posing the 
  question and proposing an approach if the feature is 
  required.</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
    [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 2002 
    2:08 PM<BR><B>To:</B> Santosh Chokhani; Ambarish Malpani; '[e-mail] 
    '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 ID<BR><BR></FONT></DIV>
    <DIV><SPAN class=242550819-17012002><FONT face=Arial color=#0000ff 
    size=2>Upon further reflection, I think thisUpdate DOES take care of 
    it.</FONT></SPAN></DIV>
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
      [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 2002 
      2:01 PM<BR><B>To:</B> Ambarish Malpani; Santosh Chokhani; 
      '[e-mail] '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 
      ID<BR><BR></FONT></DIV>
      <DIV><SPAN class=179530019-17012002><FONT face=Arial color=#0000ff 
      size=2>Ambarish: Are you suggesting that when thisUpdate=nextUpdate that 
      means response is available all the time.</FONT></SPAN></DIV>
      <DIV><SPAN class=179530019-17012002><FONT face=Arial color=#0000ff 
      size=2></FONT></SPAN>&nbsp;</DIV>
      <DIV><SPAN class=179530019-17012002><FONT face=Arial color=#0000ff 
      size=2>I am trying to account for situations when the response is 
      real-time (or near real-time).</FONT></SPAN></DIV>
      <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
        <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
        size=2>-----Original Message-----<BR><B>From:</B> Ambarish Malpani 
        [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 
        2002 1:56 PM<BR><B>To:</B> 'Santosh Chokhani'; '[e-mail] 
        '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 
        ID<BR><BR></FONT></DIV>
        <DIV>&nbsp;</DIV>
        <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
        class=289555818-17012002>Santosh, why doesn't thisUpdate meet that 
        need?</SPAN></FONT></DIV>
        <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
        class=289555818-17012002></SPAN></FONT>&nbsp;</DIV>
        <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
        class=289555818-17012002>A</SPAN></FONT></DIV>
        <DIV>&nbsp;</DIV>
        <P><FONT 
        size=2>---------------------------------------------------------------------<BR>Ambarish 
        Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        650.567.5457<BR>ValiCert, 
        Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        [e-mail]<BR>339 N. Bernardo 
        Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        <A href="http://www.valicert.com/" 
        target=_blank>http://www.valicert.com</A><BR>Mountain View, CA 
        94043<BR></FONT></P>
        <BLOCKQUOTE 
        style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
          <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
          size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
          [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 
          2002 10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas'; 
          '[e-mail] '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 
          2 ID<BR><BR></DIV></FONT>
          <P><FONT size=2>I agree with what Ambarish and Carlisle are 
          saying.</FONT> </P>
          <P><FONT size=2>I have one addition question though.&nbsp; Should the 
          standard provide a capability to the relying parties (OCSP clients) 
          that the current revocation information is always available. If people 
          agree that it should, given the proposed meaning of nextUpdate, the 
          additional capability can be handled via a SingleResponse 
          extension.</FONT></P>
          <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT 
          size=2>From: Ambarish Malpani [<A 
          href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
          <BR><FONT size=2>Sent: Thursday, January 17, 2002 11:53 AM</FONT> 
          <BR><FONT size=2>To: 'Denis Pinkas'; '[e-mail] '</FONT> 
          <BR><FONT size=2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> 
          </P><BR><BR><BR>
          <P><FONT size=2>Hi Denis,</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; 
          Information about how up to date the information is, is</FONT> 
          <BR><FONT size=2>already present in the thisUpdate field in the 
          response.</FONT> </P>
          <P><FONT size=2>So, for example, if you *know* that you have 
          information that is</FONT> <BR><FONT size=2>current as of 5 seconds 
          ago, you can set that field appropriately.</FONT> </P>
          <P><FONT size=2>Does this meet your needs?</FONT> </P>
          <P><FONT size=2>Regards,</FONT> <BR><FONT size=2>Ambarish</FONT> </P>
          <P><FONT 
          size=2>---------------------------------------------------------------------</FONT> 
          <BR><FONT size=2>Ambarish Malpani</FONT> <BR><FONT 
          size=2>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          650.567.5457</FONT> <BR><FONT size=2>ValiCert, 
          Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          [e-mail]</FONT> <BR><FONT size=2>339 N. Bernardo 
          Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          <A href="http://www.valicert.com" 
          target=_blank>http://www.valicert.com</A></FONT> <BR><FONT 
          size=2>Mountain View, CA 94043</FONT> </P><BR>
          <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
          size=2>&gt; From: Denis Pinkas [<A 
          href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
          <BR><FONT size=2>&gt; Sent: Thursday, January 17, 2002 8:50 AM</FONT> 
          <BR><FONT size=2>&gt; To: Ambarish Malpani</FONT> <BR><FONT 
          size=2>&gt; Cc: 'Santosh Chokhani'; '[e-mail] '</FONT> 
          <BR><FONT size=2>&gt; Subject: Re: OCSP RFC and OCSP version 2 
          ID</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
          </FONT><BR><FONT size=2>&gt; Ambarish,</FONT> <BR><FONT size=2>&gt; 
          </FONT><BR><FONT size=2>&gt; &gt; Hi Santosh,</FONT> <BR><FONT 
          size=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Give me some time.... 
          :-)</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
          &gt; I agree with your first analysis:</FONT> <BR><FONT size=2>&gt; 
          &gt; </FONT><BR><FONT size=2>&gt; &gt; "If nextUpdate is not set, the 
          responder is indicating that newer</FONT> <BR><FONT size=2>&gt; &gt; 
          revocation information is available all the time"</FONT> <BR><FONT 
          size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; &gt; Actually, they way 
          I would prefer to state it would be something</FONT> <BR><FONT 
          size=2>&gt; &gt; like:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
          size=2>&gt; &gt; "If nextUpdate is not set, the responder is 
          indicating that it</FONT> <BR><FONT size=2>&gt; &gt; doesn't know when 
          newer information will be available and so, if</FONT> <BR><FONT 
          size=2>&gt; &gt; a client wants status information on the certificate 
          in question</FONT> <BR><FONT size=2>&gt; &gt; at a future date, it 
          should come back and ask the server again."</FONT> <BR><FONT 
          size=2>&gt; </FONT><BR><FONT size=2>&gt; I like your proposal, since 
          this means that when using the </FONT><BR><FONT size=2>&gt; on-line 
          protocol </FONT><BR><FONT size=2>&gt; it is not possible to know. Now 
          we could add a sentence that says:</FONT> <BR><FONT size=2>&gt; 
          </FONT><BR><FONT size=2>&gt; "However, the Certificate Practice 
          Statement and the </FONT><BR><FONT size=2>&gt; Certificate 
          Disclosure</FONT> <BR><FONT size=2>&gt; Statement may provide more 
          information about the refreshment </FONT><BR><FONT size=2>&gt; 
          conditions of</FONT> <BR><FONT size=2>&gt; the status 
          information."</FONT> <BR><FONT size=2>&gt;&nbsp; </FONT><BR><FONT 
          size=2>&gt; Denis</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
          size=2>&gt; &gt; This is my personal opinion. If the group agrees, I 
          am happy to</FONT> <BR><FONT size=2>&gt; &gt; modify the document to 
          reflect this point of view.</FONT> <BR><FONT size=2>&gt; &gt; 
          </FONT><BR><FONT size=2>&gt; &gt; Regards,</FONT> <BR><FONT 
          size=2>&gt; &gt; Ambarish</FONT> <BR><FONT size=2>&gt; &gt; 
          </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
          ---------------------------------------------------------------------</FONT> 
          <BR><FONT size=2>&gt; &gt; Ambarish Malpani</FONT> <BR><FONT 
          size=2>&gt; &gt; 
          Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          </FONT><BR><FONT size=2>&gt; 650.567.5457</FONT> <BR><FONT size=2>&gt; 
          &gt; ValiCert, 
          Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          </FONT><BR><FONT size=2>&gt; [e-mail]</FONT> <BR><FONT 
          size=2>&gt; &gt; 339 N. Bernardo 
          Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
          </FONT><BR><FONT size=2><A href="http://www.valicert.com" 
          target=_blank>http://www.valicert.com</A></FONT> <BR><FONT size=2>&gt; 
          Mountain View, CA 94043</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT 
          size=2>&gt; -----Original Message-----</FONT> <BR><FONT size=2>&gt; 
          From: Santosh Chokhani [<A 
          href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
          <BR><FONT size=2>&gt; Sent: Wednesday, January 16, 2002 11:50 
          AM</FONT> <BR><FONT size=2>&gt; To: Peter Williams; 'Denis Pinkas '; 
          Santosh Chokhani</FONT> <BR><FONT size=2>&gt; Cc: '[e-mail] 
          '</FONT> <BR><FONT size=2>&gt; Subject: RE: OCSP RFC and OCSP version 
          2 ID</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Why 
          aren't the authors responding to this contradiction in the RFC 
          and</FONT> <BR><FONT size=2>&gt; carried out in the ID?</FONT> 
          <BR><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
          size=2>&gt; From: Peter Williams [<A 
          href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
          <BR><FONT size=2>&gt; Sent: Wednesday, January 16, 2002 2:41 PM</FONT> 
          <BR><FONT size=2>&gt; To: 'Denis Pinkas '; 'Santosh Chokhani '</FONT> 
          <BR><FONT size=2>&gt; Cc: '[e-mail] '</FONT> <BR><FONT 
          size=2>&gt; Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> 
          <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Denis,</FONT> 
          <BR><FONT size=2>&gt; You refer to an assumed&nbsp; "main mechanism" 
          in your note. Speaking</FONT> <BR><FONT size=2>factually,</FONT> 
          <BR><FONT size=2>&gt; to hopefully guide you, sensibly:-</FONT> 
          <BR><FONT size=2>&gt; The main [reference] mechanism(s) at, and 
          shortly after,</FONT> <BR><FONT size=2>&gt; the time of writing OCSP 
          IDs included:-</FONT> <BR><FONT size=2>&gt; (1) VeriSign, who used an 
          oracle database-based repository to feed data</FONT> <BR><FONT 
          size=2>&gt; to OCSP deamons acting in cached and interactive, 
          direct-trust</FONT> <BR><FONT size=2>&gt; mode; CRLs were not 
          involved. OCSP proxing/multiplexing interactive</FONT> <BR><FONT 
          size=2>&gt; direct-trust mode was&nbsp; added, shortly after 
          standarization, for a</FONT> <BR><FONT size=2>&gt; defense customer 
          bridging multiple certification domains.</FONT> <BR><FONT size=2>&gt; 
          (2) ValiCert, who used direct CRLs to feed data to direct/indirect 
          OCSP</FONT> <BR><FONT size=2>&gt; deamons. Indirect CRLs and CRLDPs 
          support was added slightly after</FONT> <BR><FONT size=2>&gt; the 
          architects had harmonized their work.</FONT> <BR><FONT size=2>&gt; 
          Both mechanisms evolved further, outside of IETF and</FONT> <BR><FONT 
          size=2>&gt; in vendor forums, particularly in the area of: 
          application</FONT> <BR><FONT size=2>&gt; integration, CRLDPs and 
          delta-CRL data sources, proxying</FONT> <BR><FONT size=2>&gt; 
          transaction semantics and response resigning, data freshness</FONT> 
          <BR><FONT size=2>&gt; signalling, and OCSP client interaction with 
          X.509 and</FONT> <BR><FONT size=2>&gt; PKIX-style path processing and 
          X.509 applications such as</FONT> <BR><FONT size=2>&gt; SSLv3/https 
          and MTA-based automatic xmldsig signature</FONT> <BR><FONT size=2>&gt; 
          verification on B2B and banking protocol XML streams.</FONT> <BR><FONT 
          size=2>&gt; Historically, this work essentially re-designed the 
          standardized</FONT> <BR><FONT size=2>&gt; features of the "distributed 
          authentication model" of</FONT> <BR><FONT size=2>&gt; X.500 1988, for 
          OCSP-borne queries.</FONT> <BR><FONT size=2>&gt; Currently, VeriSign's 
          current work in W3C also</FONT> <BR><FONT size=2>&gt; reflects alot of 
          the understanding on the required</FONT> <BR><FONT size=2>&gt; 
          semantics of realtime trust models.</FONT> <BR><FONT size=2>&gt; 
          Peter.</FONT> <BR><FONT size=2>&gt; -----Original Message-----</FONT> 
          <BR><FONT size=2>&gt; From: Denis Pinkas</FONT> <BR><FONT size=2>&gt; 
          To: Santosh Chokhani</FONT> <BR><FONT size=2>&gt; Cc: 
          [e-mail]</FONT> <BR><FONT size=2>&gt; Sent: 1/16/02 12:04 
          AM</FONT> <BR><FONT size=2>&gt; Subject: Re: OCSP RFC and OCSP version 
          2 ID</FONT> <BR><FONT size=2>&gt; At the time the document was 
          written, the main mechanism to feed the</FONT> <BR><FONT size=2>&gt; 
          information to the OCSP server was to use CRLs. So it seems sensible 
          to</FONT> <BR><FONT size=2>&gt; think that these fields are copied 
          from a CRL.</FONT> <BR><FONT size=2>&gt;</FONT> 
      </P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C19F8E.637D1A00--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HJNul24561 for ietf-pkix-bks; Thu, 17 Jan 2002 11:23:56 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HJNt324556 for <[e-mail]>; Thu, 17 Jan 2002 11:23:55 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <D1BG8N1D>; Thu, 17 Jan 2002 14:23:52 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B631@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: Santosh Chokhani <[e-mail]>, Ambarish Malpani <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 14:22:38 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19F8C.538A60A0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C19F8C.538A60A0
Content-Type: text/plain

I guess today is my day (every day is my day) to make errors, deeper
reflections and second guessing.
 
I guess what I am saying is as follows.  Do the relying parties need to know
that the responder provides real-time revocation information?  Having
thisUpdate=NOW may not prove that since this could be simply coincidence.  A
pattern of responses may create statistical certainty.
 
So, after all this, this question remains.  Please do not construe my emails
to mean that I am saying the feature is required.  I am simply posing the
question and proposing an approach if the feature is required.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 2:08 PM
To: Santosh Chokhani; Ambarish Malpani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Upon further reflection, I think thisUpdate DOES take care of it.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
response is available all the time.
 
I am trying to account for situations when the response is real-time (or
near real-time).

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


 
Santosh, why doesn't thisUpdate meet that need?
 
A
 

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID



I agree with what Ambarish and Carlisle are saying. 

I have one addition question though.  Should the standard provide a
capability to the relying parties (OCSP clients) that the current revocation
information is always available. If people agree that it should, given the
proposed meaning of nextUpdate, the additional capability can be handled via
a SingleResponse extension.

-----Original Message----- 
From: Ambarish Malpani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; '[e-mail] ' 
Subject: RE: OCSP RFC and OCSP version 2 ID 




Hi Denis, 
    Information about how up to date the information is, is 
already present in the thisUpdate field in the response. 

So, for example, if you *know* that you have information that is 
current as of 5 seconds ago, you can set that field appropriately. 

Does this meet your needs? 

Regards, 
Ambarish 

--------------------------------------------------------------------- 
Ambarish Malpani 
Architect                                                650.567.5457 
ValiCert, Inc.                                  [e-mail] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 


> -----Original Message----- 
> From: Denis Pinkas [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; '[e-mail] ' 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> 
> 
> Ambarish, 
> 
> > Hi Santosh, 
> >     Give me some time.... :-) 
> > 
> > I agree with your first analysis: 
> > 
> > "If nextUpdate is not set, the responder is indicating that newer 
> > revocation information is available all the time" 
> > 
> > Actually, they way I would prefer to state it would be something 
> > like: 
> 
> > "If nextUpdate is not set, the responder is indicating that it 
> > doesn't know when newer information will be available and so, if 
> > a client wants status information on the certificate in question 
> > at a future date, it should come back and ask the server again." 
> 
> I like your proposal, since this means that when using the 
> on-line protocol 
> it is not possible to know. Now we could add a sentence that says: 
> 
> "However, the Certificate Practice Statement and the 
> Certificate Disclosure 
> Statement may provide more information about the refreshment 
> conditions of 
> the status information." 
>  
> Denis 
> 
> > This is my personal opinion. If the group agrees, I am happy to 
> > modify the document to reflect this point of view. 
> > 
> > Regards, 
> > Ambarish 
> > 
> > 
> --------------------------------------------------------------------- 
> > Ambarish Malpani 
> > Architect                                                
> 650.567.5457 
> > ValiCert, Inc.                                  
> [e-mail] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Why aren't the authors responding to this contradiction in the RFC and 
> carried out in the ID? 
> -----Original Message----- 
> From: Peter Williams [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Denis, 
> You refer to an assumed  "main mechanism" in your note. Speaking 
factually, 
> to hopefully guide you, sensibly:- 
> The main [reference] mechanism(s) at, and shortly after, 
> the time of writing OCSP IDs included:- 
> (1) VeriSign, who used an oracle database-based repository to feed data 
> to OCSP deamons acting in cached and interactive, direct-trust 
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive 
> direct-trust mode was  added, shortly after standarization, for a 
> defense customer bridging multiple certification domains. 
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP 
> deamons. Indirect CRLs and CRLDPs support was added slightly after 
> the architects had harmonized their work. 
> Both mechanisms evolved further, outside of IETF and 
> in vendor forums, particularly in the area of: application 
> integration, CRLDPs and delta-CRL data sources, proxying 
> transaction semantics and response resigning, data freshness 
> signalling, and OCSP client interaction with X.509 and 
> PKIX-style path processing and X.509 applications such as 
> SSLv3/https and MTA-based automatic xmldsig signature 
> verification on B2B and banking protocol XML streams. 
> Historically, this work essentially re-designed the standardized 
> features of the "distributed authentication model" of 
> X.500 1988, for OCSP-borne queries. 
> Currently, VeriSign's current work in W3C also 
> reflects alot of the understanding on the required 
> semantics of realtime trust models. 
> Peter. 
> -----Original Message----- 
> From: Denis Pinkas 
> To: Santosh Chokhani 
> Cc: [e-mail] 
> Sent: 1/16/02 12:04 AM 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> At the time the document was written, the main mechanism to feed the 
> information to the OCSP server was to use CRLs. So it seems sensible to 
> think that these fields are copied from a CRL. 
> 


------_=_NextPart_001_01C19F8C.538A60A0
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>

<META content="MSHTML 5.50.4912.300" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff size=2>I 
guess today is my day (every day is my day) to make errors, deeper reflections 
and second guessing.</FONT></SPAN></DIV>
<DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff size=2>I 
guess what I am saying is as follows.&nbsp; Do the relying parties need to know 
that the responder provides real-time revocation information?&nbsp; Having 
thisUpdate=NOW may not prove that since this could be simply coincidence.&nbsp; 
A pattern of responses may create statistical certainty.</FONT></SPAN></DIV>
<DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=869291819-17012002><FONT face=Arial color=#0000ff size=2>So, 
after all this, this question remains.&nbsp; Please do not construe my emails to 
mean that I am saying the feature is required.&nbsp; I am simply posing the 
question and proposing an approach if the feature is 
required.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
  <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
  size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 2002 2:08 
  PM<BR><B>To:</B> Santosh Chokhani; Ambarish Malpani; '[e-mail] 
  '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 ID<BR><BR></FONT></DIV>
  <DIV><SPAN class=242550819-17012002><FONT face=Arial color=#0000ff size=2>Upon 
  further reflection, I think thisUpdate DOES take care of 
  it.</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
    <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
    size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
    [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 2002 
    2:01 PM<BR><B>To:</B> Ambarish Malpani; Santosh Chokhani; '[e-mail] 
    '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 ID<BR><BR></FONT></DIV>
    <DIV><SPAN class=179530019-17012002><FONT face=Arial color=#0000ff 
    size=2>Ambarish: Are you suggesting that when thisUpdate=nextUpdate that 
    means response is available all the time.</FONT></SPAN></DIV>
    <DIV><SPAN class=179530019-17012002><FONT face=Arial color=#0000ff 
    size=2></FONT></SPAN>&nbsp;</DIV>
    <DIV><SPAN class=179530019-17012002><FONT face=Arial color=#0000ff size=2>I 
    am trying to account for situations when the response is real-time (or near 
    real-time).</FONT></SPAN></DIV>
    <BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
      <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
      size=2>-----Original Message-----<BR><B>From:</B> Ambarish Malpani 
      [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 2002 
      1:56 PM<BR><B>To:</B> 'Santosh Chokhani'; '[e-mail] 
      '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 
      ID<BR><BR></FONT></DIV>
      <DIV>&nbsp;</DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=289555818-17012002>Santosh, why doesn't thisUpdate meet that 
      need?</SPAN></FONT></DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=289555818-17012002></SPAN></FONT>&nbsp;</DIV>
      <DIV><FONT face=Arial color=#0000ff size=2><SPAN 
      class=289555818-17012002>A</SPAN></FONT></DIV>
      <DIV>&nbsp;</DIV>
      <P><FONT 
      size=2>---------------------------------------------------------------------<BR>Ambarish 
      Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      650.567.5457<BR>ValiCert, 
      Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      [e-mail]<BR>339 N. Bernardo 
      Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
      <A target=_blank 
      href="http://www.valicert.com/">http://www.valicert.com</A><BR>Mountain 
      View, CA 94043<BR></FONT></P>
      <BLOCKQUOTE 
      style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
        <DIV class=OutlookMessageHeader dir=ltr align=left><FONT face=Tahoma 
        size=2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani 
        [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, 
        2002 10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas'; 
        '[e-mail] '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 
        ID<BR><BR></DIV></FONT>
        <P><FONT size=2>I agree with what Ambarish and Carlisle are 
        saying.</FONT> </P>
        <P><FONT size=2>I have one addition question though.&nbsp; Should the 
        standard provide a capability to the relying parties (OCSP clients) that 
        the current revocation information is always available. If people agree 
        that it should, given the proposed meaning of nextUpdate, the additional 
        capability can be handled via a SingleResponse extension.</FONT></P>
        <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: 
        Ambarish Malpani [<A 
        href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
        <BR><FONT size=2>Sent: Thursday, January 17, 2002 11:53 AM</FONT> 
        <BR><FONT size=2>To: 'Denis Pinkas'; '[e-mail] '</FONT> 
        <BR><FONT size=2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> 
        </P><BR><BR><BR>
        <P><FONT size=2>Hi Denis,</FONT> <BR><FONT size=2>&nbsp;&nbsp;&nbsp; 
        Information about how up to date the information is, is</FONT> <BR><FONT 
        size=2>already present in the thisUpdate field in the response.</FONT> 
        </P>
        <P><FONT size=2>So, for example, if you *know* that you have information 
        that is</FONT> <BR><FONT size=2>current as of 5 seconds ago, you can set 
        that field appropriately.</FONT> </P>
        <P><FONT size=2>Does this meet your needs?</FONT> </P>
        <P><FONT size=2>Regards,</FONT> <BR><FONT size=2>Ambarish</FONT> </P>
        <P><FONT 
        size=2>---------------------------------------------------------------------</FONT> 
        <BR><FONT size=2>Ambarish Malpani</FONT> <BR><FONT 
        size=2>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        650.567.5457</FONT> <BR><FONT size=2>ValiCert, 
        Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        [e-mail]</FONT> <BR><FONT size=2>339 N. Bernardo 
        Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        <A target=_blank 
        href="http://www.valicert.com">http://www.valicert.com</A></FONT> 
        <BR><FONT size=2>Mountain View, CA 94043</FONT> </P><BR>
        <P><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
        size=2>&gt; From: Denis Pinkas [<A 
        href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
        <BR><FONT size=2>&gt; Sent: Thursday, January 17, 2002 8:50 AM</FONT> 
        <BR><FONT size=2>&gt; To: Ambarish Malpani</FONT> <BR><FONT size=2>&gt; 
        Cc: 'Santosh Chokhani'; '[e-mail] '</FONT> <BR><FONT 
        size=2>&gt; Subject: Re: OCSP RFC and OCSP version 2 ID</FONT> <BR><FONT 
        size=2>&gt; </FONT><BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
        Ambarish,</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; 
        Hi Santosh,</FONT> <BR><FONT size=2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; 
        Give me some time.... :-)</FONT> <BR><FONT size=2>&gt; &gt; 
        </FONT><BR><FONT size=2>&gt; &gt; I agree with your first 
        analysis:</FONT> <BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
        &gt; "If nextUpdate is not set, the responder is indicating that 
        newer</FONT> <BR><FONT size=2>&gt; &gt; revocation information is 
        available all the time"</FONT> <BR><FONT size=2>&gt; &gt; 
        </FONT><BR><FONT size=2>&gt; &gt; Actually, they way I would prefer to 
        state it would be something</FONT> <BR><FONT size=2>&gt; &gt; 
        like:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; &gt; "If 
        nextUpdate is not set, the responder is indicating that it</FONT> 
        <BR><FONT size=2>&gt; &gt; doesn't know when newer information will be 
        available and so, if</FONT> <BR><FONT size=2>&gt; &gt; a client wants 
        status information on the certificate in question</FONT> <BR><FONT 
        size=2>&gt; &gt; at a future date, it should come back and ask the 
        server again."</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
        I like your proposal, since this means that when using the 
        </FONT><BR><FONT size=2>&gt; on-line protocol </FONT><BR><FONT 
        size=2>&gt; it is not possible to know. Now we could add a sentence that 
        says:</FONT> <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; 
        "However, the Certificate Practice Statement and the </FONT><BR><FONT 
        size=2>&gt; Certificate Disclosure</FONT> <BR><FONT size=2>&gt; 
        Statement may provide more information about the refreshment 
        </FONT><BR><FONT size=2>&gt; conditions of</FONT> <BR><FONT size=2>&gt; 
        the status information."</FONT> <BR><FONT size=2>&gt;&nbsp; 
        </FONT><BR><FONT size=2>&gt; Denis</FONT> <BR><FONT size=2>&gt; 
        </FONT><BR><FONT size=2>&gt; &gt; This is my personal opinion. If the 
        group agrees, I am happy to</FONT> <BR><FONT size=2>&gt; &gt; modify the 
        document to reflect this point of view.</FONT> <BR><FONT size=2>&gt; 
        &gt; </FONT><BR><FONT size=2>&gt; &gt; Regards,</FONT> <BR><FONT 
        size=2>&gt; &gt; Ambarish</FONT> <BR><FONT size=2>&gt; &gt; 
        </FONT><BR><FONT size=2>&gt; &gt; </FONT><BR><FONT size=2>&gt; 
        ---------------------------------------------------------------------</FONT> 
        <BR><FONT size=2>&gt; &gt; Ambarish Malpani</FONT> <BR><FONT size=2>&gt; 
        &gt; 
        Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        </FONT><BR><FONT size=2>&gt; 650.567.5457</FONT> <BR><FONT size=2>&gt; 
        &gt; ValiCert, 
        Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        </FONT><BR><FONT size=2>&gt; [e-mail]</FONT> <BR><FONT 
        size=2>&gt; &gt; 339 N. Bernardo 
        Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
        </FONT><BR><FONT size=2><A target=_blank 
        href="http://www.valicert.com">http://www.valicert.com</A></FONT> 
        <BR><FONT size=2>&gt; Mountain View, CA 94043</FONT> <BR><FONT 
        size=2>&gt; </FONT><BR><FONT size=2>&gt; -----Original 
        Message-----</FONT> <BR><FONT size=2>&gt; From: Santosh Chokhani [<A 
        href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
        <BR><FONT size=2>&gt; Sent: Wednesday, January 16, 2002 11:50 AM</FONT> 
        <BR><FONT size=2>&gt; To: Peter Williams; 'Denis Pinkas '; Santosh 
        Chokhani</FONT> <BR><FONT size=2>&gt; Cc: '[e-mail] '</FONT> 
        <BR><FONT size=2>&gt; Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> 
        <BR><FONT size=2>&gt; </FONT><BR><FONT size=2>&gt; Why aren't the 
        authors responding to this contradiction in the RFC and</FONT> <BR><FONT 
        size=2>&gt; carried out in the ID?</FONT> <BR><FONT size=2>&gt; 
        -----Original Message-----</FONT> <BR><FONT size=2>&gt; From: Peter 
        Williams [<A 
        href="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT> 
        <BR><FONT size=2>&gt; Sent: Wednesday, January 16, 2002 2:41 PM</FONT> 
        <BR><FONT size=2>&gt; To: 'Denis Pinkas '; 'Santosh Chokhani '</FONT> 
        <BR><FONT size=2>&gt; Cc: '[e-mail] '</FONT> <BR><FONT 
        size=2>&gt; Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> <BR><FONT 
        size=2>&gt; </FONT><BR><FONT size=2>&gt; Denis,</FONT> <BR><FONT 
        size=2>&gt; You refer to an assumed&nbsp; "main mechanism" in your note. 
        Speaking</FONT> <BR><FONT size=2>factually,</FONT> <BR><FONT size=2>&gt; 
        to hopefully guide you, sensibly:-</FONT> <BR><FONT size=2>&gt; The main 
        [reference] mechanism(s) at, and shortly after,</FONT> <BR><FONT 
        size=2>&gt; the time of writing OCSP IDs included:-</FONT> <BR><FONT 
        size=2>&gt; (1) VeriSign, who used an oracle database-based repository 
        to feed data</FONT> <BR><FONT size=2>&gt; to OCSP deamons acting in 
        cached and interactive, direct-trust</FONT> <BR><FONT size=2>&gt; mode; 
        CRLs were not involved. OCSP proxing/multiplexing interactive</FONT> 
        <BR><FONT size=2>&gt; direct-trust mode was&nbsp; added, shortly after 
        standarization, for a</FONT> <BR><FONT size=2>&gt; defense customer 
        bridging multiple certification domains.</FONT> <BR><FONT size=2>&gt; 
        (2) ValiCert, who used direct CRLs to feed data to direct/indirect 
        OCSP</FONT> <BR><FONT size=2>&gt; deamons. Indirect CRLs and CRLDPs 
        support was added slightly after</FONT> <BR><FONT size=2>&gt; the 
        architects had harmonized their work.</FONT> <BR><FONT size=2>&gt; Both 
        mechanisms evolved further, outside of IETF and</FONT> <BR><FONT 
        size=2>&gt; in vendor forums, particularly in the area of: 
        application</FONT> <BR><FONT size=2>&gt; integration, CRLDPs and 
        delta-CRL data sources, proxying</FONT> <BR><FONT size=2>&gt; 
        transaction semantics and response resigning, data freshness</FONT> 
        <BR><FONT size=2>&gt; signalling, and OCSP client interaction with X.509 
        and</FONT> <BR><FONT size=2>&gt; PKIX-style path processing and X.509 
        applications such as</FONT> <BR><FONT size=2>&gt; SSLv3/https and 
        MTA-based automatic xmldsig signature</FONT> <BR><FONT size=2>&gt; 
        verification on B2B and banking protocol XML streams.</FONT> <BR><FONT 
        size=2>&gt; Historically, this work essentially re-designed the 
        standardized</FONT> <BR><FONT size=2>&gt; features of the "distributed 
        authentication model" of</FONT> <BR><FONT size=2>&gt; X.500 1988, for 
        OCSP-borne queries.</FONT> <BR><FONT size=2>&gt; Currently, VeriSign's 
        current work in W3C also</FONT> <BR><FONT size=2>&gt; reflects alot of 
        the understanding on the required</FONT> <BR><FONT size=2>&gt; semantics 
        of realtime trust models.</FONT> <BR><FONT size=2>&gt; Peter.</FONT> 
        <BR><FONT size=2>&gt; -----Original Message-----</FONT> <BR><FONT 
        size=2>&gt; From: Denis Pinkas</FONT> <BR><FONT size=2>&gt; To: Santosh 
        Chokhani</FONT> <BR><FONT size=2>&gt; Cc: [e-mail]</FONT> 
        <BR><FONT size=2>&gt; Sent: 1/16/02 12:04 AM</FONT> <BR><FONT 
        size=2>&gt; Subject: Re: OCSP RFC and OCSP version 2 ID</FONT> <BR><FONT 
        size=2>&gt; At the time the document was written, the main mechanism to 
        feed the</FONT> <BR><FONT size=2>&gt; information to the OCSP server was 
        to use CRLs. So it seems sensible to</FONT> <BR><FONT size=2>&gt; think 
        that these fields are copied from a CRL.</FONT> <BR><FONT 
        size=2>&gt;</FONT> 
</P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C19F8C.538A60A0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HJ9kF24126 for ietf-pkix-bks; Thu, 17 Jan 2002 11:09:46 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HJ9j324122 for <[e-mail]>; Thu, 17 Jan 2002 11:09:45 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <D1BG8M75>; Thu, 17 Jan 2002 14:09:42 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B62A@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: Santosh Chokhani <[e-mail]>, Ambarish Malpani <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 14:08:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19F8A.58554110"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C19F8A.58554110
Content-Type: text/plain

Upon further reflection, I think thisUpdate DOES take care of it.

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
response is available all the time.
 
I am trying to account for situations when the response is real-time (or
near real-time).

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


 
Santosh, why doesn't thisUpdate meet that need?
 
A
 

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID



I agree with what Ambarish and Carlisle are saying. 

I have one addition question though.  Should the standard provide a
capability to the relying parties (OCSP clients) that the current revocation
information is always available. If people agree that it should, given the
proposed meaning of nextUpdate, the additional capability can be handled via
a SingleResponse extension.

-----Original Message----- 
From: Ambarish Malpani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; '[e-mail] ' 
Subject: RE: OCSP RFC and OCSP version 2 ID 




Hi Denis, 
    Information about how up to date the information is, is 
already present in the thisUpdate field in the response. 

So, for example, if you *know* that you have information that is 
current as of 5 seconds ago, you can set that field appropriately. 

Does this meet your needs? 

Regards, 
Ambarish 

--------------------------------------------------------------------- 
Ambarish Malpani 
Architect                                                650.567.5457 
ValiCert, Inc.                                  [e-mail] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 


> -----Original Message----- 
> From: Denis Pinkas [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; '[e-mail] ' 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> 
> 
> Ambarish, 
> 
> > Hi Santosh, 
> >     Give me some time.... :-) 
> > 
> > I agree with your first analysis: 
> > 
> > "If nextUpdate is not set, the responder is indicating that newer 
> > revocation information is available all the time" 
> > 
> > Actually, they way I would prefer to state it would be something 
> > like: 
> 
> > "If nextUpdate is not set, the responder is indicating that it 
> > doesn't know when newer information will be available and so, if 
> > a client wants status information on the certificate in question 
> > at a future date, it should come back and ask the server again." 
> 
> I like your proposal, since this means that when using the 
> on-line protocol 
> it is not possible to know. Now we could add a sentence that says: 
> 
> "However, the Certificate Practice Statement and the 
> Certificate Disclosure 
> Statement may provide more information about the refreshment 
> conditions of 
> the status information." 
>  
> Denis 
> 
> > This is my personal opinion. If the group agrees, I am happy to 
> > modify the document to reflect this point of view. 
> > 
> > Regards, 
> > Ambarish 
> > 
> > 
> --------------------------------------------------------------------- 
> > Ambarish Malpani 
> > Architect                                                
> 650.567.5457 
> > ValiCert, Inc.                                  
> [e-mail] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Why aren't the authors responding to this contradiction in the RFC and 
> carried out in the ID? 
> -----Original Message----- 
> From: Peter Williams [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Denis, 
> You refer to an assumed  "main mechanism" in your note. Speaking 
factually, 
> to hopefully guide you, sensibly:- 
> The main [reference] mechanism(s) at, and shortly after, 
> the time of writing OCSP IDs included:- 
> (1) VeriSign, who used an oracle database-based repository to feed data 
> to OCSP deamons acting in cached and interactive, direct-trust 
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive 
> direct-trust mode was  added, shortly after standarization, for a 
> defense customer bridging multiple certification domains. 
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP 
> deamons. Indirect CRLs and CRLDPs support was added slightly after 
> the architects had harmonized their work. 
> Both mechanisms evolved further, outside of IETF and 
> in vendor forums, particularly in the area of: application 
> integration, CRLDPs and delta-CRL data sources, proxying 
> transaction semantics and response resigning, data freshness 
> signalling, and OCSP client interaction with X.509 and 
> PKIX-style path processing and X.509 applications such as 
> SSLv3/https and MTA-based automatic xmldsig signature 
> verification on B2B and banking protocol XML streams. 
> Historically, this work essentially re-designed the standardized 
> features of the "distributed authentication model" of 
> X.500 1988, for OCSP-borne queries. 
> Currently, VeriSign's current work in W3C also 
> reflects alot of the understanding on the required 
> semantics of realtime trust models. 
> Peter. 
> -----Original Message----- 
> From: Denis Pinkas 
> To: Santosh Chokhani 
> Cc: [e-mail] 
> Sent: 1/16/02 12:04 AM 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> At the time the document was written, the main mechanism to feed the 
> information to the OCSP server was to use CRLs. So it seems sensible to 
> think that these fields are copied from a CRL. 
> 


------_=_NextPart_001_01C19F8A.58554110
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>

<META content=3D"MSHTML 5.50.4912.300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D242550819-17012002><FONT face=3DArial =
color=3D#0000ff size=3D2>Upon=20
further reflection, I think thisUpdate DOES take care of =
it.</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, =
2002 2:01=20
  PM<BR><B>To:</B> Ambarish Malpani; Santosh Chokhani; =
'[e-mail]=20
  '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 =
ID<BR><BR></FONT></DIV>
  <DIV><SPAN class=3D179530019-17012002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2>Ambarish: Are you suggesting that when =
thisUpdate=3DnextUpdate that means=20
  response is available all the time.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D179530019-17012002><FONT face=3DArial =
color=3D#0000ff=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D179530019-17012002><FONT face=3DArial =
color=3D#0000ff size=3D2>I am=20
  trying to account for situations when the response is real-time (or =
near=20
  real-time).</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Ambarish =
Malpani=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January =
17, 2002=20
    1:56 PM<BR><B>To:</B> 'Santosh Chokhani'; '[e-mail]=20
    '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 =
ID<BR><BR></FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D289555818-17012002>Santosh, why doesn't thisUpdate meet =
that=20
    need?</SPAN></FONT></DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D289555818-17012002></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
    class=3D289555818-17012002>A</SPAN></FONT></DIV>
    <DIV>&nbsp;</DIV>
    <P><FONT=20
    =
size=3D2>---------------------------------------------------------------=
------<BR>Ambarish=20
    =
Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
    650.567.5457<BR>ValiCert,=20
    =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    [e-mail]<BR>339 N. Bernardo=20
    =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
    <A target=3D_blank=20
    =
href=3D"http://www.valicert.com/">http://www.valicert.com</A><BR>Mountai=
n=20
    View, CA 94043<BR></FONT></P>
    <BLOCKQUOTE=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> Santosh =
Chokhani=20
      [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January =
17, 2002=20
      10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas';=20
      '[e-mail] '<BR><B>Subject:</B> RE: OCSP RFC and OCSP =
version 2=20
      ID<BR><BR></DIV></FONT>
      <P><FONT size=3D2>I agree with what Ambarish and Carlisle are =
saying.</FONT>=20
      </P>
      <P><FONT size=3D2>I have one addition question though.&nbsp; =
Should the=20
      standard provide a capability to the relying parties (OCSP =
clients) that=20
      the current revocation information is always available. If people =
agree=20
      that it should, given the proposed meaning of nextUpdate, the =
additional=20
      capability can be handled via a SingleResponse =
extension.</FONT></P>
      <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
      Ambarish Malpani [<A=20
      =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>=20
      <BR><FONT size=3D2>Sent: Thursday, January 17, 2002 11:53 =
AM</FONT>=20
      <BR><FONT size=3D2>To: 'Denis Pinkas'; '[e-mail] =
'</FONT> <BR><FONT=20
      size=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> =
</P><BR><BR><BR>
      <P><FONT size=3D2>Hi Denis,</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
      Information about how up to date the information is, is</FONT> =
<BR><FONT=20
      size=3D2>already present in the thisUpdate field in the =
response.</FONT>=20
</P>
      <P><FONT size=3D2>So, for example, if you *know* that you have =
information=20
      that is</FONT> <BR><FONT size=3D2>current as of 5 seconds ago, =
you can set=20
      that field appropriately.</FONT> </P>
      <P><FONT size=3D2>Does this meet your needs?</FONT> </P>
      <P><FONT size=3D2>Regards,</FONT> <BR><FONT =
size=3D2>Ambarish</FONT> </P>
      <P><FONT=20
      =
size=3D2>---------------------------------------------------------------=
------</FONT>=20
      <BR><FONT size=3D2>Ambarish Malpani</FONT> <BR><FONT=20
      =
size=3D2>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
      650.567.5457</FONT> <BR><FONT size=3D2>ValiCert,=20
      =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      [e-mail]</FONT> <BR><FONT size=3D2>339 N. Bernardo=20
      =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
      <A target=3D_blank=20
      =
href=3D"http://www.valicert.com">http://www.valicert.com</A></FONT>=20
      <BR><FONT size=3D2>Mountain View, CA 94043</FONT> </P><BR>
      <P><FONT size=3D2>&gt; -----Original Message-----</FONT> =
<BR><FONT=20
      size=3D2>&gt; From: Denis Pinkas [<A=20
      =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>=20
      <BR><FONT size=3D2>&gt; Sent: Thursday, January 17, 2002 8:50 =
AM</FONT>=20
      <BR><FONT size=3D2>&gt; To: Ambarish Malpani</FONT> <BR><FONT =
size=3D2>&gt;=20
      Cc: 'Santosh Chokhani'; '[e-mail] '</FONT> <BR><FONT =
size=3D2>&gt;=20
      Subject: Re: OCSP RFC and OCSP version 2 ID</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
Ambarish,</FONT>=20
      <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; Hi =
Santosh,</FONT>=20
      <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Give me some =
time....=20
      :-)</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt; I=20
      agree with your first analysis:</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; "If nextUpdate is not set, =
the responder=20
      is indicating that newer</FONT> <BR><FONT size=3D2>&gt; &gt; =
revocation=20
      information is available all the time"</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; Actually, they way I would =
prefer to=20
      state it would be something</FONT> <BR><FONT size=3D2>&gt; &gt; =
like:</FONT>=20
      <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; "If =
nextUpdate is=20
      not set, the responder is indicating that it</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt; doesn't know when newer information will be available and =
so,=20
      if</FONT> <BR><FONT size=3D2>&gt; &gt; a client wants status =
information on=20
      the certificate in question</FONT> <BR><FONT size=3D2>&gt; &gt; =
at a future=20
      date, it should come back and ask the server again."</FONT> =
<BR><FONT=20
      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; I like your =
proposal, since this=20
      means that when using the </FONT><BR><FONT size=3D2>&gt; on-line =
protocol=20
      </FONT><BR><FONT size=3D2>&gt; it is not possible to know. Now we =
could add=20
      a sentence that says:</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
      size=3D2>&gt; "However, the Certificate Practice Statement and =
the=20
      </FONT><BR><FONT size=3D2>&gt; Certificate Disclosure</FONT> =
<BR><FONT=20
      size=3D2>&gt; Statement may provide more information about the =
refreshment=20
      </FONT><BR><FONT size=3D2>&gt; conditions of</FONT> <BR><FONT =
size=3D2>&gt;=20
      the status information."</FONT> <BR><FONT size=3D2>&gt;&nbsp;=20
      </FONT><BR><FONT size=3D2>&gt; Denis</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; This is my personal opinion. =
If the=20
      group agrees, I am happy to</FONT> <BR><FONT size=3D2>&gt; &gt; =
modify the=20
      document to reflect this point of view.</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; Regards,</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt; Ambarish</FONT> <BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
      size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt;=20
      =
---------------------------------------------------------------------</F=
ONT>=20
      <BR><FONT size=3D2>&gt; &gt; Ambarish Malpani</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt;=20
      =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
      </FONT><BR><FONT size=3D2>&gt; 650.567.5457</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt; ValiCert,=20
      =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      </FONT><BR><FONT size=3D2>&gt; [e-mail]</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; 339 N. Bernardo=20
      =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
      </FONT><BR><FONT size=3D2><A target=3D_blank=20
      =
href=3D"http://www.valicert.com">http://www.valicert.com</A></FONT>=20
      <BR><FONT size=3D2>&gt; Mountain View, CA 94043</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; -----Original Message-----</FONT> =
<BR><FONT=20
      size=3D2>&gt; From: Santosh Chokhani [<A=20
      =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>=20
      <BR><FONT size=3D2>&gt; Sent: Wednesday, January 16, 2002 11:50 =
AM</FONT>=20
      <BR><FONT size=3D2>&gt; To: Peter Williams; 'Denis Pinkas '; =
Santosh=20
      Chokhani</FONT> <BR><FONT size=3D2>&gt; Cc: '[e-mail] =
'</FONT>=20
      <BR><FONT size=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>=20
      <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Why aren't =
the authors=20
      responding to this contradiction in the RFC and</FONT> <BR><FONT=20
      size=3D2>&gt; carried out in the ID?</FONT> <BR><FONT =
size=3D2>&gt;=20
      -----Original Message-----</FONT> <BR><FONT size=3D2>&gt; From: =
Peter=20
      Williams [<A=20
      =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>=20
      <BR><FONT size=3D2>&gt; Sent: Wednesday, January 16, 2002 2:41 =
PM</FONT>=20
      <BR><FONT size=3D2>&gt; To: 'Denis Pinkas '; 'Santosh Chokhani =
'</FONT>=20
      <BR><FONT size=3D2>&gt; Cc: '[e-mail] '</FONT> <BR><FONT =

      size=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> =
<BR><FONT=20
      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Denis,</FONT> =
<BR><FONT=20
      size=3D2>&gt; You refer to an assumed&nbsp; "main mechanism" in =
your note.=20
      Speaking</FONT> <BR><FONT size=3D2>factually,</FONT> <BR><FONT =
size=3D2>&gt;=20
      to hopefully guide you, sensibly:-</FONT> <BR><FONT size=3D2>&gt; =
The main=20
      [reference] mechanism(s) at, and shortly after,</FONT> <BR><FONT=20
      size=3D2>&gt; the time of writing OCSP IDs included:-</FONT> =
<BR><FONT=20
      size=3D2>&gt; (1) VeriSign, who used an oracle database-based =
repository to=20
      feed data</FONT> <BR><FONT size=3D2>&gt; to OCSP deamons acting =
in cached=20
      and interactive, direct-trust</FONT> <BR><FONT size=3D2>&gt; =
mode; CRLs were=20
      not involved. OCSP proxing/multiplexing interactive</FONT> =
<BR><FONT=20
      size=3D2>&gt; direct-trust mode was&nbsp; added, shortly after=20
      standarization, for a</FONT> <BR><FONT size=3D2>&gt; defense =
customer=20
      bridging multiple certification domains.</FONT> <BR><FONT =
size=3D2>&gt; (2)=20
      ValiCert, who used direct CRLs to feed data to direct/indirect =
OCSP</FONT>=20
      <BR><FONT size=3D2>&gt; deamons. Indirect CRLs and CRLDPs support =
was added=20
      slightly after</FONT> <BR><FONT size=3D2>&gt; the architects had =
harmonized=20
      their work.</FONT> <BR><FONT size=3D2>&gt; Both mechanisms =
evolved further,=20
      outside of IETF and</FONT> <BR><FONT size=3D2>&gt; in vendor =
forums,=20
      particularly in the area of: application</FONT> <BR><FONT =
size=3D2>&gt;=20
      integration, CRLDPs and delta-CRL data sources, proxying</FONT> =
<BR><FONT=20
      size=3D2>&gt; transaction semantics and response resigning, data=20
      freshness</FONT> <BR><FONT size=3D2>&gt; signalling, and OCSP =
client=20
      interaction with X.509 and</FONT> <BR><FONT size=3D2>&gt; =
PKIX-style path=20
      processing and X.509 applications such as</FONT> <BR><FONT =
size=3D2>&gt;=20
      SSLv3/https and MTA-based automatic xmldsig signature</FONT> =
<BR><FONT=20
      size=3D2>&gt; verification on B2B and banking protocol XML =
streams.</FONT>=20
      <BR><FONT size=3D2>&gt; Historically, this work essentially =
re-designed the=20
      standardized</FONT> <BR><FONT size=3D2>&gt; features of the =
"distributed=20
      authentication model" of</FONT> <BR><FONT size=3D2>&gt; X.500 =
1988, for=20
      OCSP-borne queries.</FONT> <BR><FONT size=3D2>&gt; Currently, =
VeriSign's=20
      current work in W3C also</FONT> <BR><FONT size=3D2>&gt; reflects =
alot of the=20
      understanding on the required</FONT> <BR><FONT size=3D2>&gt; =
semantics of=20
      realtime trust models.</FONT> <BR><FONT size=3D2>&gt; =
Peter.</FONT>=20
      <BR><FONT size=3D2>&gt; -----Original Message-----</FONT> =
<BR><FONT=20
      size=3D2>&gt; From: Denis Pinkas</FONT> <BR><FONT size=3D2>&gt; =
To: Santosh=20
      Chokhani</FONT> <BR><FONT size=3D2>&gt; Cc: =
[e-mail]</FONT>=20
      <BR><FONT size=3D2>&gt; Sent: 1/16/02 12:04 AM</FONT> <BR><FONT =
size=3D2>&gt;=20
      Subject: Re: OCSP RFC and OCSP version 2 ID</FONT> <BR><FONT =
size=3D2>&gt;=20
      At the time the document was written, the main mechanism to feed=20
      the</FONT> <BR><FONT size=3D2>&gt; information to the OCSP server =
was to use=20
      CRLs. So it seems sensible to</FONT> <BR><FONT size=3D2>&gt; =
think that=20
      these fields are copied from a CRL.</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
      </P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C19F8A.58554110--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HJ8Vb24099 for ietf-pkix-bks; Thu, 17 Jan 2002 11:08:31 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HJ8U324095 for <[e-mail]>; Thu, 17 Jan 2002 11:08:30 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 17 Jan 2002 11:08:32 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 17 Jan 2002 11:08:31 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <C2FYW93D>; Thu, 17 Jan 2002 11:08:29 -0800
Content-return: allowed
Date: Thu, 17 Jan 2002 11:08:21 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'Santosh Chokhani'" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative; boundary="Boundary_(ID_IEj5PRPrHzP9Mjms+bs90Q)"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_IEj5PRPrHzP9Mjms+bs90Q)
Content-type: text/plain

Hi Santosh,
    No, what I am suggesting, is that when thisUpdate ~= NOW, is when the
response is
real-time/near real-time.
 
A
 

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 11:01 AM
To: Ambarish Malpani; Santosh Chokhani; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
response is available all the time.
 
I am trying to account for situations when the response is real-time (or
near real-time).

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


 
Santosh, why doesn't thisUpdate meet that need?
 
A
 

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID



I agree with what Ambarish and Carlisle are saying. 

I have one addition question though.  Should the standard provide a
capability to the relying parties (OCSP clients) that the current revocation
information is always available. If people agree that it should, given the
proposed meaning of nextUpdate, the additional capability can be handled via
a SingleResponse extension.

-----Original Message----- 
From: Ambarish Malpani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; '[e-mail] ' 
Subject: RE: OCSP RFC and OCSP version 2 ID 




Hi Denis, 
    Information about how up to date the information is, is 
already present in the thisUpdate field in the response. 

So, for example, if you *know* that you have information that is 
current as of 5 seconds ago, you can set that field appropriately. 

Does this meet your needs? 

Regards, 
Ambarish 

--------------------------------------------------------------------- 
Ambarish Malpani 
Architect                                                650.567.5457 
ValiCert, Inc.                                  [e-mail] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 


> -----Original Message----- 
> From: Denis Pinkas [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; '[e-mail] ' 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> 
> 
> Ambarish, 
> 
> > Hi Santosh, 
> >     Give me some time.... :-) 
> > 
> > I agree with your first analysis: 
> > 
> > "If nextUpdate is not set, the responder is indicating that newer 
> > revocation information is available all the time" 
> > 
> > Actually, they way I would prefer to state it would be something 
> > like: 
> 
> > "If nextUpdate is not set, the responder is indicating that it 
> > doesn't know when newer information will be available and so, if 
> > a client wants status information on the certificate in question 
> > at a future date, it should come back and ask the server again." 
> 
> I like your proposal, since this means that when using the 
> on-line protocol 
> it is not possible to know. Now we could add a sentence that says: 
> 
> "However, the Certificate Practice Statement and the 
> Certificate Disclosure 
> Statement may provide more information about the refreshment 
> conditions of 
> the status information." 
>  
> Denis 
> 
> > This is my personal opinion. If the group agrees, I am happy to 
> > modify the document to reflect this point of view. 
> > 
> > Regards, 
> > Ambarish 
> > 
> > 
> --------------------------------------------------------------------- 
> > Ambarish Malpani 
> > Architect                                                
> 650.567.5457 
> > ValiCert, Inc.                                  
> [e-mail] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Why aren't the authors responding to this contradiction in the RFC and 
> carried out in the ID? 
> -----Original Message----- 
> From: Peter Williams [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Denis, 
> You refer to an assumed  "main mechanism" in your note. Speaking 
factually, 
> to hopefully guide you, sensibly:- 
> The main [reference] mechanism(s) at, and shortly after, 
> the time of writing OCSP IDs included:- 
> (1) VeriSign, who used an oracle database-based repository to feed data 
> to OCSP deamons acting in cached and interactive, direct-trust 
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive 
> direct-trust mode was  added, shortly after standarization, for a 
> defense customer bridging multiple certification domains. 
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP 
> deamons. Indirect CRLs and CRLDPs support was added slightly after 
> the architects had harmonized their work. 
> Both mechanisms evolved further, outside of IETF and 
> in vendor forums, particularly in the area of: application 
> integration, CRLDPs and delta-CRL data sources, proxying 
> transaction semantics and response resigning, data freshness 
> signalling, and OCSP client interaction with X.509 and 
> PKIX-style path processing and X.509 applications such as 
> SSLv3/https and MTA-based automatic xmldsig signature 
> verification on B2B and banking protocol XML streams. 
> Historically, this work essentially re-designed the standardized 
> features of the "distributed authentication model" of 
> X.500 1988, for OCSP-borne queries. 
> Currently, VeriSign's current work in W3C also 
> reflects alot of the understanding on the required 
> semantics of realtime trust models. 
> Peter. 
> -----Original Message----- 
> From: Denis Pinkas 
> To: Santosh Chokhani 
> Cc: [e-mail] 
> Sent: 1/16/02 12:04 AM 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> At the time the document was written, the main mechanism to feed the 
> information to the OCSP server was to use CRLs. So it seems sensible to 
> think that these fields are copied from a CRL. 
> 


--Boundary_(ID_IEj5PRPrHzP9Mjms+bs90Q)
Content-type: text/html
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>

<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN =
class=3D284131019-17012002>Hi=20
Santosh,</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D284131019-17012002>&nbsp;&nbsp;&nbsp; No, what I am suggesting, =
is that=20
when thisUpdate ~=3D NOW, is when the response is</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D284131019-17012002>real-time/near =
real-time.</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D284131019-17012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D284131019-17012002>A</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<P><FONT=20
size=3D2>---------------------------------------------------------------=
------<BR>Ambarish=20
Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
650.567.5457<BR>ValiCert,=20
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[e-mail]<BR>339 N. Bernardo=20
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
<A href=3D"http://www.valicert.com/"=20
target=3D_blank>http://www.valicert.com</A><BR>Mountain View, CA=20
94043<BR></FONT></P>
<BLOCKQUOTE dir=3Dltr=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, =
2002=20
  11:01 AM<BR><B>To:</B> Ambarish Malpani; Santosh Chokhani; =
'[e-mail]=20
  '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 =
ID<BR><BR></DIV></FONT>
  <DIV><SPAN class=3D179530019-17012002><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2>Ambarish: Are you suggesting that when =
thisUpdate=3DnextUpdate that means=20
  response is available all the time.</FONT></SPAN></DIV>
  <DIV><SPAN class=3D179530019-17012002><FONT color=3D#0000ff =
face=3DArial=20
  size=3D2></FONT></SPAN>&nbsp;</DIV>
  <DIV><SPAN class=3D179530019-17012002><FONT color=3D#0000ff =
face=3DArial size=3D2>I am=20
  trying to account for situations when the response is real-time (or =
near=20
  real-time).</FONT></SPAN></DIV>
  <BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
    <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
    size=3D2>-----Original Message-----<BR><B>From:</B> Ambarish =
Malpani=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January =
17, 2002=20
    1:56 PM<BR><B>To:</B> 'Santosh Chokhani'; '[e-mail]=20
    '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 =
ID<BR><BR></FONT></DIV>
    <DIV>&nbsp;</DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D289555818-17012002>Santosh, why doesn't thisUpdate meet =
that=20
    need?</SPAN></FONT></DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D289555818-17012002></SPAN></FONT>&nbsp;</DIV>
    <DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
    class=3D289555818-17012002>A</SPAN></FONT></DIV>
    <DIV>&nbsp;</DIV>
    <P><FONT=20
    =
size=3D2>---------------------------------------------------------------=
------<BR>Ambarish=20
    =
Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
    650.567.5457<BR>ValiCert,=20
    =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    [e-mail]<BR>339 N. Bernardo=20
    =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
    <A href=3D"http://www.valicert.com/"=20
    target=3D_blank>http://www.valicert.com</A><BR>Mountain View, CA=20
    94043<BR></FONT></P>
    <BLOCKQUOTE=20
    style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
      <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
      size=3D2>-----Original Message-----<BR><B>From:</B> Santosh =
Chokhani=20
      [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January =
17, 2002=20
      10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas';=20
      '[e-mail] '<BR><B>Subject:</B> RE: OCSP RFC and OCSP =
version 2=20
      ID<BR><BR></DIV></FONT>
      <P><FONT size=3D2>I agree with what Ambarish and Carlisle are =
saying.</FONT>=20
      </P>
      <P><FONT size=3D2>I have one addition question though.&nbsp; =
Should the=20
      standard provide a capability to the relying parties (OCSP =
clients) that=20
      the current revocation information is always available. If people =
agree=20
      that it should, given the proposed meaning of nextUpdate, the =
additional=20
      capability can be handled via a SingleResponse =
extension.</FONT></P>
      <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
      Ambarish Malpani [<A=20
      =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>=20
      <BR><FONT size=3D2>Sent: Thursday, January 17, 2002 11:53 =
AM</FONT>=20
      <BR><FONT size=3D2>To: 'Denis Pinkas'; '[e-mail] =
'</FONT> <BR><FONT=20
      size=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> =
</P><BR><BR><BR>
      <P><FONT size=3D2>Hi Denis,</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
      Information about how up to date the information is, is</FONT> =
<BR><FONT=20
      size=3D2>already present in the thisUpdate field in the =
response.</FONT>=20
</P>
      <P><FONT size=3D2>So, for example, if you *know* that you have =
information=20
      that is</FONT> <BR><FONT size=3D2>current as of 5 seconds ago, =
you can set=20
      that field appropriately.</FONT> </P>
      <P><FONT size=3D2>Does this meet your needs?</FONT> </P>
      <P><FONT size=3D2>Regards,</FONT> <BR><FONT =
size=3D2>Ambarish</FONT> </P>
      <P><FONT=20
      =
size=3D2>---------------------------------------------------------------=
------</FONT>=20
      <BR><FONT size=3D2>Ambarish Malpani</FONT> <BR><FONT=20
      =
size=3D2>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
      650.567.5457</FONT> <BR><FONT size=3D2>ValiCert,=20
      =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      [e-mail]</FONT> <BR><FONT size=3D2>339 N. Bernardo=20
      =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
      <A href=3D"http://www.valicert.com"=20
      target=3D_blank>http://www.valicert.com</A></FONT> <BR><FONT =
size=3D2>Mountain 
      View, CA 94043</FONT> </P><BR>
      <P><FONT size=3D2>&gt; -----Original Message-----</FONT> =
<BR><FONT=20
      size=3D2>&gt; From: Denis Pinkas [<A=20
      =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>=20
      <BR><FONT size=3D2>&gt; Sent: Thursday, January 17, 2002 8:50 =
AM</FONT>=20
      <BR><FONT size=3D2>&gt; To: Ambarish Malpani</FONT> <BR><FONT =
size=3D2>&gt;=20
      Cc: 'Santosh Chokhani'; '[e-mail] '</FONT> <BR><FONT =
size=3D2>&gt;=20
      Subject: Re: OCSP RFC and OCSP version 2 ID</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
Ambarish,</FONT>=20
      <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; Hi =
Santosh,</FONT>=20
      <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Give me some =
time....=20
      :-)</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt; I=20
      agree with your first analysis:</FONT> <BR><FONT size=3D2>&gt; =
&gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; "If nextUpdate is not set, =
the responder=20
      is indicating that newer</FONT> <BR><FONT size=3D2>&gt; &gt; =
revocation=20
      information is available all the time"</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; Actually, they way I would =
prefer to=20
      state it would be something</FONT> <BR><FONT size=3D2>&gt; &gt; =
like:</FONT>=20
      <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; "If =
nextUpdate is=20
      not set, the responder is indicating that it</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt; doesn't know when newer information will be available and =
so,=20
      if</FONT> <BR><FONT size=3D2>&gt; &gt; a client wants status =
information on=20
      the certificate in question</FONT> <BR><FONT size=3D2>&gt; &gt; =
at a future=20
      date, it should come back and ask the server again."</FONT> =
<BR><FONT=20
      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; I like your =
proposal, since this=20
      means that when using the </FONT><BR><FONT size=3D2>&gt; on-line =
protocol=20
      </FONT><BR><FONT size=3D2>&gt; it is not possible to know. Now we =
could add=20
      a sentence that says:</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
      size=3D2>&gt; "However, the Certificate Practice Statement and =
the=20
      </FONT><BR><FONT size=3D2>&gt; Certificate Disclosure</FONT> =
<BR><FONT=20
      size=3D2>&gt; Statement may provide more information about the =
refreshment=20
      </FONT><BR><FONT size=3D2>&gt; conditions of</FONT> <BR><FONT =
size=3D2>&gt;=20
      the status information."</FONT> <BR><FONT size=3D2>&gt;&nbsp;=20
      </FONT><BR><FONT size=3D2>&gt; Denis</FONT> <BR><FONT =
size=3D2>&gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; This is my personal opinion. =
If the=20
      group agrees, I am happy to</FONT> <BR><FONT size=3D2>&gt; &gt; =
modify the=20
      document to reflect this point of view.</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
      </FONT><BR><FONT size=3D2>&gt; &gt; Regards,</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt; Ambarish</FONT> <BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
      size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt;=20
      =
---------------------------------------------------------------------</F=
ONT>=20
      <BR><FONT size=3D2>&gt; &gt; Ambarish Malpani</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt;=20
      =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
      </FONT><BR><FONT size=3D2>&gt; 650.567.5457</FONT> <BR><FONT =
size=3D2>&gt;=20
      &gt; ValiCert,=20
      =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      </FONT><BR><FONT size=3D2>&gt; [e-mail]</FONT> =
<BR><FONT=20
      size=3D2>&gt; &gt; 339 N. Bernardo=20
      =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
      </FONT><BR><FONT size=3D2><A href=3D"http://www.valicert.com"=20
      target=3D_blank>http://www.valicert.com</A></FONT> <BR><FONT =
size=3D2>&gt;=20
      Mountain View, CA 94043</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
      size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt; From:=20
      Santosh Chokhani [<A=20
      =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>=20
      <BR><FONT size=3D2>&gt; Sent: Wednesday, January 16, 2002 11:50 =
AM</FONT>=20
      <BR><FONT size=3D2>&gt; To: Peter Williams; 'Denis Pinkas '; =
Santosh=20
      Chokhani</FONT> <BR><FONT size=3D2>&gt; Cc: '[e-mail] =
'</FONT>=20
      <BR><FONT size=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>=20
      <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Why aren't =
the authors=20
      responding to this contradiction in the RFC and</FONT> <BR><FONT=20
      size=3D2>&gt; carried out in the ID?</FONT> <BR><FONT =
size=3D2>&gt;=20
      -----Original Message-----</FONT> <BR><FONT size=3D2>&gt; From: =
Peter=20
      Williams [<A=20
      =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>=20
      <BR><FONT size=3D2>&gt; Sent: Wednesday, January 16, 2002 2:41 =
PM</FONT>=20
      <BR><FONT size=3D2>&gt; To: 'Denis Pinkas '; 'Santosh Chokhani =
'</FONT>=20
      <BR><FONT size=3D2>&gt; Cc: '[e-mail] '</FONT> <BR><FONT =

      size=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> =
<BR><FONT=20
      size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Denis,</FONT> =
<BR><FONT=20
      size=3D2>&gt; You refer to an assumed&nbsp; "main mechanism" in =
your note.=20
      Speaking</FONT> <BR><FONT size=3D2>factually,</FONT> <BR><FONT =
size=3D2>&gt;=20
      to hopefully guide you, sensibly:-</FONT> <BR><FONT size=3D2>&gt; =
The main=20
      [reference] mechanism(s) at, and shortly after,</FONT> <BR><FONT=20
      size=3D2>&gt; the time of writing OCSP IDs included:-</FONT> =
<BR><FONT=20
      size=3D2>&gt; (1) VeriSign, who used an oracle database-based =
repository to=20
      feed data</FONT> <BR><FONT size=3D2>&gt; to OCSP deamons acting =
in cached=20
      and interactive, direct-trust</FONT> <BR><FONT size=3D2>&gt; =
mode; CRLs were=20
      not involved. OCSP proxing/multiplexing interactive</FONT> =
<BR><FONT=20
      size=3D2>&gt; direct-trust mode was&nbsp; added, shortly after=20
      standarization, for a</FONT> <BR><FONT size=3D2>&gt; defense =
customer=20
      bridging multiple certification domains.</FONT> <BR><FONT =
size=3D2>&gt; (2)=20
      ValiCert, who used direct CRLs to feed data to direct/indirect =
OCSP</FONT>=20
      <BR><FONT size=3D2>&gt; deamons. Indirect CRLs and CRLDPs support =
was added=20
      slightly after</FONT> <BR><FONT size=3D2>&gt; the architects had =
harmonized=20
      their work.</FONT> <BR><FONT size=3D2>&gt; Both mechanisms =
evolved further,=20
      outside of IETF and</FONT> <BR><FONT size=3D2>&gt; in vendor =
forums,=20
      particularly in the area of: application</FONT> <BR><FONT =
size=3D2>&gt;=20
      integration, CRLDPs and delta-CRL data sources, proxying</FONT> =
<BR><FONT=20
      size=3D2>&gt; transaction semantics and response resigning, data=20
      freshness</FONT> <BR><FONT size=3D2>&gt; signalling, and OCSP =
client=20
      interaction with X.509 and</FONT> <BR><FONT size=3D2>&gt; =
PKIX-style path=20
      processing and X.509 applications such as</FONT> <BR><FONT =
size=3D2>&gt;=20
      SSLv3/https and MTA-based automatic xmldsig signature</FONT> =
<BR><FONT=20
      size=3D2>&gt; verification on B2B and banking protocol XML =
streams.</FONT>=20
      <BR><FONT size=3D2>&gt; Historically, this work essentially =
re-designed the=20
      standardized</FONT> <BR><FONT size=3D2>&gt; features of the =
"distributed=20
      authentication model" of</FONT> <BR><FONT size=3D2>&gt; X.500 =
1988, for=20
      OCSP-borne queries.</FONT> <BR><FONT size=3D2>&gt; Currently, =
VeriSign's=20
      current work in W3C also</FONT> <BR><FONT size=3D2>&gt; reflects =
alot of the=20
      understanding on the required</FONT> <BR><FONT size=3D2>&gt; seman=
tics of=20
      realtime trust models.</FONT> <BR><FONT size=3D2>&gt; =
Peter.</FONT>=20
      <BR><FONT size=3D2>&gt; -----Original Message-----</FONT> =
<BR><FONT=20
      size=3D2>&gt; From: Denis Pinkas</FONT> <BR><FONT size=3D2>&gt; =
To: Santosh=20
      Chokhani</FONT> <BR><FONT size=3D2>&gt; Cc: =
[e-mail]</FONT>=20
      <BR><FONT size=3D2>&gt; Sent: 1/16/02 12:04 AM</FONT> <BR><FONT =
size=3D2>&gt;=20
      Subject: Re: OCSP RFC and OCSP version 2 ID</FONT> <BR><FONT =
size=3D2>&gt;=20
      At the time the document was written, the main mechanism to feed=20
      the</FONT> <BR><FONT size=3D2>&gt; information to the OCSP server =
was to use=20
      CRLs. So it seems sensible to</FONT> <BR><FONT size=3D2>&gt; =
think that=20
      these fields are copied from a CRL.</FONT> <BR><FONT =
size=3D2>&gt;</FONT>=20
      </P></BLOCKQUOTE></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_IEj5PRPrHzP9Mjms+bs90Q)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HJ2MU23940 for ietf-pkix-bks; Thu, 17 Jan 2002 11:02:22 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HJ2L323935 for <[e-mail]>; Thu, 17 Jan 2002 11:02:21 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <D1BG8MZS>; Thu, 17 Jan 2002 14:02:18 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B627@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: Ambarish Malpani <[e-mail]>, Santosh Chokhani <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 14:01:04 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19F89.50120A20"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C19F89.50120A20
Content-Type: text/plain

Ambarish: Are you suggesting that when thisUpdate=nextUpdate that means
response is available all the time.
 
I am trying to account for situations when the response is real-time (or
near real-time).

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


 
Santosh, why doesn't thisUpdate meet that need?
 
A
 

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID



I agree with what Ambarish and Carlisle are saying. 

I have one addition question though.  Should the standard provide a
capability to the relying parties (OCSP clients) that the current revocation
information is always available. If people agree that it should, given the
proposed meaning of nextUpdate, the additional capability can be handled via
a SingleResponse extension.

-----Original Message----- 
From: Ambarish Malpani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; '[e-mail] ' 
Subject: RE: OCSP RFC and OCSP version 2 ID 




Hi Denis, 
    Information about how up to date the information is, is 
already present in the thisUpdate field in the response. 

So, for example, if you *know* that you have information that is 
current as of 5 seconds ago, you can set that field appropriately. 

Does this meet your needs? 

Regards, 
Ambarish 

--------------------------------------------------------------------- 
Ambarish Malpani 
Architect                                                650.567.5457 
ValiCert, Inc.                                  [e-mail] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 


> -----Original Message----- 
> From: Denis Pinkas [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; '[e-mail] ' 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> 
> 
> Ambarish, 
> 
> > Hi Santosh, 
> >     Give me some time.... :-) 
> > 
> > I agree with your first analysis: 
> > 
> > "If nextUpdate is not set, the responder is indicating that newer 
> > revocation information is available all the time" 
> > 
> > Actually, they way I would prefer to state it would be something 
> > like: 
> 
> > "If nextUpdate is not set, the responder is indicating that it 
> > doesn't know when newer information will be available and so, if 
> > a client wants status information on the certificate in question 
> > at a future date, it should come back and ask the server again." 
> 
> I like your proposal, since this means that when using the 
> on-line protocol 
> it is not possible to know. Now we could add a sentence that says: 
> 
> "However, the Certificate Practice Statement and the 
> Certificate Disclosure 
> Statement may provide more information about the refreshment 
> conditions of 
> the status information." 
>  
> Denis 
> 
> > This is my personal opinion. If the group agrees, I am happy to 
> > modify the document to reflect this point of view. 
> > 
> > Regards, 
> > Ambarish 
> > 
> > 
> --------------------------------------------------------------------- 
> > Ambarish Malpani 
> > Architect                                                
> 650.567.5457 
> > ValiCert, Inc.                                  
> [e-mail] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Why aren't the authors responding to this contradiction in the RFC and 
> carried out in the ID? 
> -----Original Message----- 
> From: Peter Williams [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Denis, 
> You refer to an assumed  "main mechanism" in your note. Speaking 
factually, 
> to hopefully guide you, sensibly:- 
> The main [reference] mechanism(s) at, and shortly after, 
> the time of writing OCSP IDs included:- 
> (1) VeriSign, who used an oracle database-based repository to feed data 
> to OCSP deamons acting in cached and interactive, direct-trust 
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive 
> direct-trust mode was  added, shortly after standarization, for a 
> defense customer bridging multiple certification domains. 
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP 
> deamons. Indirect CRLs and CRLDPs support was added slightly after 
> the architects had harmonized their work. 
> Both mechanisms evolved further, outside of IETF and 
> in vendor forums, particularly in the area of: application 
> integration, CRLDPs and delta-CRL data sources, proxying 
> transaction semantics and response resigning, data freshness 
> signalling, and OCSP client interaction with X.509 and 
> PKIX-style path processing and X.509 applications such as 
> SSLv3/https and MTA-based automatic xmldsig signature 
> verification on B2B and banking protocol XML streams. 
> Historically, this work essentially re-designed the standardized 
> features of the "distributed authentication model" of 
> X.500 1988, for OCSP-borne queries. 
> Currently, VeriSign's current work in W3C also 
> reflects alot of the understanding on the required 
> semantics of realtime trust models. 
> Peter. 
> -----Original Message----- 
> From: Denis Pinkas 
> To: Santosh Chokhani 
> Cc: [e-mail] 
> Sent: 1/16/02 12:04 AM 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> At the time the document was written, the main mechanism to feed the 
> information to the OCSP server was to use CRLs. So it seems sensible to 
> think that these fields are copied from a CRL. 
> 


------_=_NextPart_001_01C19F89.50120A20
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>

<META content=3D"MSHTML 5.50.4912.300" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D179530019-17012002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2>Ambarish: Are you suggesting that when thisUpdate=3DnextUpdate =
that means=20
response is available all the time.</FONT></SPAN></DIV>
<DIV><SPAN class=3D179530019-17012002><FONT face=3DArial =
color=3D#0000ff=20
size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=3D179530019-17012002><FONT face=3DArial =
color=3D#0000ff size=3D2>I am=20
trying to account for situations when the response is real-time (or =
near=20
real-time).</FONT></SPAN></DIV>
<BLOCKQUOTE dir=3Dltr style=3D"MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader dir=3Dltr align=3Dleft><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Ambarish Malpani=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, =
2002 1:56=20
  PM<BR><B>To:</B> 'Santosh Chokhani'; '[e-mail] =
'<BR><B>Subject:</B>=20
  RE: OCSP RFC and OCSP version 2 ID<BR><BR></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D289555818-17012002>Santosh, why doesn't thisUpdate meet that=20
  need?</SPAN></FONT></DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D289555818-17012002></SPAN></FONT>&nbsp;</DIV>
  <DIV><FONT face=3DArial color=3D#0000ff size=3D2><SPAN=20
  class=3D289555818-17012002>A</SPAN></FONT></DIV>
  <DIV>&nbsp;</DIV>
  <P><FONT=20
  =
size=3D2>---------------------------------------------------------------=
------<BR>Ambarish=20
  =
Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
  650.567.5457<BR>ValiCert,=20
  =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [e-mail]<BR>339 N. Bernardo=20
  =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
  <A target=3D_blank=20
  =
href=3D"http://www.valicert.com/">http://www.valicert.com</A><BR>Mountai=
n View,=20
  CA 94043<BR></FONT></P>
  <BLOCKQUOTE=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> Santosh =
Chokhani=20
    [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January =
17, 2002=20
    10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas'; =
'[e-mail]=20
    '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 =
ID<BR><BR></DIV></FONT>
    <P><FONT size=3D2>I agree with what Ambarish and Carlisle are =
saying.</FONT>=20
    </P>
    <P><FONT size=3D2>I have one addition question though.&nbsp; Should =
the=20
    standard provide a capability to the relying parties (OCSP clients) =
that the=20
    current revocation information is always available. If people agree =
that it=20
    should, given the proposed meaning of nextUpdate, the additional =
capability=20
    can be handled via a SingleResponse extension.</FONT></P>
    <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
    Ambarish Malpani [<A=20
    =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>=20
    <BR><FONT size=3D2>Sent: Thursday, January 17, 2002 11:53 AM</FONT> =
<BR><FONT=20
    size=3D2>To: 'Denis Pinkas'; '[e-mail] '</FONT> <BR><FONT=20
    size=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> =
</P><BR><BR><BR>
    <P><FONT size=3D2>Hi Denis,</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
    Information about how up to date the information is, is</FONT> =
<BR><FONT=20
    size=3D2>already present in the thisUpdate field in the =
response.</FONT> </P>
    <P><FONT size=3D2>So, for example, if you *know* that you have =
information=20
    that is</FONT> <BR><FONT size=3D2>current as of 5 seconds ago, you =
can set=20
    that field appropriately.</FONT> </P>
    <P><FONT size=3D2>Does this meet your needs?</FONT> </P>
    <P><FONT size=3D2>Regards,</FONT> <BR><FONT =
size=3D2>Ambarish</FONT> </P>
    <P><FONT=20
    =
size=3D2>---------------------------------------------------------------=
------</FONT>=20
    <BR><FONT size=3D2>Ambarish Malpani</FONT> <BR><FONT=20
    =
size=3D2>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
    650.567.5457</FONT> <BR><FONT size=3D2>ValiCert,=20
    =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    [e-mail]</FONT> <BR><FONT size=3D2>339 N. Bernardo=20
    =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
    <A target=3D_blank=20
    href=3D"http://www.valicert.com">http://www.valicert.com</A></FONT> =
<BR><FONT=20
    size=3D2>Mountain View, CA 94043</FONT> </P><BR>
    <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
    From: Denis Pinkas [<A=20
    =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>=20
    <BR><FONT size=3D2>&gt; Sent: Thursday, January 17, 2002 8:50 =
AM</FONT>=20
    <BR><FONT size=3D2>&gt; To: Ambarish Malpani</FONT> <BR><FONT =
size=3D2>&gt; Cc:=20
    'Santosh Chokhani'; '[e-mail] '</FONT> <BR><FONT =
size=3D2>&gt;=20
    Subject: Re: OCSP RFC and OCSP version 2 ID</FONT> <BR><FONT =
size=3D2>&gt;=20
    </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
Ambarish,</FONT>=20
    <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; Hi =
Santosh,</FONT>=20
    <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Give me some =
time....=20
    :-)</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt; I=20
    agree with your first analysis:</FONT> <BR><FONT size=3D2>&gt; &gt; =

    </FONT><BR><FONT size=3D2>&gt; &gt; "If nextUpdate is not set, the =
responder=20
    is indicating that newer</FONT> <BR><FONT size=3D2>&gt; &gt; =
revocation=20
    information is available all the time"</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
    </FONT><BR><FONT size=3D2>&gt; &gt; Actually, they way I would =
prefer to state=20
    it would be something</FONT> <BR><FONT size=3D2>&gt; &gt; =
like:</FONT>=20
    <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; "If =
nextUpdate is=20
    not set, the responder is indicating that it</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt; doesn't know when newer information will be available and so, =
if</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; a client wants status information on =
the=20
    certificate in question</FONT> <BR><FONT size=3D2>&gt; &gt; at a =
future date,=20
    it should come back and ask the server again."</FONT> <BR><FONT =
size=3D2>&gt;=20
    </FONT><BR><FONT size=3D2>&gt; I like your proposal, since this =
means that=20
    when using the </FONT><BR><FONT size=3D2>&gt; on-line protocol=20
    </FONT><BR><FONT size=3D2>&gt; it is not possible to know. Now we =
could add a=20
    sentence that says:</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =

    size=3D2>&gt; "However, the Certificate Practice Statement and the=20
    </FONT><BR><FONT size=3D2>&gt; Certificate Disclosure</FONT> =
<BR><FONT=20
    size=3D2>&gt; Statement may provide more information about the =
refreshment=20
    </FONT><BR><FONT size=3D2>&gt; conditions of</FONT> <BR><FONT =
size=3D2>&gt; the=20
    status information."</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
</FONT><BR><FONT=20
    size=3D2>&gt; Denis</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
    &gt; This is my personal opinion. If the group agrees, I am happy =
to</FONT>=20
    <BR><FONT size=3D2>&gt; &gt; modify the document to reflect this =
point of=20
    view.</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
    Regards,</FONT> <BR><FONT size=3D2>&gt; &gt; Ambarish</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
    size=3D2>&gt;=20
    =
---------------------------------------------------------------------</F=
ONT>=20
    <BR><FONT size=3D2>&gt; &gt; Ambarish Malpani</FONT> <BR><FONT =
size=3D2>&gt;=20
    &gt;=20
    =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
    </FONT><BR><FONT size=3D2>&gt; 650.567.5457</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
    ValiCert,=20
    =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
    </FONT><BR><FONT size=3D2>&gt; [e-mail]</FONT> =
<BR><FONT=20
    size=3D2>&gt; &gt; 339 N. Bernardo=20
    =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
    </FONT><BR><FONT size=3D2><A target=3D_blank=20
    href=3D"http://www.valicert.com">http://www.valicert.com</A></FONT> =
<BR><FONT=20
    size=3D2>&gt; Mountain View, CA 94043</FONT> <BR><FONT =
size=3D2>&gt;=20
    </FONT><BR><FONT size=3D2>&gt; -----Original Message-----</FONT> =
<BR><FONT=20
    size=3D2>&gt; From: Santosh Chokhani [<A=20
    =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>=20
    <BR><FONT size=3D2>&gt; Sent: Wednesday, January 16, 2002 11:50 =
AM</FONT>=20
    <BR><FONT size=3D2>&gt; To: Peter Williams; 'Denis Pinkas '; =
Santosh=20
    Chokhani</FONT> <BR><FONT size=3D2>&gt; Cc: '[e-mail] =
'</FONT>=20
    <BR><FONT size=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>=20
    <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Why aren't =
the authors=20
    responding to this contradiction in the RFC and</FONT> <BR><FONT =
size=3D2>&gt;=20
    carried out in the ID?</FONT> <BR><FONT size=3D2>&gt; -----Original =

    Message-----</FONT> <BR><FONT size=3D2>&gt; From: Peter Williams =
[<A=20
    =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>=20
    <BR><FONT size=3D2>&gt; Sent: Wednesday, January 16, 2002 2:41 =
PM</FONT>=20
    <BR><FONT size=3D2>&gt; To: 'Denis Pinkas '; 'Santosh Chokhani =
'</FONT>=20
    <BR><FONT size=3D2>&gt; Cc: '[e-mail] '</FONT> <BR><FONT =
size=3D2>&gt;=20
    Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> <BR><FONT =
size=3D2>&gt;=20
    </FONT><BR><FONT size=3D2>&gt; Denis,</FONT> <BR><FONT =
size=3D2>&gt; You refer=20
    to an assumed&nbsp; "main mechanism" in your note. Speaking</FONT> =
<BR><FONT=20
    size=3D2>factually,</FONT> <BR><FONT size=3D2>&gt; to hopefully =
guide you,=20
    sensibly:-</FONT> <BR><FONT size=3D2>&gt; The main [reference] =
mechanism(s)=20
    at, and shortly after,</FONT> <BR><FONT size=3D2>&gt; the time of =
writing OCSP=20
    IDs included:-</FONT> <BR><FONT size=3D2>&gt; (1) VeriSign, who =
used an oracle=20
    database-based repository to feed data</FONT> <BR><FONT =
size=3D2>&gt; to OCSP=20
    deamons acting in cached and interactive, direct-trust</FONT> =
<BR><FONT=20
    size=3D2>&gt; mode; CRLs were not involved. OCSP =
proxing/multiplexing=20
    interactive</FONT> <BR><FONT size=3D2>&gt; direct-trust mode =
was&nbsp; added,=20
    shortly after standarization, for a</FONT> <BR><FONT size=3D2>&gt; =
defense=20
    customer bridging multiple certification domains.</FONT> <BR><FONT=20
    size=3D2>&gt; (2) ValiCert, who used direct CRLs to feed data to=20
    direct/indirect OCSP</FONT> <BR><FONT size=3D2>&gt; deamons. =
Indirect CRLs and=20
    CRLDPs support was added slightly after</FONT> <BR><FONT =
size=3D2>&gt; the=20
    architects had harmonized their work.</FONT> <BR><FONT =
size=3D2>&gt; Both=20
    mechanisms evolved further, outside of IETF and</FONT> <BR><FONT =
size=3D2>&gt;=20
    in vendor forums, particularly in the area of: application</FONT> =
<BR><FONT=20
    size=3D2>&gt; integration, CRLDPs and delta-CRL data sources, =
proxying</FONT>=20
    <BR><FONT size=3D2>&gt; transaction semantics and response =
resigning, data=20
    freshness</FONT> <BR><FONT size=3D2>&gt; signalling, and OCSP =
client=20
    interaction with X.509 and</FONT> <BR><FONT size=3D2>&gt; =
PKIX-style path=20
    processing and X.509 applications such as</FONT> <BR><FONT =
size=3D2>&gt;=20
    SSLv3/https and MTA-based automatic xmldsig signature</FONT> =
<BR><FONT=20
    size=3D2>&gt; verification on B2B and banking protocol XML =
streams.</FONT>=20
    <BR><FONT size=3D2>&gt; Historically, this work essentially =
re-designed the=20
    standardized</FONT> <BR><FONT size=3D2>&gt; features of the =
"distributed=20
    authentication model" of</FONT> <BR><FONT size=3D2>&gt; X.500 1988, =
for=20
    OCSP-borne queries.</FONT> <BR><FONT size=3D2>&gt; Currently, =
VeriSign's=20
    current work in W3C also</FONT> <BR><FONT size=3D2>&gt; reflects =
alot of the=20
    understanding on the required</FONT> <BR><FONT size=3D2>&gt; =
semantics of=20
    realtime trust models.</FONT> <BR><FONT size=3D2>&gt; Peter.</FONT> =
<BR><FONT=20
    size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt; From:=20
    Denis Pinkas</FONT> <BR><FONT size=3D2>&gt; To: Santosh =
Chokhani</FONT>=20
    <BR><FONT size=3D2>&gt; Cc: [e-mail]</FONT> <BR><FONT =
size=3D2>&gt;=20
    Sent: 1/16/02 12:04 AM</FONT> <BR><FONT size=3D2>&gt; Subject: Re: =
OCSP RFC=20
    and OCSP version 2 ID</FONT> <BR><FONT size=3D2>&gt; At the time =
the document=20
    was written, the main mechanism to feed the</FONT> <BR><FONT =
size=3D2>&gt;=20
    information to the OCSP server was to use CRLs. So it seems =
sensible=20
    to</FONT> <BR><FONT size=3D2>&gt; think that these fields are =
copied from a=20
    CRL.</FONT> <BR><FONT size=3D2>&gt;</FONT>=20
</P></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C19F89.50120A20--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HIuAp23761 for ietf-pkix-bks; Thu, 17 Jan 2002 10:56:10 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HIu9323757 for <[e-mail]>; Thu, 17 Jan 2002 10:56:09 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 17 Jan 2002 10:56:11 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 17 Jan 2002 10:56:10 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <C2FYW9MD>; Thu, 17 Jan 2002 10:56:08 -0800
Content-return: allowed
Date: Thu, 17 Jan 2002 10:56:08 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'Santosh Chokhani'" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: multipart/alternative; boundary="Boundary_(ID_vdDpiuMYz440jSUP+ifE0Q)"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--Boundary_(ID_vdDpiuMYz440jSUP+ifE0Q)
Content-type: text/plain

 
Santosh, why doesn't thisUpdate meet that need?
 
A
 

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043


-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID



I agree with what Ambarish and Carlisle are saying. 

I have one addition question though.  Should the standard provide a
capability to the relying parties (OCSP clients) that the current revocation
information is always available. If people agree that it should, given the
proposed meaning of nextUpdate, the additional capability can be handled via
a SingleResponse extension.

-----Original Message----- 
From: Ambarish Malpani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; '[e-mail] ' 
Subject: RE: OCSP RFC and OCSP version 2 ID 




Hi Denis, 
    Information about how up to date the information is, is 
already present in the thisUpdate field in the response. 

So, for example, if you *know* that you have information that is 
current as of 5 seconds ago, you can set that field appropriately. 

Does this meet your needs? 

Regards, 
Ambarish 

--------------------------------------------------------------------- 
Ambarish Malpani 
Architect                                                650.567.5457 
ValiCert, Inc.                                  [e-mail] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 


> -----Original Message----- 
> From: Denis Pinkas [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; '[e-mail] ' 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> 
> 
> Ambarish, 
> 
> > Hi Santosh, 
> >     Give me some time.... :-) 
> > 
> > I agree with your first analysis: 
> > 
> > "If nextUpdate is not set, the responder is indicating that newer 
> > revocation information is available all the time" 
> > 
> > Actually, they way I would prefer to state it would be something 
> > like: 
> 
> > "If nextUpdate is not set, the responder is indicating that it 
> > doesn't know when newer information will be available and so, if 
> > a client wants status information on the certificate in question 
> > at a future date, it should come back and ask the server again." 
> 
> I like your proposal, since this means that when using the 
> on-line protocol 
> it is not possible to know. Now we could add a sentence that says: 
> 
> "However, the Certificate Practice Statement and the 
> Certificate Disclosure 
> Statement may provide more information about the refreshment 
> conditions of 
> the status information." 
>  
> Denis 
> 
> > This is my personal opinion. If the group agrees, I am happy to 
> > modify the document to reflect this point of view. 
> > 
> > Regards, 
> > Ambarish 
> > 
> > 
> --------------------------------------------------------------------- 
> > Ambarish Malpani 
> > Architect                                                
> 650.567.5457 
> > ValiCert, Inc.                                  
> [e-mail] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Why aren't the authors responding to this contradiction in the RFC and 
> carried out in the ID? 
> -----Original Message----- 
> From: Peter Williams [ mailto:[e-mail]
<mailto:[e-mail]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: '[e-mail] ' 
> Subject: RE: OCSP RFC and OCSP version 2 ID 
> 
> Denis, 
> You refer to an assumed  "main mechanism" in your note. Speaking 
factually, 
> to hopefully guide you, sensibly:- 
> The main [reference] mechanism(s) at, and shortly after, 
> the time of writing OCSP IDs included:- 
> (1) VeriSign, who used an oracle database-based repository to feed data 
> to OCSP deamons acting in cached and interactive, direct-trust 
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive 
> direct-trust mode was  added, shortly after standarization, for a 
> defense customer bridging multiple certification domains. 
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP 
> deamons. Indirect CRLs and CRLDPs support was added slightly after 
> the architects had harmonized their work. 
> Both mechanisms evolved further, outside of IETF and 
> in vendor forums, particularly in the area of: application 
> integration, CRLDPs and delta-CRL data sources, proxying 
> transaction semantics and response resigning, data freshness 
> signalling, and OCSP client interaction with X.509 and 
> PKIX-style path processing and X.509 applications such as 
> SSLv3/https and MTA-based automatic xmldsig signature 
> verification on B2B and banking protocol XML streams. 
> Historically, this work essentially re-designed the standardized 
> features of the "distributed authentication model" of 
> X.500 1988, for OCSP-borne queries. 
> Currently, VeriSign's current work in W3C also 
> reflects alot of the understanding on the required 
> semantics of realtime trust models. 
> Peter. 
> -----Original Message----- 
> From: Denis Pinkas 
> To: Santosh Chokhani 
> Cc: [e-mail] 
> Sent: 1/16/02 12:04 AM 
> Subject: Re: OCSP RFC and OCSP version 2 ID 
> At the time the document was written, the main mechanism to feed the 
> information to the OCSP server was to use CRLs. So it seems sensible to 
> think that these fields are copied from a CRL. 
> 


--Boundary_(ID_vdDpiuMYz440jSUP+ifE0Q)
Content-type: text/html
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>

<META content=3D"MSHTML 5.00.2920.0" name=3DGENERATOR></HEAD>
<BODY>
<DIV>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D289555818-17012002>Santosh, why doesn't thisUpdate meet that=20
need?</SPAN></FONT></DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D289555818-17012002></SPAN></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#0000ff face=3DArial size=3D2><SPAN=20
class=3D289555818-17012002>A</SPAN></FONT></DIV>
<DIV>&nbsp;</DIV>
<P><FONT=20
size=3D2>---------------------------------------------------------------=
------<BR>Ambarish=20
Malpani<BR>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;=20
650.567.5457<BR>ValiCert,=20
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
[e-mail]<BR>339 N. Bernardo=20
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
<A href=3D"http://www.valicert.com/"=20
target=3D_blank>http://www.valicert.com</A><BR>Mountain View, CA=20
94043<BR></FONT></P>
<BLOCKQUOTE=20
style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; =
MARGIN-RIGHT: 0px; PADDING-LEFT: 5px">
  <DIV align=3Dleft class=3DOutlookMessageHeader dir=3Dltr><FONT =
face=3DTahoma=20
  size=3D2>-----Original Message-----<BR><B>From:</B> Santosh Chokhani=20
  [mailto:[e-mail]]<BR><B>Sent:</B> Thursday, January 17, =
2002=20
  10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas'; =
'[e-mail]=20
  '<BR><B>Subject:</B> RE: OCSP RFC and OCSP version 2 =
ID<BR><BR></DIV></FONT>
  <P><FONT size=3D2>I agree with what Ambarish and Carlisle are =
saying.</FONT>=20
</P>
  <P><FONT size=3D2>I have one addition question though.&nbsp; Should =
the standard=20
  provide a capability to the relying parties (OCSP clients) that the =
current=20
  revocation information is always available. If people agree that it =
should,=20
  given the proposed meaning of nextUpdate, the additional capability =
can be=20
  handled via a SingleResponse extension.</FONT></P>
  <P><FONT size=3D2>-----Original Message-----</FONT> <BR><FONT =
size=3D2>From:=20
  Ambarish Malpani [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>=20
  <BR><FONT size=3D2>Sent: Thursday, January 17, 2002 11:53 AM</FONT> =
<BR><FONT=20
  size=3D2>To: 'Denis Pinkas'; '[e-mail] '</FONT> <BR><FONT=20
  size=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> =
</P><BR><BR><BR>
  <P><FONT size=3D2>Hi Denis,</FONT> <BR><FONT =
size=3D2>&nbsp;&nbsp;&nbsp;=20
  Information about how up to date the information is, is</FONT> =
<BR><FONT=20
  size=3D2>already present in the thisUpdate field in the =
response.</FONT> </P>
  <P><FONT size=3D2>So, for example, if you *know* that you have =
information that=20
  is</FONT> <BR><FONT size=3D2>current as of 5 seconds ago, you can set =
that field=20
  appropriately.</FONT> </P>
  <P><FONT size=3D2>Does this meet your needs?</FONT> </P>
  <P><FONT size=3D2>Regards,</FONT> <BR><FONT size=3D2>Ambarish</FONT> =
</P>
  <P><FONT=20
  =
size=3D2>---------------------------------------------------------------=
------</FONT>=20
  <BR><FONT size=3D2>Ambarish Malpani</FONT> <BR><FONT=20
  =
size=3D2>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;=20
  650.567.5457</FONT> <BR><FONT size=3D2>ValiCert,=20
  =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  [e-mail]</FONT> <BR><FONT size=3D2>339 N. Bernardo=20
  =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
  <A href=3D"http://www.valicert.com"=20
  target=3D_blank>http://www.valicert.com</A></FONT> <BR><FONT =
size=3D2>Mountain=20
  View, CA 94043</FONT> </P><BR>
  <P><FONT size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt;=20
  From: Denis Pinkas [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Thursday, January 17, 2002 8:50 =
AM</FONT>=20
  <BR><FONT size=3D2>&gt; To: Ambarish Malpani</FONT> <BR><FONT =
size=3D2>&gt; Cc:=20
  'Santosh Chokhani'; '[e-mail] '</FONT> <BR><FONT =
size=3D2>&gt; Subject:=20
  Re: OCSP RFC and OCSP version 2 ID</FONT> <BR><FONT size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; =
Ambarish,</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; &gt; Hi =
Santosh,</FONT>=20
  <BR><FONT size=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Give me some =
time....=20
  :-)</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt; I=20
  agree with your first analysis:</FONT> <BR><FONT size=3D2>&gt; &gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; "If nextUpdate is not set, the =
responder is=20
  indicating that newer</FONT> <BR><FONT size=3D2>&gt; &gt; revocation =
information=20
  is available all the time"</FONT> <BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; &gt; Actually, they way I would prefer to state it =
would be=20
  something</FONT> <BR><FONT size=3D2>&gt; &gt; like:</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; &gt; "If nextUpdate is not set, the =
responder is=20
  indicating that it</FONT> <BR><FONT size=3D2>&gt; &gt; doesn't know =
when newer=20
  information will be available and so, if</FONT> <BR><FONT =
size=3D2>&gt; &gt; a=20
  client wants status information on the certificate in question</FONT> =

  <BR><FONT size=3D2>&gt; &gt; at a future date, it should come back =
and ask the=20
  server again."</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt; I=20
  like your proposal, since this means that when using the =
</FONT><BR><FONT=20
  size=3D2>&gt; on-line protocol </FONT><BR><FONT size=3D2>&gt; it is =
not possible=20
  to know. Now we could add a sentence that says:</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; "However, the Certificate Practice =
Statement and=20
  the </FONT><BR><FONT size=3D2>&gt; Certificate Disclosure</FONT> =
<BR><FONT=20
  size=3D2>&gt; Statement may provide more information about the =
refreshment=20
  </FONT><BR><FONT size=3D2>&gt; conditions of</FONT> <BR><FONT =
size=3D2>&gt; the=20
  status information."</FONT> <BR><FONT size=3D2>&gt;&nbsp; =
</FONT><BR><FONT=20
  size=3D2>&gt; Denis</FONT> <BR><FONT size=3D2>&gt; </FONT><BR><FONT =
size=3D2>&gt;=20
  &gt; This is my personal opinion. If the group agrees, I am happy =
to</FONT>=20
  <BR><FONT size=3D2>&gt; &gt; modify the document to reflect this =
point of=20
  view.</FONT> <BR><FONT size=3D2>&gt; &gt; </FONT><BR><FONT =
size=3D2>&gt; &gt;=20
  Regards,</FONT> <BR><FONT size=3D2>&gt; &gt; Ambarish</FONT> =
<BR><FONT=20
  size=3D2>&gt; &gt; </FONT><BR><FONT size=3D2>&gt; &gt; =
</FONT><BR><FONT=20
  size=3D2>&gt;=20
  =
---------------------------------------------------------------------</F=
ONT>=20
  <BR><FONT size=3D2>&gt; &gt; Ambarish Malpani</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
  </FONT><BR><FONT size=3D2>&gt; 650.567.5457</FONT> <BR><FONT =
size=3D2>&gt; &gt;=20
  ValiCert,=20
  =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
  </FONT><BR><FONT size=3D2>&gt; [e-mail]</FONT> <BR><FONT =

  size=3D2>&gt; &gt; 339 N. Bernardo=20
  =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;=20
  </FONT><BR><FONT size=3D2><A href=3D"http://www.valicert.com"=20
  target=3D_blank>http://www.valicert.com</A></FONT> <BR><FONT =
size=3D2>&gt;=20
  Mountain View, CA 94043</FONT> <BR><FONT size=3D2>&gt; =
</FONT><BR><FONT=20
  size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt; From:=20
  Santosh Chokhani [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>=20
  <BR><FONT size=3D2>&gt; Sent: Wednesday, January 16, 2002 11:50 =
AM</FONT>=20
  <BR><FONT size=3D2>&gt; To: Peter Williams; 'Denis Pinkas '; Santosh=20
  Chokhani</FONT> <BR><FONT size=3D2>&gt; Cc: '[e-mail] =
'</FONT>=20
  <BR><FONT size=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>=20
  <BR><FONT size=3D2>&gt; </FONT><BR><FONT size=3D2>&gt; Why aren't the =
authors=20
  responding to this contradiction in the RFC and</FONT> <BR><FONT =
size=3D2>&gt;=20
  carried out in the ID?</FONT> <BR><FONT size=3D2>&gt; -----Original=20
  Message-----</FONT> <BR><FONT size=3D2>&gt; From: Peter Williams [<A=20
  =
href=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>=20
  <BR><FONT size=3D2>&gt; Sent: Wednesday, January 16, 2002 2:41 =
PM</FONT>=20
  <BR><FONT size=3D2>&gt; To: 'Denis Pinkas '; 'Santosh Chokhani =
'</FONT>=20
  <BR><FONT size=3D2>&gt; Cc: '[e-mail] '</FONT> <BR><FONT =
size=3D2>&gt;=20
  Subject: RE: OCSP RFC and OCSP version 2 ID</FONT> <BR><FONT =
size=3D2>&gt;=20
  </FONT><BR><FONT size=3D2>&gt; Denis,</FONT> <BR><FONT size=3D2>&gt; =
You refer to=20
  an assumed&nbsp; "main mechanism" in your note. Speaking</FONT> =
<BR><FONT=20
  size=3D2>factually,</FONT> <BR><FONT size=3D2>&gt; to hopefully guide =
you,=20
  sensibly:-</FONT> <BR><FONT size=3D2>&gt; The main [reference] =
mechanism(s) at,=20
  and shortly after,</FONT> <BR><FONT size=3D2>&gt; the time of writing =
OCSP IDs=20
  included:-</FONT> <BR><FONT size=3D2>&gt; (1) VeriSign, who used an =
oracle=20
  database-based repository to feed data</FONT> <BR><FONT size=3D2>&gt; =
to OCSP=20
  deamons acting in cached and interactive, direct-trust</FONT> =
<BR><FONT=20
  size=3D2>&gt; mode; CRLs were not involved. OCSP proxing/multiplexing =

  interactive</FONT> <BR><FONT size=3D2>&gt; direct-trust mode =
was&nbsp; added,=20
  shortly after standarization, for a</FONT> <BR><FONT size=3D2>&gt; =
defense=20
  customer bridging multiple certification domains.</FONT> <BR><FONT =
size=3D2>&gt;=20
  (2) ValiCert, who used direct CRLs to feed data to direct/indirect =
OCSP</FONT>=20
  <BR><FONT size=3D2>&gt; deamons. Indirect CRLs and CRLDPs support was =
added=20
  slightly after</FONT> <BR><FONT size=3D2>&gt; the architects had =
harmonized=20
  their work.</FONT> <BR><FONT size=3D2>&gt; Both mechanisms evolved =
further,=20
  outside of IETF and</FONT> <BR><FONT size=3D2>&gt; in vendor forums,=20
  particularly in the area of: application</FONT> <BR><FONT =
size=3D2>&gt;=20
  integration, CRLDPs and delta-CRL data sources, proxying</FONT> =
<BR><FONT=20
  size=3D2>&gt; transaction semantics and response resigning, data=20
  freshness</FONT> <BR><FONT size=3D2>&gt; signalling, and OCSP client =
interaction=20
  with X.509 and</FONT> <BR><FONT size=3D2>&gt; PKIX-style path =
processing and=20
  X.509 applications such as</FONT> <BR><FONT size=3D2>&gt; SSLv3/https =
and=20
  MTA-based automatic xmldsig signature</FONT> <BR><FONT size=3D2>&gt;=20
  verification on B2B and banking protocol XML streams.</FONT> =
<BR><FONT=20
  size=3D2>&gt; Historically, this work essentially re-designed the=20
  standardized</FONT> <BR><FONT size=3D2>&gt; features of the =
"distributed=20
  authentication model" of</FONT> <BR><FONT size=3D2>&gt; X.500 1988, =
for=20
  OCSP-borne queries.</FONT> <BR><FONT size=3D2>&gt; Currently, =
VeriSign's current=20
  work in W3C also</FONT> <BR><FONT size=3D2>&gt; reflects alot of the=20
  understanding on the required</FONT> <BR><FONT size=3D2>&gt; =
semantics of=20
  realtime trust models.</FONT> <BR><FONT size=3D2>&gt; Peter.</FONT> =
<BR><FONT=20
  size=3D2>&gt; -----Original Message-----</FONT> <BR><FONT =
size=3D2>&gt; From:=20
  Denis Pinkas</FONT> <BR><FONT size=3D2>&gt; To: Santosh =
Chokhani</FONT>=20
  <BR><FONT size=3D2>&gt; Cc: [e-mail]</FONT> <BR><FONT =
size=3D2>&gt; Sent:=20
  1/16/02 12:04 AM</FONT> <BR><FONT size=3D2>&gt; Subject: Re: OCSP RFC =
and OCSP=20
  version 2 ID</FONT> <BR><FONT size=3D2>&gt; At the time the document =
was=20
  written, the main mechanism to feed the</FONT> <BR><FONT =
size=3D2>&gt;=20
  information to the OCSP server was to use CRLs. So it seems sensible =
to</FONT>=20
  <BR><FONT size=3D2>&gt; think that these fields are copied from a =
CRL.</FONT>=20
  <BR><FONT size=3D2>&gt;</FONT> </P></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_vdDpiuMYz440jSUP+ifE0Q)--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HIVrj22949 for ietf-pkix-bks; Thu, 17 Jan 2002 10:31:53 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HIVq322945 for <[e-mail]>; Thu, 17 Jan 2002 10:31:52 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <D1BG8MKV>; Thu, 17 Jan 2002 13:31:49 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B61E@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: Ambarish Malpani <[e-mail]>, "'Denis Pinkas'" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 13:30:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19F85.0E05C350"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C19F85.0E05C350
Content-Type: text/plain

I agree with what Ambarish and Carlisle are saying.

I have one addition question though.  Should the standard provide a
capability to the relying parties (OCSP clients) that the current revocation
information is always available. If people agree that it should, given the
proposed meaning of nextUpdate, the additional capability can be handled via
a SingleResponse extension.

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Thursday, January 17, 2002 11:53 AM
To: 'Denis Pinkas'; '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID




Hi Denis,
    Information about how up to date the information is, is
already present in the thisUpdate field in the response.

So, for example, if you *know* that you have information that is
current as of 5 seconds ago, you can set that field appropriately.

Does this meet your needs?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 8:50 AM
> To: Ambarish Malpani
> Cc: 'Santosh Chokhani'; '[e-mail] '
> Subject: Re: OCSP RFC and OCSP version 2 ID
> 
> 
> Ambarish,
> 
> > Hi Santosh,
> >     Give me some time.... :-)
> > 
> > I agree with your first analysis:
> > 
> > "If nextUpdate is not set, the responder is indicating that newer
> > revocation information is available all the time"
> > 
> > Actually, they way I would prefer to state it would be something
> > like:
> 
> > "If nextUpdate is not set, the responder is indicating that it
> > doesn't know when newer information will be available and so, if
> > a client wants status information on the certificate in question
> > at a future date, it should come back and ask the server again."
> 
> I like your proposal, since this means that when using the 
> on-line protocol 
> it is not possible to know. Now we could add a sentence that says:
> 
> "However, the Certificate Practice Statement and the 
> Certificate Disclosure
> Statement may provide more information about the refreshment 
> conditions of
> the status information."
>  
> Denis
> 
> > This is my personal opinion. If the group agrees, I am happy to
> > modify the document to reflect this point of view.
> > 
> > Regards,
> > Ambarish
> > 
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [e-mail]
> > 339 N. Bernardo Ave.                          
http://www.valicert.com
> Mountain View, CA 94043
> 
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Wednesday, January 16, 2002 11:50 AM
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> Cc: '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
> 
> Why aren't the authors responding to this contradiction in the RFC and
> carried out in the ID?
> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Wednesday, January 16, 2002 2:41 PM
> To: 'Denis Pinkas '; 'Santosh Chokhani '
> Cc: '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
> 
> Denis,
> You refer to an assumed  "main mechanism" in your note. Speaking
factually,
> to hopefully guide you, sensibly:-
> The main [reference] mechanism(s) at, and shortly after,
> the time of writing OCSP IDs included:-
> (1) VeriSign, who used an oracle database-based repository to feed data
> to OCSP deamons acting in cached and interactive, direct-trust
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive
> direct-trust mode was  added, shortly after standarization, for a
> defense customer bridging multiple certification domains.
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP
> deamons. Indirect CRLs and CRLDPs support was added slightly after
> the architects had harmonized their work.
> Both mechanisms evolved further, outside of IETF and
> in vendor forums, particularly in the area of: application
> integration, CRLDPs and delta-CRL data sources, proxying
> transaction semantics and response resigning, data freshness
> signalling, and OCSP client interaction with X.509 and
> PKIX-style path processing and X.509 applications such as
> SSLv3/https and MTA-based automatic xmldsig signature
> verification on B2B and banking protocol XML streams.
> Historically, this work essentially re-designed the standardized
> features of the "distributed authentication model" of
> X.500 1988, for OCSP-borne queries.
> Currently, VeriSign's current work in W3C also
> reflects alot of the understanding on the required
> semantics of realtime trust models.
> Peter.
> -----Original Message-----
> From: Denis Pinkas
> To: Santosh Chokhani
> Cc: [e-mail]
> Sent: 1/16/02 12:04 AM
> Subject: Re: OCSP RFC and OCSP version 2 ID
> At the time the document was written, the main mechanism to feed the
> information to the OCSP server was to use CRLs. So it seems sensible to
> think that these fields are copied from a CRL.
>

------_=_NextPart_001_01C19F85.0E05C350
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I agree with what Ambarish and Carlisle are =
saying.</FONT>
</P>

<P><FONT SIZE=3D2>I have one addition question though.&nbsp; Should the =
standard provide a capability to the relying parties (OCSP clients) =
that the current revocation information is always available. If people =
agree that it should, given the proposed meaning of nextUpdate, the =
additional capability can be handled via a SingleResponse =
extension.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ambarish Malpani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 11:53 AM</FONT>
<BR><FONT SIZE=3D2>To: 'Denis Pinkas'; '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi Denis,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Information about how up to date =
the information is, is</FONT>
<BR><FONT SIZE=3D2>already present in the thisUpdate field in the =
response.</FONT>
</P>

<P><FONT SIZE=3D2>So, for example, if you *know* that you have =
information that is</FONT>
<BR><FONT SIZE=3D2>current as of 5 seconds ago, you can set that field =
appropriately.</FONT>
</P>

<P><FONT SIZE=3D2>Does this meet your needs?</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Ambarish</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
------</FONT>
<BR><FONT SIZE=3D2>Ambarish Malpani</FONT>
<BR><FONT =
SIZE=3D2>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>Mountain View, CA 94043</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Denis Pinkas [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 17, 2002 8:50 AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: 'Santosh Chokhani'; '[e-mail] =
'</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Ambarish,</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Hi Santosh,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;&nbsp;&nbsp;&nbsp;&nbsp; Give me some =
time.... :-)</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; I agree with your first analysis:</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;If nextUpdate is not set, the =
responder is indicating that newer</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; revocation information is available all =
the time&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Actually, they way I would prefer to state =
it would be something</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; like:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &quot;If nextUpdate is not set, the =
responder is indicating that it</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; doesn't know when newer information will =
be available and so, if</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; a client wants status information on the =
certificate in question</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; at a future date, it should come back and =
ask the server again.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I like your proposal, since this means that =
when using the </FONT>
<BR><FONT SIZE=3D2>&gt; on-line protocol </FONT>
<BR><FONT SIZE=3D2>&gt; it is not possible to know. Now we could add a =
sentence that says:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &quot;However, the Certificate Practice =
Statement and the </FONT>
<BR><FONT SIZE=3D2>&gt; Certificate Disclosure</FONT>
<BR><FONT SIZE=3D2>&gt; Statement may provide more information about =
the refreshment </FONT>
<BR><FONT SIZE=3D2>&gt; conditions of</FONT>
<BR><FONT SIZE=3D2>&gt; the status information.&quot;</FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; This is my personal opinion. If the group =
agrees, I am happy to</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; modify the document to reflect this point =
of view.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Regards,</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ambarish</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; =
---------------------------------------------------------------------</F=
ONT>
<BR><FONT SIZE=3D2>&gt; &gt; Ambarish Malpani</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; =
Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp; </FONT>
<BR><FONT SIZE=3D2>&gt; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; </FONT>
<BR><FONT SIZE=3D2><A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>&gt; Mountain View, CA 94043</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, January 16, 2002 11:50 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: Peter Williams; 'Denis Pinkas '; Santosh =
Chokhani</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Why aren't the authors responding to this =
contradiction in the RFC and</FONT>
<BR><FONT SIZE=3D2>&gt; carried out in the ID?</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Peter Williams [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]</FON=
T>
<BR><FONT SIZE=3D2>&gt; Sent: Wednesday, January 16, 2002 2:41 =
PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Denis Pinkas '; 'Santosh Chokhani '</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: RE: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Denis,</FONT>
<BR><FONT SIZE=3D2>&gt; You refer to an assumed&nbsp; &quot;main =
mechanism&quot; in your note. Speaking</FONT>
<BR><FONT SIZE=3D2>factually,</FONT>
<BR><FONT SIZE=3D2>&gt; to hopefully guide you, sensibly:-</FONT>
<BR><FONT SIZE=3D2>&gt; The main [reference] mechanism(s) at, and =
shortly after,</FONT>
<BR><FONT SIZE=3D2>&gt; the time of writing OCSP IDs included:-</FONT>
<BR><FONT SIZE=3D2>&gt; (1) VeriSign, who used an oracle database-based =
repository to feed data</FONT>
<BR><FONT SIZE=3D2>&gt; to OCSP deamons acting in cached and =
interactive, direct-trust</FONT>
<BR><FONT SIZE=3D2>&gt; mode; CRLs were not involved. OCSP =
proxing/multiplexing interactive</FONT>
<BR><FONT SIZE=3D2>&gt; direct-trust mode was&nbsp; added, shortly =
after standarization, for a</FONT>
<BR><FONT SIZE=3D2>&gt; defense customer bridging multiple =
certification domains.</FONT>
<BR><FONT SIZE=3D2>&gt; (2) ValiCert, who used direct CRLs to feed data =
to direct/indirect OCSP</FONT>
<BR><FONT SIZE=3D2>&gt; deamons. Indirect CRLs and CRLDPs support was =
added slightly after</FONT>
<BR><FONT SIZE=3D2>&gt; the architects had harmonized their =
work.</FONT>
<BR><FONT SIZE=3D2>&gt; Both mechanisms evolved further, outside of =
IETF and</FONT>
<BR><FONT SIZE=3D2>&gt; in vendor forums, particularly in the area of: =
application</FONT>
<BR><FONT SIZE=3D2>&gt; integration, CRLDPs and delta-CRL data sources, =
proxying</FONT>
<BR><FONT SIZE=3D2>&gt; transaction semantics and response resigning, =
data freshness</FONT>
<BR><FONT SIZE=3D2>&gt; signalling, and OCSP client interaction with =
X.509 and</FONT>
<BR><FONT SIZE=3D2>&gt; PKIX-style path processing and X.509 =
applications such as</FONT>
<BR><FONT SIZE=3D2>&gt; SSLv3/https and MTA-based automatic xmldsig =
signature</FONT>
<BR><FONT SIZE=3D2>&gt; verification on B2B and banking protocol XML =
streams.</FONT>
<BR><FONT SIZE=3D2>&gt; Historically, this work essentially re-designed =
the standardized</FONT>
<BR><FONT SIZE=3D2>&gt; features of the &quot;distributed =
authentication model&quot; of</FONT>
<BR><FONT SIZE=3D2>&gt; X.500 1988, for OCSP-borne queries.</FONT>
<BR><FONT SIZE=3D2>&gt; Currently, VeriSign's current work in W3C =
also</FONT>
<BR><FONT SIZE=3D2>&gt; reflects alot of the understanding on the =
required</FONT>
<BR><FONT SIZE=3D2>&gt; semantics of realtime trust models.</FONT>
<BR><FONT SIZE=3D2>&gt; Peter.</FONT>
<BR><FONT SIZE=3D2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=3D2>&gt; From: Denis Pinkas</FONT>
<BR><FONT SIZE=3D2>&gt; To: Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2>&gt; Cc: [e-mail]</FONT>
<BR><FONT SIZE=3D2>&gt; Sent: 1/16/02 12:04 AM</FONT>
<BR><FONT SIZE=3D2>&gt; Subject: Re: OCSP RFC and OCSP version 2 =
ID</FONT>
<BR><FONT SIZE=3D2>&gt; At the time the document was written, the main =
mechanism to feed the</FONT>
<BR><FONT SIZE=3D2>&gt; information to the OCSP server was to use CRLs. =
So it seems sensible to</FONT>
<BR><FONT SIZE=3D2>&gt; think that these fields are copied from a =
CRL.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19F85.0E05C350--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HI2r521795 for ietf-pkix-bks; Thu, 17 Jan 2002 10:02:53 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HI2q321790 for <[e-mail]>; Thu, 17 Jan 2002 10:02:52 -0800 (PST)
Received: from vhqpostal-gw1.verisign.com (verisign.com [65.205.251.55]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g0HHxMR16281; Thu, 17 Jan 2002 09:59:23 -0800 (PST)
Received: by vhqpostal-gw1.verisign.com with Internet Mail Service (5.5.2653.19) id <Y2WKAHG8>; Thu, 17 Jan 2002 10:03:37 -0800
Message-ID: <[e-mail]>
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, Petra Barzin <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Date: Thu, 17 Jan 2002 10:03:24 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C19F81.417D1AC0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_000_01C19F81.417D1AC0
Content-Type: text/plain;
	charset="iso-8859-1"

Russ,

	I would be very much better disposed to the argument you make if I
had not heard it from the original author of SCVP before.

	Back when OCSP was initially developed it used a simple syntax. This
was then changed to ASN.1 by Ambarish, a change that was directly and
specifically justified by the need for 'extensibility'.

	So when a few years later the proposal for SCVP is made one would
assume that the extensibility features designed into OCSP would be used. But
no, instead we have a completely new platform.

	So no, I will not for a minute accept greater extensibility as a
justification for SCVP. Not even if the authors give me a signed affidavit
saying that this is the last time they will introduce a greenfield
specification rather than re-use the one they introduced only a short time
earlier.


	The issue we come down to is of platform reuse. Supporting two
platforms with almost idential but not quite identical semantics is a
nightmare. With OCSP and XKMS there are clear points of comparison. However
there is little chance that XKMS semantics will be accidentally transported
into OCSP or vice versa. With OCSP and SCVP it appears to me to be almost
inevitable that we end up with "OCVP" and "SCSP" implementations that create
mix 'n match hybrids of the specifications.

	The only objection I have heard to building SCVP on OCSP that
appears to me that could justify a new platform is that it is alleged that
OCSP does not support quite the right retreival semantics. I say could
because the justification would only exist if OCSP could not be fixed.

	In fact ensuring that OCSP gets 'fixed' as necessary is the reason
that I believe platform reuse is essential. If we keep introducing new
platforms each time we want to address a new aspect of Online Certificate
processing we will never get any of them right.


	The other issue to consider is that PKIX already has a reputation
for proliferating protocols. There are groups that are proposing to develop
profiles of the PKIX profile of X.509. 

		Phill


Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
[e-mail]
781 245 6996 x227


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Wednesday, January 16, 2002 9:40 AM
> To: Petra Barzin; Denis Pinkas
> Cc: [e-mail]
> Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
> 
> 
> 
> Petra and Denis:
> 
> The structure of SCVP makes it very easy to add support of attribute 
> certificates (or PGP certificates for that matter) at a later 
> date.  We 
> need to make sure that there is a constituency for the 
> protocols we develop 
> for the standards track.
> 
> Russ
> 
> 
> At 12:36 PM 1/16/2002 +0100, Denis Pinkas wrote:
> 
> >Petra,
> >
> > > Yes, thanks for the pointer. I found the ASN.1 definitions there.
> > >
> > > One more question turned up:
> > > Is DPV restricted to X.509 public key certificates or is 
> it possible
> > > to use it for X.509 attribute certificates as well?
> >
> >Clearly, both the DPV-DPD protocol draft and the DPV-DPD 
> requirement draft
> >have been specifically written to support PKIX public key 
> certificates.
> >
> >At the last IETF meeting a question has been raised to the audience:
> >Who, in the room, has implemented Attribute Certificates ?
> >No hand showed up.
> >
> >So it seems that there is no urgence to support PKIX attribute
> certificates.
> >
> >However, maybe by making some changes, PKIX attribute 
> certificates could be
> >supported, but this is an exercise that I have not undertaken.
> >
> >The basic question is thus whether to include the support of 
> attribute
> >certificates in the current DPV-DPD requirement draft.
> >
> >Unless you, or someone else, can rapidly provide arguments 
> and demonstrate
> >that it will not delay the support of PKIX public key 
> certificates, I would
> >rather think that it should not be included at this time.
> >
> >Regards,
> >
> >Denis
> >
> >
> > > - Petra
> > >
> > > Denis Pinkas schrieb:
> > >
> > > > Petra,
> > > >
> > > > Please take a look at RFC 3126, where many of the ASN.1 
> structures
> were
> > > > imported from and are thus defined there. This should 
> answer all your
> > > > questions.
> > > >
> > > > Regards,
> > > >
> > > > Denis
> > > >
> > > > > Denis,
> > > > >
> > > > > may I still ask some questions concerning the 
> document "Delegated
> > > > > Path Validation and Delegated Path Discovery Protocols" ?
> > > > >
> > > > > > PathValues :: = SEQUENCE {
> > > > > >        certificateValues      CertificateValues,
> > > > > >        revocationValues       RevocationValues }
> > > > > >
> > > > > I'm missing some ASN.1 definitions. You refer to 
> "CertificateValues"
> > > > > and "RevocationValues" but I couldn't find these definitions.
> > > > >
> > > > > By the way, you should move this definition of 
> "PathValues" from
> > > > > the chapter "5.2.1. Request" to the chapter "5.2.2.  Response
> Syntax"
> > > > > where it is used.
> > > > >
> > > > > Another ASN.1 question:
> > > > >
> > > > > > UsefulRevoc ::= CHOICE {
> > > > > >        certificateRevocationLists     
> CertificateRevocationLists,
> > > > > >        completeRevocationRefs         
> CompleteRevocationRefs }
> > > > > >
> > > > > A DPV request may contain useful revocation 
> information provided
> > > > > by the client. Maybe it's because I don't know the element
> > > > > "CompleteRevocationRefs" but where do I store OCSP answers?
> > > > >
> > > > > Could you please send the definition of 
> "CompleteRevocationRefs"
> > > > > and "completeCertificateRefs"? I guess they are imported from
> [ES-F],
> > > > > "Electronic Signature Formats for long term 
> electronic signatures", 
> > aren't
> > > > > they?
> > > > >
> > > > > >    CertOrCertRef ::=  CHOICE {
> > > > > >        certificate          [1]  Certificate,
> > > > > >        certRef              [2]  OtherCertID }
> > > > > >
> > > > > I'm also missing the definition of OtherCertID used 
> in a DPV and DPD
> > > > > request.
> > > > >
> > > > > Thanks, Petra
> > > > >
> > > > > Denis Pinkas schrieb:
> > > > >
> > > > > > Petra,
> > > > > >
> > > > > > > Denis,
> > > > > >
> > > > > > > is there also a new version of the document 
> "Delegated Path
> > > > > > > Validation and Delegated Path Discovery Protocols"
> > > > > >
> > > > > > Not at this time. Currently we need first to agree 
> on the DPV /
> DPD
> > > > > > requirements, then we will discuss the solutions to these 
> > requirements.
> > > > > >
> > > > > > The so-called "Delegated Path Validation and Delegated Path
> Discovery
> > > > > > Protocols" document could be a candidate to fulfill these 
> > requirements.
> > > > > > It is too early to say and this will only be 
> discussed once the
> > > > > > requirements
> > > > > > document is adopted.
> > > > > >
> > > > > > > or just a new requirement document?
> > > > > >
> > > > > > Correct. It is a new document for both the DPV and DPD
> requirements.
> > > > > >
> > > > > > There is also a companion document for the DSV requirements.
> > > > > > We will only discuss the DSV requirements document 
> in detail when
> > > > > > the DPV / DPD requirements document has completed 
> the WG last
> call.
> > > > > >
> > > > > > Denis
> 
> 
> 
> 
> ==============================================================
> ==============
> ================
> This e-mail, its content and any files transmitted with it 
> are intended
> solely for the addressee(s) and are PRIVILEGED and 
> CONFIDENTIAL.  Access by any other party is unauthorized 
> without the express
> prior written permission of the sender.  If 
> you have received this e-mail in error you may not copy, 
> disclose to any
> third party or use the contents, attachments or 
> information in any way, Please delete all copies of the e-mail and the
> attachment(s), if any and notify the sender. 
> Thank You.
> ==============================================================
> ==============
> ================
> 


------_=_NextPart_000_01C19F81.417D1AC0
Content-Type: application/octet-stream;
	name="Phillip Hallam-Baker (E-mail).vcf"
Content-Disposition: attachment;
	filename="Phillip Hallam-Baker (E-mail).vcf"

BEGIN:VCARD
VERSION:2.1
N:Hallam-Baker;Phillip
FN:Phillip Hallam-Baker (E-mail)
ORG:VeriSign
TITLE:Principal Consultant
TEL;WORK;VOICE:[phone] x227
EMAIL;PREF;INTERNET:[e-mail]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C19F81.417D1AC0--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HGrHO18727 for ietf-pkix-bks; Thu, 17 Jan 2002 08:53:17 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HGrG318721 for <[e-mail]>; Thu, 17 Jan 2002 08:53:16 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Thu, 17 Jan 2002 08:53:17 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Thu, 17 Jan 2002 08:53:17 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <C2FYW8X0>; Thu, 17 Jan 2002 08:53:15 -0800
Content-return: allowed
Date: Thu, 17 Jan 2002 08:53:05 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'Denis Pinkas'" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi Denis,
    Information about how up to date the information is, is
already present in the thisUpdate field in the response.

So, for example, if you *know* that you have information that is
current as of 5 seconds ago, you can set that field appropriately.

Does this meet your needs?

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Denis Pinkas [mailto:[e-mail]]
> Sent: Thursday, January 17, 2002 8:50 AM
> To: Ambarish Malpani
> Cc: 'Santosh Chokhani'; '[e-mail] '
> Subject: Re: OCSP RFC and OCSP version 2 ID
> 
> 
> Ambarish,
> 
> > Hi Santosh,
> >     Give me some time.... :-)
> > 
> > I agree with your first analysis:
> > 
> > "If nextUpdate is not set, the responder is indicating that newer
> > revocation information is available all the time"
> > 
> > Actually, they way I would prefer to state it would be something
> > like:
> 
> > "If nextUpdate is not set, the responder is indicating that it
> > doesn't know when newer information will be available and so, if
> > a client wants status information on the certificate in question
> > at a future date, it should come back and ask the server again."
> 
> I like your proposal, since this means that when using the 
> on-line protocol 
> it is not possible to know. Now we could add a sentence that says:
> 
> "However, the Certificate Practice Statement and the 
> Certificate Disclosure
> Statement may provide more information about the refreshment 
> conditions of
> the status information."
>  
> Denis
> 
> > This is my personal opinion. If the group agrees, I am happy to
> > modify the document to reflect this point of view.
> > 
> > Regards,
> > Ambarish
> > 
> > 
> ---------------------------------------------------------------------
> > Ambarish Malpani
> > Architect                                                
> 650.567.5457
> > ValiCert, Inc.                                  
> [e-mail]
> > 339 N. Bernardo Ave.                          
http://www.valicert.com
> Mountain View, CA 94043
> 
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Wednesday, January 16, 2002 11:50 AM
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> Cc: '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
> 
> Why aren't the authors responding to this contradiction in the RFC and
> carried out in the ID?
> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Wednesday, January 16, 2002 2:41 PM
> To: 'Denis Pinkas '; 'Santosh Chokhani '
> Cc: '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
> 
> Denis,
> You refer to an assumed  "main mechanism" in your note. Speaking
factually,
> to hopefully guide you, sensibly:-
> The main [reference] mechanism(s) at, and shortly after,
> the time of writing OCSP IDs included:-
> (1) VeriSign, who used an oracle database-based repository to feed data
> to OCSP deamons acting in cached and interactive, direct-trust
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive
> direct-trust mode was  added, shortly after standarization, for a
> defense customer bridging multiple certification domains.
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP
> deamons. Indirect CRLs and CRLDPs support was added slightly after
> the architects had harmonized their work.
> Both mechanisms evolved further, outside of IETF and
> in vendor forums, particularly in the area of: application
> integration, CRLDPs and delta-CRL data sources, proxying
> transaction semantics and response resigning, data freshness
> signalling, and OCSP client interaction with X.509 and
> PKIX-style path processing and X.509 applications such as
> SSLv3/https and MTA-based automatic xmldsig signature
> verification on B2B and banking protocol XML streams.
> Historically, this work essentially re-designed the standardized
> features of the "distributed authentication model" of
> X.500 1988, for OCSP-borne queries.
> Currently, VeriSign's current work in W3C also
> reflects alot of the understanding on the required
> semantics of realtime trust models.
> Peter.
> -----Original Message-----
> From: Denis Pinkas
> To: Santosh Chokhani
> Cc: [e-mail]
> Sent: 1/16/02 12:04 AM
> Subject: Re: OCSP RFC and OCSP version 2 ID
> At the time the document was written, the main mechanism to feed the
> information to the OCSP server was to use CRLs. So it seems sensible to
> think that these fields are copied from a CRL.
>


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HGouQ18644 for ietf-pkix-bks; Thu, 17 Jan 2002 08:50:56 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HGos318640 for <[e-mail]>; Thu, 17 Jan 2002 08:50:55 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA22056; Thu, 17 Jan 2002 17:52:06 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA17274; Thu, 17 Jan 2002 17:50:20 +0100
Message-ID: <[e-mail]>
Date: Thu, 17 Jan 2002 17:49:51 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: "'Santosh Chokhani'" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: OCSP RFC and OCSP version 2 ID
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Ambarish,

> Hi Santosh,
>     Give me some time.... :-)
> 
> I agree with your first analysis:
> 
> "If nextUpdate is not set, the responder is indicating that newer
> revocation information is available all the time"
> 
> Actually, they way I would prefer to state it would be something
> like:

> "If nextUpdate is not set, the responder is indicating that it
> doesn't know when newer information will be available and so, if
> a client wants status information on the certificate in question
> at a future date, it should come back and ask the server again."

I like your proposal, since this means that when using the on-line protocol 
it is not possible to know. Now we could add a sentence that says:

"However, the Certificate Practice Statement and the Certificate Disclosure
Statement may provide more information about the refreshment conditions of
the status information."
 
Denis

> This is my personal opinion. If the group agrees, I am happy to
> modify the document to reflect this point of view.
> 
> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> -----Original Message-----
> From: Santosh Chokhani [mailto:[e-mail]]
> Sent: Wednesday, January 16, 2002 11:50 AM
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> Cc: '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
> 
> Why aren't the authors responding to this contradiction in the RFC and
> carried out in the ID?
> -----Original Message-----
> From: Peter Williams [mailto:[e-mail]]
> Sent: Wednesday, January 16, 2002 2:41 PM
> To: 'Denis Pinkas '; 'Santosh Chokhani '
> Cc: '[e-mail] '
> Subject: RE: OCSP RFC and OCSP version 2 ID
> 
> Denis,
> You refer to an assumed  "main mechanism" in your note. Speaking factually,
> to hopefully guide you, sensibly:-
> The main [reference] mechanism(s) at, and shortly after,
> the time of writing OCSP IDs included:-
> (1) VeriSign, who used an oracle database-based repository to feed data
> to OCSP deamons acting in cached and interactive, direct-trust
> mode; CRLs were not involved. OCSP proxing/multiplexing interactive
> direct-trust mode was  added, shortly after standarization, for a
> defense customer bridging multiple certification domains.
> (2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP
> deamons. Indirect CRLs and CRLDPs support was added slightly after
> the architects had harmonized their work.
> Both mechanisms evolved further, outside of IETF and
> in vendor forums, particularly in the area of: application
> integration, CRLDPs and delta-CRL data sources, proxying
> transaction semantics and response resigning, data freshness
> signalling, and OCSP client interaction with X.509 and
> PKIX-style path processing and X.509 applications such as
> SSLv3/https and MTA-based automatic xmldsig signature
> verification on B2B and banking protocol XML streams.
> Historically, this work essentially re-designed the standardized
> features of the "distributed authentication model" of
> X.500 1988, for OCSP-borne queries.
> Currently, VeriSign's current work in W3C also
> reflects alot of the understanding on the required
> semantics of realtime trust models.
> Peter.
> -----Original Message-----
> From: Denis Pinkas
> To: Santosh Chokhani
> Cc: [e-mail]
> Sent: 1/16/02 12:04 AM
> Subject: Re: OCSP RFC and OCSP version 2 ID
> At the time the document was written, the main mechanism to feed the
> information to the OCSP server was to use CRLs. So it seems sensible to
> think that these fields are copied from a CRL.
>


Received: by above.proper.com (8.11.6/8.11.3) id g0HGUde17935 for ietf-pkix-bks; Thu, 17 Jan 2002 08:30:39 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HGUc317930 for <[e-mail]>; Thu, 17 Jan 2002 08:30:38 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA17698; Thu, 17 Jan 2002 17:31:49 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA12678; Thu, 17 Jan 2002 17:30:03 +0100
Message-ID: <[e-mail]>
Date: Thu, 17 Jan 2002 17:29:38 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Petra Barzin <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Petra,

See my response to Russ on this topic. We are not going to make any
requirement for Attribute Certificates at this time or "when the document is
stable".

Denis

> Denis,
> 
> in Germany there are implementations of attribute certificates.
> But they are not relevant for us now. Nevertheless I would like
> to see that the protocol design allows us to use it for attribute
> certificates as well when they might become a requirement.
> 
> In the requirement document you already talk about "any kind of
> certificate". My proposal is: just add the different types in brackets.
> 
> > 3. Rational and benefits for DPV (Delegated Path Validation)
> >
> > DPV allows to perform a real time validation for a time T for any kind
> > of certificate and any kind of security service.
> >
> 
> The DPV/DPD draft only allows for X.509 public key certificates.
> I guess you will update this when the requirement document is stable,
> don't you?
> 
> - Petra
> 
> Denis Pinkas schrieb:
> 
> > Russ,
> >
> > > Petra and Denis:
> > >
> > > The structure of SCVP makes it very easy to add support of attribute
> > > certificates (or PGP certificates for that matter) at a later date.
> >
> > We are not talking of solutions at this time, but only of requirements.
> > So the question is whether we add in the requirements document some text
> >
> > to cover attribute certificates. If we do, which text ?
> >
> > We have not say, at this time, whether SCVP or some flavor of it, will
> > be
> > the protocol that answers to these requirements.
> >
> > Denis
> >
> > > We need to make sure that there is a constituency for the protocols
> > > we develop for the standards track.
> > >
> > > Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HGIRu16880 for ietf-pkix-bks; Thu, 17 Jan 2002 08:18:27 -0800 (PST)
Received: from sottmxs02.entrust.com ([216.191.251.52]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HGIQ316875 for <[e-mail]>; Thu, 17 Jan 2002 08:18:26 -0800 (PST)
Received: by sottmxs02.entrust.com with Internet Mail Service (5.5.2650.21) id <DAAGNN7H>; Thu, 17 Jan 2002 11:18:14 -0500
Message-ID: <[e-mail]>
From: Carlisle Adams <[e-mail]>
To: Santosh Chokhani <[e-mail]>, "'Ambarish Malpani'" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 11:18:13 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19F72.902D4AA0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C19F72.902D4AA0
Content-Type: text/plain

Hi,

> ----------
> From: 	Ambarish Malpani[SMTP:[e-mail]]
> Sent: 	Wednesday, January 16, 2002 4:38 PM
> To: 	'Santosh Chokhani'
> Cc: 	'[e-mail] '
> Subject: 	RE: OCSP RFC and OCSP version 2 ID
> 
> Hi Santosh,
>     Give me some time.... :-)
 
Me too.  I get fewer opportunities to follow the PKIX list these days...

> I agree with your first analysis:
> 
> "If nextUpdate is not set, the responder is indicating that newer
> revocation information is available all the time"
> 
> Actually, they way I would prefer to state it would be something
> like:
> "If nextUpdate is not set, the responder is indicating that it
> doesn't know when newer information will be available and so, if
> a client wants status information on the certificate in question
> at a future date, it should come back and ask the server again."
> 
> This is my personal opinion. If the group agrees, I am happy to
> modify the document to reflect this point of view.
 
That's exactly the sort of wording I had in mind, too, when I read Santosh's
e-mail on this.  I'd be happy to see the above text included in the
document.

Carlisle.


------_=_NextPart_001_01C19F72.902D4AA0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2652.35">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>
</HEAD>
<BODY>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Hi,</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"MS Sans Serif">----------</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">From:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Ambarish =
Malpani[SMTP:[e-mail]]</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Sent:</FONT></B> &nbsp; =
<FONT SIZE=3D2 FACE=3D"MS Sans Serif">Wednesday, January 16, 2002 4:38 =
PM</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">To:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans Serif">'Santosh =
Chokhani'</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Cc:</FONT></B> =
&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">'[e-mail] '</FONT>
<BR><B><FONT SIZE=3D2 FACE=3D"MS Sans Serif">Subject:</FONT></B> =
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 FACE=3D"MS Sans =
Serif">RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Hi Santosh,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp;&nbsp;&nbsp; Give me some =
time.... :-)</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">Me =
too.&nbsp; I get fewer opportunities to follow the PKIX list these =
days...</FONT>
</P>
<UL>
<P><FONT SIZE=3D2 FACE=3D"Arial">I agree with your first =
analysis:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;If nextUpdate is not set, the =
responder is indicating that newer</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">revocation information is available =
all the time&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Actually, they way I would prefer to =
state it would be something</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">like:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">&quot;If nextUpdate is not set, the =
responder is indicating that it</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">doesn't know when newer information =
will be available and so, if</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">a client wants status information on =
the certificate in question</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">at a future date, it should come back =
and ask the server again.&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This is my personal opinion. If the =
group agrees, I am happy to</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">modify the document to reflect this =
point of view.</FONT>
</UL>
<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">&nbsp;</FONT>
<BR><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New Roman">That's =
exactly the sort of wording I had in mind, too, when I read Santosh's =
e-mail on this.&nbsp; I'd be happy to see the above text included in =
the document.</FONT></P>

<P><FONT COLOR=3D"#0000FF" SIZE=3D2 FACE=3D"Times New =
Roman">Carlisle.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19F72.902D4AA0--


Received: by above.proper.com (8.11.6/8.11.3) id g0HGE1T16719 for ietf-pkix-bks; Thu, 17 Jan 2002 08:14:01 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HGE0316715 for <[e-mail]>; Thu, 17 Jan 2002 08:14:00 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 7267DC1BB; Thu, 17 Jan 2002 17:13:57 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZKPQVJRN; Thu, 17 Jan 2002 17:13:56 +0100
Message-ID: <[e-mail]>
Date: Thu, 17 Jan 2002 17:15:43 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Denis,
<p>in Germany there are implementations of attribute certificates.
<br>But they are not relevant for us now. Nevertheless I would like
<br>to see that the protocol design allows us to use it for attribute
<br>certificates as well when they might become a requirement.
<p>In the requirement document you already talk about "any kind of
<br>certificate". My proposal is: just add the different types in brackets.
<blockquote TYPE=CITE>
<pre>3. Rational and benefits for DPV (Delegated Path Validation)

DPV allows to perform a real time validation for a time T for any kind&nbsp;
of certificate and any kind of security service.</pre>
</blockquote>

<p><br>The DPV/DPD draft only allows for X.509 public key certificates.
<br>I guess you will update this when the requirement document is stable,
<br>don't you?
<p>- Petra
<p>Denis Pinkas schrieb:
<blockquote TYPE=CITE>Russ,
<p>> Petra and Denis:
<br>>
<br>> The structure of SCVP makes it very easy to add support of attribute
<br>> certificates (or PGP certificates for that matter) at a later date.
<p>We are not talking of solutions at this time, but only of requirements.
<br>So the question is whether we add in the requirements document some
text
<br>to cover attribute certificates. If we do, which text ?
<p>We have not say, at this time, whether SCVP or some flavor of it, will
be
<br>the protocol that answers to these requirements.
<p>Denis
<p>> We need to make sure that there is a constituency for the protocols
<br>> we develop for the standards track.
<br>>
<br>> Russ</blockquote>
</html>



Received: by above.proper.com (8.11.6/8.11.3) id g0HED9O14228 for ietf-pkix-bks; Thu, 17 Jan 2002 06:13:09 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HED7314224 for <[e-mail]>; Thu, 17 Jan 2002 06:13:08 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id PAA17854; Thu, 17 Jan 2002 15:14:15 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id PAA03952; Thu, 17 Jan 2002 15:12:29 +0100
Message-ID: <[e-mail]>
Date: Thu, 17 Jan 2002 15:12:26 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> Denis:
 
> > > The structure of SCVP makes it very easy to add support of attribute
> > > certificates (or PGP certificates for that matter) at a later date.
> >
> >We are not talking of solutions at this time, but only of requirements.
> >So the question is whether we add in the requirements document some text
> >to cover attribute certificates. If we do, which text ?
 
> I raised this question in Salt Lake City.  The group did not want to
> address DPV for attribute certificates at this time.  

Good, I did not remembered, 
... since the meeting report has not yet been distributed to the list. :-(

> The point that I was
> trying to make above is that the protocol design allows us to easily add
> this support in the future.

No protocol has been elected at this time, so this sentence is still not
appropriate. Let us close this debate.

Denis
 
> >We have not say, at this time, whether SCVP or some flavor of it, will be
> >the protocol that answers to these requirements.
> 
> It is not a requirement!
> 
> Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HDvwX12560 for ietf-pkix-bks; Thu, 17 Jan 2002 05:57:58 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0HDvu312552 for <[e-mail]>; Thu, 17 Jan 2002 05:57:57 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 17 Jan 2002 13:57:32 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA06705 for <[e-mail]>; Thu, 17 Jan 2002 08:57:57 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g0HDvtg08021 for <[e-mail]>; Thu, 17 Jan 2002 08:57:55 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <CJPH6BVC>; Thu, 17 Jan 2002 08:57:55 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.118]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPH6B40; Thu, 17 Jan 2002 08:57:46 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Date: Thu, 17 Jan 2002 08:56:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis:

> > The structure of SCVP makes it very easy to add support of attribute
> > certificates (or PGP certificates for that matter) at a later date.
>
>We are not talking of solutions at this time, but only of requirements.
>So the question is whether we add in the requirements document some text
>to cover attribute certificates. If we do, which text ?

I raised this question in Salt Lake City.  The group did not want to 
address DPV for attribute certificates at this time.  The point that I was 
trying to make above is that the protocol design allows us to easily add 
this support in the future.

>We have not say, at this time, whether SCVP or some flavor of it, will be
>the protocol that answers to these requirements.

It is not a requirement!

Russ




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HCwfR10543 for ietf-pkix-bks; Thu, 17 Jan 2002 04:58:41 -0800 (PST)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HCwd310539 for <[e-mail]>; Thu, 17 Jan 2002 04:58:39 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id HAA414978 for <[e-mail]>; Thu, 17 Jan 2002 07:55:33 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0HCwXn41704 for <[e-mail]>; Thu, 17 Jan 2002 07:58:33 -0500
Importance: Normal
Sensitivity: 
Subject: Re: Cautionary Period Straw Poll
To: [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Wed, 16 Jan 2002 16:29:07 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9 |November 26, 2001) at 01/17/2002 07:58:34 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I believe that DPV protocols developed by the PKIX working group
ought not to include support for a cautionary period.

      I believe this because I believe that DSV is the proper place for
this valuable feature, which applies to object signatures rather than to
certificates.

            Tom Gindin




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0HA5rl26282 for ietf-pkix-bks; Thu, 17 Jan 2002 02:05:54 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0HA5p326273 for <[e-mail]>; Thu, 17 Jan 2002 02:05:52 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id LAA21020; Thu, 17 Jan 2002 11:07:00 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id LAA15836; Thu, 17 Jan 2002 11:05:11 +0100
Message-ID: <[e-mail]>
Date: Thu, 17 Jan 2002 11:05:14 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: Petra Barzin <[e-mail]>, [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ,

> Petra and Denis:
> 
> The structure of SCVP makes it very easy to add support of attribute
> certificates (or PGP certificates for that matter) at a later date.  

We are not talking of solutions at this time, but only of requirements. 
So the question is whether we add in the requirements document some text 
to cover attribute certificates. If we do, which text ?

We have not say, at this time, whether SCVP or some flavor of it, will be
the protocol that answers to these requirements.

Denis

> We need to make sure that there is a constituency for the protocols 
> we develop for the standards track.
> 
> Russ
> 
> At 12:36 PM 1/16/2002 +0100, Denis Pinkas wrote:
> 
> >Petra,
> >
> > > Yes, thanks for the pointer. I found the ASN.1 definitions there.
> > >
> > > One more question turned up:
> > > Is DPV restricted to X.509 public key certificates or is it possible
> > > to use it for X.509 attribute certificates as well?
> >
> >Clearly, both the DPV-DPD protocol draft and the DPV-DPD requirement draft
> >have been specifically written to support PKIX public key certificates.
> >
> >At the last IETF meeting a question has been raised to the audience:
> >Who, in the room, has implemented Attribute Certificates ?
> >No hand showed up.
> >
> >So it seems that there is no urgence to support PKIX attribute
> certificates.
> >
> >However, maybe by making some changes, PKIX attribute certificates could be
> >supported, but this is an exercise that I have not undertaken.
> >
> >The basic question is thus whether to include the support of attribute
> >certificates in the current DPV-DPD requirement draft.
> >
> >Unless you, or someone else, can rapidly provide arguments and demonstrate
> >that it will not delay the support of PKIX public key certificates, I would
> >rather think that it should not be included at this time.
> >
> >Regards,
> >
> >Denis
> >
> >
> > > - Petra
> > >
> > > Denis Pinkas schrieb:
> > >
> > > > Petra,
> > > >
> > > > Please take a look at RFC 3126, where many of the ASN.1 structures
> were
> > > > imported from and are thus defined there. This should answer all your
> > > > questions.
> > > >
> > > > Regards,
> > > >
> > > > Denis
> > > >
> > > > > Denis,
> > > > >
> > > > > may I still ask some questions concerning the document "Delegated
> > > > > Path Validation and Delegated Path Discovery Protocols" ?
> > > > >
> > > > > > PathValues :: = SEQUENCE {
> > > > > >        certificateValues      CertificateValues,
> > > > > >        revocationValues       RevocationValues }
> > > > > >
> > > > > I'm missing some ASN.1 definitions. You refer to "CertificateValues"
> > > > > and "RevocationValues" but I couldn't find these definitions.
> > > > >
> > > > > By the way, you should move this definition of "PathValues" from
> > > > > the chapter "5.2.1. Request" to the chapter "5.2.2.  Response
> Syntax"
> > > > > where it is used.
> > > > >
> > > > > Another ASN.1 question:
> > > > >
> > > > > > UsefulRevoc ::= CHOICE {
> > > > > >        certificateRevocationLists     CertificateRevocationLists,
> > > > > >        completeRevocationRefs         CompleteRevocationRefs }
> > > > > >
> > > > > A DPV request may contain useful revocation information provided
> > > > > by the client. Maybe it's because I don't know the element
> > > > > "CompleteRevocationRefs" but where do I store OCSP answers?
> > > > >
> > > > > Could you please send the definition of "CompleteRevocationRefs"
> > > > > and "completeCertificateRefs"? I guess they are imported from
> [ES-F],
> > > > > "Electronic Signature Formats for long term electronic signatures",
> > aren't
> > > > > they?
> > > > >
> > > > > >    CertOrCertRef ::=  CHOICE {
> > > > > >        certificate          [1]  Certificate,
> > > > > >        certRef              [2]  OtherCertID }
> > > > > >
> > > > > I'm also missing the definition of OtherCertID used in a DPV and DPD
> > > > > request.
> > > > >
> > > > > Thanks, Petra
> > > > >
> > > > > Denis Pinkas schrieb:
> > > > >
> > > > > > Petra,
> > > > > >
> > > > > > > Denis,
> > > > > >
> > > > > > > is there also a new version of the document "Delegated Path
> > > > > > > Validation and Delegated Path Discovery Protocols"
> > > > > >
> > > > > > Not at this time. Currently we need first to agree on the DPV /
> DPD
> > > > > > requirements, then we will discuss the solutions to these
> > requirements.
> > > > > >
> > > > > > The so-called "Delegated Path Validation and Delegated Path
> Discovery
> > > > > > Protocols" document could be a candidate to fulfill these
> > requirements.
> > > > > > It is too early to say and this will only be discussed once the
> > > > > > requirements
> > > > > > document is adopted.
> > > > > >
> > > > > > > or just a new requirement document?
> > > > > >
> > > > > > Correct. It is a new document for both the DPV and DPD
> requirements.
> > > > > >
> > > > > > There is also a companion document for the DSV requirements.
> > > > > > We will only discuss the DSV requirements document in detail when
> > > > > > the DPV / DPD requirements document has completed the WG last
> call.
> > > > > >
> > > > > > Denis
> 
> ============================================================================
> ================
> This e-mail, its content and any files transmitted with it are intended
> solely for the addressee(s) and are PRIVILEGED and
> CONFIDENTIAL.  Access by any other party is unauthorized without the express
> prior written permission of the sender.  If
> you have received this e-mail in error you may not copy, disclose to any
> third party or use the contents, attachments or
> information in any way, Please delete all copies of the e-mail and the
> attachment(s), if any and notify the sender.
> Thank You.
> ============================================================================
> ================


Received: by above.proper.com (8.11.6/8.11.3) id g0H24hV24843 for ietf-pkix-bks; Wed, 16 Jan 2002 18:04:43 -0800 (PST)
Received: from zolera.com ([63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0H24f324839 for <[e-mail]>; Wed, 16 Jan 2002 18:04:41 -0800 (PST)
Received: from zolera.com (pool-141-154-56-231.bos.east.verizon.net [141.154.56.231]) by zolera.com (8.11.6/8.11.6) with ESMTP id g0H25SK21453; Wed, 16 Jan 2002 21:05:28 -0500
Message-ID: <[e-mail]>
Date: Wed, 16 Jan 2002 21:04:41 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: Hash values in OCSP
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> 1. The IssuerNameHash has to be calculated using the DER encoding of the
> issuer's name field EXACTLY as it appears in the target certificate (the one
> being checked with OCSP)? Or is there a standard regarding the order of the
> SETs in the RDN components?

Well it's DER, which specifies exactly one way to encode things, so if
the cert is encoded in DER, then it is presumably encoding the RDN SETs
the right way.  So the answer to your question is "yes" :)

#2 -- someone else will have to answer; I've been away from OCSP for too
long.
	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com


Received: by above.proper.com (8.11.6/8.11.3) id g0H1iFg23910 for ietf-pkix-bks; Wed, 16 Jan 2002 17:44:15 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0H1iE323905 for <[e-mail]>; Wed, 16 Jan 2002 17:44:14 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 16 Jan 2002 17:44:17 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 16 Jan 2002 17:44:16 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <C2FYW669>; Wed, 16 Jan 2002 17:44:16 -0800
Content-return: allowed
Date: Wed, 16 Jan 2002 17:44:15 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Hash values in OCSP
To: "'[e-mail]'" <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain;	charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi Mars,
    Responses inline.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> Sent: Wednesday, January 16, 2002 3:47 PM
> To: [e-mail]
> Subject: Hash values in OCSP
> 
> 
> 
> I request your help in the following issues regarding RFC 2560:
> 
> 1. The IssuerNameHash has to be calculated using the DER 
> encoding of the
> issuer's name field EXACTLY as it appears in the target 
> certificate (the one
> being checked with OCSP)? Or is there a standard regarding 
> the order of the
> SETs in the RDN components?

It is the (correct and unique) DER encoding of the issuer's name.
That said, quite a few people incorrectly perform DER encoding
of DNs. If either you, or the responder you are relying upon,
incorrectly do the DER encoding, all bets are off.

> 
> 2. The IssuerKeyHash value must be calculated excluding tag 
> and length of
> the DER encoding
> of the subject public key field in the issuer's certificate. 
> Since it is
> encoded as a BIT STRING, are we required to include the first 
> contents octet
> (AKA the number of unused bits) in the input to the hash function?

As it turns out, all implementations that I know of, have EXCLUDED
the number of unused bits. I have clarified this in the version of
the spec set up to go to draft standard.

> 
> Thanks, best regards,
> 
> Miguel A. Rodriguez
> Software Engineer
> SeguriDATA
> Mexico
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0H01vJ20171 for ietf-pkix-bks; Wed, 16 Jan 2002 16:01:57 -0800 (PST)
Received: from zolera.com ([63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0H01u320167 for <[e-mail]>; Wed, 16 Jan 2002 16:01:56 -0800 (PST)
Received: from zolera.com (pool-141-154-56-231.bos.east.verizon.net [141.154.56.231]) by zolera.com (8.11.6/8.11.6) with ESMTP id g0H01pK20820; Wed, 16 Jan 2002 19:01:51 -0500
Message-ID: <[e-mail]>
Date: Wed, 16 Jan 2002 19:01:04 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Williams <[e-mail]>
CC: "'Denis Pinkas '" <[e-mail]>, "'Santosh Chokhani '" <[e-mail]>, "'[e-mail] '" <[e-mail]>
Subject: Re: OCSP RFC and OCSP version 2 ID
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

>From the time of the first I-D for OCSPv1 up until close to RFC status,
CertCo was the third major entity in the OCSP arena. We were at least
partially fronting for the still-being-created Identrus, and we (CertCo
and the tech commmittee folks from the initial working groups) saw OCSP
as the keystone for its online trust services.

For what it's worth, the CertCo product used CRL's, but also had a "fast
track" interface for updating its internal database.  At the time, we
would often explain that CRL-only approaches were deficient to our
LDAP-based publication and CRL approach, since a CRL couldn't tell you
if a certificate was, in fact, never issued. :)

> Currently, VeriSign's current work in W3C also
> reflects alot of the understanding on the required
> semantics of realtime trust models.

Hardly.  Much as I like XKMS (a co-worker is co-editor on the
requirements document), its approach to semantics is to sweep them under
the rug; post to the right URL and "just trust me."
	/r$
-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GNuTN20060 for ietf-pkix-bks; Wed, 16 Jan 2002 15:56:29 -0800 (PST)
Received: from www.seguridata.com (seguridata02.terra.net.mx [200.4.103.226]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GNuP320056 for <[e-mail]>; Wed, 16 Jan 2002 15:56:26 -0800 (PST)
Received: from mars ([10.0.0.1]) by www.seguridata.com (Post.Office MTA v3.5.3 release 223 ID# 517-61027U100L2S100V35) with SMTP id com for <[e-mail]>; Wed, 16 Jan 2002 18:02:33 -0600
Reply-To: <[e-mail]>
From: [e-mail] (Miguel Angel Rodriguez)
To: <[e-mail]>
Subject: Hash values in OCSP
Date: Wed, 16 Jan 2002 17:46:49 -0600
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I request your help in the following issues regarding RFC 2560:

1. The IssuerNameHash has to be calculated using the DER encoding of the
issuer's name field EXACTLY as it appears in the target certificate (the one
being checked with OCSP)? Or is there a standard regarding the order of the
SETs in the RDN components?

2. The IssuerKeyHash value must be calculated excluding tag and length of
the DER encoding
of the subject public key field in the issuer's certificate. Since it is
encoded as a BIT STRING, are we required to include the first contents octet
(AKA the number of unused bits) in the input to the hash function?

Thanks, best regards,

Miguel A. Rodriguez
Software Engineer
SeguriDATA
Mexico



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GNYfh19676 for ietf-pkix-bks; Wed, 16 Jan 2002 15:34:41 -0800 (PST)
Received: from zolera.com ([63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GNYd319672 for <[e-mail]>; Wed, 16 Jan 2002 15:34:39 -0800 (PST)
Received: from zolera.com (pool-141-154-56-231.bos.east.verizon.net [141.154.56.231]) by zolera.com (8.11.6/8.11.6) with ESMTP id g0GNZhK20713 for <[e-mail]>; Wed, 16 Jan 2002 18:35:43 -0500
Message-ID: <[e-mail]>
Date: Wed, 16 Jan 2002 18:34:56 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
CC: [e-mail]
Subject: Re: Cautionary Period Straw Poll
References: <[e-mail]> <p05101202b86b6e1f1ee8@[165.227.249.20]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I am against cautionary periods; I believe the confusion and complexity
greatly outweighs the gain.
	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com


Received: by above.proper.com (8.11.6/8.11.3) id g0GMDGG16857 for ietf-pkix-bks; Wed, 16 Jan 2002 14:13:16 -0800 (PST)
Received: from femail12.sdc1.sfba.home.com (femail12.sdc1.sfba.home.com [24.0.95.108]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GMDF316853 for <[e-mail]>; Wed, 16 Jan 2002 14:13:15 -0800 (PST)
Received: from SJOSEPH ([68.55.160.145]) by femail12.sdc1.sfba.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with SMTP id <20020116221318.DYOB26021.femail12.sdc1.sfba.home.com@SJOSEPH> for <[e-mail]>; Wed, 16 Jan 2002 14:13:18 -0800
Message-ID: <008f01c19eda$847b5960$6501a8c0@SJOSEPH>
From: "Al Arsenault" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Cautionary Period Straw Poll
Date: Wed, 16 Jan 2002 17:09:50 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I believe that DPV protocols developed by the PKIX working group ought not
include support for a cautionary period.

I believe this because it would make the protocol even bigger and more
complex than it already will be, and that will inevitably lead to even
slower adoption and use.

If this is truly a feature needed by some users, they can add it at the
application layer without affecting the protocol  itself.

            Al Arsenault





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GLkiI15919 for ietf-pkix-bks; Wed, 16 Jan 2002 13:46:44 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GLkh315915 for <[e-mail]>; Wed, 16 Jan 2002 13:46:43 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <DB0JNQY6>; Wed, 16 Jan 2002 16:46:35 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B5C1@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: Ambarish Malpani <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Wed, 16 Jan 2002 16:45:22 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19ED7.19852D00"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C19ED7.19852D00
Content-Type: text/plain

Ambarish:

It seems that your approach to modify is fine.  It seems to align the
semantics of the nextUpdate field with CRL.

I have no problem with that.  Keeping the other language is guarantying
freshness and it means that the OCSP responder is getting real-time
revocation information from CA.

-----Original Message-----
From: Ambarish Malpani [mailto:[e-mail]]
Sent: Wednesday, January 16, 2002 4:38 PM
To: 'Santosh Chokhani'
Cc: '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID




Hi Santosh,
    Give me some time.... :-)

I agree with your first analysis:

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

Actually, they way I would prefer to state it would be something
like:
"If nextUpdate is not set, the responder is indicating that it
doesn't know when newer information will be available and so, if
a client wants status information on the certificate in question
at a future date, it should come back and ask the server again."

This is my personal opinion. If the group agrees, I am happy to
modify the document to reflect this point of view.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, January 16, 2002 11:50 AM
To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
Cc: '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Why aren't the authors responding to this contradiction in the RFC and
carried out in the ID? 
-----Original Message----- 
From: Peter Williams [mailto:[e-mail]] 
Sent: Wednesday, January 16, 2002 2:41 PM 
To: 'Denis Pinkas '; 'Santosh Chokhani ' 
Cc: '[e-mail] ' 
Subject: RE: OCSP RFC and OCSP version 2 ID 


Denis, 
You refer to an assumed  "main mechanism" in your note. Speaking factually, 
to hopefully guide you, sensibly:- 
The main [reference] mechanism(s) at, and shortly after, 
the time of writing OCSP IDs included:- 
(1) VeriSign, who used an oracle database-based repository to feed data 
to OCSP deamons acting in cached and interactive, direct-trust 
mode; CRLs were not involved. OCSP proxing/multiplexing interactive 
direct-trust mode was  added, shortly after standarization, for a 
defense customer bridging multiple certification domains. 
(2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP 
deamons. Indirect CRLs and CRLDPs support was added slightly after 
the architects had harmonized their work. 
Both mechanisms evolved further, outside of IETF and 
in vendor forums, particularly in the area of: application 
integration, CRLDPs and delta-CRL data sources, proxying 
transaction semantics and response resigning, data freshness 
signalling, and OCSP client interaction with X.509 and 
PKIX-style path processing and X.509 applications such as 
SSLv3/https and MTA-based automatic xmldsig signature 
verification on B2B and banking protocol XML streams. 
Historically, this work essentially re-designed the standardized 
features of the "distributed authentication model" of 
X.500 1988, for OCSP-borne queries. 
Currently, VeriSign's current work in W3C also 
reflects alot of the understanding on the required 
semantics of realtime trust models. 
Peter. 
-----Original Message----- 
From: Denis Pinkas 
To: Santosh Chokhani 
Cc: [e-mail] 
Sent: 1/16/02 12:04 AM 
Subject: Re: OCSP RFC and OCSP version 2 ID 
At the time the document was written, the main mechanism to feed the 
information to the OCSP server was to use CRLs. So it seems sensible to 
think that these fields are copied from a CRL. 
  

------_=_NextPart_001_01C19ED7.19852D00
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Ambarish:</FONT>
</P>

<P><FONT SIZE=3D2>It seems that your approach to modify is fine.&nbsp; =
It seems to align the semantics of the nextUpdate field with =
CRL.</FONT>
</P>

<P><FONT SIZE=3D2>I have no problem with that.&nbsp; Keeping the other =
language is guarantying freshness and it means that the OCSP responder =
is getting real-time revocation information from CA.</FONT></P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Ambarish Malpani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, January 16, 2002 4:38 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Santosh Chokhani'</FONT>
<BR><FONT SIZE=3D2>Cc: '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=3D2>Hi Santosh,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp; Give me some time.... :-)</FONT>
</P>

<P><FONT SIZE=3D2>I agree with your first analysis:</FONT>
</P>

<P><FONT SIZE=3D2>&quot;If nextUpdate is not set, the responder is =
indicating that newer</FONT>
<BR><FONT SIZE=3D2>revocation information is available all the =
time&quot;</FONT>
</P>

<P><FONT SIZE=3D2>Actually, they way I would prefer to state it would =
be something</FONT>
<BR><FONT SIZE=3D2>like:</FONT>
<BR><FONT SIZE=3D2>&quot;If nextUpdate is not set, the responder is =
indicating that it</FONT>
<BR><FONT SIZE=3D2>doesn't know when newer information will be =
available and so, if</FONT>
<BR><FONT SIZE=3D2>a client wants status information on the certificate =
in question</FONT>
<BR><FONT SIZE=3D2>at a future date, it should come back and ask the =
server again.&quot;</FONT>
</P>

<P><FONT SIZE=3D2>This is my personal opinion. If the group agrees, I =
am happy to</FONT>
<BR><FONT SIZE=3D2>modify the document to reflect this point of =
view.</FONT>
</P>

<P><FONT SIZE=3D2>Regards,</FONT>
<BR><FONT SIZE=3D2>Ambarish</FONT>
</P>

<P><FONT =
SIZE=3D2>---------------------------------------------------------------=
------</FONT>
<BR><FONT SIZE=3D2>Ambarish Malpani</FONT>
<BR><FONT =
SIZE=3D2>Architect&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp; 650.567.5457</FONT>
<BR><FONT SIZE=3D2>ValiCert, =
Inc.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[e-mail]</FONT>
<BR><FONT SIZE=3D2>339 N. Bernardo =
Ave.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
bsp;&nbsp; <A HREF=3D"http://www.valicert.com" =
TARGET=3D"_blank">http://www.valicert.com</A></FONT>
<BR><FONT SIZE=3D2>Mountain View, CA 94043</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Santosh Chokhani [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, January 16, 2002 11:50 AM</FONT>
<BR><FONT SIZE=3D2>To: Peter Williams; 'Denis Pinkas '; Santosh =
Chokhani</FONT>
<BR><FONT SIZE=3D2>Cc: '[e-mail] '</FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Why aren't the authors responding to this =
contradiction in the RFC and</FONT>
<BR><FONT SIZE=3D2>carried out in the ID? </FONT>
<BR><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Peter Williams [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Wednesday, January 16, 2002 2:41 PM </FONT>
<BR><FONT SIZE=3D2>To: 'Denis Pinkas '; 'Santosh Chokhani ' </FONT>
<BR><FONT SIZE=3D2>Cc: '[e-mail] ' </FONT>
<BR><FONT SIZE=3D2>Subject: RE: OCSP RFC and OCSP version 2 ID </FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Denis, </FONT>
<BR><FONT SIZE=3D2>You refer to an assumed&nbsp; &quot;main =
mechanism&quot; in your note. Speaking factually, </FONT>
<BR><FONT SIZE=3D2>to hopefully guide you, sensibly:- </FONT>
<BR><FONT SIZE=3D2>The main [reference] mechanism(s) at, and shortly =
after, </FONT>
<BR><FONT SIZE=3D2>the time of writing OCSP IDs included:- </FONT>
<BR><FONT SIZE=3D2>(1) VeriSign, who used an oracle database-based =
repository to feed data </FONT>
<BR><FONT SIZE=3D2>to OCSP deamons acting in cached and interactive, =
direct-trust </FONT>
<BR><FONT SIZE=3D2>mode; CRLs were not involved. OCSP =
proxing/multiplexing interactive </FONT>
<BR><FONT SIZE=3D2>direct-trust mode was&nbsp; added, shortly after =
standarization, for a </FONT>
<BR><FONT SIZE=3D2>defense customer bridging multiple certification =
domains. </FONT>
<BR><FONT SIZE=3D2>(2) ValiCert, who used direct CRLs to feed data to =
direct/indirect OCSP </FONT>
<BR><FONT SIZE=3D2>deamons. Indirect CRLs and CRLDPs support was added =
slightly after </FONT>
<BR><FONT SIZE=3D2>the architects had harmonized their work. </FONT>
<BR><FONT SIZE=3D2>Both mechanisms evolved further, outside of IETF and =
</FONT>
<BR><FONT SIZE=3D2>in vendor forums, particularly in the area of: =
application </FONT>
<BR><FONT SIZE=3D2>integration, CRLDPs and delta-CRL data sources, =
proxying </FONT>
<BR><FONT SIZE=3D2>transaction semantics and response resigning, data =
freshness </FONT>
<BR><FONT SIZE=3D2>signalling, and OCSP client interaction with X.509 =
and </FONT>
<BR><FONT SIZE=3D2>PKIX-style path processing and X.509 applications =
such as </FONT>
<BR><FONT SIZE=3D2>SSLv3/https and MTA-based automatic xmldsig =
signature </FONT>
<BR><FONT SIZE=3D2>verification on B2B and banking protocol XML =
streams. </FONT>
<BR><FONT SIZE=3D2>Historically, this work essentially re-designed the =
standardized </FONT>
<BR><FONT SIZE=3D2>features of the &quot;distributed authentication =
model&quot; of </FONT>
<BR><FONT SIZE=3D2>X.500 1988, for OCSP-borne queries. </FONT>
<BR><FONT SIZE=3D2>Currently, VeriSign's current work in W3C also =
</FONT>
<BR><FONT SIZE=3D2>reflects alot of the understanding on the required =
</FONT>
<BR><FONT SIZE=3D2>semantics of realtime trust models. </FONT>
<BR><FONT SIZE=3D2>Peter. </FONT>
<BR><FONT SIZE=3D2>-----Original Message----- </FONT>
<BR><FONT SIZE=3D2>From: Denis Pinkas </FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani </FONT>
<BR><FONT SIZE=3D2>Cc: [e-mail] </FONT>
<BR><FONT SIZE=3D2>Sent: 1/16/02 12:04 AM </FONT>
<BR><FONT SIZE=3D2>Subject: Re: OCSP RFC and OCSP version 2 ID </FONT>
<BR><FONT SIZE=3D2>At the time the document was written, the main =
mechanism to feed the </FONT>
<BR><FONT SIZE=3D2>information to the OCSP server was to use CRLs. So =
it seems sensible to </FONT>
<BR><FONT SIZE=3D2>think that these fields are copied from a CRL. =
</FONT>
<BR><FONT SIZE=3D2>&nbsp; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19ED7.19852D00--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GLcDS14908 for ietf-pkix-bks; Wed, 16 Jan 2002 13:38:13 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GLcC314899 for <[e-mail]>; Wed, 16 Jan 2002 13:38:12 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 16 Jan 2002 13:38:15 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 16 Jan 2002 13:38:14 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <C2FYW5QC>; Wed, 16 Jan 2002 13:38:14 -0800
Content-return: allowed
Date: Wed, 16 Jan 2002 13:38:13 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'Santosh Chokhani'" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi Santosh,
    Give me some time.... :-)

I agree with your first analysis:

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

Actually, they way I would prefer to state it would be something
like:
"If nextUpdate is not set, the responder is indicating that it
doesn't know when newer information will be available and so, if
a client wants status information on the certificate in question
at a future date, it should come back and ask the server again."

This is my personal opinion. If the group agrees, I am happy to
modify the document to reflect this point of view.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[e-mail]]
Sent: Wednesday, January 16, 2002 11:50 AM
To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
Cc: '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Why aren't the authors responding to this contradiction in the RFC and
carried out in the ID? 
-----Original Message----- 
From: Peter Williams [mailto:[e-mail]] 
Sent: Wednesday, January 16, 2002 2:41 PM 
To: 'Denis Pinkas '; 'Santosh Chokhani ' 
Cc: '[e-mail] ' 
Subject: RE: OCSP RFC and OCSP version 2 ID 


Denis, 
You refer to an assumed  "main mechanism" in your note. Speaking factually, 
to hopefully guide you, sensibly:- 
The main [reference] mechanism(s) at, and shortly after, 
the time of writing OCSP IDs included:- 
(1) VeriSign, who used an oracle database-based repository to feed data 
to OCSP deamons acting in cached and interactive, direct-trust 
mode; CRLs were not involved. OCSP proxing/multiplexing interactive 
direct-trust mode was  added, shortly after standarization, for a 
defense customer bridging multiple certification domains. 
(2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP 
deamons. Indirect CRLs and CRLDPs support was added slightly after 
the architects had harmonized their work. 
Both mechanisms evolved further, outside of IETF and 
in vendor forums, particularly in the area of: application 
integration, CRLDPs and delta-CRL data sources, proxying 
transaction semantics and response resigning, data freshness 
signalling, and OCSP client interaction with X.509 and 
PKIX-style path processing and X.509 applications such as 
SSLv3/https and MTA-based automatic xmldsig signature 
verification on B2B and banking protocol XML streams. 
Historically, this work essentially re-designed the standardized 
features of the "distributed authentication model" of 
X.500 1988, for OCSP-borne queries. 
Currently, VeriSign's current work in W3C also 
reflects alot of the understanding on the required 
semantics of realtime trust models. 
Peter. 
-----Original Message----- 
From: Denis Pinkas 
To: Santosh Chokhani 
Cc: [e-mail] 
Sent: 1/16/02 12:04 AM 
Subject: Re: OCSP RFC and OCSP version 2 ID 
At the time the document was written, the main mechanism to feed the 
information to the OCSP server was to use CRLs. So it seems sensible to 
think that these fields are copied from a CRL. 
  


Received: by above.proper.com (8.11.6/8.11.3) id g0GKnEt13330 for ietf-pkix-bks; Wed, 16 Jan 2002 12:49:14 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GKnD313326 for <[e-mail]>; Wed, 16 Jan 2002 12:49:13 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g0GKjrR27430 for <[e-mail]>; Wed, 16 Jan 2002 12:45:53 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <Y2Y1FK32>; Wed, 16 Jan 2002 12:50:07 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: [e-mail]
Subject: RE: Cautionary Period Straw Poll
Date: Wed, 16 Jan 2002 12:48:13 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I believe that DPV protocols developed by the PKIX working group
ought not include support for a cautionary period.

Alex


Received: by above.proper.com (8.11.6/8.11.3) id g0GKAYK12450 for ietf-pkix-bks; Wed, 16 Jan 2002 12:10:34 -0800 (PST)
Received: from ocasey.baltimore.com (ocasey.baltimore.com [193.41.17.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GKAT312441; Wed, 16 Jan 2002 12:10:30 -0800 (PST)
Received: from Baltimore-FW1 ([172.19.1.1]) by ocasey.baltimore.com (8.11.6/8.9.3) with SMTP id g0GKAVU02894; Wed, 16 Jan 2002 20:10:31 GMT
Received: from Baltimore-FW1 (wilde-i-1.ie.baltimore.com) by emeairlsw1.baltimore.com (Content Technologies SMTPRS 4.2.5) with SMTP id <[e-mail]>; Wed, 16 Jan 2002 20:06:06 +0000
Received: from baltimore.ie (wks113-25.ie.baltimore.com [10.153.26.113] (may be forged)) by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id UAA27756; Wed, 16 Jan 2002 20:10:26 GMT
Message-ID: <[e-mail]>
Date: Wed, 16 Jan 2002 20:06:04 +0000
From: Stephen Farrell <[e-mail]>
Reply-To: [e-mail]
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Cautionary Period Straw Poll
References: <[e-mail]> <p05101202b86b6e1f1ee8@[165.227.249.20]>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I believe that DPV protocols developed by the PKIX working group
ought not include support for a cautionary period.

I believe this for reasons already stated (e.g. by Paul Hoffman)
and also because I believe we shouldn't make DPV even more
dubious (there - I tried again:-).

Stephen.

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



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GJplE12089 for ietf-pkix-bks; Wed, 16 Jan 2002 11:51:47 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GJpk312085 for <[e-mail]>; Wed, 16 Jan 2002 11:51:46 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <DB0JN38J>; Wed, 16 Jan 2002 14:51:38 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B5A8@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: Peter Williams <[e-mail]>, "'Denis Pinkas '" <[e-mail]>, Santosh Chokhani <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Wed, 16 Jan 2002 14:50:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19EC7.0A9B3970"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C19EC7.0A9B3970
Content-Type: text/plain

Why aren't the authors responding to this contradiction in the RFC and
carried out in the ID?

-----Original Message-----
From: Peter Williams [mailto:[e-mail]]
Sent: Wednesday, January 16, 2002 2:41 PM
To: 'Denis Pinkas '; 'Santosh Chokhani '
Cc: '[e-mail] '
Subject: RE: OCSP RFC and OCSP version 2 ID


Denis,

You refer to an assumed  "main mechanism" in your note. Speaking factually,
to hopefully guide you, sensibly:-

The main [reference] mechanism(s) at, and shortly after,
the time of writing OCSP IDs included:-

(1) VeriSign, who used an oracle database-based repository to feed data
to OCSP deamons acting in cached and interactive, direct-trust 
mode; CRLs were not involved. OCSP proxing/multiplexing interactive
direct-trust mode was  added, shortly after standarization, for a 
defense customer bridging multiple certification domains.

(2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP
deamons. Indirect CRLs and CRLDPs support was added slightly after
the architects had harmonized their work.

Both mechanisms evolved further, outside of IETF and
in vendor forums, particularly in the area of: application 
integration, CRLDPs and delta-CRL data sources, proxying 
transaction semantics and response resigning, data freshness 
signalling, and OCSP client interaction with X.509 and 
PKIX-style path processing and X.509 applications such as 
SSLv3/https and MTA-based automatic xmldsig signature 
verification on B2B and banking protocol XML streams.

Historically, this work essentially re-designed the standardized
features of the "distributed authentication model" of 
X.500 1988, for OCSP-borne queries.

Currently, VeriSign's current work in W3C also
reflects alot of the understanding on the required
semantics of realtime trust models.

Peter.

-----Original Message-----
From: Denis Pinkas
To: Santosh Chokhani
Cc: [e-mail]
Sent: 1/16/02 12:04 AM
Subject: Re: OCSP RFC and OCSP version 2 ID

At the time the document was written, the main mechanism to feed the
information to the OCSP server was to use CRLs. So it seems sensible to
think that these fields are copied from a CRL.
 

------_=_NextPart_001_01C19EC7.0A9B3970
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=US-ASCII">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>RE: OCSP RFC and OCSP version 2 ID</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Why aren't the authors responding to this contradiction in the RFC and carried out in the ID?</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Peter Williams [<A HREF="mailto:[e-mail]">mailto:[e-mail]</A>]</FONT>
<BR><FONT SIZE=2>Sent: Wednesday, January 16, 2002 2:41 PM</FONT>
<BR><FONT SIZE=2>To: 'Denis Pinkas '; 'Santosh Chokhani '</FONT>
<BR><FONT SIZE=2>Cc: '[e-mail] '</FONT>
<BR><FONT SIZE=2>Subject: RE: OCSP RFC and OCSP version 2 ID</FONT>
</P>
<BR>

<P><FONT SIZE=2>Denis,</FONT>
</P>

<P><FONT SIZE=2>You refer to an assumed&nbsp; &quot;main mechanism&quot; in your note. Speaking factually,</FONT>
<BR><FONT SIZE=2>to hopefully guide you, sensibly:-</FONT>
</P>

<P><FONT SIZE=2>The main [reference] mechanism(s) at, and shortly after,</FONT>
<BR><FONT SIZE=2>the time of writing OCSP IDs included:-</FONT>
</P>

<P><FONT SIZE=2>(1) VeriSign, who used an oracle database-based repository to feed data</FONT>
<BR><FONT SIZE=2>to OCSP deamons acting in cached and interactive, direct-trust </FONT>
<BR><FONT SIZE=2>mode; CRLs were not involved. OCSP proxing/multiplexing interactive</FONT>
<BR><FONT SIZE=2>direct-trust mode was&nbsp; added, shortly after standarization, for a </FONT>
<BR><FONT SIZE=2>defense customer bridging multiple certification domains.</FONT>
</P>

<P><FONT SIZE=2>(2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP</FONT>
<BR><FONT SIZE=2>deamons. Indirect CRLs and CRLDPs support was added slightly after</FONT>
<BR><FONT SIZE=2>the architects had harmonized their work.</FONT>
</P>

<P><FONT SIZE=2>Both mechanisms evolved further, outside of IETF and</FONT>
<BR><FONT SIZE=2>in vendor forums, particularly in the area of: application </FONT>
<BR><FONT SIZE=2>integration, CRLDPs and delta-CRL data sources, proxying </FONT>
<BR><FONT SIZE=2>transaction semantics and response resigning, data freshness </FONT>
<BR><FONT SIZE=2>signalling, and OCSP client interaction with X.509 and </FONT>
<BR><FONT SIZE=2>PKIX-style path processing and X.509 applications such as </FONT>
<BR><FONT SIZE=2>SSLv3/https and MTA-based automatic xmldsig signature </FONT>
<BR><FONT SIZE=2>verification on B2B and banking protocol XML streams.</FONT>
</P>

<P><FONT SIZE=2>Historically, this work essentially re-designed the standardized</FONT>
<BR><FONT SIZE=2>features of the &quot;distributed authentication model&quot; of </FONT>
<BR><FONT SIZE=2>X.500 1988, for OCSP-borne queries.</FONT>
</P>

<P><FONT SIZE=2>Currently, VeriSign's current work in W3C also</FONT>
<BR><FONT SIZE=2>reflects alot of the understanding on the required</FONT>
<BR><FONT SIZE=2>semantics of realtime trust models.</FONT>
</P>

<P><FONT SIZE=2>Peter.</FONT>
</P>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Denis Pinkas</FONT>
<BR><FONT SIZE=2>To: Santosh Chokhani</FONT>
<BR><FONT SIZE=2>Cc: [e-mail]</FONT>
<BR><FONT SIZE=2>Sent: 1/16/02 12:04 AM</FONT>
<BR><FONT SIZE=2>Subject: Re: OCSP RFC and OCSP version 2 ID</FONT>
</P>

<P><FONT SIZE=2>At the time the document was written, the main mechanism to feed the</FONT>
<BR><FONT SIZE=2>information to the OCSP server was to use CRLs. So it seems sensible to</FONT>
<BR><FONT SIZE=2>think that these fields are copied from a CRL.</FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19EC7.0A9B3970--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GJfTo11855 for ietf-pkix-bks; Wed, 16 Jan 2002 11:41:29 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GJfS311850 for <[e-mail]>; Wed, 16 Jan 2002 11:41:28 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Wed, 16 Jan 2002 11:41:29 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]>; Wed, 16 Jan 2002 11:41:29 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <C2FYWZ0M>; Wed, 16 Jan 2002 11:41:28 -0800
Content-return: allowed
Date: Wed, 16 Jan 2002 11:41:27 -0800
From: Peter Williams <[e-mail]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'Denis Pinkas '" <[e-mail]>, "'Santosh Chokhani '" <[e-mail]>
Cc: "'[e-mail] '" <[e-mail]>
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis,

You refer to an assumed  "main mechanism" in your note. Speaking factually,
to hopefully guide you, sensibly:-

The main [reference] mechanism(s) at, and shortly after,
the time of writing OCSP IDs included:-

(1) VeriSign, who used an oracle database-based repository to feed data
to OCSP deamons acting in cached and interactive, direct-trust 
mode; CRLs were not involved. OCSP proxing/multiplexing interactive
direct-trust mode was  added, shortly after standarization, for a 
defense customer bridging multiple certification domains.

(2) ValiCert, who used direct CRLs to feed data to direct/indirect OCSP
deamons. Indirect CRLs and CRLDPs support was added slightly after
the architects had harmonized their work.

Both mechanisms evolved further, outside of IETF and
in vendor forums, particularly in the area of: application 
integration, CRLDPs and delta-CRL data sources, proxying 
transaction semantics and response resigning, data freshness 
signalling, and OCSP client interaction with X.509 and 
PKIX-style path processing and X.509 applications such as 
SSLv3/https and MTA-based automatic xmldsig signature 
verification on B2B and banking protocol XML streams.

Historically, this work essentially re-designed the standardized
features of the "distributed authentication model" of 
X.500 1988, for OCSP-borne queries.

Currently, VeriSign's current work in W3C also
reflects alot of the understanding on the required
semantics of realtime trust models.

Peter.

-----Original Message-----
From: Denis Pinkas
To: Santosh Chokhani
Cc: [e-mail]
Sent: 1/16/02 12:04 AM
Subject: Re: OCSP RFC and OCSP version 2 ID

At the time the document was written, the main mechanism to feed the
information to the OCSP server was to use CRLs. So it seems sensible to
think that these fields are copied from a CRL.
 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GJVtx11595 for ietf-pkix-bks; Wed, 16 Jan 2002 11:31:55 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0GJVr311591 for <[e-mail]>; Wed, 16 Jan 2002 11:31:53 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for [208.184.76.43]) with SMTP; 16 Jan 2002 19:31:30 UT
Received: from exrsa01.rsa.com (exrsa01.rsa.com [10.81.217.7]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA29983 for <[e-mail]>; Wed, 16 Jan 2002 14:31:54 -0500 (EST)
Received: by exrsa01.rsa.com with Internet Mail Service (5.5.2653.19) id <C0S3KFYY>; Wed, 16 Jan 2002 11:06:27 -0800
Message-ID: <[e-mail]>
From: "Yee, Peter" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: Re: Cautionary Period Straw Poll
Date: Wed, 16 Jan 2002 11:06:26 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="ISO-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I feel that a cautionary period is NOT something for PKIX
DPV protocols.

					-Peter Yee


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GIac410302 for ietf-pkix-bks; Wed, 16 Jan 2002 10:36:38 -0800 (PST)
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GIaa310298 for <[e-mail]>; Wed, 16 Jan 2002 10:36:36 -0800 (PST)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g0GIaWY14737 for <[e-mail]>; Wed, 16 Jan 2002 11:36:32 -0700 (MST)
Received: from host66160 (slip-32-103-199-2.ga.us.prserv.net [32.103.199.2]) by smtp.digsigtrust.com with SMTP id g0GIYa020561 for <[e-mail]>; Wed, 16 Jan 2002 11:34:37 -0700 (MST)
Message-ID: <000001c19ebc$ab85d6c0$b20cb9d0@host66160>
Reply-To: "Yuriy Dzambasow" <[e-mail]>
From: "Yuriy Dzambasow" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: Cautionary Period Straw Poll
Date: Wed, 16 Jan 2002 10:13:04 -0500
Organization: Digital Signature Trust
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I believe that DPV protocols developed by the PKIX working group ought not
include support for a cautionary period.

I belive this because I believe that time stamps are more than adequate to
support most applications in determining the validity of a certificate
and/or signature, and adding a cautionary period just adds unnecessary
complexity to the DPV protocols.

Yuriy

----- Original Message -----
From: "Housley, Russ" <[e-mail]>
To: <[e-mail]>
Sent: Tuesday, January 15, 2002 1:05 PM
Subject: Cautionary Period Straw Poll


>
>  From the previous thread (which seems to have died down), I think that
> everyone understands the Cautionary Period concept.  I am trying to
> determine whether there is a constituency for Cautionary Period in DPV.
>
> I would like people that have an opinion to vote by sending a message to
> the list.  The message should be structured as follows:
>
>            To: [e-mail]
>            Subject: RE: Cautionary Period Straw Poll
>
>            I believe that DPV protocols developed by the PKIX working
group
>            [ought to | ought not] include support for a cautionary period.
>
>            [I belive this because ...]
>
> If you feel the need to reply to the rationale posted by  someone, please
> make that posting on the other thread.  Please do not clutter the straw
> poll voting with a debate.
>
> Thanks for your assistance and cooperation,
>    Russ
>



Received: by above.proper.com (8.11.6/8.11.3) id g0GHuNI09449 for ietf-pkix-bks; Wed, 16 Jan 2002 09:56:23 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GHuL309439 for <[e-mail]>; Wed, 16 Jan 2002 09:56:21 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101202b86b6e1f1ee8@[165.227.249.20]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Wed, 16 Jan 2002 09:56:18 -0800
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Cautionary Period Straw Poll
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I believe that DPV protocols developed by the PKIX working group
ought not include support for a cautionary period.

I belive this because the cautionary period is of no value, and will 
likely confuse, the principle users of DPV users, namely systems that 
need to decide immediately whether a signature in front of them 
should be allowed for identification.

The cautionary period is of some value in DSV, although it is not 
clear whether or not it will be confusing there as well. Knowing what 
your trusted DSV server's cautionary period is may or may not useful; 
knowing what your own cautionary period is useful. DSV should either 
allow the user to give definitive inputs to the cautionary period 
calculation from the DSV server, or it should not include the 
cautionary period at all.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GGnCn07296 for ietf-pkix-bks; Wed, 16 Jan 2002 08:49:12 -0800 (PST)
Received: from phaostec.temp.veriohosting.com (phaostec.temp.veriohosting.com [161.58.151.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GGnA307291 for <[e-mail]>; Wed, 16 Jan 2002 08:49:10 -0800 (PST)
Received: from phaos.com ([198.78.132.60]) by phaostec.temp.veriohosting.com (8.11.6) id g0GGnBh82696 for <[e-mail]>; Wed, 16 Jan 2002 09:49:11 -0700 (MST)
Message-ID: <[e-mail]>
Date: Wed, 16 Jan 2002 11:47:38 -0500
From: Joe Morgan <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en-GB
MIME-Version: 1.0
To: [e-mail]
Subject: TSP interop update
Content-Type: multipart/alternative; boundary="------------9BE45895AB299668C9DCA245"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--------------9BE45895AB299668C9DCA245
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit



Just a quick update on our progress with TSP interop testing.

Cheers,
Joe


SERVER                           |   HTTP     |   TCP     |
                                 |            |           |
                                 |            |           |
Peter Gutmann                    |            |           |
host = tsa.cryptoapps.com        |            |           |
port = 3318                      |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |   SUCCESS |
                                 |            |           |
                                 |            |           |
IAIK                             |            |           |
host = bais.iaik.at              |            |           |
port = 318                       |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |   SUCCESS |
                                 |            |           |
                                 |            |           |
Datum                            |            |           |
host = 64.241.183.87             |            |           |
port = 318                       |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
SIA                              |            |           |
host = 193.203.230.166           |            |           |
port = 318                       |            |           |
policy id = 1.3.135.1.2.0        |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
EdelWeb                          |            |           |
url =                            |            |           |
http://www.edelweb.fr/           |            |           |
   cgi-bin/service-tsp           |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.5309.1.2.2           |   SUCCESS  |   n/s     |
                                 |            |           |
                                 |            |           |
CNSG                             |            |           |
host = tsp.test.polito.it        |            |           |
port = 318                       |            |           |
policy id = 0.4.0.1.1.1          |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
C&A                              |            |           |
host = 195.223.2.6               |            |           |
port = 3318                      |            |           |
policy id = 0.4.0.1.1.1          |            |           |
url =                            |            |           |
http://195.223.2.6:8080/         |            |           |
   timestamp                     |   SUCCESS  |  SUCCESS  |



n/s = Not supported.
n/a = Not available.

--
Joe Morgan
[e-mail]
Software Engineer
Phaos Technology Corp.
http://www.phaos.com/


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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt></tt>&nbsp;<tt></tt>
<p><tt>Just a quick update on our progress with TSP interop testing.</tt><tt></tt>
<p><tt>Cheers,</tt>
<br><tt>Joe</tt>
<br><tt></tt>&nbsp;<tt></tt>
<p><tt>SERVER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; HTTP&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; TCP&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>Peter Gutmann&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>host = tsa.cryptoapps.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>port = 3318&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id =&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>1.3.6.1.4.1.3029.56.36.54&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; n/s&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; SUCCESS |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>IAIK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>host = bais.iaik.at&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>port = 318&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id =&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>1.3.6.1.4.1.3029.56.36.54&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; n/s&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; SUCCESS |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>Datum&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>host = 64.241.183.87&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>port = 318&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id =&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>1.3.6.1.4.1.3029.56.36.54&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; n/s&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; SUCCESS&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>SIA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>host = 193.203.230.166&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>port = 318&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id = 1.3.135.1.2.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; n/s&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; SUCCESS&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>EdelWeb&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>url =&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt><A HREF="http://www.edelweb.fr/">http://www.edelweb.fr/</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp; cgi-bin/service-tsp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id =&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>1.3.6.1.4.1.5309.1.2.2&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; SUCCESS&nbsp; |&nbsp;&nbsp; n/s&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>CNSG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>host = tsp.test.polito.it&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>port = 318&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id = 0.4.0.1.1.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; n/s&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; SUCCESS&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>C&amp;A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>host = 195.223.2.6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>port = 3318&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id = 0.4.0.1.1.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>url =&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt><A HREF="http://195.223.2.6:8080/">http://195.223.2.6:8080/</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp; timestamp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; SUCCESS&nbsp; |&nbsp; SUCCESS&nbsp; |</tt>
<br><tt>&nbsp;</tt>
<br><tt></tt>&nbsp;<tt></tt>
<p><tt>n/s = Not supported.</tt>
<br><tt>n/a = Not available.</tt>
<p>--
<br>Joe Morgan
<br>[e-mail]
<br>Software Engineer
<br>Phaos Technology Corp.
<br><A HREF="http://www.phaos.com/">http://www.phaos.com/</A>
<br>&nbsp;</html>

--------------9BE45895AB299668C9DCA245--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GFicv05750 for ietf-pkix-bks; Wed, 16 Jan 2002 07:44:38 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0GFiW305744 for <[e-mail]>; Wed, 16 Jan 2002 07:44:32 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for [208.184.76.43]) with SMTP; 16 Jan 2002 15:44:08 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA29061; Wed, 16 Jan 2002 10:44:33 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g0GEmIN00511; Wed, 16 Jan 2002 09:48:18 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <CJPH53LS>; Wed, 16 Jan 2002 09:48:17 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.12]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPH53LP; Wed, 16 Jan 2002 09:48:02 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: Petra Barzin <[e-mail]>, Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Date: Wed, 16 Jan 2002 09:39:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Petra and Denis:

The structure of SCVP makes it very easy to add support of attribute 
certificates (or PGP certificates for that matter) at a later date.  We 
need to make sure that there is a constituency for the protocols we develop 
for the standards track.

Russ


At 12:36 PM 1/16/2002 +0100, Denis Pinkas wrote:

>Petra,
>
> > Yes, thanks for the pointer. I found the ASN.1 definitions there.
> >
> > One more question turned up:
> > Is DPV restricted to X.509 public key certificates or is it possible
> > to use it for X.509 attribute certificates as well?
>
>Clearly, both the DPV-DPD protocol draft and the DPV-DPD requirement draft
>have been specifically written to support PKIX public key certificates.
>
>At the last IETF meeting a question has been raised to the audience:
>Who, in the room, has implemented Attribute Certificates ?
>No hand showed up.
>
>So it seems that there is no urgence to support PKIX attribute
certificates.
>
>However, maybe by making some changes, PKIX attribute certificates could be
>supported, but this is an exercise that I have not undertaken.
>
>The basic question is thus whether to include the support of attribute
>certificates in the current DPV-DPD requirement draft.
>
>Unless you, or someone else, can rapidly provide arguments and demonstrate
>that it will not delay the support of PKIX public key certificates, I would
>rather think that it should not be included at this time.
>
>Regards,
>
>Denis
>
>
> > - Petra
> >
> > Denis Pinkas schrieb:
> >
> > > Petra,
> > >
> > > Please take a look at RFC 3126, where many of the ASN.1 structures
were
> > > imported from and are thus defined there. This should answer all your
> > > questions.
> > >
> > > Regards,
> > >
> > > Denis
> > >
> > > > Denis,
> > > >
> > > > may I still ask some questions concerning the document "Delegated
> > > > Path Validation and Delegated Path Discovery Protocols" ?
> > > >
> > > > > PathValues :: = SEQUENCE {
> > > > >        certificateValues      CertificateValues,
> > > > >        revocationValues       RevocationValues }
> > > > >
> > > > I'm missing some ASN.1 definitions. You refer to "CertificateValues"
> > > > and "RevocationValues" but I couldn't find these definitions.
> > > >
> > > > By the way, you should move this definition of "PathValues" from
> > > > the chapter "5.2.1. Request" to the chapter "5.2.2.  Response
Syntax"
> > > > where it is used.
> > > >
> > > > Another ASN.1 question:
> > > >
> > > > > UsefulRevoc ::= CHOICE {
> > > > >        certificateRevocationLists     CertificateRevocationLists,
> > > > >        completeRevocationRefs         CompleteRevocationRefs }
> > > > >
> > > > A DPV request may contain useful revocation information provided
> > > > by the client. Maybe it's because I don't know the element
> > > > "CompleteRevocationRefs" but where do I store OCSP answers?
> > > >
> > > > Could you please send the definition of "CompleteRevocationRefs"
> > > > and "completeCertificateRefs"? I guess they are imported from
[ES-F],
> > > > "Electronic Signature Formats for long term electronic signatures", 
> aren't
> > > > they?
> > > >
> > > > >    CertOrCertRef ::=  CHOICE {
> > > > >        certificate          [1]  Certificate,
> > > > >        certRef              [2]  OtherCertID }
> > > > >
> > > > I'm also missing the definition of OtherCertID used in a DPV and DPD
> > > > request.
> > > >
> > > > Thanks, Petra
> > > >
> > > > Denis Pinkas schrieb:
> > > >
> > > > > Petra,
> > > > >
> > > > > > Denis,
> > > > >
> > > > > > is there also a new version of the document "Delegated Path
> > > > > > Validation and Delegated Path Discovery Protocols"
> > > > >
> > > > > Not at this time. Currently we need first to agree on the DPV /
DPD
> > > > > requirements, then we will discuss the solutions to these 
> requirements.
> > > > >
> > > > > The so-called "Delegated Path Validation and Delegated Path
Discovery
> > > > > Protocols" document could be a candidate to fulfill these 
> requirements.
> > > > > It is too early to say and this will only be discussed once the
> > > > > requirements
> > > > > document is adopted.
> > > > >
> > > > > > or just a new requirement document?
> > > > >
> > > > > Correct. It is a new document for both the DPV and DPD
requirements.
> > > > >
> > > > > There is also a companion document for the DSV requirements.
> > > > > We will only discuss the DSV requirements document in detail when
> > > > > the DPV / DPD requirements document has completed the WG last
call.
> > > > >
> > > > > Denis




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GFb0305532 for ietf-pkix-bks; Wed, 16 Jan 2002 07:37:00 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0GFar305528 for <[e-mail]>; Wed, 16 Jan 2002 07:36:53 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for [208.184.76.43]) with SMTP; 16 Jan 2002 15:36:29 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id KAA27191 for <[e-mail]>; Wed, 16 Jan 2002 10:36:54 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g0GEPtN28732 for <[e-mail]>; Wed, 16 Jan 2002 09:25:55 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <CJPH5325>; Wed, 16 Jan 2002 09:25:54 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.27]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPH532Z; Wed, 16 Jan 2002 09:25:49 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: Cautionary Period
Date: Wed, 16 Jan 2002 09:24:53 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis:

> > There are many application contexts where the concept of a cautionary
> > period is irrelevant.  For example: TLS.  The client will either accept
the
> > server's certificate for establishment of the TLS-protected session, or
it
> > will reject it.
>
>True, but the reverse sentence is also true: "There are application
contexts
>where the concept of a cautionary period is relevant".
>
> > So, when does it matter?  Non-repudiation of a high-value transaction.
In
> > such a context, it is very important to know when a transaction take
> > place.  The PKIX working group has done a lot of work on TSP to fill
this
> > requirement.
>
>Non-repudiation is not the single security service where a cautionary
period
>is relevant. It is also relevant for data origin authentication with
>integrity.

It does not matter for key management (key transport or key agreement).  It 
sometimes matters for signatures.  It does not when actions are taken 
immediately after the signature validation, then the signature is never 
checked again.  It is most relevant when the signature (and the signed 
data) are stored for an extended period of time.

> > Let's assume that the constrained client wants to validate such a
> > transaction.  The TSP timestamp provides the date/time of interest.  It
can
> > ask the DPV server if the signer's path was valid at the time that the
> > signature was generated.
>
>Since it is not possible to know when the signature was generated,
>an upper limit of that time is use instead: the date of the time-stamp
>applied over the digital signature or the date included in an audit record
>See the DPV requirements document at:
>http://www.imc.org/draft-ietf-pkix-dsv-req.
>
>The correct sentence is thus: "It can ask the DPV server if the signer's
>path was valid at the time that the time-stamp was applied over the digital
>signature".

I think we are trying to say the same thing.

> > In my view, the cautionary period only impacts the signature on the
> > transaction.
>
>Since a cautionary period cannot be applied in the context of a
>confidentiality service or an authentication service, the right wording
>would be : "the cautionary period only impacts the use of a certificate
>in the context of a non-repudiation service or a
>data-origin-authentication-with-integrity service".

Again, I think we are trying to say the same thing.  The signature 
validation is the central event.  The certificate is being validated as a 
necessary condition to the signature validation.

> > The DPV server does not validate this signature.  Has
> > adequate time passed since the signature was applied to ensure that
recent
> > compromise of the end-entity private key has been reported?  I submit
that
> > this a signature validation question, not a certification path
validation
> > question.
>
>The basic question is how clients can take advantage of a DPV server in the
>case where a cautionary period exists and in the context of a
>non-repudiation service or a data-origin-authentication-with-integrity
>service ?

This is the crux of our disagreement.  I argue that cautionary period is a 
concept that relates to a single signature, not to the certificate that 
contains the public key used to validate the signature.  If there is any 
protocol that should include the cautionary period concept, it is the DSV 
protocol -- not the DPV protocol.

>There are two options whether :
>
>1) the cautionary period has to be known by the client
>    (which is what your arguments mandate).
>
>2) the cautionary period is known by the server
>    (which is what my arguments mandate).
>
>In the context of a non repudiation service, clients must necessarilly know
>either the date of the time-stamp or the date of the audit record.
>
>In the context of a data-origin-authentication-with-integrity service,
>clients must necessarilly know the purported date of the digital signature.
>
>With option 1, clients must locally manage the cautionary period for each
>supported policy and locally compare it either with the date of the
>time-stamp or the date of the audit record, or the the purported date of
the
>digital signature. This makes management actions more difficult
>(and makes also thin clients fater) since if that period changes,
>local tables need to be updated in each client application.
>
>With option 2, clients do not need to manage that information locally since
>it is part of the policy supported by the server. They simply need to send
>to the server either the date of the time-stamp or the date of the audit
>record, or the purported date of the digital signature.
>
>The goal of these protocols is to delegate as much as possible all the
>validation conditions to a server. The cautionary period does not
>make an exception.

I disagree.  The goal of these protocols is to delegate the certification 
path construction and validation to a server.  The client is still 
responsible for all actions that use the public key in the server validated 
certificate.  If one of those actions is signature validation in a context 
where cautionary period applies, then the client is responsible for 
observing the cautionary period.  If the server were performing the public 
key operation (as it is in DSV), then the server would be responsible for 
observing the cautionary period.

Russ




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GES4203635 for ietf-pkix-bks; Wed, 16 Jan 2002 06:28:04 -0800 (PST)
Received: from mailrelay.tugraz.at (mailrelay.tu-graz.ac.at [129.27.3.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GERj303628 for <[e-mail]>; Wed, 16 Jan 2002 06:27:45 -0800 (PST)
Received: from iaik.tu-graz.ac.at (iaik.tu-graz.ac.at [129.27.152.30]) by mailrelay.tugraz.at (8.12.1/8.12.1) with ESMTP id g0GERcUQ029938; Wed, 16 Jan 2002 15:27:38 +0100 (MET)
Received: from plato [129.27.152.123] by iaik.tu-graz.ac.at (SMTPD32-6.06) id ADC665190154; Wed, 16 Jan 2002 15:27:18 +0100
Received: from plato.iaik.at [127.0.0.1] by plato (IAIK S/MIME Mapper 2.01 18/May/2001); Wed, 16 Jan 2002 15:32:27 +0100
From: "Stefan Kraxberger" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, "Todd Glassey" <[e-mail]>, "Tho" <[e-mail]>, "Stephen Kent" <[e-mail]>, "Peter Gutmann" <[e-mail]>, "Peter Sylvester" <[e-mail]>, "Joe Morgan" <[e-mail]>, "Cristian Marinescu" <[e-mail]>, "Bianca Taglialagamba" <[e-mail]>, "A. Caccia" <[e-mail]>
Cc: "PKIX" <[e-mail]>
Subject: IAIK TSA
Date: Wed, 16 Jan 2002 15:32:22 +0100
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=sha1; boundary="--IAIK.SMIME.MAPPER.D1DB3296--"; protocol="application/x-pkcs7-signature"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-Virus-Scanned: by amavisd-milter (http://amavis.org/)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a multipart MIME message, it may require a MIME capable user agent.
----IAIK.SMIME.MAPPER.D1DB3296--
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Now our TSA is online again.=20

Currently only the socket based service is available.=20
=20
The address is bias.iaik.at at port 318. =20

Regards,=20

Stefan=20




----IAIK.SMIME.MAPPER.D1DB3296--
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAA
oIIgqTCCBNYwggO+oAMCAQICFQC3HWS4/i03mbnh7A3pagLKv3pQqTANBgkqhkiG
9w0BAQUFADCBxDELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lU
WSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJ
bmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEhMB8GA1UE
CxMYSUFJSyBFdXJvUEtJIElOVFJBTkVUIENBMSEwHwYDVQQDExhJQUlLIEV1cm9Q
S0kgVFUtR1JBWiBTSUcwHhcNMDExMTI5MTMyNzE2WhcNMDIxMjMwMjIwMDAwWjCB
mjELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNI
Tk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlv
biBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEaMBgGA1UEAxMRU3RlZmFu
IEtyYXhiZXJnZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAIfTFg1Y/7xJ
Z3LWZc9hycGVAHTAWpyTIBUeEZKhx4x213MRRx9SFTzGbFuro5vGLIgLYy/GROKS
N5T4ADhjB5+OTFJ3VgMSLROOhQ4TBDWB+5PXNqLHJ5NxL/40Vz/mG9qk5qT+vPWe
4U6RfmD+zF9nR6BUxYJ3y2b0FcrJvEqtAgMBAAGjggFpMIIBZTAMBgNVHRMBAf8E
AjAAMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBR4tVWhM72DJX/q8+eMt6Of
lXOqezBUBgNVHSAETTBLMEkGDCsGAQQBlRIBAgIBAjA5MDcGCCsGAQUFBwIBFito
dHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2ludHJhbmV0L2Nwcy8xLjIvMEwGA1Ud
HwRFMEMwQaA/oD2GO2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaW50cmFuZXQv
Y3JsL2lhaWtfZXVyb3BraV9zaWcuY3JsMBEGCWCGSAGG+EIBAQQEAwIAIDAoBglg
hkgBhvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5FVDAkBgNVHREEHTAb
gRlzdGVmYW4ua3JheGJlcmdlckBpYWlrLmF0MB0GA1UdDgQWBBS3HWS4/i03mbnh
7A3pagHgRzEPEDANBgkqhkiG9w0BAQUFAAOCAQEAQxdjAsPNy6A3S6sj3DxWkfCS
6D2YRrUZwsM1fwe4Y08Du5jfIwWZ0+HJCAfysGWUm4wmApCxD9IhMzaufkfqgJMM
cXkdoXX75V839/FbrzXwMY+Ve6ba7WrNZvEUcl+/Xyg7UaAl/D7+QODLHgacuFVH
7FiFnQuiC5JHAMxMDKcrKSw7fJ75zTspRsRM2RXTu3HAoLe0MNxeNmFsvynTtb8Y
zSz5afUcvWFFDOe2Uf7B34sc+MszUz26p8xat8DGqdp11kI7IdZDMD83BRZlYJ47
sJMVQiglalwAZLZLkOp1dJOa7/Ob086p3elkDD6TVwTqeIEqEMX/ZJZtAsPZVzCC
BTwwggQkoAMCAQICFHi1VaEzvYMlf+rz54y3pIMcl/owMA0GCSqGSIb3DQEBBQUA
MIHLMQswCQYDVQQGEwJBVDENMAsGA1UEBxMER3JhejEZMBcGA1UECRMQSW5mZmVs
ZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xP
R1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFBy
b2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25zMSEwHwYDVQQDExhJQUlLIEV1cm9Q
S0kgSW50cmFuZXQgQ0EwHhcNMDAxMjE5MTEyMTQ3WhcNMDIxMjMwMjI1OTMwWjCB
xDELMAkGA1UEBhMCQVQxJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lUWSBPRiBURUNI
Tk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJbmZvcm1hdGlv
biBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEhMB8GA1UECxMYSUFJSyBF
dXJvUEtJIElOVFJBTkVUIENBMSEwHwYDVQQDExhJQUlLIEV1cm9QS0kgVFUtR1JB
WiBTSUcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDxWjtQORZimthv
kSAAJlIL97tgPeJ8+151iGCyd44WFAyjHsP9oQrZHxazVAB+o8clYdPpp/ECognU
41o40iafdgkNIfsjyFMm3VvcWNx+F4vKYTHoLQascxRJUULgub+B4k4pb9A4URQn
xkrMriQlISoFXeEY1l2Mv4DlXHF3qOEMiLW5B1vmZZaEpNvH/me8fuvJYLi9FWA+
Ojk/UybbrGybkeJY3RAq+FImnWkaB9BAoAhdROR+GXU8YvqZTzqUndKog1KccBKa
FTBKwSz9RxOVPFORs1VLGItlnGRCn25uOiDTDfrU2D4D9cyFEVU+Qd55RzD6PfgP
8BbeUyTxAgMBAAGjggEbMIIBFzASBgNVHRMBAf8ECDAGAQH/AgEAMA4GA1UdDwEB
/wQEAwIBxjAfBgNVHSMEGDAWgBSEWAP+T9cNWn701+2abEq0uxAz0jBUBgNVHSAE
TTBLMEkGDCsGAQQBlRIBAgIBATA5MDcGCCsGAQUFBwIBFitodHRwOi8vZXVyb3Br
aS5pYWlrLmF0L2NhL2ludHJhbmV0L2Nwcy8xLjEvMEgGA1UdHwRBMD8wPaA7oDmG
N2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaW50cmFuZXQvY3JsL2lhaWtfZXVy
b3BraS5jcmwwEQYJYIZIAYb4QgEBBAQDAgACMB0GA1UdDgQWBBR4tVWhM72DJX/q
8+eMt6OflXOqezANBgkqhkiG9w0BAQUFAAOCAQEAscTGRuY2BJizRRfug1JU1qha
LVOjZvYPOikXleQuPBPXFSoT9jwbzDkyN76QMnondlgf0F1Gr+w4LqljFKAdjqFG
SXJxAzGjMFbjTjyv7mit0Ppk7wKohXM/c8ThDCEBnnAYcTgg504BtJhBmN0ThyL6
tAXYfRFqHsgn1rj58bS+6lAa6n9iepn/yznhnFWr24imSVvef8nbI2GwphBAhNXh
+Jq+BWR1pr5uUJ9ilzL44elcZ+Omh4lsILiUf6YR1xR9+d3G4VQMMOmpfgf0GJVK
NKcelVlK4PW/0VgvDxoyQQFVE2hiLd5r/jUzT4zlLy+5hk3FnxSUgnl14w/u3DCC
BLMwggOboAMCAQICFQCEWAP+T9cNWn701+2abEuYPjyavTANBgkqhkiG9w0BAQUF
ADBSMQswCQYDVQQGEwJBVDEQMA4GA1UEChMHRXVyb1BLSTExMC8GA1UEAxMoRXVy
b1BLSSBBdXN0cmlhbiBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wMDEyMTgx
NjUyMzFaFw0wMjEyMzAyMjU5MzBaMIHLMQswCQYDVQQGEwJBVDENMAsGA1UEBxME
R3JhejEZMBcGA1UECRMQSW5mZmVsZGdhc3NlIDE2YTEmMCQGA1UEChMdR1JBWiBV
TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB
cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z
MSEwHwYDVQQDExhJQUlLIEV1cm9QS0kgSW50cmFuZXQgQ0EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDPwrEj1RtzPWRZUGptWv2/KsgPQ0FyMHHYemhn
/+QjUv51aD9fmcqqUU/CgroJE6sLtN6cZoQ91gnxIS/Gw95PNhUX6jZfN4PF5K/G
Xz3ZUx/bcvcm4tjFGG12jxWT4IN9d3oT5SMMjh1Aw0BE35yySnlqBcfWHR7gtBps
dAovw1Txy8Bt8vmBrhe27dY0d3bJitULO1CG19G0Q374rnJ/CY9ZEHsz0498Ej5+
eFnefSEilJ7kQNDNU2zCx7xuu0jdu0yrb5Y1+RBdgJHCoMldUbOA2HkNOz9YLyiY
WPWRxT9fcPgXv9jSYu+t+DB0MMPz53ZcYILVsopsjhKduVO5AgMBAAGjggEEMIIB
ADAPBgNVHRMBAf8EBTADAQH/MA4GA1UdDwEB/wQEAwIBxjAfBgNVHSMEGDAWgBQA
emdURVCCrBm2toURUbtpOdgt1DBWBgNVHSAETzBNMEsGDCsGAQQBlRIBAgEBATA7
MDkGCCsGAQUFBwIBFi1odHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2V1cm9wa2kt
YXQvY3BzLzEuMS8wRQYDVR0fBD4wPDA6oDigNoY0aHR0cDovL2V1cm9wa2kuaWFp
ay5hdC9jYS9ldXJvcGtpLWF0L2NybC9hdXN0cmlhLmNybDAdBgNVHQ4EFgQUhFgD
/k/XDVp+9NftmmxKtLsQM9IwDQYJKoZIhvcNAQEFBQADggEBAC8BA5jJSByaJAeD
xiEW4O8mJJdSsuO/KyoEJVjcAyyMx9lJdHNtgwabhFHR2cUZz++vKkJFpmA+A7jg
jRO5IwQxiMTordze8X7rxmBlZvizFJfxUwalTAUbJ9iaLjJza42qTwjRRPSEji4b
9hcg+6PpK4pOdZ++SrIrE1qIvRqx3fFqEo8LHkkR8ZHKB/tT4GKQck/tUfeuotfQ
I/XlprqctmgzmjRC0giMEurV2Ogf6kxz9BzmibwGBtCqG0GLN5XKCr6fNBAD3W+X
t0FoujZfZlJqK3bt6re712rdZnztVlOaCc6gSB9WY7ZrNFhAm9+a2HzlTc7ZS+eP
jC8yLW4wggRQMIIDOKADAgECAgEJMA0GCSqGSIb3DQEBBAUAMEExEDAOBgNVBAoT
B0V1cm9QS0kxLTArBgNVBAMTJEV1cm9QS0kgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1
dGhvcml0eTAeFw0wMDExMjMxNDI0NDVaFw0wMjEyMzExMjAwMDBaMFIxCzAJBgNV
BAYTAkFUMRAwDgYDVQQKEwdFdXJvUEtJMTEwLwYDVQQDEyhFdXJvUEtJIEF1c3Ry
aWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEAoE5gWK44kT3O3Yenp0GT6+gkypmIAlhqYAcmokavl3WaQ4Bh
BlAv4ORtBF/hVObG1ugPCep7cTNyoXZ+sNIbmlLzBxzrRpT4nYQIEu3IXR108c6A
PycH+9vbYIUQrsCKx8Qs/csU5rdOxc15pHsZLJiiCYATB0GWyrcbVcoNgAj6crv7
Lx37SlENgMAssOoG4E3/2wrCQ2n/QiqBEosscpnEqQs6ABvdQiLKSpfVQJA77l9u
jQ1C/ugtlYwAr5GrtSOhOTYvKB4tuVleqlHFzJoA6XaWQRpD4Oy4ymF0+5IAe9q+
lOQ6U57rWIZ0MMr8xAmf7VZtmk0KJYCkAl3DPwIDAQABo4IBQDCCATwwTAYJYIZI
AYb4QgENBD8WPUlzc3VlZCB1bmRlciBwb2xpY3k6CiBodHRwOi8vd3d3LmV1cm9w
a2kub3JnL2NhL3Jvb3QvY3BzLzEuMS8wOwYDVR0fBDQwMjAwoC6gLIYqaHR0cDov
L3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2NybC9jcmwuZGVyMA8GA1UdEwEB/wQF
MAMBAf8wTgYDVR0gBEcwRTBDBgorBgEEAakHAQEBMDUwMwYIKwYBBQUHAgEWJ2h0
dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzAOBgNVHQ8BAf8E
BAMCAf4wHQYDVR0OBBYEFAB6Z1RFUIKsGba2hRFRu2k52C3UMB8GA1UdIwQYMBaA
FIzci7GlSpDnTohzGDyd1V5+5LLNMA0GCSqGSIb3DQEBBAUAA4IBAQD0VfvB2KWA
/FyENfhXDK7/YQwRxdAJj/3VzpdvUPb9mHW9O1kry3ZeM9IfcYqbFPdP9ZvW/g2m
WQI9k4vMKDtePnzQuy+ZUuvxuKlJ7taWAAHkiXTBbJoscHetWVlIINuPYCQF33DT
d5otjcOxsE+U9xjqP5tCLMzQEmnmTaUdZYWZFIjfKzoLC2JEaeVjDUQrYYwL6OUY
P6aWoML1gqUP2PFzRKQK/EMSjRQzTU9ZZLVvc+FS797ki6f8zRxPGqheV4EyjFXR
bY03/4fjcZ5pwictxM97tFYmmlkmWmkEvI+7ToPZ/WtPyqXciKJ9ZT/OJWWWzfXg
iz5ECXNBlO0DMIIDYDCCAkigAwIBAgIBADANBgkqhkiG9w0BAQQFADBBMRAwDgYD
VQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRFdXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlv
biBBdXRob3JpdHkwHhcNOTkxMjI5MTczMDM5WhcNMTAxMjMxMTIwMDAwWjBBMRAw
DgYDVQQKEwdFdXJvUEtJMS0wKwYDVQQDEyRFdXJvUEtJIFJvb3QgQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD/
L/zLh4UggkIiJA2Jmuwd6/TLOoToZz3Dr0FoCgehip+ZNrX1ehBw0esCK6Z18SfD
OeyDB+ia3qWaltedQVttLUQnVPdXmzubIVapWFoHm1u3oLhBgSp1mHBmAsKmGvHV
/IYF4t709tUQlpeZgjIzpbjzN799Xoa2X2yJqGGBADzHKiJn5p80LsMnx3VR/UyI
XZJEq611UlADfJH1qhwUzNa0F80j0tk7/paLhnWrZDsfZNGkAugQLBDUi+nBKUu4
FicpfYL7HGX4fRmtg+oLuQ1vHlYe2YVs+UGI47e7jd4Yf1vbjinQ0OUrx2nx8z+x
o47lgXwMbEJ7VwrECjS3AgMBAAGjYzBhMB8GA1UdIwQYMBaAFIzci7GlSpDnTohz
GDyd1V5+5LLNMB0GA1UdDgQWBBSM3IuxpUqQ506Icxg8ndVefuSyzTAOBgNVHQ8B
Af8EBAMCAcYwDwYDVR0TAQH/BAUwAwEB/zANBgkqhkiG9w0BAQQFAAOCAQEAW2j/
nnW9QhtCe1iQdV9KFy9rnOpKH43tHFjuUBlgpgvNv01/rXMXLn/W81nuLTmZwdhY
cjldUZZR6WUGLtArOLQaUkTQMHjc/EkU/s0v8MuWNg5vhC3ZsFFNVtfR8iWa2a+g
A4uBH17cXd6PuzqD0HMFA75P32kes3xblFWZ5qSYGQvy4aWoT/FDsbeJG/Upp8Fb
Z2Z0pSqfi9cAWGqzRYlT0dgu8Z2RFwwd/vPvVpQldB1ScRkfpL6PCLvmmfMRHq8Z
g0JMcqmIXYYg0PcPdJ+ECikSYd/7G50/uIfJDDZEOIkmpXVn3cQmcMDRauhvwsoR
6B2lCX/cEI0PEnMBaDCCBNkwggPBoAMCAQICFD9EDnR1EdQ3xFRjSEwGBggogBmx
MA0GCSqGSIb3DQEBBQUAMIHGMQswCQYDVQQGEwJBVDEmMCQGA1UEChMdR1JBWiBV
TklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPkluc2l0dXRlIGZvciBB
cHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENvbW11bmljYXRpb25z
MSEwHwYDVQQLExhJQUlLIEV1cm9QS0kgSU5UUkFORVQgQ0ExIzAhBgNVBAMTGklB
SUsgRXVyb1BLSSBUVS1HUkFaIENSWVBUMB4XDTAxMTEyOTEzMjUwMVoXDTAyMTIz
MDIyMDAwMFowgZoxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZFUlNJ
VFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxpZWQg
SW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxGjAYBgNV
BAMTEVN0ZWZhbiBLcmF4YmVyZ2VyMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQDEVxohomk0KckxKIduxV98fR68UbG7oAhiZas5KwNmw/eIWTWowzjNm7wEoIse
tBq6fVNKHBIhIn47XqTk+N76hjoADWnNn1QAVztCxXDNZVfc7+1vUioJu1QYcWPZ
NyAJskap8JOS9AKje5Hdnmnd5tWPxCigbo8QiEtLIcD8wQIDAQABo4IBazCCAWcw
DAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCBDAwHwYDVR0jBBgwFoAUmikZ1hee
wVHfzGeDobfkvw+4Qx0wVAYDVR0gBE0wSzBJBgwrBgEEAZUSAQICAQIwOTA3Bggr
BgEFBQcCARYraHR0cDovL2V1cm9wa2kuaWFpay5hdC9jYS9pbnRyYW5ldC9jcHMv
MS4yLzBOBgNVHR8ERzBFMEOgQaA/hj1odHRwOi8vZXVyb3BraS5pYWlrLmF0L2Nh
L2ludHJhbmV0L2NybC9pYWlrX2V1cm9wa2lfY3J5cHQuY3JsMBEGCWCGSAGG+EIB
AQQEAwIAIDAoBglghkgBhvhCAQ0EGxYZVXNlci1DZXJ0aWZpY2F0ZSBJTlRSQU5F
VDAkBgNVHREEHTAbgRlzdGVmYW4ua3JheGJlcmdlckBpYWlrLmF0MB0GA1UdDgQW
BBQ/RA50dRHUN8RUY0hMBgUdsDjWPjANBgkqhkiG9w0BAQUFAAOCAQEACK/LT4Q5
JodHhwc98Yuyv7wZfymxAOFyRJsO1sseOriRFPpp9WAjZORNRUTYRPMuhd9RS3BR
/jTn79AlsHevONt06xO4eatRoU01qZXQjoDZBOYsPIeId2Egs/7IWqC4iY5RBS8X
6Y3Tne/OGhzMTNiiRh0J573yPNqTUO0JK6yeYq0nNb2W4An6z+VPOW2mDEJcEj3H
/PjbR/sRbhi2DjkiN4JkjRDt4aRvT3yfnlqefoQqD4kakmdllaA98VasPjS9RLjh
rXKNixXlu+zzIbs0tRsN+ewLsVAUgSWl6SFOgSzPa5vTXurFbLaLRkrus6k+J19J
slSUkAIajSKpmTCCBT8wggQnoAMCAQICFQCaKRnWF57BUd/MZ4Oht+WilucS8TAN
BgkqhkiG9w0BAQUFADCByzELMAkGA1UEBhMCQVQxDTALBgNVBAcTBEdyYXoxGTAX
BgNVBAkTEEluZmZlbGRnYXNzZSAxNmExJjAkBgNVBAoTHUdSQVogVU5JVkVSU0lU
WSBPRiBURUNITk9MT0dZMUcwRQYDVQQLEz5JbnNpdHV0ZSBmb3IgQXBwbGllZCBJ
bmZvcm1hdGlvbiBQcm9jZXNzaW5nIGFuZCBDb21tdW5pY2F0aW9uczEhMB8GA1UE
AxMYSUFJSyBFdXJvUEtJIEludHJhbmV0IENBMB4XDTAwMTIxOTExMzMxMVoXDTAy
MTIzMDIyNTkzMFowgcYxCzAJBgNVBAYTAkFUMSYwJAYDVQQKEx1HUkFaIFVOSVZF
UlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+SW5zaXR1dGUgZm9yIEFwcGxp
ZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQgQ29tbXVuaWNhdGlvbnMxITAf
BgNVBAsTGElBSUsgRXVyb1BLSSBJTlRSQU5FVCBDQTEjMCEGA1UEAxMaSUFJSyBF
dXJvUEtJIFRVLUdSQVogQ1JZUFQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEK
AoIBAQDWIkt24ac2iD1RZW0BzsolEcM7k6C5Pb8EHxVojWsjJsscBB32XS9H2h2/
XmjVOLtCPoNiEaqm8WrqFky29IdoktkLdV6bvW4gN32k17mvPUNCPmqO78idaqXC
m//ocXRMwUHpMCv1NN+5KUMJ18BDchltI/Zj1btYA7cZy4Ax01k6Z2zHUJkoAc7/
+x95o8Cm/1D9JxxZ5o6tHdiAYgyUjCA6Q3L0DmNQgLPOMWU5ZfcANDWfMTAH71c3
oRJaKIum3yCKzThyX24X7iSU/SI1mA2uJnOerEweuLNhmu5kJzH+079B2Jyscr92
1fzcz6KEEjEoEtnF8VSUvhFWxb2bAgMBAAGjggEbMIIBFzASBgNVHRMBAf8ECDAG
AQH/AgEAMA4GA1UdDwEB/wQEAwIBxjAfBgNVHSMEGDAWgBSEWAP+T9cNWn701+2a
bEq0uxAz0jBUBgNVHSAETTBLMEkGDCsGAQQBlRIBAgIBATA5MDcGCCsGAQUFBwIB
FitodHRwOi8vZXVyb3BraS5pYWlrLmF0L2NhL2ludHJhbmV0L2Nwcy8xLjEvMEgG
A1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9ldXJvcGtpLmlhaWsuYXQvY2EvaW50cmFu
ZXQvY3JsL2lhaWtfZXVyb3BraS5jcmwwEQYJYIZIAYb4QgEBBAQDAgACMB0GA1Ud
DgQWBBSaKRnWF57BUd/MZ4Oht+S/D7hDHTANBgkqhkiG9w0BAQUFAAOCAQEAQJx9
PjiaQ085JR96Xq1xrjg5YYZJZzOm39jim/QXlHhc2i9OOHl17kKql9mHUUHbDM+C
eBz8oN7nkPXK0W3p9jrQbGij6v3MSPztnfkwbZl7askTeeyrmI3rC/jR6mWTL/AC
Cxn7btTc8U/9IJIFv1OQM+I9o1L68CzxsbddTSgGn6hjzZO6TnkMW+I8aWQe+uOj
tthe/1Erhl9YGSHv8EkqLOWfJroKc9mmKs2iYNcEbT8VFg7K5+/cCqqpp68vFLsY
Jtmlyq7vU60XNFMSaA5mgzc4wrB8ObMO98roBRJsMfKSAirSXugiKkRRyoPdC+rx
siaVKay2Xd7GDSu5pDGCAy0wggMpAgEBMIHeMIHEMQswCQYDVQQGEwJBVDEmMCQG
A1UEChMdR1JBWiBVTklWRVJTSVRZIE9GIFRFQ0hOT0xPR1kxRzBFBgNVBAsTPklu
c2l0dXRlIGZvciBBcHBsaWVkIEluZm9ybWF0aW9uIFByb2Nlc3NpbmcgYW5kIENv
bW11bmljYXRpb25zMSEwHwYDVQQLExhJQUlLIEV1cm9QS0kgSU5UUkFORVQgQ0Ex
ITAfBgNVBAMTGElBSUsgRXVyb1BLSSBUVS1HUkFaIFNJRwIVALcdZLj+LTeZueHs
DelqAsq/elCpMAkGBSsOAwIaBQCgggGkMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B
BwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDExNjE0MzIyN1owIwYJKoZIhvcNAQkEMRYE
FK/KyRS/+J8HwQ9ARYuNyvb/xDSOMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcN
AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMA0GCCqGSIb3DQMCAgEo
MAcGBSsOAwIHMIHwBgkrBgEEAYI3EAQxgeIwgd8wgcYxCzAJBgNVBAYTAkFUMSYw
JAYDVQQKEx1HUkFaIFVOSVZFUlNJVFkgT0YgVEVDSE5PTE9HWTFHMEUGA1UECxM+
SW5zaXR1dGUgZm9yIEFwcGxpZWQgSW5mb3JtYXRpb24gUHJvY2Vzc2luZyBhbmQg
Q29tbXVuaWNhdGlvbnMxITAfBgNVBAsTGElBSUsgRXVyb1BLSSBJTlRSQU5FVCBD
QTEjMCEGA1UEAxMaSUFJSyBFdXJvUEtJIFRVLUdSQVogQ1JZUFQCFD9EDnR1EdQ3
xFRjSEwGBggogBmxMA0GCSqGSIb3DQEBAQUABIGAAwNLnU9aW4oIulrYu+1fx1f1
PbK0gQDDvQT6zeY/C7EVzENwhTJI8Ls+1Rqr9WMBih2mdSB/02bbmLdleLtjJkvB
W4yAUUu6OjRtOeYKJ3N5zDP3NTW57sQbVdD0ckg8jz8ZWLVbEs40qoQvYKxFeYfH
133+gFk+JzOC3JNz8+IAAAAAAAA=
----IAIK.SMIME.MAPPER.D1DB3296----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GBbUs22705 for ietf-pkix-bks; Wed, 16 Jan 2002 03:37:30 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GBbT322701 for <[e-mail]>; Wed, 16 Jan 2002 03:37:29 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA25230; Wed, 16 Jan 2002 12:38:37 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA08902; Wed, 16 Jan 2002 12:36:56 +0100
Message-ID: <[e-mail]>
Date: Wed, 16 Jan 2002 12:36:58 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Petra Barzin <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Petra,

> Yes, thanks for the pointer. I found the ASN.1 definitions there.
> 
> One more question turned up:
> Is DPV restricted to X.509 public key certificates or is it possible
> to use it for X.509 attribute certificates as well?

Clearly, both the DPV-DPD protocol draft and the DPV-DPD requirement draft
have been specifically written to support PKIX public key certificates.

At the last IETF meeting a question has been raised to the audience: 
Who, in the room, has implemented Attribute Certificates ? 
No hand showed up. 

So it seems that there is no urgence to support PKIX attribute certificates.

However, maybe by making some changes, PKIX attribute certificates could be
supported, but this is an exercise that I have not undertaken.

The basic question is thus whether to include the support of attribute
certificates in the current DPV-DPD requirement draft.

Unless you, or someone else, can rapidly provide arguments and demonstrate
that it will not delay the support of PKIX public key certificates, I would
rather think that it should not be included at this time.

Regards,

Denis

 
> - Petra
> 
> Denis Pinkas schrieb:
> 
> > Petra,
> >
> > Please take a look at RFC 3126, where many of the ASN.1 structures were
> > imported from and are thus defined there. This should answer all your
> > questions.
> >
> > Regards,
> >
> > Denis
> >
> > > Denis,
> > >
> > > may I still ask some questions concerning the document "Delegated
> > > Path Validation and Delegated Path Discovery Protocols" ?
> > >
> > > > PathValues :: = SEQUENCE {
> > > >        certificateValues      CertificateValues,
> > > >        revocationValues       RevocationValues }
> > > >
> > > I'm missing some ASN.1 definitions. You refer to "CertificateValues"
> > > and "RevocationValues" but I couldn't find these definitions.
> > >
> > > By the way, you should move this definition of "PathValues" from
> > > the chapter "5.2.1. Request" to the chapter "5.2.2.  Response Syntax"
> > > where it is used.
> > >
> > > Another ASN.1 question:
> > >
> > > > UsefulRevoc ::= CHOICE {
> > > >        certificateRevocationLists     CertificateRevocationLists,
> > > >        completeRevocationRefs         CompleteRevocationRefs }
> > > >
> > > A DPV request may contain useful revocation information provided
> > > by the client. Maybe it's because I don't know the element
> > > "CompleteRevocationRefs" but where do I store OCSP answers?
> > >
> > > Could you please send the definition of "CompleteRevocationRefs"
> > > and "completeCertificateRefs"? I guess they are imported from [ES-F],
> > > "Electronic Signature Formats for long term electronic signatures", aren't
> > > they?
> > >
> > > >    CertOrCertRef ::=  CHOICE {
> > > >        certificate          [1]  Certificate,
> > > >        certRef              [2]  OtherCertID }
> > > >
> > > I'm also missing the definition of OtherCertID used in a DPV and DPD
> > > request.
> > >
> > > Thanks, Petra
> > >
> > > Denis Pinkas schrieb:
> > >
> > > > Petra,
> > > >
> > > > > Denis,
> > > >
> > > > > is there also a new version of the document "Delegated Path
> > > > > Validation and Delegated Path Discovery Protocols"
> > > >
> > > > Not at this time. Currently we need first to agree on the DPV / DPD
> > > > requirements, then we will discuss the solutions to these requirements.
> > > >
> > > > The so-called "Delegated Path Validation and Delegated Path Discovery
> > > > Protocols" document could be a candidate to fulfill these requirements.
> > > > It is too early to say and this will only be discussed once the
> > > > requirements
> > > > document is adopted.
> > > >
> > > > > or just a new requirement document?
> > > >
> > > > Correct. It is a new document for both the DPV and DPD requirements.
> > > >
> > > > There is also a companion document for the DSV requirements.
> > > > We will only discuss the DSV requirements document in detail when
> > > > the DPV / DPD requirements document has completed the WG last call.
> > > >
> > > > Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0GAnhN19292 for ietf-pkix-bks; Wed, 16 Jan 2002 02:49:43 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0GAng319288 for <[e-mail]>; Wed, 16 Jan 2002 02:49:42 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 98D9D6787; Wed, 16 Jan 2002 11:49:35 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZKPQV2N7; Wed, 16 Jan 2002 11:49:35 +0100
Message-ID: <[e-mail]>
Date: Wed, 16 Jan 2002 11:51:27 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Yes, thanks for the pointer. I found the ASN.1 definitions there.

One more question turned up:
Is DPV restricted to X.509 public key certificates or is it possible
to use it for X.509 attribute certificates as well?

- Petra

Denis Pinkas schrieb:

> Petra,
>
> Please take a look at RFC 3126, where many of the ASN.1 structures were
> imported from and are thus defined there. This should answer all your
> questions.
>
> Regards,
>
> Denis
>
> > Denis,
> >
> > may I still ask some questions concerning the document "Delegated
> > Path Validation and Delegated Path Discovery Protocols" ?
> >
> > > PathValues :: = SEQUENCE {
> > >        certificateValues      CertificateValues,
> > >        revocationValues       RevocationValues }
> > >
> > I'm missing some ASN.1 definitions. You refer to "CertificateValues"
> > and "RevocationValues" but I couldn't find these definitions.
> >
> > By the way, you should move this definition of "PathValues" from
> > the chapter "5.2.1. Request" to the chapter "5.2.2.  Response Syntax"
> > where it is used.
> >
> > Another ASN.1 question:
> >
> > > UsefulRevoc ::= CHOICE {
> > >        certificateRevocationLists     CertificateRevocationLists,
> > >        completeRevocationRefs         CompleteRevocationRefs }
> > >
> > A DPV request may contain useful revocation information provided
> > by the client. Maybe it's because I don't know the element
> > "CompleteRevocationRefs" but where do I store OCSP answers?
> >
> > Could you please send the definition of "CompleteRevocationRefs"
> > and "completeCertificateRefs"? I guess they are imported from [ES-F],
> > "Electronic Signature Formats for long term electronic signatures", aren't
> > they?
> >
> > >    CertOrCertRef ::=  CHOICE {
> > >        certificate          [1]  Certificate,
> > >        certRef              [2]  OtherCertID }
> > >
> > I'm also missing the definition of OtherCertID used in a DPV and DPD
> > request.
> >
> > Thanks, Petra
> >
> > Denis Pinkas schrieb:
> >
> > > Petra,
> > >
> > > > Denis,
> > >
> > > > is there also a new version of the document "Delegated Path
> > > > Validation and Delegated Path Discovery Protocols"
> > >
> > > Not at this time. Currently we need first to agree on the DPV / DPD
> > > requirements, then we will discuss the solutions to these requirements.
> > >
> > > The so-called "Delegated Path Validation and Delegated Path Discovery
> > > Protocols" document could be a candidate to fulfill these requirements.
> > > It is too early to say and this will only be discussed once the
> > > requirements
> > > document is adopted.
> > >
> > > > or just a new requirement document?
> > >
> > > Correct. It is a new document for both the DPV and DPD requirements.
> > >
> > > There is also a companion document for the DSV requirements.
> > > We will only discuss the DSV requirements document in detail when
> > > the DPV / DPD requirements document has completed the WG last call.
> > >
> > > Denis



Received: by above.proper.com (8.11.6/8.11.3) id g0G97tn07644 for ietf-pkix-bks; Wed, 16 Jan 2002 01:07:55 -0800 (PST)
Received: from server.speedcom.it (server.speedcom.it [195.32.69.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G97r307636 for <[e-mail]>; Wed, 16 Jan 2002 01:07:53 -0800 (PST)
Received: (from adg@localhost) by server.speedcom.it (0.0.0/0.0.0) id KAA22234; Wed, 16 Jan 2002 10:08:48 +0100
Date: Wed, 16 Jan 2002 10:08:48 +0100
From: Alfonso De Gregorio <[e-mail]>
To: "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Subject: Re: Cautionary Period Straw Poll
Message-ID: <[e-mail]>
Reply-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <[e-mail]>
User-Agent: mymua
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I  believe that DPV protocols developed by the PKIX working group
ought to include support for a cautionary period.

alfonso


On Tue, Jan 15, 2002 at 01:05:22PM -0500, Housley, Russ wrote:
> 
>  From the previous thread (which seems to have died down), I think that 
> everyone understands the Cautionary Period concept.  I am trying to 
> determine whether there is a constituency for Cautionary Period in DPV.
> 
> I would like people that have an opinion to vote by sending a message to 
> the list.  The message should be structured as follows:
> 
>            To: [e-mail]
>            Subject: RE: Cautionary Period Straw Poll
> 
>            I believe that DPV protocols developed by the PKIX working group
>            [ought to | ought not] include support for a cautionary period.
> 
>            [I belive this because ...]
> 
> If you feel the need to reply to the rationale posted by  someone, please 
> make that posting on the other thread.  Please do not clutter the straw 
> poll voting with a debate.
> 
> Thanks for your assistance and cooperation,
>    Russ


Received: by above.proper.com (8.11.6/8.11.3) id g0G96LW07399 for ietf-pkix-bks; Wed, 16 Jan 2002 01:06:21 -0800 (PST)
Received: from server.speedcom.it (server.speedcom.it [195.32.69.66]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G96I307388 for <[e-mail]>; Wed, 16 Jan 2002 01:06:19 -0800 (PST)
Received: (from adg@localhost) by server.speedcom.it (0.0.0/0.0.0) id KAA22225; Wed, 16 Jan 2002 10:06:19 +0100
Date: Wed, 16 Jan 2002 10:06:19 +0100
From: Alfonso De Gregorio <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: Tom Gindin <[e-mail]>, "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: Cautionary Period
Message-ID: <[e-mail]>
Reply-To: [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <[e-mail]>
User-Agent: mymua
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

On Tue, Jan 15, 2002 at 06:35:32PM +0100, Denis Pinkas wrote:

I agree with Denis point of view.
In certain contexts (eg. data origin authentication with
integrity) some clients would still like to observe a 
cautionary period and use DPV.
Performing the cautionary-period observation at server-side
makes the life easier to clients and makes the set of target
execution environments larger (since let them to be unconscious
of the current-time).
Consider cautionary-periods a requirement for DPV does not make
necessarily the protocol more complex. Validation policies MAY
support cautionary periods.

Finally... we should delegate as much as possible all the validation
conditions to DPV servers.

alfonso

> >       You are correct that there are other services than NR for which
> > cautionary period is useful.  However, don't they all involve the
> > validation of signed data (and data to be kept for a considerable time, 
> 
> Is a week-end period a "considerable time" ? I do not think so. 
> An e-mail sent on the friday may only be opened on the monday. 
> Applying a cautionary period increases the confidence and reduces the risk.
> 
> > at that)?  If they do, then cautionary period should go into DSV.
> 
> Everybody agrees that a cautionary period certainly applies to DSV.
> 
> However, some thin clients would still like to use DPV to verify digital
> signatures in particular in the context of data origin authentication with
> integrity. I do not think it would be appropriate to say that it is not
> possible and that the cautionary period, when it exists, shall only be
> applied *locally* by the client.
>
> Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0G8Vls04000 for ietf-pkix-bks; Wed, 16 Jan 2002 00:31:47 -0800 (PST)
Received: from webmail.wipro.co.in (host130-22.wipro.net.in [202.177.130.22] (may be forged)) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G8Va303966 for <[e-mail]>; Wed, 16 Jan 2002 00:31:37 -0800 (PST)
Received: from galaxy.wipro.co.in (GALAXY [10.100.8.6]) by webmail.wipro.co.in with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id DADWY83P; Wed, 16 Jan 2002 13:52:49 +0530
Received: by galaxy.wipro.co.in with Internet Mail Service (5.5.2653.19) id <DA1GC67T>; Wed, 16 Jan 2002 13:56:53 +0530
Message-ID: <[e-mail]>
From: "Sanjeev Shukla (SSD-DELRO-ESCR)" <[e-mail]>
To: [e-mail]
Subject: 
Date: Wed, 16 Jan 2002 14:03:16 +0530
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I believe that DPV protocols should not include support for a cautionary
period.

Sanjeev Shukla
Consultant
Wipro Limited
2nd Floor, Thapar House, 
124 Janpath,
New Delhi-110 001. 
India
E mail:[e-mail]

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Tuesday, January 15, 2002 10:07 AM
> To: [e-mail]
> Subject: Re: Cautionary Period Straw Poll
> 
> 
> 
> I believe that DPV protocols developed by the PKIX working group
> ought not include support for a cautionary period.
> 
> Russ








	Disclaimer 

		Information contained and transmitted by this E-MAIL is
proprietary to Wipro Limited and is intended for use only by the individual
or entity to which it is addressed, and may contain information that is
privileged, confidential or exempt from disclosure under applicable law. If
this is a forwarded message, the content of this E-MAIL may not have been
sent with the authority of the Company. If you are not the intended
recipient, an agent of the intended recipient or a  person responsible for
delivering the information to the named recipient,  you are notified that
any use, distribution, transmission, printing, copying or dissemination of
this information in any way or in any manner is strictly prohibited. If you
have received this communication in error, please delete this mail & notify
us immediately at [e-mail]




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0G8PR402843 for ietf-pkix-bks; Wed, 16 Jan 2002 00:25:27 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G8PQ302836 for <[e-mail]>; Wed, 16 Jan 2002 00:25:26 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA24810; Wed, 16 Jan 2002 09:26:30 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA14758; Wed, 16 Jan 2002 09:24:52 +0100
Message-ID: <[e-mail]>
Date: Wed, 16 Jan 2002 09:24:54 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: Cautionary Period Straw Poll
References: <8D7EC1912E25D411A32100D0B7695397E1B4E5@SCYGMXS01>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Santosh,

> I believe that DPV protocols developed by the PKIX working group ought not
> include support for a cautionary period.
 
> I believe this because I am.

Quite an interresting technical argument.  :-)

Denis

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Tuesday, January 15, 2002 1:05 PM
> To: [e-mail]
> Subject: Cautionary Period Straw Poll
> 
>  From the previous thread (which seems to have died down), I think that
> everyone understands the Cautionary Period concept.  I am trying to
> determine whether there is a constituency for Cautionary Period in DPV.
> 
> I would like people that have an opinion to vote by sending a message to
> the list.  The message should be structured as follows:
> 
>            To: [e-mail]
>            Subject: RE: Cautionary Period Straw Poll
> 
>            I believe that DPV protocols developed by the PKIX working
> group
>            [ought to | ought not] include support for a cautionary period.
> 
>            [I belive this because ...]
> 
> If you feel the need to reply to the rationale posted by  someone, please
> make that posting on the other thread.  Please do not clutter the straw
> poll voting with a debate.
> 
> Thanks for your assistance and cooperation,
>    Russ


Received: by above.proper.com (8.11.6/8.11.3) id g0G85Ge00320 for ietf-pkix-bks; Wed, 16 Jan 2002 00:05:16 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G85F300313 for <[e-mail]>; Wed, 16 Jan 2002 00:05:15 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id JAA22690; Wed, 16 Jan 2002 09:06:22 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id JAA14706; Wed, 16 Jan 2002 09:04:40 +0100
Message-ID: <[e-mail]>
Date: Wed, 16 Jan 2002 09:04:42 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: [e-mail]
Subject: Re: OCSP RFC and OCSP version 2 ID
References: <8D7EC1912E25D411A32100D0B7695397E1B544@SCYGMXS01>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Santosh,

> Folks:
> 
> I am looking at both the RFC and version 2 ID for OCSP.  Each document
> contains statements that seem contradictory to me.  This relates to the
> meaning of nextUpdate field in the OCSP SingleResponse.  Some places each
> document states that:
> 
> "If nextUpdate is not set, the responder is indicating that newer
> revocation information is available all the time"
> 
> Other places each document states that:
> 
> "Responses where the nextUpdate value is not set are equivalent to a CRL
> with no time for nextUpdate"
> 
> Now, this appear contradictory to me since I do not interpret X.509 to
> imply that absence of nextUpdate field in CRL means near real-time CRL
> generation.
> 
> I assume that the above is editorial oversight and the authors of both the
> RFC and ID mean that for OCSP, absence of nextUpdate means newer
> revocation information is available all the time.

The OCSP RFC advertises thisUpdate and nextUpdate as:

   - thisUpdate: The time at which the status being indicated is known
                 to be correct

   - nextUpdate: The time at or before which newer information will be
                 available about the status of the certificate

At the time the document was written, the main mechanism to feed the
information to the OCSP server was to use CRLs. So it seems sensible to
think that these fields are copied from a CRL.

So I would say that "responses where the nextUpdate value is not set are
equivalent to a CRL with no time for nextUpdate" is the correct
interpretation.

Now the text could be clarified to say what this really means !

Section 5.1.2.5 (Next Update) from PKIX Part 1 does not say a word in that
case.

The general response is the "certificate policy will tell", in the same way
that when some extensions are absent, e.g. the CRL Distribution points, the
certificate policy will tell.

So I would certainly not interpret it as: "If nextUpdate is not set, the
responder is indicating that newer revocation information is available all
the time".

Denis 


> Santosh Chokhani
> CygnaCom Solutions, Inc.
> 7927 Jones Branch Drive, Suite 100 West
> McLean, VA 22102
> [e-mail]
> [phone]  [phone] (fax)
> www.cygnacom.com
> 
> Entrust CygnaCom


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0G7hOL27286 for ietf-pkix-bks; Tue, 15 Jan 2002 23:43:24 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G7hM327278 for <[e-mail]>; Tue, 15 Jan 2002 23:43:22 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id IAA27416; Wed, 16 Jan 2002 08:44:29 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id IAA22136; Wed, 16 Jan 2002 08:42:47 +0100
Message-ID: <[e-mail]>
Date: Wed, 16 Jan 2002 08:42:49 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: [e-mail]
Subject: Re: Cautionary Period Straw Poll
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ,

Before lauching a straw poll, I would appreciate that you answer to the
e-mail that I sent you on Monday 14. You have not refuted the arguments.

That e-mail is copied below.

If there is a straw poll, then it is between option 1) and option 2).

Regards,

Denis

=========================================================================
Russ,

(text deleted) 

> There are many application contexts where the concept of a cautionary
> period is irrelevant.  For example: TLS.  The client will either accept the
> server's certificate for establishment of the TLS-protected session, or it
> will reject it.

True, but the reverse sentence is also true: "There are application contexts
where the concept of a cautionary period is relevant".
 
> So, when does it matter?  Non-repudiation of a high-value transaction. In
> such a context, it is very important to know when a transaction take
> place.  The PKIX working group has done a lot of work on TSP to fill this
> requirement.

Non-repudiation is not the single security service where a cautionary period
is relevant. It is also relevant for data origin authentication with
integrity.

> Let's assume that the constrained client wants to validate such a
> transaction.  The TSP timestamp provides the date/time of interest.  It can
> ask the DPV server if the signer's path was valid at the time that the
> signature was generated.

Since it is not possible to know when the signature was generated, 
an upper limit of that time is use instead: the date of the time-stamp
applied over the digital signature or the date included in an audit record
See the DPV requirements document at:
http://www.imc.org/draft-ietf-pkix-dsv-req. 

The correct sentence is thus: "It can ask the DPV server if the signer's
path was valid at the time that the time-stamp was applied over the digital
signature".

> In my view, the cautionary period only impacts the signature on the
> transaction.  

Since a cautionary period cannot be applied in the context of a
confidentiality service or an authentication service, the right wording 
would be : "the cautionary period only impacts the use of a certificate 
in the context of a non-repudiation service or a
data-origin-authentication-with-integrity service".

> The DPV server does not validate this signature.  Has
> adequate time passed since the signature was applied to ensure that recent
> compromise of the end-entity private key has been reported?  I submit that
> this a signature validation question, not a certification path validation
> question.

The basic question is how clients can take advantage of a DPV server in the
case where a cautionary period exists and in the context of a
non-repudiation service or a data-origin-authentication-with-integrity
service ?

There are two options whether :

1) the cautionary period has to be known by the client 
   (which is what your arguments mandate).

2) the cautionary period is known by the server 
   (which is what my arguments mandate).

In the context of a non repudiation service, clients must necessarilly know
either the date of the time-stamp or the date of the audit record. 

In the context of a data-origin-authentication-with-integrity service,
clients must necessarilly know the purported date of the digital signature.

With option 1, clients must locally manage the cautionary period for each
supported policy and locally compare it either with the date of the
time-stamp or the date of the audit record, or the the purported date of the
digital signature. This makes management actions more difficult 
(and makes also thin clients fater) since if that period changes, 
local tables need to be updated in each client application.

With option 2, clients do not need to manage that information locally since
it is part of the policy supported by the server. They simply need to send 
to the server either the date of the time-stamp or the date of the audit
record, or the purported date of the digital signature.

The goal of these protocols is to delegate as much as possible all the 
validation conditions to a server. The cautionary period does not
make an exception.

Denis

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



 
>  From the previous thread (which seems to have died down), I think that
> everyone understands the Cautionary Period concept.  I am trying to
> determine whether there is a constituency for Cautionary Period in DPV.
> 
> I would like people that have an opinion to vote by sending a message to
> the list.  The message should be structured as follows:
> 
>            To: [e-mail]
>            Subject: RE: Cautionary Period Straw Poll
> 
>            I believe that DPV protocols developed by the PKIX working group
>            [ought to | ought not] include support for a cautionary period.
> 
>            [I belive this because ...]
> 
> If you feel the need to reply to the rationale posted by  someone, please
> make that posting on the other thread.  Please do not clutter the straw
> poll voting with a debate.
> 
> Thanks for your assistance and cooperation,
>    Russ


Received: by above.proper.com (8.11.6/8.11.3) id g0G4xpf17900 for ietf-pkix-bks; Tue, 15 Jan 2002 20:59:51 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G4xo317895 for <[e-mail]>; Tue, 15 Jan 2002 20:59:50 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Tue, 15 Jan 2002 20:59:49 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Tue, 15 Jan 2002 20:59:48 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <C2FYWXRB>; Tue, 15 Jan 2002 20:59:48 -0800
Content-return: allowed
Date: Tue, 15 Jan 2002 20:59:45 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Cautionary Period Straw Poll
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I belive that DPV shouldn't include support for cautionary
period.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Tuesday, January 15, 2002 10:07 AM
> To: [e-mail]
> Subject: Re: Cautionary Period Straw Poll
> 
> 
> 
> I believe that DPV protocols developed by the PKIX working group
> ought not include support for a cautionary period.
> 
> Russ
> 


Received: by above.proper.com (8.11.6/8.11.3) id g0G2SIx15525 for ietf-pkix-bks; Tue, 15 Jan 2002 18:28:18 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G2SG315521 for <[e-mail]>; Tue, 15 Jan 2002 18:28:16 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id PAA21760; Wed, 16 Jan 2002 15:28:13 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA385397; Wed, 16 Jan 2002 15:28:12 +1300 (NZDT) (sender [e-mail])
Date: Wed, 16 Jan 2002 15:28:12 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  OCSP RFC and OCSP version 2 ID
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Santosh Chokhani <[e-mail]> writes:

>I am looking at both the RFC and version 2 ID for OCSP.  Each document
>contains statements that seem contradictory to me.  This relates to the
>meaning of nextUpdate field in the OCSP SingleResponse.  Some places each
>document states that:
>
>"If nextUpdate is not set, the responder is indicating that newer revocation
>information is available all the time"
>
>Other places each document states that:
>
>"Responses where the nextUpdate value is not set are equivalent to a CRL
>with no time for nextUpdate"
>
>Now, this appear contradictory to me since I do not interpret X.509 to imply
>that absence of nextUpdate field in CRL means near real-time CRL generation.
>
>I assume that the above is editorial oversight and the authors of both the RFC
>and ID mean that for OCSP, absence of nextUpdate means newer revocation
>information is available all the time.

There appears to be quite a bit of confusion over these fields among
implementors because the RFC is so vague over how they're handled.  I've seen
responses where nextUpdate isn't set, where it's set to a value later than
thisUpdate, and where it's set to a value equal to thisUpdate (which seems
bogus since it auto-invalidates itself, but I haven't heard any complaints
about this so I guess no-one notices).  Other responders just copy the info
across from the CRL, which leads to funny results if the CRL doesn't contain a
notAfter (== nextUpdate), since the client is supposed to think that new info
is always available even though it's coming from a CRL which may only be
updated once a day (a truth-in-advertising problem).  My solution has been to
ignore the fields and let users decide, which I suspect means they just check
whenever they feel like it, because I doubt anyone's going to try and handle
all the weird special cases which crop up.  I seem to remember something on the
OpenSSL list where someone was grumbling about having to implement variable-
configuration options to handle this as well, so others have run into this
problem too.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0G0gm413625 for ietf-pkix-bks; Tue, 15 Jan 2002 16:42:48 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0G0gl313620 for <[e-mail]>; Tue, 15 Jan 2002 16:42:47 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <DAB9DBJH>; Tue, 15 Jan 2002 19:42:45 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B544@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: [e-mail]
Subject: OCSP RFC and OCSP version 2 ID
Date: Tue, 15 Jan 2002 19:41:33 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19E26.8BBF23F0"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C19E26.8BBF23F0
Content-Type: text/plain;
	charset="iso-8859-1"

Folks:

I am looking at both the RFC and version 2 ID for OCSP.  Each document
contains statements that seem contradictory to me.  This relates to the
meaning of nextUpdate field in the OCSP SingleResponse.  Some places each
document states that:

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

Other places each document states that:

"Responses where the nextUpdate value is not set are equivalent to a CRL
with no time for nextUpdate"

Now, this appear contradictory to me since I do not interpret X.509 to imply
that absence of nextUpdate field in CRL means near real-time CRL generation.

I assume that the above is editorial oversight and the authors of both the
RFC and ID mean that for OCSP, absence of nextUpdate means newer revocation
information is available all the time.


Raccoon Eyes

Santosh Chokhani
CygnaCom Solutions, Inc.
7927 Jones Branch Drive, Suite 100 West
McLean, VA 22102
[e-mail]
[phone]  [phone] (fax)
www.cygnacom.com

Entrust CygnaCom





------_=_NextPart_001_01C19E26.8BBF23F0
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>OCSP RFC and OCSP version 2 ID</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Folks:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I am looking at both the RFC and =
version 2 ID for OCSP.&nbsp; Each document contains statements that =
seem contradictory to me.&nbsp; This relates to the meaning of =
nextUpdate field in the OCSP SingleResponse.&nbsp; Some places each =
document states that:</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;If nextUpdate is not set, the =
responder is indicating that newer revocation information is available =
all the time&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Other places each document states =
that:</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">&quot;Responses where the nextUpdate =
value is not set are equivalent to a CRL with no time for =
nextUpdate&quot;</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Now, this appear contradictory to me =
since I do not interpret X.509 to imply that absence of nextUpdate =
field in CRL means near real-time CRL generation.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">I assume that the above is editorial =
oversight and the authors of both the RFC and ID mean that for OCSP, =
absence of nextUpdate means newer revocation information is available =
all the time.</FONT></P>
<BR>

<P><B><FONT SIZE=3D2 FACE=3D"Arial">Raccoon</FONT></B><FONT SIZE=3D2 =
FACE=3D"Arial"></FONT><B> <FONT COLOR=3D"#808000" SIZE=3D2 =
FACE=3D"Arial">Eyes</FONT></B><BR>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Santosh Chokhani</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">CygnaCom Solutions, Inc.</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">7927 Jones Branch Drive, Suite 100 =
West</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">McLean, VA 22102</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[e-mail]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">[phone]&nbsp; [phone] =
(fax)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">www.cygnacom.com</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Entrust CygnaCom</FONT>
<BR>
</P>
<BR>
<BR>

</BODY>
</HTML>
------_=_NextPart_001_01C19E26.8BBF23F0--


Received: by above.proper.com (8.11.6/8.11.3) id g0FL2Fm09057 for ietf-pkix-bks; Tue, 15 Jan 2002 13:02:15 -0800 (PST)
Received: from prv-mail20.provo.novell.com (prv-mail20.provo.novell.com [137.65.81.122]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0FL2D309052 for <[e-mail]>; Tue, 15 Jan 2002 13:02:13 -0800 (PST)
Received: from INET-PRV-MTA by prv-mail20.provo.novell.com with Novell_GroupWise; Tue, 15 Jan 2002 14:03:42 -0700
Message-Id: <[e-mail]>
X-Mailer: Novell GroupWise Internet Agent 6.0.1
Date: Tue, 15 Jan 2002 14:03:35 -0700
From: "Tolga Acar" <[e-mail]>
To: <[e-mail]>, <[e-mail]>
Subject: Re: Question about encoding of RSA public Exponent
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Jim,

>
>The public exponent is what confuses me - it doesn't seem to be in
two's
>complement form.
No, it is not supposed to be.

>The exponent value is 65537
>Hex  is                                        010001
>Binary is                                    0000 0001 0000 0000 0000
>0001
which is correct.

>I would have thought this would have to be encoded as
>020400FEFFFF
Nope.

>Could you tell me what I'm overlooking in this case?
Check with PKCS#1 downloadable from RSA, or it is also RFC 2437.

- Tolga


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0FJ6pP06110 for ietf-pkix-bks; Tue, 15 Jan 2002 11:06:51 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0FJ6m306106 for <[e-mail]>; Tue, 15 Jan 2002 11:06:48 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 15 Jan 2002 19:06:25 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA14974 for <[e-mail]>; Tue, 15 Jan 2002 14:06:41 -0500 (EST)
Received: from exno02.dynas.se (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g0FIWD417925 for <[e-mail]>; Tue, 15 Jan 2002 13:32:13 -0500 (EST)
Received: by exno02.dynas.se with Internet Mail Service (5.5.2653.19) id <V47AGPFG>; Tue, 15 Jan 2002 19:32:00 +0100
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.46]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPH5DM9; Tue, 15 Jan 2002 13:31:56 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 15 Jan 2002 13:07:04 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Re: Cautionary Period Straw Poll
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I believe that DPV protocols developed by the PKIX working group
ought not include support for a cautionary period.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0FJ54c06070 for ietf-pkix-bks; Tue, 15 Jan 2002 11:05:04 -0800 (PST)
Received: from SOTTMXS01.entrust.com ([216.191.251.35]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0FJ53306066 for <[e-mail]>; Tue, 15 Jan 2002 11:05:03 -0800 (PST)
Received: by SOTTMXS01.entrust.com with Internet Mail Service (5.5.2653.19) id <DAB9C75C>; Tue, 15 Jan 2002 14:04:50 -0500
Message-ID: <8D7EC1912E25D411A32100D0B7695397E1B4E5@SCYGMXS01>
From: Santosh Chokhani <[e-mail]>
To: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: RE: Cautionary Period Straw Poll
Date: Tue, 15 Jan 2002 14:03:37 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C19DF7.56A74410"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C19DF7.56A74410
Content-Type: text/plain

I believe that DPV protocols developed by the PKIX working group ought not
include support for a cautionary period.

I believe this because I am.

-----Original Message-----
From: Housley, Russ [mailto:[e-mail]]
Sent: Tuesday, January 15, 2002 1:05 PM
To: [e-mail]
Subject: Cautionary Period Straw Poll



 From the previous thread (which seems to have died down), I think that 
everyone understands the Cautionary Period concept.  I am trying to 
determine whether there is a constituency for Cautionary Period in DPV.

I would like people that have an opinion to vote by sending a message to 
the list.  The message should be structured as follows:

           To: [e-mail]
           Subject: RE: Cautionary Period Straw Poll

           I believe that DPV protocols developed by the PKIX working group
           [ought to | ought not] include support for a cautionary period.

           [I belive this because ...]

If you feel the need to reply to the rationale posted by  someone, please 
make that posting on the other thread.  Please do not clutter the straw 
poll voting with a debate.

Thanks for your assistance and cooperation,
   Russ

------_=_NextPart_001_01C19DF7.56A74410
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3DUS-ASCII">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2653.12">
<TITLE>RE: Cautionary Period Straw Poll</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>I believe that DPV protocols developed by the PKIX =
working group ought not include support for a cautionary period.</FONT>
</P>

<P><FONT SIZE=3D2>I believe this because I am.</FONT>
</P>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Housley, Russ [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, January 15, 2002 1:05 PM</FONT>
<BR><FONT SIZE=3D2>To: [e-mail]</FONT>
<BR><FONT SIZE=3D2>Subject: Cautionary Period Straw Poll</FONT>
</P>
<BR>
<BR>

<P><FONT SIZE=3D2>&nbsp;From the previous thread (which seems to have =
died down), I think that </FONT>
<BR><FONT SIZE=3D2>everyone understands the Cautionary Period =
concept.&nbsp; I am trying to </FONT>
<BR><FONT SIZE=3D2>determine whether there is a constituency for =
Cautionary Period in DPV.</FONT>
</P>

<P><FONT SIZE=3D2>I would like people that have an opinion to vote by =
sending a message to </FONT>
<BR><FONT SIZE=3D2>the list.&nbsp; The message should be structured as =
follows:</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
To: [e-mail]</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Subject: RE: Cautionary Period Straw Poll</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I =
believe that DPV protocols developed by the PKIX working group</FONT>
<BR><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[ought to | ought not] include support for a cautionary period.</FONT>
</P>

<P><FONT =
SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
[I belive this because ...]</FONT>
</P>

<P><FONT SIZE=3D2>If you feel the need to reply to the rationale posted =
by&nbsp; someone, please </FONT>
<BR><FONT SIZE=3D2>make that posting on the other thread.&nbsp; Please =
do not clutter the straw </FONT>
<BR><FONT SIZE=3D2>poll voting with a debate.</FONT>
</P>

<P><FONT SIZE=3D2>Thanks for your assistance and cooperation,</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Russ</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C19DF7.56A74410--


Received: by above.proper.com (8.11.6/8.11.3) id g0FIW9N05481 for ietf-pkix-bks; Tue, 15 Jan 2002 10:32:09 -0800 (PST)
Received: from nebula.x509.com (nebula.x509.com [199.175.150.19]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0FIW7305476 for <[e-mail]>; Tue, 15 Jan 2002 10:32:07 -0800 (PST)
Received: from crack.x509.com (mail.x509.com [199.175.150.1]) by nebula.x509.com (8.11.6/XCERT) with ESMTP id g0FIW2i18183 for <[e-mail]>; Tue, 15 Jan 2002 10:32:02 -0800 (PST)
Received: from exvan01.x509.com (exvan01.x509.com [10.9.22.50]) by crack.x509.com (8.11.6/XCERT) with ESMTP id g0FIW2w23102 for <[e-mail]>; Tue, 15 Jan 2002 10:32:02 -0800 (PST)
Received: by exvan01.x509.com with Internet Mail Service (5.5.2653.19) id <VVXYYKCB>; Tue, 15 Jan 2002 10:34:30 -0800
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.46]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPH5DM8; Tue, 15 Jan 2002 13:31:55 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Tue, 15 Jan 2002 13:05:22 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Cautionary Period Straw Poll
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

 From the previous thread (which seems to have died down), I think that 
everyone understands the Cautionary Period concept.  I am trying to 
determine whether there is a constituency for Cautionary Period in DPV.

I would like people that have an opinion to vote by sending a message to 
the list.  The message should be structured as follows:

           To: [e-mail]
           Subject: RE: Cautionary Period Straw Poll

           I believe that DPV protocols developed by the PKIX working group
           [ought to | ought not] include support for a cautionary period.

           [I belive this because ...]

If you feel the need to reply to the rationale posted by  someone, please 
make that posting on the other thread.  Please do not clutter the straw 
poll voting with a debate.

Thanks for your assistance and cooperation,
   Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0FHahn03969 for ietf-pkix-bks; Tue, 15 Jan 2002 09:36:43 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0FHaf303965 for <[e-mail]>; Tue, 15 Jan 2002 09:36:41 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA25334; Tue, 15 Jan 2002 18:37:50 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA16526; Tue, 15 Jan 2002 18:35:49 +0100
Message-ID: <[e-mail]>
Date: Tue, 15 Jan 2002 18:35:32 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Tom Gindin <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, Alfonso De Gregorio <[e-mail]>, [e-mail]
Subject: Re: Cautionary Period
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Tom,

>       Denis:
 
>       You are correct that there are other services than NR for which
> cautionary period is useful.  However, don't they all involve the
> validation of signed data (and data to be kept for a considerable time, 

Is a week-end period a "considerable time" ? I do not think so. 
An e-mail sent on the friday may only be opened on the monday. 
Applying a cautionary period increases the confidence and reduces the risk.

> at that)?  If they do, then cautionary period should go into DSV.

Everybody agrees that a cautionary period certainly applies to DSV.

However, some thin clients would still like to use DPV to verify digital
signatures in particular in the context of data origin authentication with
integrity. I do not think it would be appropriate to say that it is not
possible and that the cautionary period, when it exists, shall only be
applied *locally* by the client.

Denis

>             Tom Gindin
> 
> Denis Pinkas <[e-mail]>@mail.imc.org on 01/14/2002 04:20:06 AM
> 
> Sent by:    [e-mail]
> 
> To:    "Housley, Russ" <[e-mail]>
> cc:    Alfonso De Gregorio <[e-mail]>, [e-mail]
> Subject:    Re: Cautionary Period
> 
> Russ,
> 
> (text deleted)
> 
> > There are many application contexts where the concept of a cautionary
> > period is irrelevant.  For example: TLS.  The client will either accept
> the
> > server's certificate for establishment of the TLS-protected session, or
> it
> > will reject it.
> 
> True, but the reverse sentence is also true: "There are application
> contexts
> where the concept of a cautionary period is relevant".
> 
> > So, when does it matter?  Non-repudiation of a high-value transaction. In
> > such a context, it is very important to know when a transaction take
> > place.  The PKIX working group has done a lot of work on TSP to fill this
> > requirement.
> 
> Non-repudiation is not the single security service where a cautionary
> period
> is relevant. It is also relevant for data origin authentication with
> integrity.
> 
> > Let's assume that the constrained client wants to validate such a
> > transaction.  The TSP timestamp provides the date/time of interest.  It
> can
> > ask the DPV server if the signer's path was valid at the time that the
> > signature was generated.
> 
> Since it is not possible to know when the signature was generated,
> an upper limit of that time is use instead: the date of the time-stamp
> applied over the digital signature or the date included in an audit record
> See the DPV requirements document at:
> http://www.imc.org/draft-ietf-pkix-dsv-req.
> 
> The correct sentence is thus: "It can ask the DPV server if the signer's
> path was valid at the time that the time-stamp was applied over the digital
> signature".
> 
> > In my view, the cautionary period only impacts the signature on the
> > transaction.
> 
> Since a cautionary period cannot be applied in the context of a
> confidentiality service or an authentication service, the right wording
> would be : "the cautionary period only impacts the use of a certificate
> in the context of a non-repudiation service or a
> data-origin-authentication-with-integrity service".
> 
> > The DPV server does not validate this signature.  Has
> > adequate time passed since the signature was applied to ensure that
> recent
> > compromise of the end-entity private key has been reported?  I submit
> that
> > this a signature validation question, not a certification path validation
> > question.
> 
> The basic question is how clients can take advantage of a DPV server in the
> case where a cautionary period exists and in the context of a
> non-repudiation service or a data-origin-authentication-with-integrity
> service ?
> 
> There are two options whether :
> 
> 1) the cautionary period has to be known by the client
>    (which is what your arguments mandate).
> 
> 2) the cautionary period is known by the server
>    (which is what my arguments mandate).
> 
> In the context of a non repudiation service, clients must necessarilly know
> either the date of the time-stamp or the date of the audit record.
> 
> In the context of a data-origin-authentication-with-integrity service,
> clients must necessarilly know the purported date of the digital signature.
> 
> With option 1, clients must locally manage the cautionary period for each
> supported policy and locally compare it either with the date of the
> time-stamp or the date of the audit record, or the the purported date of
> the
> digital signature. This makes management actions more difficult
> (and makes also thin clients fater) since if that period changes,
> local tables need to be updated in each client application.
> 
> With option 2, clients do not need to manage that information locally since
> it is part of the policy supported by the server. They simply need to send
> to the server either the date of the time-stamp or the date of the audit
> record, or the purported date of the digital signature.
> 
> The goal of these protocols is to delegate as much as possible all the
> validation conditions to a server. The cautionary period does not
> make an exception.
> 
> Denis
> 
> > Russ


Received: by above.proper.com (8.11.6/8.11.3) id g0FGfmx02005 for ietf-pkix-bks; Tue, 15 Jan 2002 08:41:48 -0800 (PST)
Received: from emerson.torrentnet.com (emerson.torrentnet.com [198.78.51.110]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0FGfk302000 for <[e-mail]>; Tue, 15 Jan 2002 08:41:46 -0800 (PST)
Received: from imperial.torrentnet.com (imperial.torrentnet.com [198.78.51.109]) by emerson.torrentnet.com (8.11.2/8.11.2) with ESMTP id g0FGflZ04272 for <[e-mail]>; Tue, 15 Jan 2002 11:41:47 -0500 (EST)
Received: from castillo.torrentnet.com (castillo.torrentnet.com [4.18.161.34]) by imperial.torrentnet.com (8.11.2/8.11.2) with ESMTP id g0FGfko74340 for <[e-mail]>; Tue, 15 Jan 2002 11:41:46 -0500 (EST)
Received: from torrentnet.com (cristall.torrentnet.com [4.18.161.46]) by castillo.torrentnet.com (8.9.3/8.9.3) with ESMTP id LAA22139; Tue, 15 Jan 2002 11:41:44 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 15 Jan 2002 11:41:43 -0500
From: James Comen <[e-mail]>
X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 2.2.2-RELEASE i386)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Question about encoding of RSA public Exponent
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hello,
I looked through the archives and couldn't find the answer to this
question.
There was info about two's complement form for integers but nothing
about
the public exponents.
If this is not the appropriate forum for this question - I apologize -
feel free to
point me to the proper forum.

I've spent some time trying to decode the RSA public key which is part
of
the X.509 certificate.  More specifically, it is the key used to
exchange with a
Cisco router when doing IKE with encrypted nonces.  I want to know
what information a cisco router expects and what I shoud expect when
copying the RSA key from a cisco router

For the RSA public key, there is a modulus and a public exponent.  I
generated
a 1024 bit RSA key.

The modulus is    0241 00C8934A 22BE0C99 ...

02                means it's an integer
41                is the length of the modulus - it's 41 rather than 40
due to the leading 00 to prevent it
                    from being interpreted as a negative value
00C8...       is the modulus


The public exponent is 020301 0001

02              means it's an integer
03              is the length of the public exponent
010001     is the public exponent.

The public exponent is what confuses me - it doesn't seem to be in two's
complement form.
The exponent value is 65537
Hex  is                                        010001
Binary is                                    0000 0001 0000 0000 0000
0001
Two's complement is             1111 1110 1111 1111 1111 1110  + 1
hex is                                             F       E
F        F      F        F

I would have thought this would have to be encoded as
020400FEFFFF

Could you tell me what I'm overlooking in this case?

Oh, one other quick question  - Is  the modulus  encoded as a string of
bytes
or a  multiprecision integer?

Thank you very much,
Jim Comen




Received: by above.proper.com (8.11.6/8.11.3) id g0FBTc216654 for ietf-pkix-bks; Tue, 15 Jan 2002 03:29:38 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0FBTb316650 for <[e-mail]>; Tue, 15 Jan 2002 03:29:37 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18054; Tue, 15 Jan 2002 06:29:36 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-roadmap-07.txt
Date: Tue, 15 Jan 2002 06:29:36 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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: Roadmap
	Author(s)	: A. Arsenault, S. Turner
	Filename	: draft-ietf-pkix-roadmap-07.txt
	Pages		: 53
	Date		: 14-Jan-02
	
This document provides an overview or 'roadmap' of the work done by
the IETF PKIX working group. It describes some of the terminology
used in the working group's documents, and the theory behind an
X.509-based Public Key Infrastructure, Privilege Management
Infrastructure (PMI), and Time Stamping and Data Certification
Infrastructures. It identifies each document developed by the PKIX
working group, and describes the relationships among the various
documents. It also provides advice to would-be PKIX implementors
about some of the issues discussed at length during PKIX
development, in hopes of making it easier to build implementations
that will actually interoperate.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-roadmap-07.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0ENXqZ22930 for ietf-pkix-bks; Mon, 14 Jan 2002 15:33:52 -0800 (PST)
Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ENXo322925 for <[e-mail]>; Mon, 14 Jan 2002 15:33:50 -0800 (PST)
Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e1.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA405034; Mon, 14 Jan 2002 18:30:46 -0500
Received: from d01ml062.pok.ibm.com (d01ml062.pok.ibm.com [9.117.250.163]) by northrelay02.pok.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g0ENXi7109694; Mon, 14 Jan 2002 18:33:44 -0500
Importance: Normal
Sensitivity: 
Subject: Re: Cautionary Period
To: Denis Pinkas <[e-mail]>
Cc: "Housley, Russ" <[e-mail]>, Alfonso De Gregorio <[e-mail]>, [e-mail]
X-Mailer: Lotus Notes Release 5.0.7  March 21, 2001
Message-ID: <[e-mail]>
From: "Tom Gindin" <[e-mail]>
Date: Mon, 14 Jan 2002 18:33:24 -0500
X-MIMETrack: Serialize by Router on D01ML062/01/M/IBM(Release 5.0.9 |November 26, 2001) at 01/14/2002 06:33:46 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

      Denis:

      You are correct that there are other services than NR for which
cautionary period is useful.  However, don't they all involve the
validation of signed data (and data to be kept for a considerable time, at
that)?  If they do, then cautionary period should go into DSV.

            Tom Gindin


Denis Pinkas <[e-mail]>@mail.imc.org on 01/14/2002 04:20:06 AM

Sent by:    [e-mail]


To:    "Housley, Russ" <[e-mail]>
cc:    Alfonso De Gregorio <[e-mail]>, [e-mail]
Subject:    Re: Cautionary Period



Russ,

(text deleted)

> There are many application contexts where the concept of a cautionary
> period is irrelevant.  For example: TLS.  The client will either accept
the
> server's certificate for establishment of the TLS-protected session, or
it
> will reject it.

True, but the reverse sentence is also true: "There are application
contexts
where the concept of a cautionary period is relevant".

> So, when does it matter?  Non-repudiation of a high-value transaction. In
> such a context, it is very important to know when a transaction take
> place.  The PKIX working group has done a lot of work on TSP to fill this
> requirement.

Non-repudiation is not the single security service where a cautionary
period
is relevant. It is also relevant for data origin authentication with
integrity.

> Let's assume that the constrained client wants to validate such a
> transaction.  The TSP timestamp provides the date/time of interest.  It
can
> ask the DPV server if the signer's path was valid at the time that the
> signature was generated.

Since it is not possible to know when the signature was generated,
an upper limit of that time is use instead: the date of the time-stamp
applied over the digital signature or the date included in an audit record
See the DPV requirements document at:
http://www.imc.org/draft-ietf-pkix-dsv-req.

The correct sentence is thus: "It can ask the DPV server if the signer's
path was valid at the time that the time-stamp was applied over the digital
signature".

> In my view, the cautionary period only impacts the signature on the
> transaction.

Since a cautionary period cannot be applied in the context of a
confidentiality service or an authentication service, the right wording
would be : "the cautionary period only impacts the use of a certificate
in the context of a non-repudiation service or a
data-origin-authentication-with-integrity service".

> The DPV server does not validate this signature.  Has
> adequate time passed since the signature was applied to ensure that
recent
> compromise of the end-entity private key has been reported?  I submit
that
> this a signature validation question, not a certification path validation
> question.

The basic question is how clients can take advantage of a DPV server in the
case where a cautionary period exists and in the context of a
non-repudiation service or a data-origin-authentication-with-integrity
service ?

There are two options whether :

1) the cautionary period has to be known by the client
   (which is what your arguments mandate).

2) the cautionary period is known by the server
   (which is what my arguments mandate).

In the context of a non repudiation service, clients must necessarilly know
either the date of the time-stamp or the date of the audit record.

In the context of a data-origin-authentication-with-integrity service,
clients must necessarilly know the purported date of the digital signature.

With option 1, clients must locally manage the cautionary period for each
supported policy and locally compare it either with the date of the
time-stamp or the date of the audit record, or the the purported date of
the
digital signature. This makes management actions more difficult
(and makes also thin clients fater) since if that period changes,
local tables need to be updated in each client application.

With option 2, clients do not need to manage that information locally since
it is part of the policy supported by the server. They simply need to send
to the server either the date of the time-stamp or the date of the audit
record, or the purported date of the digital signature.

The goal of these protocols is to delegate as much as possible all the
validation conditions to a server. The cautionary period does not
make an exception.

Denis


> Russ




Received: by above.proper.com (8.11.6/8.11.3) id g0EJVih16598 for ietf-pkix-bks; Mon, 14 Jan 2002 11:31:44 -0800 (PST)
Received: from finch-post-12.mail.demon.net (finch-post-12.mail.demon.net [194.217.242.41]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EJVg316593 for <[e-mail]>; Mon, 14 Jan 2002 11:31:42 -0800 (PST)
Received: from drh-consultancy.demon.co.uk ([193.237.150.98] helo=gemplus.com) by finch-post-12.mail.demon.net with esmtp (Exim 2.12 #1) id 16QCpa-000Iab-0C for [e-mail]; Mon, 14 Jan 2002 19:31:43 +0000
Message-ID: <[e-mail]>
Date: Mon, 14 Jan 2002 19:34:41 +0000
From: Dr S N Henson <[e-mail]>
X-Mailer: Mozilla 4.79 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"Housley, Russ" wrote:
> 
> Peter:
> 
> > > I would prefer to maintain alignment with RFC 2585.  The use of
> > SEQUENCE OF
> > > would be fewer bit on the wire, but it would also require the
> > specification
> > > of another MIME type for the transfer of certificates.
> >
> >And what about using a cert-only cms message?
> 
> This is acceptable, but I prefer one that is more straightforward to
> implement with web server tools.
> 

Couldn't a valid indefinite length encoded certs only cms message be
generated just using cut and paste?

Steve.
-- 
Dr Stephen N. Henson.   http://www.drh-consultancy.demon.co.uk/
Personal Email: [e-mail] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [e-mail] PGP key: via homepage.



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EJUK916565 for ietf-pkix-bks; Mon, 14 Jan 2002 11:30:20 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EJUI316561 for <[e-mail]>; Mon, 14 Jan 2002 11:30:18 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id UAA07884; Mon, 14 Jan 2002 20:30:08 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 14 Jan 2002 20:30:08 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id UAA20352; Mon, 14 Jan 2002 20:30:07 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id UAA03532; Mon, 14 Jan 2002 20:30:06 +0100 (MET)
Date: Mon, 14 Jan 2002 20:30:06 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> >>This is acceptable, but I prefer one that is more straightforward to implement
> >>with web server tools.
> > 
> > That's probably the best argument for choosing MIME multipart/RFC 2585 rather
> > than a SEQUENCE OF, the server shouldn't need to do anything more specialised
> > than "fetch value based on key, via HTTP".  Any special-case processing can be
> > done by the client.
> 
> 
> I don't agree. Complexity should be put in the server, not the client. 

Another argument may be that using a 'simple' standard developement kit
for a server to create unnecessary overhead for a client (and useless
data) instead of having a small and fast logic may result in
having all kinds of possible and undesirable errors and protocol messages 
above HTTP/MIME to escape at some point. 



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EHfDV13255 for ietf-pkix-bks; Mon, 14 Jan 2002 09:41:13 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EHfC313248 for <[e-mail]>; Mon, 14 Jan 2002 09:41:12 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id SAA38354; Mon, 14 Jan 2002 18:42:20 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id SAA20094; Mon, 14 Jan 2002 18:40:41 +0100
Message-ID: <[e-mail]>
Date: Mon, 14 Jan 2002 18:25:27 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Petra Barzin <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Petra,

Please take a look at RFC 3126, where many of the ASN.1 structures were
imported from and are thus defined there. This should answer all your
questions.

Regards,

Denis
 
> Denis,
> 
> may I still ask some questions concerning the document "Delegated
> Path Validation and Delegated Path Discovery Protocols" ?
> 
> > PathValues :: = SEQUENCE {
> >        certificateValues      CertificateValues,
> >        revocationValues       RevocationValues }
> >
> I'm missing some ASN.1 definitions. You refer to "CertificateValues"
> and "RevocationValues" but I couldn't find these definitions.
> 
> By the way, you should move this definition of "PathValues" from
> the chapter "5.2.1. Request" to the chapter "5.2.2.  Response Syntax"
> where it is used.
> 
> Another ASN.1 question:
> 
> > UsefulRevoc ::= CHOICE {
> >        certificateRevocationLists     CertificateRevocationLists,
> >        completeRevocationRefs         CompleteRevocationRefs }
> >
> A DPV request may contain useful revocation information provided
> by the client. Maybe it's because I don't know the element
> "CompleteRevocationRefs" but where do I store OCSP answers?
> 
> Could you please send the definition of "CompleteRevocationRefs"
> and "completeCertificateRefs"? I guess they are imported from [ES-F],
> "Electronic Signature Formats for long term electronic signatures", aren't
> they?
> 
> >    CertOrCertRef ::=  CHOICE {
> >        certificate          [1]  Certificate,
> >        certRef              [2]  OtherCertID }
> >
> I'm also missing the definition of OtherCertID used in a DPV and DPD
> request.
> 
> Thanks, Petra
> 
> Denis Pinkas schrieb:
> 
> > Petra,
> >
> > > Denis,
> >
> > > is there also a new version of the document "Delegated Path
> > > Validation and Delegated Path Discovery Protocols"
> >
> > Not at this time. Currently we need first to agree on the DPV / DPD
> > requirements, then we will discuss the solutions to these requirements.
> >
> > The so-called "Delegated Path Validation and Delegated Path Discovery
> > Protocols" document could be a candidate to fulfill these requirements.
> > It is too early to say and this will only be discussed once the
> > requirements
> > document is adopted.
> >
> > > or just a new requirement document?
> >
> > Correct. It is a new document for both the DPV and DPD requirements.
> >
> > There is also a companion document for the DSV requirements.
> > We will only discuss the DSV requirements document in detail when
> > the DPV / DPD requirements document has completed the WG last call.
> >
> > Denis


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EFeWc09902 for ietf-pkix-bks; Mon, 14 Jan 2002 07:40:32 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EFeT309896 for <[e-mail]>; Mon, 14 Jan 2002 07:40:29 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04657; Mon, 14 Jan 2002 10:40:28 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ldap-v3-05.txt
Date: Mon, 14 Jan 2002 10:40:27 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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 Operational 
                          Protocols - LDAPv3
	Author(s)	: D. Chadwick
	Filename	: draft-ietf-pkix-ldap-v3-05.txt
	Pages		: 
	Date		: 11-Jan-02
	
This document describes the features of the Lightweight Directory 
Access Protocol v3 that are needed in order to support a public key 
infrastructure based on X.509 certificates and CRLs.

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ldap-v3-05.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EF0hL08503 for ietf-pkix-bks; Mon, 14 Jan 2002 07:00:43 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EF0f308498 for <[e-mail]>; Mon, 14 Jan 2002 07:00:42 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 47DF7B44F; Mon, 14 Jan 2002 16:00:32 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZKPQVH1J; Mon, 14 Jan 2002 16:00:31 +0100
Message-ID: <[e-mail]>
Date: Mon, 14 Jan 2002 16:02:25 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Denis,
<p>may I still ask some questions concerning the document "Delegated
<br>Path Validation and Delegated Path Discovery Protocols" ?
<blockquote TYPE=CITE>
<pre>PathValues :: = SEQUENCE {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificateValues&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CertificateValues,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; revocationValues&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; RevocationValues }</pre>
</blockquote>
I'm missing some ASN.1 definitions. You refer to "CertificateValues"
<br>and "RevocationValues" but I couldn't find these definitions.
<p>By the way, you should move this definition of "PathValues" from
<br>the chapter "5.2.1. Request" to the chapter "5.2.2.&nbsp; Response
Syntax"
<br>where it is used.
<p>Another ASN.1 question:
<blockquote TYPE=CITE>
<pre>UsefulRevoc ::= CHOICE {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificateRevocationLists&nbsp;&nbsp;&nbsp;&nbsp; CertificateRevocationLists,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; completeRevocationRefs&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; CompleteRevocationRefs }</pre>
</blockquote>
A DPV request may contain useful revocation information provided
<br>by the client. Maybe it's because I don't know the element
<br>"CompleteRevocationRefs" but where do I store OCSP answers?
<p>Could you please send the definition of "CompleteRevocationRefs"
<br>and "completeCertificateRefs"? I guess they are imported from [ES-F],
<br>"Electronic Signature Formats for long term electronic signatures",
aren't they?
<blockquote TYPE=CITE>
<pre>&nbsp;&nbsp; CertOrCertRef ::=&nbsp; CHOICE {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certificate&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [1]&nbsp; Certificate,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; certRef&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [2]&nbsp; OtherCertID }</pre>
</blockquote>
I'm also missing the definition of OtherCertID used in a DPV and DPD request.
<p>Thanks, Petra
<p>Denis Pinkas schrieb:
<blockquote TYPE=CITE>Petra,
<p>> Denis,
<p>> is there also a new version of the document "Delegated Path
<br>> Validation and Delegated Path Discovery Protocols"
<p>Not at this time. Currently we need first to agree on the DPV / DPD
<br>requirements, then we will discuss the solutions to these requirements.
<p>The so-called "Delegated Path Validation and Delegated Path Discovery
<br>Protocols" document could be a candidate to fulfill these requirements.
<br>It is too early to say and this will only be discussed once the requirements
<br>document is adopted.
<p>> or just a new requirement document?
<p>Correct. It is a new document for both the DPV and DPD requirements.
<p>There is also a companion document for the DSV requirements.
<br>We will only discuss the DSV requirements document in detail when
<br>the DPV / DPD requirements document has completed the WG last call.
<p>Denis</blockquote>
</html>



Received: by above.proper.com (8.11.6/8.11.3) id g0EEEq507353 for ietf-pkix-bks; Mon, 14 Jan 2002 06:14:52 -0800 (PST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EEEp307349 for <[e-mail]>; Mon, 14 Jan 2002 06:14:51 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA09874; Mon, 14 Jan 2002 07:14:46 -0700 (MST)
Received: from sun.com (dhcp-edub03-21 [129.156.220.138]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id OAA10546; Mon, 14 Jan 2002 14:14:45 GMT
Message-ID: <[e-mail]>
Date: Mon, 14 Jan 2002 14:14:40 +0000
From: Andreas Sterbenz <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221
X-Accept-Language: en-us
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Gutmann wrote:

> "Housley, Russ" <[e-mail]> writes:
> 
>>This is acceptable, but I prefer one that is more straightforward to implement
>>with web server tools.
> 
> That's probably the best argument for choosing MIME multipart/RFC 2585 rather
> than a SEQUENCE OF, the server shouldn't need to do anything more specialised
> than "fetch value based on key, via HTTP".  Any special-case processing can be
> done by the client.


I don't agree. Complexity should be put in the server, not the client. 
Reason being that there are typically more client than server 
implementations and that clients may have to operate with limited resources.

I do agree that a non-standard SEQUENCE OF is suboptimal, but that 
argument does not apply for a CMS certs only message.

[Did I mention that I do not feel like implementing multipart MIME 
messages this year? ;-) ]

Andreas.



Received: by above.proper.com (8.11.6/8.11.3) id g0EDXjI05166 for ietf-pkix-bks; Mon, 14 Jan 2002 05:33:45 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EDXh305157 for <[e-mail]>; Mon, 14 Jan 2002 05:33:43 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id OAA05373; Mon, 14 Jan 2002 14:33:28 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 14 Jan 2002 14:33:29 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id OAA17936; Mon, 14 Jan 2002 14:33:27 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id OAA03403; Mon, 14 Jan 2002 14:33:27 +0100 (MET)
Date: Mon, 14 Jan 2002 14:33:27 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Cautionary Period
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

It seems possible to me that a server indicates in a response
a date in the past for which the 'ok'-status is definitive,
or example the earliest date in CRLs etc., in order to avoids 
the client to check these details. 

If one wants to make statements about the future, i.e. to
respond to a a 'now' request, the answer would always be,
'so far, ok, but (You have to check later|I'll send another
answer later)'.

I don't think it is necessary for a server to
indicate: "not sure, come back in one day". 

 

   


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EBuqs00430 for ietf-pkix-bks; Mon, 14 Jan 2002 03:56:52 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EBuo300421 for <[e-mail]>; Mon, 14 Jan 2002 03:56:50 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA22820; Mon, 14 Jan 2002 12:57:57 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA19578; Mon, 14 Jan 2002 12:56:18 +0100
Message-ID: <[e-mail]>
Date: Mon, 14 Jan 2002 12:56:23 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Petra Barzin <[e-mail]>
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Petra,

> Denis,
 
> is there also a new version of the document "Delegated Path
> Validation and Delegated Path Discovery Protocols" 

Not at this time. Currently we need first to agree on the DPV / DPD
requirements, then we will discuss the solutions to these requirements.
 
The so-called "Delegated Path Validation and Delegated Path Discovery
Protocols" document could be a candidate to fulfill these requirements. 
It is too early to say and this will only be discussed once the requirements
document is adopted.

> or just a new requirement document?

Correct. It is a new document for both the DPV and DPD requirements.

There is also a companion document for the DSV requirements. 
We will only discuss the DSV requirements document in detail when 
the DPV / DPD requirements document has completed the WG last call.

Denis
 
> - Petra
> 
> > Petra,
> >
> > A new version has been posted last Friday to the web master. It should be
> > published "soon". While waiting for the publication, here is an answer to
> > your comments.
> >
> [e-mail] schrieb:
> 
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> > This draft is a work item of the Public-Key Infrastructure (X.509)
> > Working Group of the IETF.
> >
> >         Title           : Delegated Path Validation and Delegated Path
> > Discovery
> >                           Protocol Requirements (DPV&DPD-REQ)
> >         Author(s)       : D. Pinkas
> >         Filename        : draft-ietf-pkix-dpv-dpd-req-01.txt
> >         Pages           : 14
> >         Date            : 10-Jan-02
> >
> > This document specifies requirements for two main request/response
> > pairs.
> > The first one, called Delegated Path Validation (DPV), can be used to
> > fully delegate a path validation processing to an DPV server,
> > according to a set of rules, called a validation policy.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-01.txt
> >
> > To remove yourself from the IETF Announcement list, send a message to
> > ietf-announce-request with the word unsubscribe in the body of the
> > message.
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> > username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >         "get draft-ietf-pkix-dpv-dpd-req-01.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >         [e-mail].
> > In the body type:
> >         "FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-01.txt".
> >
> > NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before the "FILE"
> >         command.  To decode the response(s), you will need "munpack" or
> >         a MIME-compliant mail reader.  Different MIME-compliant mail
> > readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which have been split
> >         up into multiple messages), so check your local documentation on
> >
> >         how to manipulate these messages.
> >
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> >
> > ------------------------------------------------------------------------


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0EAOxj23628 for ietf-pkix-bks; Mon, 14 Jan 2002 02:24:59 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EAOw323624 for <[e-mail]>; Mon, 14 Jan 2002 02:24:58 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id D9773CD1E for <[e-mail]>; Mon, 14 Jan 2002 11:24:46 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZKPQVG5X; Mon, 14 Jan 2002 11:24:46 +0100
Message-ID: <[e-mail]>
Date: Mon, 14 Jan 2002 11:26:41 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
References: <[e-mail]>
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Denis,
<p>is there also a new version of the document "Delegated Path
<br>Validation and Delegated Path Discovery Protocols" or just
<br>a new requirement document?
<p>- Petra
<blockquote TYPE=CITE>
<pre>Petra,

A new version has been posted last Friday to the web master. It should be
published "soon". While waiting for the publication, here is an answer to
your comments.</pre>
</blockquote>

<p>[e-mail] schrieb:
<blockquote TYPE=CITE>A New Internet-Draft is available from the on-line
Internet-Drafts directories.
<br>This draft is a work item of the Public-Key Infrastructure (X.509)
Working Group of the IETF.
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: Delegated Path Validation and Delegated Path Discovery
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
Protocol Requirements (DPV&amp;DPD-REQ)
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: D. Pinkas
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: draft-ietf-pkix-dpv-dpd-req-01.txt
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: 14
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
: 10-Jan-02
<p>This document specifies requirements for two main request/response
<br>pairs.
<br>The first one, called Delegated Path Validation (DPV), can be used
to
<br>fully delegate a path validation processing to an DPV server,
<br>according to a set of rules, called a validation policy.
<p>A URL for this Internet-Draft is:
<br><a href="http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-01.txt">http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-01.txt</a>
<p>To remove yourself from the IETF Announcement list, send a message to
<br>ietf-announce-request with the word unsubscribe in the body of the
message.
<p>Internet-Drafts are also available by anonymous FTP. Login with the
username
<br>"anonymous" and a password of your e-mail address. After logging in,
<br>type "cd internet-drafts" and then
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "get draft-ietf-pkix-dpv-dpd-req-01.txt".
<p>A list of Internet-Drafts directories can be found in
<br><a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>
<br>or <a href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a>
<p>Internet-Drafts can also be obtained by e-mail.
<p>Send a message to:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [e-mail].
<br>In the body type:
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-01.txt".
<p>NOTE:&nbsp;&nbsp; The mail server at ietf.org can return the document
in
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; MIME-encoded form by using
the "mpack" utility.&nbsp; To use this
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; feature, insert the command
"ENCODING mime" before the "FILE"
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; command.&nbsp; To decode
the response(s), you will need "munpack" or
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; a MIME-compliant mail reader.&nbsp;
Different MIME-compliant mail readers
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; exhibit different behavior,
especially when dealing with
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; "multipart" MIME messages
(i.e. documents which have been split
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; up into multiple messages),
so check your local documentation on
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; how to manipulate these
messages.
<br>&nbsp;
<p>Below is the data which will enable a MIME compliant mail reader
<br>implementation to automatically retrieve the ASCII version of the
<br>Internet-Draft.
<p>&nbsp; ------------------------------------------------------------------------</blockquote>
</html>



Received: by above.proper.com (8.11.6/8.11.3) id g0EAMrc23372 for ietf-pkix-bks; Mon, 14 Jan 2002 02:22:53 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0EAMo323357 for <[e-mail]>; Mon, 14 Jan 2002 02:22:51 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id LAA04574; Mon, 14 Jan 2002 11:22:46 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 14 Jan 2002 11:22:46 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id LAA17375; Mon, 14 Jan 2002 11:22:45 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id LAA03356; Mon, 14 Jan 2002 11:22:44 +0100 (MET)
Date: Mon, 14 Jan 2002 11:22:44 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: draft-ietf-pkix-dpv-dpd-req-01.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> 
> I would prefer to change the second MUST to SHOULD.  If a client is 
> configured to work with one or more organizational DPV servers, then that 
> client must accept the response, regardless of the policy indicated.
> . 

Russ, 

I can live with that but it might be useful to explain
somehow the difference between

    'MUST check whether it it is acceptable' 

and 

    'SHOULD check whether it it is acceptable' 

TIA
Peter


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0E9n6p18699 for ietf-pkix-bks; Mon, 14 Jan 2002 01:49:06 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0E9n4318695 for <[e-mail]>; Mon, 14 Jan 2002 01:49:04 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id KAA04471; Mon, 14 Jan 2002 10:49:02 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Mon, 14 Jan 2002 10:49:03 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id KAA17274; Mon, 14 Jan 2002 10:49:01 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id KAA03347; Mon, 14 Jan 2002 10:49:00 +0100 (MET)
Date: Mon, 14 Jan 2002 10:49:00 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: TSP interop
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

>                                  |            |           |
>                                  |            |           |
> EdelWeb                          |            |           |
> url =                            |            |           |
> http://www.edelweb.fr/           |            |           |
>    cgi-bin/service-tsp           |            |           |
> policy id = 1.2.3.4.5.6          |   SUCCESS  |   n/s     |
>                                  |            |           |
>                                  |            |           |

Does You client test whether the returned policy is the same
as the one that You send ?


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0E9Kar13630 for ietf-pkix-bks; Mon, 14 Jan 2002 01:20:36 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0E9KZ313626 for <[e-mail]>; Mon, 14 Jan 2002 01:20:35 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA32096; Mon, 14 Jan 2002 10:21:37 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA15026; Mon, 14 Jan 2002 10:19:58 +0100
Message-ID: <[e-mail]>
Date: Mon, 14 Jan 2002 10:20:06 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: "Housley, Russ" <[e-mail]>
CC: Alfonso De Gregorio <[e-mail]>, [e-mail]
Subject: Re: Cautionary Period
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ,

(text deleted) 

> There are many application contexts where the concept of a cautionary
> period is irrelevant.  For example: TLS.  The client will either accept the
> server's certificate for establishment of the TLS-protected session, or it
> will reject it.

True, but the reverse sentence is also true: "There are application contexts
where the concept of a cautionary period is relevant".
 
> So, when does it matter?  Non-repudiation of a high-value transaction. In
> such a context, it is very important to know when a transaction take
> place.  The PKIX working group has done a lot of work on TSP to fill this
> requirement.

Non-repudiation is not the single security service where a cautionary period
is relevant. It is also relevant for data origin authentication with
integrity.

> Let's assume that the constrained client wants to validate such a
> transaction.  The TSP timestamp provides the date/time of interest.  It can
> ask the DPV server if the signer's path was valid at the time that the
> signature was generated.

Since it is not possible to know when the signature was generated, 
an upper limit of that time is use instead: the date of the time-stamp
applied over the digital signature or the date included in an audit record
See the DPV requirements document at:
http://www.imc.org/draft-ietf-pkix-dsv-req. 

The correct sentence is thus: "It can ask the DPV server if the signer's
path was valid at the time that the time-stamp was applied over the digital
signature".

> In my view, the cautionary period only impacts the signature on the
> transaction.  

Since a cautionary period cannot be applied in the context of a
confidentiality service or an authentication service, the right wording 
would be : "the cautionary period only impacts the use of a certificate 
in the context of a non-repudiation service or a
data-origin-authentication-with-integrity service".

> The DPV server does not validate this signature.  Has
> adequate time passed since the signature was applied to ensure that recent
> compromise of the end-entity private key has been reported?  I submit that
> this a signature validation question, not a certification path validation
> question.

The basic question is how clients can take advantage of a DPV server in the
case where a cautionary period exists and in the context of a
non-repudiation service or a data-origin-authentication-with-integrity
service ?

There are two options whether :

1) the cautionary period has to be known by the client 
   (which is what your arguments mandate).

2) the cautionary period is known by the server 
   (which is what my arguments mandate).

In the context of a non repudiation service, clients must necessarilly know
either the date of the time-stamp or the date of the audit record. 

In the context of a data-origin-authentication-with-integrity service,
clients must necessarilly know the purported date of the digital signature.

With option 1, clients must locally manage the cautionary period for each
supported policy and locally compare it either with the date of the
time-stamp or the date of the audit record, or the the purported date of the
digital signature. This makes management actions more difficult 
(and makes also thin clients fater) since if that period changes, 
local tables need to be updated in each client application.

With option 2, clients do not need to manage that information locally since
it is part of the policy supported by the server. They simply need to send 
to the server either the date of the time-stamp or the date of the audit
record, or the purported date of the digital signature.

The goal of these protocols is to delegate as much as possible all the 
validation conditions to a server. The cautionary period does not
make an exception.

Denis


> Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0E96b912335 for ietf-pkix-bks; Mon, 14 Jan 2002 01:06:37 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0E96a312327 for <[e-mail]>; Mon, 14 Jan 2002 01:06:36 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id KAA21608; Mon, 14 Jan 2002 10:07:41 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id KAA16170; Mon, 14 Jan 2002 10:06:01 +0100
Message-ID: <[e-mail]>
Date: Mon, 14 Jan 2002 10:06:09 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Ambarish Malpani <[e-mail]>
CC: [e-mail]
Subject: Re: Cautionary Period
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> Hi Alfonso, Denis,

>     I disagree with the need for cautionary period in the DPV
> protocol. Here is my reasoning:
 
> The rationale for cautionary period, is the argument that a CRL/
> OCSP response is necessarily out of date, because it takes some
> time to discover, report and process a revocation request. This
> means that a certificate should not be trusted for some time
> after you have received it - to ensure that the revocation
> information is current.
 
> In most practical systems that I have seen, people are more than
> willing to accept the risk of using a certificate if it is not.

Most people are "accepting the risk", just because most of them ignore 
the risk.

I do agree that it is not always possible to apply a cautionnary
period. In such a case, a risk is necessarilly taken. However, there are
cases where, it is possible to lower the risk. This is possible for two
security services:

- non repudiation and
- data origin authentication with integrity.

For these cases, the support of a cautionary period allows to lower the
risk.

> currently revoked - most people don't want to wait till the next
> CRL is published, or wait till a CA has been given enough of a
> margin to be able to process revocation requests. For example, in
> the credit card world, we use our cards and get our mechandise
> immediately, even though it would take some time to report the
> loss of a credit card.
> 
> I think adding cautionary period to this protocol would just add
> unnecessary complexity.

This complexity argument does not stand. It is the reverse: simplicity !

Clients just ignore whether the policy includes or not a cautionary period.
This is simplicity. 

There is no obligation for a policy to include a cautionary period, this is
only one possibility.

Clients need to be able to process an additional status. If they do not want
to take advantage of that status, they can even consider it as equivalent to
"not valid". This is certainly not adding complexity.

Regards,

Denis

> Regards,
> Ambarish
> 
> ---------------------------------------------------------------------
> Ambarish Malpani
> Architect                                                650.567.5457
> ValiCert, Inc.                                  [e-mail]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> > -----Original Message-----
> > From: Alfonso De Gregorio [mailto:[e-mail]]
> > Sent: Friday, January 11, 2002 9:06 AM
> > To: [e-mail]; Housley, Russ
> > Cc: [e-mail]
> > Subject: Re: Cautionary Period
> >
> >
> >
> > Hi Russ, hi Denis, hi Everyone,
> >
> > > I encourage everyone to read DPV and DPD requirements
> > document, and post
> > > their view on this subject.  I believe that the document
> > expresses Denis'
> > > view on the issue.  My view is that cautionary period is a not a
> > > requirement for DPV or DPD.  However, cautionary periods
> > might be used as
> > > part of an application-specific risk mitigation mechanism
> > when trying to
> > > determine the validity of a particular signature.  For
> > example, waiting for
> > > cautionary period before considering a signature to be valid on a
> > > high-value electronic contract may be prudent.  Therefore,
> > cautionary
> > > periods might be supported in DSV (delegated signature validation).
> >
> > In order to observe the cautionary-period-delay at application level
> > the execution environment must be current-time-aware.
> > DPV target execution environments are assumed to be constrained, at
> > least by a processing and/or communication point of view.
> > Constrained execution environments, such as telephones and PDA,
> > are not necessarily current-time-aware (or have time-sources not
> > necessarily trusted).
> > Delegating a path validation to a TTP allows execution environments
> > to be unaware of the current-time.
> > So, IMHO, cautionary periods should be a requirement for DPV.
> >
> > alfonso
> >


Received: by above.proper.com (8.11.6/8.11.3) id g0DDc7601333 for ietf-pkix-bks; Sun, 13 Jan 2002 05:38:07 -0800 (PST)
Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0DDc5301324 for <[e-mail]>; Sun, 13 Jan 2002 05:38:05 -0800 (PST)
Received: from fwd02.sul.t-online.de  by mailout02.sul.t-online.com with smtp  id 16Pkpa-0004Cq-04; Sun, 13 Jan 2002 14:37:50 +0100
Received: from junker.stroeder.com (520010731148-0001@[62.224.170.110]) by fmrl02.sul.t-online.com with esmtp id 16PkpY-0h0ECmC; Sun, 13 Jan 2002 14:37:48 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 4722E157117 for <[e-mail]>; Sun, 13 Jan 2002 14:36:48 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sun, 13 Jan 2002 14:36:47 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Tomas Gustavsson wrote:
> 
> > Hmm, I think the cert store implementation itself should deal with
> > these kind of index optimization issues. I vote for just submitting
> > search values as is and let the certificate store backend do the bit
> > reducing at the server-side if necessary at all. That makes client
> > implementations simpler and leaves up decisions about how to deal
> > with possible collisions to the server-side cert store
> > implementation.
> 
> I would agree with this. It simplifies things to use 'real'
> values and let the backend/middleware do the optimization.

While we're at it: It could also be useful to simply use a string
hex-encoding of e.g. SHA-1 fingerprint as search value instead
base64-encoding the binary SHA-1 value. I'd also like to suggest
that a cert store implementation simply strips colons or spaces used
as hex-byte separator to determine the search value. This would
enable the cert store to search for values which the user can
cut&paste from another software's output. (Off course the search
value is assumed to be URL-encoded as already stated in the draft.)

Example of typically used representations of SHA-1 fingerprint used
as search value treated as equal:

C1:50:FF:EF:93:5A:FA:8C:15:49:AE:74:C1:A0:8E:FA:CC:10:99:1F

C150 FFEF 935A FA8C 1549 AE74 C1A0 8EFA CC10 991F

C150FFEF935AFA8C1549AE74C1A08EFACC10991F

c150ffef935afa8c1549ae74c1a08efacc10991f

This can all be implemented very easily with typical programming
languages used for web apps today.

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0CJnD408961 for ietf-pkix-bks; Sat, 12 Jan 2002 11:49:13 -0800 (PST)
Received: from [165.227.249.20] (165-227-249-20.client.dsl.net [165.227.249.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0CJn9308957; Sat, 12 Jan 2002 11:49:10 -0800 (PST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05101202b866439cc698@[165.227.249.20]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Sat, 12 Jan 2002 11:49:06 -0800
To: "Housley, Russ" <[e-mail]>, [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: Cautionary Period
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 3:10 PM -0500 1/10/02, Housley, Russ wrote:
>My view is that cautionary period is a not a requirement for DPV or 
>DPD.  ...  Therefore, cautionary periods might be supported in DSV 
>(delegated signature validation).

Agree.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by above.proper.com (8.11.6/8.11.3) id g0CC9ns29922 for ietf-pkix-bks; Sat, 12 Jan 2002 04:09:49 -0800 (PST)
Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0CC9l329918 for <[e-mail]>; Sat, 12 Jan 2002 04:09:47 -0800 (PST)
Received: from fwd07.sul.t-online.de  by mailout09.sul.t-online.com with smtp  id 16PMyg-0006fN-00; Sat, 12 Jan 2002 13:09:38 +0100
Received: from junker.stroeder.com (520010731148-0001@[217.1.20.98]) by fmrl07.sul.t-online.com with esmtp id 16PMyQ-15oTnEC; Sat, 12 Jan 2002 13:09:22 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id E32451572B5 for <[e-mail]>; Sat, 12 Jan 2002 13:09:24 +0100 (CET)
Message-ID: <[e-mail]>
Date: Sat, 12 Jan 2002 13:09:24 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Gutmann wrote:
> 
> "Housley, Russ" <[e-mail]> writes:
> 
> >This is acceptable, but I prefer one that is more straightforward to implement
> >with web server tools.
> 
> That's probably the best argument for choosing MIME multipart/RFC 2585 rather
> than a SEQUENCE OF, the server shouldn't need to do anything more specialised
> than "fetch value based on key, via HTTP".  Any special-case processing can be
> done by the client.

+1

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0C6dGk24128 for ietf-pkix-bks; Fri, 11 Jan 2002 22:39:16 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0C6dA324121 for <[e-mail]>; Fri, 11 Jan 2002 22:39:14 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id TAA23608 for <[e-mail]>; Sat, 12 Jan 2002 19:39:09 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id TAA232072 for [e-mail]; Sat, 12 Jan 2002 19:39:09 +1300 (NZDT) (sender [e-mail])
Date: Sat, 12 Jan 2002 19:39:09 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I wrote:

>That's probably the best argument for choosing MIME multipart/RFC 2585 rather
>than a SEQUENCE OF, the server shouldn't need to do anything more specialised
>than "fetch value based on key, via HTTP".  Any special-case processing can be
>done by the client.

There's another reason which I just realised while I was adding the IANA
considerations: Requiring a DER-encoded response is rather ugly if you're
processing something which isn't a DER-encoded certificate.  While I shall
reserve my opinion on the value of (say) XML certificates, I wouldn't want to
implicitly exclude them through a particular data-encoding requirement.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g0C5DWJ22288 for ietf-pkix-bks; Fri, 11 Jan 2002 21:13:32 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0C5DT322282 for <[e-mail]>; Fri, 11 Jan 2002 21:13:30 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id SAA21685; Sat, 12 Jan 2002 18:13:18 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA230488; Sat, 12 Jan 2002 18:13:17 +1300 (NZDT) (sender [e-mail])
Date: Sat, 12 Jan 2002 18:13:17 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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

>This is acceptable, but I prefer one that is more straightforward to implement
>with web server tools.

That's probably the best argument for choosing MIME multipart/RFC 2585 rather
than a SEQUENCE OF, the server shouldn't need to do anything more specialised
than "fetch value based on key, via HTTP".  Any special-case processing can be
done by the client.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g0C4eDw21478 for ietf-pkix-bks; Fri, 11 Jan 2002 20:40:13 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0C4e8321473 for <[e-mail]>; Fri, 11 Jan 2002 20:40:11 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id RAA20850; Sat, 12 Jan 2002 17:39:49 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA229729; Sat, 12 Jan 2002 17:39:45 +1300 (NZDT) (sender [e-mail])
Date: Sat, 12 Jan 2002 17:39:45 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Michael StrM-vder <[e-mail]> writes:

>Hmm, I think the cert store implementation itself should deal with these kind
>of index optimization issues. I vote for just submitting search values as is
>and let the certificate store backend do the bit reducing at the server-side
>if necessary at all. That makes client implementations simpler and leaves up
>decisions about how to deal with possible collisions to the server-side cert
>store implementation.

Fair enough, if no-one has any objections to the full 160 bits I'll leave it at
that.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g0C4Lma21184 for ietf-pkix-bks; Fri, 11 Jan 2002 20:21:48 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0C4Lk321179 for <[e-mail]>; Fri, 11 Jan 2002 20:21:46 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id RAA20053; Sat, 12 Jan 2002 17:20:17 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA229582; Sat, 12 Jan 2002 17:20:15 +1300 (NZDT) (sender [e-mail])
Date: Sat, 12 Jan 2002 17:20:15 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re:  TSP interop
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Joe Morgan <[e-mail]> writes:

>policy id = 1.3.6.1.4.1.3029.56.36.54

In case anyone's wondering what that value is, that's the 'snooze policy,
"Anything that arrives, we sign" (based on the Fido 'snooze editorial policy,
"Anything that arrives, we print").

>tsa.cryptoapps.com

It'll be back after the weekend when I rebuild it on the new machine.  Anyone
can also get the full code (client + server) from
http://www.cs.auckland.ac.nz/~pgut001/cryptlib/ if they want it.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0C2Rip19293 for ietf-pkix-bks; Fri, 11 Jan 2002 18:27:44 -0800 (PST)
Received: from peacock.verisign.com (peacock.verisign.com [65.205.251.73]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0C2Rh319289 for <[e-mail]>; Fri, 11 Jan 2002 18:27:43 -0800 (PST)
Received: from vhqpostal-gw2.verisign.com (verisign.com [65.205.251.56]) by peacock.verisign.com (8.11.3/BCH1.7.5) with ESMTP id g0C2OMR08817; Fri, 11 Jan 2002 18:24:22 -0800 (PST)
Received: by vhqpostal-gw2.verisign.com with Internet Mail Service (5.5.2653.19) id <Y2YD8TR3>; Fri, 11 Jan 2002 18:28:33 -0800
Message-ID: <[e-mail]>
From: "Deacon, Alex" <[e-mail]>
To: "'Housley, Russ'" <[e-mail]>, Alfonso De Gregorio <[e-mail]>
Cc: [e-mail]
Subject: RE: Cautionary Period
Date: Fri, 11 Jan 2002 18:26:44 -0800
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Right, it seems pretty clear to me from the paragraph in section 4.1 copied
below that the cautionary period only impacts the status of the signature
that was created by the certificate at some point in the recent past....not
the status of the certificate itself.  So I agree that this is a DSV
concept, not a DPV concept.

"When the public key within the certificate is used to verify some usage
from the recent past, it is possible to apply a cautionary period to further
reduce the risk. In such a case, the policy MAY indicate a minimum delay to
be observed between the time T in the past, i.e. when the use of the private
key took was supposed to take place, and the time of the current
verification." 

BTW, I think the word "took" in that last sentence is stray and should be
removed.

Regards,
Alex


> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Friday, January 11, 2002 11:10 AM
> To: Alfonso De Gregorio
> Cc: [e-mail]
> Subject: Re: Cautionary Period
> 
> 
> 
> Alfonso:
> 
> > > I encourage everyone to read DPV and DPD requirements 
> document, and post
> > > their view on this subject.  I believe that the document expresses
> Denis'
> > > view on the issue.  My view is that cautionary period is a not a
> > > requirement for DPV or DPD.  However, cautionary periods 
> might be used
> as
> > > part of an application-specific risk mitigation mechanism 
> when trying to
> > > determine the validity of a particular signature.  For 
> example, waiting 
> > for
> > > cautionary period before considering a signature to be valid on a
> > > high-value electronic contract may be prudent.  
> Therefore, cautionary
> > > periods might be supported in DSV (delegated signature 
> validation).
> >
> >In order to observe the cautionary-period-delay at application level
> >the execution environment must be current-time-aware.
> >DPV target execution environments are assumed to be constrained, at
> >least by a processing and/or communication point of view.
> >Constrained execution environments, such as telephones and PDA,
> >are not necessarily current-time-aware (or have time-sources not
> >necessarily trusted).
> >Delegating a path validation to a TTP allows execution environments
> >to be unaware of the current-time.
> >So, IMHO, cautionary periods should be a requirement for DPV.
> 
> There are many application contexts where the concept of a cautionary 
> period is irrelevant.  For example: TLS.  The client will 
> either accept the 
> server's certificate for establishment of the TLS-protected 
> session, or it 
> will reject it.
> 
> So, when does it matter?  Non-repudiation of a high-value 
> transaction. In 
> such a context, it is very important to know when a transaction take 
> place.  The PKIX working group has done a lot of work on TSP 
> to fill this 
> requirement.
> 
> Let's assume that the constrained client wants to validate such a 
> transaction.  The TSP timestamp provides the date/time of 
> interest.  It can 
> ask the DPV server if the signer's path was valid at the time 
> that the 
> signature was generated.
> 
> In my view, the cautionary period only impacts the signature on the 
> transaction.  The DPV server does not validate this signature.  Has 
> adequate time passed since the signature was applied to 
> ensure that recent 
> compromise of the end-entity private key has been reported?  
> I submit that 
> this a signature validation question, not a certification 
> path validation 
> question.
> 
> Russ
> 
> 
> 
> 
> ==============================================================
> ==============
> ================
> This e-mail, its content and any files transmitted with it 
> are intended
> solely for the addressee(s) and are PRIVILEGED and 
> CONFIDENTIAL.  Access by any other party is unauthorized 
> without the express
> prior written permission of the sender.  If 
> you have received this e-mail in error you may not copy, 
> disclose to any
> third party or use the contents, attachments or 
> information in any way, Please delete all copies of the e-mail and the
> attachment(s), if any and notify the sender. 
> Thank You.
> ==============================================================
> ==============
> ================
> 


Received: by above.proper.com (8.11.6/8.11.3) id g0BMWhp10468 for ietf-pkix-bks; Fri, 11 Jan 2002 14:32:43 -0800 (PST)
Received: from geos.coastside.net (mail.coastside.net [207.213.212.6]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BMWg310464 for <[e-mail]>; Fri, 11 Jan 2002 14:32:42 -0800 (PST)
Received: from laptop (dsl-63-194-153-52.coastside.net [63.194.153.52]) by geos.coastside.net (8.11.0/8.11.3) with SMTP id g0BMWhL07962 for <[e-mail]>; Fri, 11 Jan 2002 14:32:44 -0800 (PST)
From: "Michael Myers" <[e-mail]>
To: <[e-mail]>
Subject: RE: Cautionary Period
Date: Fri, 11 Jan 2002 14:30:33 -0800
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <[e-mail]>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I agree with Russ.  Simpler is better.  Consider IKE vs. JFK.

Mike

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]On Behalf Of 
> Housley, Russ
> Sent: Thursday, January 10, 2002 12:10 PM
> To: [e-mail]
> Subject: Cautionary Period
> 
> 
> 
> The updated Delegated Path Validation (DPV) and 
> Delegated Path Discovery 
> (DPD) Protocol Requirements document 
> <draft-ietf-pkix-dpv-dpd-req-01.txt> 
> was recently posted.  You may notice that I am a 
> co-author with Denis on 
> this document.  Denis invited me to be a co-author 
> because I submitted many 
> comments.  There were many, many editorial ones.  
> There were also technical 
> ones.  Denis and I were able to resolve the vast bulk 
> of the technical 
> issues; however, we have not been able to reach a 
> compromise on one open 
> issue.  That issue is the subject of this note.
> 
> I encourage everyone to read DPV and DPD requirements 
> document, and post 
> their view on this subject.  I believe that the 
> document expresses Denis' 
> view on the issue.  My view is that cautionary period 
> is a not a 
> requirement for DPV or DPD.  However, cautionary 
> periods might be used as 
> part of an application-specific risk mitigation 
> mechanism when trying to 
> determine the validity of a particular signature.  
> For example, waiting for 
> cautionary period before considering a signature to 
> be valid on a 
> high-value electronic contract may be prudent.  
> Therefore, cautionary 
> periods might be supported in DSV (delegated 
> signature validation).
> 
> Since Denis and I were unable to resolve this issue 
> in an author-to-author 
> dialogue, I am bring this issue to the whole mail 
> list.  As far as I know, 
> this is the only open issue with the DPV and DPD 
> Protocol Requirements 
> document.  I hope that this issue can be quickly 
> resolved so that we can 
> get on with the protocol development.
> 
> Russ
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BJlJh05807 for ietf-pkix-bks; Fri, 11 Jan 2002 11:47:19 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0BJlH305802 for <[e-mail]>; Fri, 11 Jan 2002 11:47:17 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Jan 2002 19:46:56 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA05544 for <[e-mail]>; Fri, 11 Jan 2002 14:47:19 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g0BJlHR24981 for <[e-mail]>; Fri, 11 Jan 2002 14:47:17 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <CJPHZCM8>; Fri, 11 Jan 2002 14:47:15 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.77]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPHZCMV; Fri, 11 Jan 2002 14:47:02 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
Subject: Re: draft-ietf-pkix-dpv-dpd-req-01.txt
Date: Fri, 11 Jan 2002 14:45:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter:

>Another one:
>
> > If the DPV request does not specify a validation policy, the server
> > response MUST indicate the one that was used. In such a case, the
> > client must verify that the one selected by the server is appropriate.
>
>I propose:
>
>"A server response MUST indicate the validation policy that has been used,
>  and a client MUST verify that it is acceptable."

I would prefer to change the second MUST to SHOULD.  If a client is 
configured to work with one or more organizational DPV servers, then that 
client must accept the response, regardless of the policy indicated.

Russ






============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BJlI705804 for ietf-pkix-bks; Fri, 11 Jan 2002 11:47:18 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0BJlG305791 for <[e-mail]>; Fri, 11 Jan 2002 11:47:16 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Jan 2002 19:46:55 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA05536 for <[e-mail]>; Fri, 11 Jan 2002 14:47:17 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g0BJlGR24971 for <[e-mail]>; Fri, 11 Jan 2002 14:47:16 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <CJPHZCM7>; Fri, 11 Jan 2002 14:47:15 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.77]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPHZCMT; Fri, 11 Jan 2002 14:47:00 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: Peter Sylvester <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Date: Fri, 11 Jan 2002 14:41:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter:

> > I would prefer to maintain alignment with RFC 2585.  The use of 
> SEQUENCE OF
> > would be fewer bit on the wire, but it would also require the 
> specification
> > of another MIME type for the transfer of certificates.
>
>And what about using a cert-only cms message?

This is acceptable, but I prefer one that is more straightforward to 
implement with web server tools.

Russ




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BJCNc04697 for ietf-pkix-bks; Fri, 11 Jan 2002 11:12:23 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0BJCL304693 for <[e-mail]>; Fri, 11 Jan 2002 11:12:21 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Jan 2002 19:12:00 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA02388 for <[e-mail]>; Fri, 11 Jan 2002 14:12:23 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g0BJCLe21363 for <[e-mail]>; Fri, 11 Jan 2002 14:12:21 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <CJPHZBWZ>; Fri, 11 Jan 2002 14:12:20 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.67]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPHZBWT; Fri, 11 Jan 2002 14:12:05 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: Alfonso De Gregorio <[e-mail]>
Cc: [e-mail]
Subject: Re: Cautionary Period
Date: Fri, 11 Jan 2002 14:09:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Alfonso:

> > I encourage everyone to read DPV and DPD requirements document, and post
> > their view on this subject.  I believe that the document expresses
Denis'
> > view on the issue.  My view is that cautionary period is a not a
> > requirement for DPV or DPD.  However, cautionary periods might be used
as
> > part of an application-specific risk mitigation mechanism when trying to
> > determine the validity of a particular signature.  For example, waiting 
> for
> > cautionary period before considering a signature to be valid on a
> > high-value electronic contract may be prudent.  Therefore, cautionary
> > periods might be supported in DSV (delegated signature validation).
>
>In order to observe the cautionary-period-delay at application level
>the execution environment must be current-time-aware.
>DPV target execution environments are assumed to be constrained, at
>least by a processing and/or communication point of view.
>Constrained execution environments, such as telephones and PDA,
>are not necessarily current-time-aware (or have time-sources not
>necessarily trusted).
>Delegating a path validation to a TTP allows execution environments
>to be unaware of the current-time.
>So, IMHO, cautionary periods should be a requirement for DPV.

There are many application contexts where the concept of a cautionary 
period is irrelevant.  For example: TLS.  The client will either accept the 
server's certificate for establishment of the TLS-protected session, or it 
will reject it.

So, when does it matter?  Non-repudiation of a high-value transaction. In 
such a context, it is very important to know when a transaction take 
place.  The PKIX working group has done a lot of work on TSP to fill this 
requirement.

Let's assume that the constrained client wants to validate such a 
transaction.  The TSP timestamp provides the date/time of interest.  It can 
ask the DPV server if the signer's path was valid at the time that the 
signature was generated.

In my view, the cautionary period only impacts the signature on the 
transaction.  The DPV server does not validate this signature.  Has 
adequate time passed since the signature was applied to ensure that recent 
compromise of the end-entity private key has been reported?  I submit that 
this a signature validation question, not a certification path validation 
question.

Russ




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BIsWH04115 for ietf-pkix-bks; Fri, 11 Jan 2002 10:54:32 -0800 (PST)
Received: from phaostec.temp.veriohosting.com (phaostec.temp.veriohosting.com [161.58.151.210]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BIsU304111 for <[e-mail]>; Fri, 11 Jan 2002 10:54:30 -0800 (PST)
Received: from phaos.com ([198.78.132.60]) by phaostec.temp.veriohosting.com (8.11.6) id g0BIsWL47430 for <[e-mail]>; Fri, 11 Jan 2002 11:54:32 -0700 (MST)
Message-ID: <[e-mail]>
Date: Fri, 11 Jan 2002 13:52:54 -0500
From: Joe Morgan <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en-GB
MIME-Version: 1.0
To: [e-mail]
Subject: TSP interop
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms0628B9E204A178C2FD023D44"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a cryptographically signed message in MIME format.

--------------ms0628B9E204A178C2FD023D44
Content-Type: multipart/alternative;
 boundary="------------D7578175CBB0B815C0811901"


--------------D7578175CBB0B815C0811901
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello all,

Below are the results the interoperability tests we've
conducted with our new TSP implementation against some of the test TSAs
mentioned previously on this mailing list.

Cheers,
Joe

--
Joe Morgan
Senior Software Engineer
Phaos Technology Corp.
http://www.phaos.com/

SERVER                           |   HTTP     |   TCP     |
                                 |            |           |
                                 |            |           |
Peter Gutmann                    |            |           |
host = tsa.cryptoapps.com        |            |           |
port = 3318                      |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |   n/a     |
                                 |            |           |
                                 |            |           |
IAIK                             |            |           |
host = bais.iaik.at              |            |           |
port = 318                       |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |   SUCCESS |
                                 |            |           |
                                 |            |           |
Datum                            |            |           |
host = 64.241.183.87             |            |           |
port = 318                       |            |           |
policy id =                      |            |           |
1.3.6.1.4.1.3029.56.36.54        |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
SIA                              |            |           |
host = 193.203.230.166           |            |           |
port = 318                       |            |           |
policy id = 1.3.135.1.2.0        |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
EdelWeb                          |            |           |
url =                            |            |           |
http://www.edelweb.fr/           |            |           |
   cgi-bin/service-tsp           |            |           |
policy id = 1.2.3.4.5.6          |   SUCCESS  |   n/s     |
                                 |            |           |
                                 |            |           |
CNSG                             |            |           |
host = tsp.test.polito.it        |            |           |
port = 318                       |            |           |
policy id = 0.4.0.1.1.1          |    n/s     |  SUCCESS  |
                                 |            |           |
                                 |            |           |
C&A                              |            |           |
host = 195.223.2.6               |            |           |
port = 3318                      |            |           |
policy id = 0.4.0.1.1.1          |            |           |
url =                            |            |           |
http://195.223.2.6:8080/         |            |           |
   timestamp                     |   SUCCESS  |  SUCCESS  |



n/s = Not supported.
n/a = Not available.




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

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>Hello all,</tt><tt></tt>
<p><tt>Below are the results the interoperability tests we've</tt>
<br><tt>conducted with our new TSP implementation against some of the test
TSAs</tt>
<br><tt>mentioned previously on this mailing list.</tt><tt></tt>
<p><tt>Cheers,</tt>
<br><tt>Joe</tt><tt></tt>
<p><tt>--</tt>
<br><tt>Joe Morgan</tt>
<br><tt>Senior Software Engineer</tt>
<br><tt>Phaos Technology Corp.</tt>
<br><tt><A HREF="http://www.phaos.com/">http://www.phaos.com/</A></tt><tt></tt>
<p><tt>SERVER&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; HTTP&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; TCP&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>Peter Gutmann&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>host = tsa.cryptoapps.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>port = 3318&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id =&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>1.3.6.1.4.1.3029.56.36.54&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; n/s&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; n/a&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>IAIK&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>host = bais.iaik.at&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>port = 318&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id =&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>1.3.6.1.4.1.3029.56.36.54&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; n/s&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp; SUCCESS |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>Datum&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>host = 64.241.183.87&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>port = 318&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id =&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>1.3.6.1.4.1.3029.56.36.54&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; n/s&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; SUCCESS&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>SIA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>host = 193.203.230.166&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>port = 318&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id = 1.3.135.1.2.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; n/s&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; SUCCESS&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>EdelWeb&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>url =&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt><A HREF="http://www.edelweb.fr/">http://www.edelweb.fr/</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp; cgi-bin/service-tsp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id = 1.2.3.4.5.6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; SUCCESS&nbsp; |&nbsp;&nbsp; n/s&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>CNSG&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>host = tsp.test.polito.it&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>port = 318&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id = 0.4.0.1.1.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; n/s&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp; SUCCESS&nbsp; |</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>C&amp;A&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>host = 195.223.2.6&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>port = 3318&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>policy id = 0.4.0.1.1.1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>url =&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt><A HREF="http://195.223.2.6:8080/">http://195.223.2.6:8080/</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>&nbsp;&nbsp; timestamp&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; SUCCESS&nbsp; |&nbsp; SUCCESS&nbsp; |</tt>
<br><tt>&nbsp;</tt>
<br><tt>&nbsp;</tt><tt></tt>
<p><tt>n/s = Not supported.</tt>
<br><tt>n/a = Not available.</tt>
<br><tt>&nbsp;</tt>
<br><tt></tt>&nbsp;
<br><tt></tt>&nbsp;</html>

--------------D7578175CBB0B815C0811901--

--------------ms0628B9E204A178C2FD023D44
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIJRAYJKoZIhvcNAQcCoIIJNTCCCTECAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BvIwggbuMIIF1qADAgECAhEA0B5HMgAAAnwAAAAnAAAeGDANBgkqhkiG9w0BAQUFADCBqTEL
MAkGA1UEBhMCdXMxDTALBgNVBAgTBFV0YWgxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MSQw
IgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xETAPBgNVBAsTCERTVENBIFgx
MRYwFAYDVQQDEw1EU1QgUm9vdENBIFgxMSEwHwYJKoZIhvcNAQkBFhJjYUBkaWdzaWd0cnVz
dC5jb20wHhcNMDEwMjA1MjAyOTMyWhcNMDIwMjA1MjAyOTMyWjCByzELMAkGA1UEBhMCVVMx
ETAPBgNVBAgTCE5ldyBZb3JrMREwDwYDVQQHEwhOZXcgWW9yazEZMBcGA1UEChMQUEhBT1Mg
VEVDSE5PTE9HWTEZMBcGA1UECxMQUEhBT1MgVEVDSE5PTE9HWTEYMBYGA1UEAxMPSm9zZXBo
IE0gTW9yZ2FuMSAwHgYJKoZIhvcNAQkBFhFqbW9yZ2FuQHBoYW9zLmNvbTEkMCIGCgmSJomT
8ixkAQETFEQwMUU0NzMyLjI3Qy4yNy4xRTE2MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKB
gQCvgpFidXcUh+hajHg9EP8GlSxB6MOwOKbRxcdaBdZlkPvDCcezbRx8rS/BIQuI4TJfZgY1
Kh4TV1XLi0x2GWOrEnF6U6+BbjCqI1gDxct4lyjIkbegqOyH/RqYQu0LyqLJhXRYtye5O/uV
26PpUkaKjw+SO562JkmVTtMMBR8c1wIDAQABo4IDbzCCA2swggGiBgNVHSAEggGZMIIBlTCC
AZEGCWCGSAGG+S8AADCCAYIwUgYIKwYBBQUHAgEWRmh0dHBzOi8vc2VjdXJlLmRpZ3NpZ3Ry
dXN0LmNvbS9kb2NzL3BvbGljaWVzL3RzL2RzdC1jcHMtdjE5OTkwODI0Lmh0bWwwggEqBggr
BgEFBQcCAjCCARwaggEYVGhlIHZhbHVlIG9mIHRoaXMgVHJ1c3QgSUQgQ2VydGlmaWNhdGUs
IGl0cyByZWxpYW5jZSBsaW1pdCwgYW5kIHRoZSBsaWFiaWxpdHkgb2YgdGhlIGlzc3VlciBh
cmUgZXN0YWJsaXNoZWQgYnkgY29udHJhY3QgYW5kIGxpbWl0ZWQgYnkgVXRhaCBsYXcuICBU
byByZWFzb25hYmx5IHJlbHkgb24gdGhpcyBjZXJ0aWZpY2F0ZSwgeW91IG11c3QgYmUgYW4g
YXV0aG9yaXplZCByZWx5aW5nIHBhcnR5IGFuZCB2YWxpZGF0ZSBpdCBhdDogIGh0dHBzOi8v
c2VjdXJlLmRpZ3NpZ3RydXN0LmNvbS90czB8BgNVHR8EdTBzMHGgb6BthmtsZGFwOi8vbGRh
cC5kaWdzaWd0cnVzdC5jb20vb3U9RFNUQ0EgWDEsbz1EaWdpdGFsIFNpZ25hdHVyZSBUcnVz
dCBDby4sYz1VUz9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTCCASsGCWCGSAGG
+EIBDQSCARwWggEYVGhlIHZhbHVlIG9mIHRoaXMgVHJ1c3QgSUQgQ2VydGlmaWNhdGUsIGl0
cyByZWxpYW5jZSBsaW1pdCwgYW5kIHRoZSBsaWFiaWxpdHkgb2YgdGhlIGlzc3VlciBhcmUg
ZXN0YWJsaXNoZWQgYnkgY29udHJhY3QgYW5kIGxpbWl0ZWQgYnkgVXRhaCBsYXcuICBUbyBy
ZWFzb25hYmx5IHJlbHkgb24gdGhpcyBjZXJ0aWZpY2F0ZSwgeW91IG11c3QgYmUgYW4gYXV0
aG9yaXplZCByZWx5aW5nIHBhcnR5IGFuZCB2YWxpZGF0ZSBpdCBhdDogIGh0dHBzOi8vc2Vj
dXJlLmRpZ3NpZ3RydXN0LmNvbS90czAJBgNVHRMEAjAAMAsGA1UdDwQEAwID+DANBgkqhkiG
9w0BAQUFAAOCAQEAHb1tvm6pDfxHPE80Ebv20BEO5e0/+8BUtxe9HgMhpkemGXmsH5ZY7F7w
73DT8vsCi6UcAOTFxnPNm0cpT+PuiNPKLbrTcktow7wLFUcJzHpPREtPCuDtCsDOrdjzW9Xc
HZx3FZyoMOU2JOn8UB4YgPwKUGImD+is7lxpBaB9uulJKPedzmQeMkWb6vn29/2KQR8iFL36
F8ktjl1+Z1Vm+A5jwhDC6msLRNtXC6wisjiDJnRT4vrf74o74GmNYcuANTa+QJpLdvpEAUhE
LEpNQNIfW73C/At8dGy2wVUFdr/kFqFlJ8/dcShOQSMP92XFB759aHG21Z801rXCVy3atjGC
AhowggIWAgEBMIG/MIGpMQswCQYDVQQGEwJ1czENMAsGA1UECBMEVXRhaDEXMBUGA1UEBxMO
U2FsdCBMYWtlIENpdHkxJDAiBgNVBAoTG0RpZ2l0YWwgU2lnbmF0dXJlIFRydXN0IENvLjER
MA8GA1UECxMIRFNUQ0EgWDExFjAUBgNVBAMTDURTVCBSb290Q0EgWDExITAfBgkqhkiG9w0B
CQEWEmNhQGRpZ3NpZ3RydXN0LmNvbQIRANAeRzIAAAJ8AAAAJwAAHhgwCQYFKw4DAhoFAKCB
sTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMTExODUy
NTRaMCMGCSqGSIb3DQEJBDEWBBQF9L5O6D4vZDPCLPQjJKzvrb4o+TBSBgkqhkiG9w0BCQ8x
RTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIB
QDANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASBgGb4DN7tW1AFZSeCfcWmibMKC9L4
jzCDhyfdSCubU1Vm3GZn9hOqUPyi4qWl6imAg6qeLBwNBILsMITbGZ24PG7QU+UjS3vCU8+O
CBTPPIxhuI8c533PvIjYeh7Oir6Hf15VEUTxoWhzeOwxJKzhM/1EYZtl44BdRTFRsZSiOvIy

--------------ms0628B9E204A178C2FD023D44--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BHmTF02030 for ietf-pkix-bks; Fri, 11 Jan 2002 09:48:29 -0800 (PST)
Received: from ext-mail.valicert.com (ns1.valicert.com [63.65.221.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BHmS302026 for <[e-mail]>; Fri, 11 Jan 2002 09:48:28 -0800 (PST)
Received: from CONVERSION-DAEMON by ext-mail.valicert.com (PMDF V5.2-33 #46613) id <[e-mail]> for [e-mail]; Fri, 11 Jan 2002 09:48:24 -0800 (PST)
Received: from polaris.valicert.com ([192.168.2.34]) by ext-mail.valicert.com (PMDF V5.2-33 #46613) with ESMTP id <[e-mail]> for [e-mail]; Fri, 11 Jan 2002 09:48:24 -0800 (PST)
Received: by exchange.valicert.com with Internet Mail Service (5.5.2653.19) id <C2FYWKBR>; Fri, 11 Jan 2002 09:48:23 -0800
Content-return: allowed
Date: Fri, 11 Jan 2002 09:48:22 -0800
From: Ambarish Malpani <[e-mail]>
Subject: RE: Cautionary Period
To: [e-mail]
Message-id: <[e-mail]>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi Alfonso, Denis,
    I disagree with the need for cautionary period in the DPV
protocol. Here is my reasoning:

The rationale for cautionary period, is the argument that a CRL/
OCSP response is necessarily out of date, because it takes some
time to discover, report and process a revocation request. This
means that a certificate should not be trusted for some time
after you have received it - to ensure that the revocation
information is current.

In most practical systems that I have seen, people are more than
willing to accept the risk of using a certificate if it is not
currently revoked - most people don't want to wait till the next
CRL is published, or wait till a CA has been given enough of a
margin to be able to process revocation requests. For example, in
the credit card world, we use our cards and get our mechandise
immediately, even though it would take some time to report the
loss of a credit card.

I think adding cautionary period to this protocol would just add
unnecessary complexity.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [e-mail]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043


> -----Original Message-----
> From: Alfonso De Gregorio [mailto:[e-mail]]
> Sent: Friday, January 11, 2002 9:06 AM
> To: [e-mail]; Housley, Russ
> Cc: [e-mail]
> Subject: Re: Cautionary Period
> 
> 
> 
> Hi Russ, hi Denis, hi Everyone,
> 
> > I encourage everyone to read DPV and DPD requirements 
> document, and post 
> > their view on this subject.  I believe that the document 
> expresses Denis' 
> > view on the issue.  My view is that cautionary period is a not a 
> > requirement for DPV or DPD.  However, cautionary periods 
> might be used as 
> > part of an application-specific risk mitigation mechanism 
> when trying to 
> > determine the validity of a particular signature.  For 
> example, waiting for 
> > cautionary period before considering a signature to be valid on a 
> > high-value electronic contract may be prudent.  Therefore, 
> cautionary 
> > periods might be supported in DSV (delegated signature validation).
> 
> In order to observe the cautionary-period-delay at application level
> the execution environment must be current-time-aware.
> DPV target execution environments are assumed to be constrained, at 
> least by a processing and/or communication point of view. 
> Constrained execution environments, such as telephones and PDA,
> are not necessarily current-time-aware (or have time-sources not
> necessarily trusted).
> Delegating a path validation to a TTP allows execution environments
> to be unaware of the current-time. 
> So, IMHO, cautionary periods should be a requirement for DPV.
> 
> alfonso
> 


Received: by above.proper.com (8.11.6/8.11.3) id g0BHhnF01870 for ietf-pkix-bks; Fri, 11 Jan 2002 09:43:49 -0800 (PST)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BHhk301866 for <[e-mail]>; Fri, 11 Jan 2002 09:43:46 -0800 (PST)
Received: from foobar.andxor.it (foobar.andxor.it [195.223.2.236]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id SAA61530; Fri, 11 Jan 2002 18:43:41 +0100 (CET) (envelope-from [e-mail])
Received: by foobar.andxor.it (Postfix, from userid 1000) id 3FDE5F92C; Fri, 11 Jan 2002 20:42:01 +0100 (CET)
Date: Fri, 11 Jan 2002 20:42:01 +0100
From: Alfonso De Gregorio <[e-mail]>
To: Denis Pinkas <[e-mail]>
Cc: [e-mail]
Subject: Re: Cautionary Period
Message-ID: <[e-mail]>
Reply-To: Alfonso De Gregorio <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Jan 11, 2002 at 06:22:50PM +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis, 

> Another argument is that some thin clients may not be aware of the value or
> even the existence of a cautionary period associated with some policy. That
> cautionary period may even change. So it is required to manage that value at
> the policy level (which means the server level) rather than locally at the
> client level.

Agreed.

Thanks,
alfonso


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BHRWr01188 for ietf-pkix-bks; Fri, 11 Jan 2002 09:27:32 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BHRT301184 for <[e-mail]>; Fri, 11 Jan 2002 09:27:30 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id SAA27681; Fri, 11 Jan 2002 18:27:18 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 11 Jan 2002 18:27:18 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id SAA09718; Fri, 11 Jan 2002 18:27:17 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id SAA02444; Fri, 11 Jan 2002 18:27:17 +0100 (MET)
Date: Fri, 11 Jan 2002 18:27:17 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> Peter Gutmann:
> 
> I would prefer to maintain alignment with RFC 2585.  The use of SEQUENCE OF 
> would be fewer bit on the wire, but it would also require the specification 
> of another MIME type for the transfer of certificates.
> 
> Russ
> 

And what about using a cert-only cms message? 


Received: by above.proper.com (8.11.6/8.11.3) id g0BGxC300230 for ietf-pkix-bks; Fri, 11 Jan 2002 08:59:12 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BGx9300226 for <[e-mail]>; Fri, 11 Jan 2002 08:59:09 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA27453; Fri, 11 Jan 2002 17:59:10 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 11 Jan 2002 17:59:10 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA09479; Fri, 11 Jan 2002 17:59:09 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA02430; Fri, 11 Jan 2002 17:59:08 +0100 (MET)
Date: Fri, 11 Jan 2002 17:59:08 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: draft-ietf-pkix-dpv-dpd-req-01.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Another one: 

> If the DPV request does not specify a validation policy, the server 
> response MUST indicate the one that was used. In such a case, the 
> client must verify that the one selected by the server is appropriate.

I propose:

"A server response MUST indicate the validation policy that has been used,
 and a client MUST verify that it is acceptable."



Received: by above.proper.com (8.11.6/8.11.3) id g0BGqM529944 for ietf-pkix-bks; Fri, 11 Jan 2002 08:52:22 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BGqL329940 for <[e-mail]>; Fri, 11 Jan 2002 08:52:21 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA27732; Fri, 11 Jan 2002 17:53:25 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA19424; Fri, 11 Jan 2002 17:51:46 +0100
Message-ID: <[e-mail]>
Date: Fri, 11 Jan 2002 17:51:44 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Alfonso De Gregorio <[e-mail]>
CC: "Housley, Russ" <[e-mail]>, [e-mail]
Subject: Re: Cautionary Period
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Alfonso,

Very good point. It is true that some thin clients may not have a time
reference available but may simply support a nonce mechanism. So you are
quite right to say that delegating a path validation to a TTP allows
execution environments to be unaware of the current-time.

Another argument is that some thin clients may not be aware of the value or
even the existence of a cautionary period associated with some policy. That
cautionary period may even change. So it is required to manage that value at
the policy level (which means the server level) rather than locally at the
client level.

Denis


> Hi Russ, hi Denis, hi Everyone,
> 
> > I encourage everyone to read DPV and DPD requirements document, and post
> > their view on this subject.  I believe that the document expresses Denis'
> > view on the issue.  My view is that cautionary period is a not a
> > requirement for DPV or DPD.  However, cautionary periods might be used as
> > part of an application-specific risk mitigation mechanism when trying to
> > determine the validity of a particular signature.  For example, waiting for
> > cautionary period before considering a signature to be valid on a
> > high-value electronic contract may be prudent.  Therefore, cautionary
> > periods might be supported in DSV (delegated signature validation).
> 
> In order to observe the cautionary-period-delay at application level
> the execution environment must be current-time-aware.
> DPV target execution environments are assumed to be constrained, at
> least by a processing and/or communication point of view.
> Constrained execution environments, such as telephones and PDA,
> are not necessarily current-time-aware (or have time-sources not
> necessarily trusted).
> Delegating a path validation to a TTP allows execution environments
> to be unaware of the current-time.
> So, IMHO, cautionary periods should be a requirement for DPV.
> 
> alfonso


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BGYYP29354 for ietf-pkix-bks; Fri, 11 Jan 2002 08:34:34 -0800 (PST)
Received: from slack.lne.com (dns.lne.com [209.157.136.81]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BGYW329346 for <[e-mail]>; Fri, 11 Jan 2002 08:34:33 -0800 (PST)
Received: (from ericm@localhost) by slack.lne.com (8.11.0/8.11.0) id g0BGYMh00683; Fri, 11 Jan 2002 08:34:22 -0800
Date: Fri, 11 Jan 2002 08:34:22 -0800
From: Eric Murray <[e-mail]>
To: Peter Gutmann <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.2i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Jan 11, 2002 at 06:20:05PM +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

On Fri, Jan 11, 2002 at 06:20:05PM +1300, Peter Gutmann wrote:
> 
> >. "If more than one certificate matches a query, it MUST be returned as a
> >multipart response." I assume you mean multipart/mixed? I would definitely
> >prefer a SEQUENCE of certificates.
> 
> Does anyone else have any thoughts on this?  The comments in the draft on
> SEQUENCE OF are:
> 
>   This has the advantage that it takes a lot less code to parse, OTOH it may be
>   harder to produce if what you're using is a web-enabled database, which is
>   what most of them are.

I think that it's best put in a SEQUENCE, the main reason being that
since we're talking X.509 certs, the recipient is guaranteed to
have ASN.1 parsing capability, but might not have MIME.

You should specify that it's in DER so it matches X.509.  If it's a
web-enabled database that's producing the list, wrapping the list
of certs in a SEQUENCE is a very simple bit of code.

Eric


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BGVZg29187 for ietf-pkix-bks; Fri, 11 Jan 2002 08:31:35 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0BGVT329179 for <[e-mail]>; Fri, 11 Jan 2002 08:31:29 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Jan 2002 16:31:07 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id LAA18616; Fri, 11 Jan 2002 11:31:30 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g0BGVEE05940; Fri, 11 Jan 2002 11:31:15 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <CJPHY016>; Fri, 11 Jan 2002 11:31:12 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.112]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPHY01S; Fri, 11 Jan 2002 11:31:06 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Date: Fri, 11 Jan 2002 10:16:25 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Gutmann:

I would prefer to maintain alignment with RFC 2585.  The use of SEQUENCE OF 
would be fewer bit on the wire, but it would also require the specification 
of another MIME type for the transfer of certificates.

Russ

> >. "If more than one certificate matches a query, it MUST be returned as a
> >multipart response." I assume you mean multipart/mixed? I would
definitely
> >prefer a SEQUENCE of certificates.
>
>Does anyone else have any thoughts on this?  The comments in the draft on
>SEQUENCE OF are:
>
>   This has the advantage that it takes a lot less code to parse, OTOH it 
> may be
>   harder to produce if what you're using is a web-enabled database, which
is
>   what most of them are.




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BGRdo29071 for ietf-pkix-bks; Fri, 11 Jan 2002 08:27:39 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BGRb329067 for <[e-mail]>; Fri, 11 Jan 2002 08:27:37 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id RAA27238 for <[e-mail]>; Fri, 11 Jan 2002 17:27:37 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 11 Jan 2002 17:27:37 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id RAA09237 for <[e-mail]>; Fri, 11 Jan 2002 17:27:36 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id RAA02423 for [e-mail]; Fri, 11 Jan 2002 17:27:35 +0100 (MET)
Date: Fri, 11 Jan 2002 17:27:35 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: Cautionary Period ...
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> view on the issue.  My view is that cautionary period is a not a 
> requirement for DPV or DPD.  However, cautionary periods might be used as 
> part of an application-specific risk mitigation mechanism when trying to 
> determine the validity of a particular signature.  For example, waiting for 
> cautionary period before considering a signature to be valid on a 
> high-value electronic contract may be prudent.  Therefore, cautionary 
> periods might be supported in DSV (delegated signature validation).

I agree with this point of view.

> 
> Since Denis and I were unable to resolve this issue in an author-to-author 
> dialogue, I am bring this issue to the whole mail list.  As far as I know, 
> this is the only open issue with the DPV and DPD Protocol Requirements 
No. See later. A great deal of the list of requirements for DPV
that I have send in December has not been adressed at all.
I don't know whether there is consensus that what I have send does 
not contain necessary/optional/useful requirements at all. If so, so
be it. 

> document.  I hope that this issue can be quickly resolved so that we can 
> get on with the protocol development.
Or 'protocols development'. 

Here are some editorial comments. 

The abstract says:
 "This document specifies requirements for two main request/response   
  pairs."

  followed by actually five, with two of them 'optional'.

what means 'optional' in this case? 

In fact there five different services, all of them are independant,
thus optional. 

I don't think that 'request/response pairs' is a good wording.
All occurences should be replaced by 'services' or something like that. 

And a sentence added like:

"All services are initiated by a client sending a request
 to a server; the server answers by one or more responses."

( There can be more than one response to a request. Just one
  example would be a request to determine the validity of
  a very old cert which requires some offline action, thus
  an initial response could indicate that another answer
  will be send by mail or else. 
)


> Because validation software is controlled by many parameters which, 
> if incorrectly set, may result in insecure behavior, it is useful
                                                       ------------
> to rely on pre-defined policies that are already known by the servers, 
  ---------------------------------------------------------------------
> where system security administrators carefully manage them. 
  -----------------------------------------------------------

This and the next paragraph sounds ok. But:

> Alternatively, system security administrators MAY also define policies.
What 'alternative' ? What means 'MAY also define policies'?

> However, such policy definition may be quite complex and only some 
> forms of policies can be defined in this way, otherwise testing all 
> the possible variations would lead to non-interoperable implementations
> or would increase the time necessary to ensure that two implementations 
> are interoperable.
How does 

  "testing all the possible variations would lead to
   non-interoperable implementations" ?

I would rather think the contrary ???

> Since policy definitions can be quite long and complex, all the 
> parameters SHOULD NOT be passed with each individual request; rather,  
                                          'individual DPV or DPD request'

> they SHOULD be defined using a separate policy definition 
> request/response pair. In response to a successful policy definition 
> request, the server SHALL return a policy reference (e.g. an OID).

Why SHOULD they be defined using another management protocol?
They MAY be defined in that way.  

> The certificate to be validated MUST either be directly provided in 
      certificates 

> The client MUST be able to provide to the validation server, associated
> with each certificate to be validated, "useful certificates", as well 
I don't know whether my German understanding of the English language
hits me here. Does the sentence mean: 

  "The protocol MUST provide a means to a client to provide ..."

> "The Delegated Path Validation (DPV) protocol allows a server to 
> validate one or more certificates according to a validation policy."

I suggest: 

  "The Delegated Path Validation (DPV) protocol allows a client to
   ask a server to validate one or more certificates and to provide
   a status to the client. The validation is made according to
   a validation policy." 


> The validation policy SHALL be known by the DPV server.
> The validation policy MAY be defined using an additional request/
> response pair (see section 10) prior to the DPV request. In this way 
> clients only need to be aware of the reference of the validation 
> policy to be used by a given application.

Could one try and avoid turning around phrases three times.
'in this way' refers to what? 

I propose:

"The validation policy SHALL be known by the DPV server and 
 identifed by unambiguous reference usable by the client."

And maybe :
 "In this way clients only need to be aware of the reference 
 of the validation policy to be used by a given application.
 The definition of policies and the allocation of a reference
 is outside the scope of DPV. Section 10 proposes a policy
 management protocol/service."  although this seems to be
 a repetition of text elsewhere. 



Received: by above.proper.com (8.11.6/8.11.3) id g0BF8Cs26373 for ietf-pkix-bks; Fri, 11 Jan 2002 07:08:12 -0800 (PST)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BF8A326369 for <[e-mail]>; Fri, 11 Jan 2002 07:08:11 -0800 (PST)
Received: from foobar.andxor.it (foobar.andxor.it [195.223.2.236]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id QAA59715; Fri, 11 Jan 2002 16:08:07 +0100 (CET) (envelope-from [e-mail])
Received: by foobar.andxor.it (Postfix, from userid 1000) id F11DCF92C; Fri, 11 Jan 2002 18:06:26 +0100 (CET)
Date: Fri, 11 Jan 2002 18:06:26 +0100
From: Alfonso De Gregorio <[e-mail]>
To: [e-mail], "Housley, Russ" <[e-mail]>
Cc: [e-mail]
Subject: Re: Cautionary Period
Message-ID: <[e-mail]>
Reply-To: Alfonso De Gregorio <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Jan 11, 2002 at 03:21:14PM +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi Russ, hi Denis, hi Everyone,

> I encourage everyone to read DPV and DPD requirements document, and post 
> their view on this subject.  I believe that the document expresses Denis' 
> view on the issue.  My view is that cautionary period is a not a 
> requirement for DPV or DPD.  However, cautionary periods might be used as 
> part of an application-specific risk mitigation mechanism when trying to 
> determine the validity of a particular signature.  For example, waiting for 
> cautionary period before considering a signature to be valid on a 
> high-value electronic contract may be prudent.  Therefore, cautionary 
> periods might be supported in DSV (delegated signature validation).

In order to observe the cautionary-period-delay at application level
the execution environment must be current-time-aware.
DPV target execution environments are assumed to be constrained, at 
least by a processing and/or communication point of view. 
Constrained execution environments, such as telephones and PDA,
are not necessarily current-time-aware (or have time-sources not
necessarily trusted).
Delegating a path validation to a TTP allows execution environments
to be unaware of the current-time. 
So, IMHO, cautionary periods should be a requirement for DPV.

alfonso


Received: by above.proper.com (8.11.6/8.11.3) id g0BDuvK24112 for ietf-pkix-bks; Fri, 11 Jan 2002 05:56:57 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BDuu324108 for <[e-mail]>; Fri, 11 Jan 2002 05:56:56 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14856; Fri, 11 Jan 2002 08:56:54 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Date: Fri, 11 Jan 2002 08:56:54 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--NextPart

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

	Title		: Delegated Path Validation and Delegated Path Discovery
                          Protocol Requirements (DPV&DPD-REQ)
	Author(s)	: D. Pinkas
	Filename	: draft-ietf-pkix-dpv-dpd-req-01.txt
	Pages		: 14
	Date		: 10-Jan-02
	
This document specifies requirements for two main request/response 
pairs.
The first one, called Delegated Path Validation (DPV), can be used to 
fully delegate a path validation processing to an DPV server, 
according to a set of rules, called a validation policy.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-01.txt

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-dpv-dpd-req-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BDTx022253 for ietf-pkix-bks; Fri, 11 Jan 2002 05:29:59 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g0BDTv322249 for <[e-mail]>; Fri, 11 Jan 2002 05:29:58 -0800 (PST)
Received: from sdtihq24.securitydynamics.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 11 Jan 2002 13:29:35 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA01969 for <[e-mail]>; Fri, 11 Jan 2002 08:29:52 -0500 (EST)
Received: from exeu00.securid.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g0BDTp416936 for <[e-mail]>; Fri, 11 Jan 2002 08:29:51 -0500 (EST)
Received: by exeu00.securid.com with Internet Mail Service (5.5.2653.19) id <CJPNVQZC>; Fri, 11 Jan 2002 13:29:59 -0000
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.46]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id CJPHY7G5; Fri, 11 Jan 2002 08:29:43 -0500
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0.1
Date: Thu, 10 Jan 2002 15:10:21 -0500
To: [e-mail]
From: "Housley, Russ" <[e-mail]>
Subject: Cautionary Period
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

The updated Delegated Path Validation (DPV) and Delegated Path Discovery 
(DPD) Protocol Requirements document <draft-ietf-pkix-dpv-dpd-req-01.txt> 
was recently posted.  You may notice that I am a co-author with Denis on 
this document.  Denis invited me to be a co-author because I submitted many 
comments.  There were many, many editorial ones.  There were also technical 
ones.  Denis and I were able to resolve the vast bulk of the technical 
issues; however, we have not been able to reach a compromise on one open 
issue.  That issue is the subject of this note.

I encourage everyone to read DPV and DPD requirements document, and post 
their view on this subject.  I believe that the document expresses Denis' 
view on the issue.  My view is that cautionary period is a not a 
requirement for DPV or DPD.  However, cautionary periods might be used as 
part of an application-specific risk mitigation mechanism when trying to 
determine the validity of a particular signature.  For example, waiting for 
cautionary period before considering a signature to be valid on a 
high-value electronic contract may be prudent.  Therefore, cautionary 
periods might be supported in DSV (delegated signature validation).

Since Denis and I were unable to resolve this issue in an author-to-author 
dialogue, I am bring this issue to the whole mail list.  As far as I know, 
this is the only open issue with the DPV and DPD Protocol Requirements 
document.  I hope that this issue can be quickly resolved so that we can 
get on with the protocol development.

Russ


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0BDA1I21083 for ietf-pkix-bks; Fri, 11 Jan 2002 05:10:01 -0800 (PST)
Received: from mail.motus.qc.ca (mail.motus.qc.ca [207.236.155.221]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BD9w321070 for <[e-mail]>; Fri, 11 Jan 2002 05:09:59 -0800 (PST)
Subject: =?iso-8859-1?Q?R=E9f=2E_=3A_Re=3A_I-D_ACTION=3Adraft-ietf-pkix-certstore?= =?us-ascii?Q?-http?= =?us-ascii?Q?-01?= =?us-ascii?Q?=2E?= =?us-ascii?Q?txt?=
To: [e-mail] (Peter Gutmann)
Cc: [e-mail], [e-mail]
X-Mailer: Lotus Notes Release 5.07a  May 14, 2001
Message-ID: <[e-mail]>
From: [e-mail]
Date: Fri, 11 Jan 2002 08:10:48 -0500
X-MIMETrack: Serialize by Router on motus1/Motus Technologies Inc.(Release 5.0.8 |June 18, 2001) at 2002-01-11 08:11:01
MIME-Version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0BD9x321072
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

>. key truncation to 128 bit: if we want to truncate search keys to save
space,
>we might as well truncate them to 80 or 96 bits.

See my other reply on this.  I felt that 128 bits is the least I could get
away
with without someone somewhere complaining.  The smaller the key, the more
efficient the B-tree indices become, so smaller would definitely be better.
I've added text to say that:

  Although clients MUST submit a fixed 128-bit value, servers are free to
  utilise as many bits of this value as they require, for example a server
may
  choose to use only the first 40 or 64 or 80 bits for efficiency in
searching
  and maintaining indices.

That should keep everyone happy.


<comment>
In this case why not send the whole 160 bits hash in the client query and
let the server use some part of it (64, 80, 96, 128 or 160 bits) ?

This would simplify both the client (albeit not much) and the current
specification (which, from my implementer point of view, are both good
things). Then the specification could include an "implementation comment"
saying that "servers MAY use only part of hash supplied by the client query
to retrieve a certificate or CRL".
</comment>

--------------------------------------------------------------
Sébastien Pouliot
Architecte Sécurité / Security Architect
Motus Technologies
tel: [phone] ext 307
courriel / email: [e-mail]



                                                                                                                        
                    [e-mail]                                                                                  
                    d.ac.nz (Peter            Pour :  [e-mail], [e-mail]                       
                    Gutmann)                  cc :    [e-mail]                                         
                    Envoyé par :              Objet :      Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt         
                    owner-ietf-pkix@ma                                                                                  
                    il.imc.org                                                                                          
                                                                                                                        
                                                                                                                        
                    11/01/02 13:20                                                                                      
                                                                                                                        
                                                                                                                        





Some of these have already been fixed as a result of other feedback or are
straightforward changes which I've applied, I'll coment on what's left...

> . the draft only deals with HTTP, HTTPS may also be useful in some cases
and
>should be permitted.

I meant "HTTP" as a generic "HTTP or HTTPS", but I've made it more explicit
in
the text.

>. you might want to explicitly state that both the attribute name and
value
>are case sensitive

The attribute name isn't case sensitive (unless someone can present a
strong
reason for this), but the value is, I've commented on this in the text.

>. the value description says "as it appears in the certificate" even if it
>could also refer to a CRL.

Fixed.

>. "If more than one certificate matches a query, it MUST be returned as a
>multipart response." I assume you mean multipart/mixed? I would definitely
>prefer a SEQUENCE of certificates.

Does anyone else have any thoughts on this?  The comments in the draft on
SEQUENCE OF are:

  This has the advantage that it takes a lot less code to parse, OTOH it
may be
  harder to produce if what you're using is a web-enabled database, which
is
  what most of them are.

>. Server response in case no certificate/ CRL matches a query is
undefined.
>
>. Server error behavior is undefined (invalid request, database
temporarily
>unavailable, etc.)
>
>  . server behavior in case of more complex queries should be defined
(ignore
>what you don't understand) to allow evolution of the protocol.

This is standard HTTP stuff:

  Responses to unsuccessful queries (for example to indicate a non-match or
an
  error conditions) are handled in the standard manner as per [RFC2068].
  Clients should in particular be aware that in some instances servers may
  return HTTP type 3xx redirection requests to redirect queries to another
  server.  Clients receiving this response SHOULD use the returned URI to
  replace their existing one and resubmit the query to the new server.

>. key truncation to 128 bit: if we want to truncate search keys to save
space,
>we might as well truncate them to 80 or 96 bits.

See my other reply on this.  I felt that 128 bits is the least I could get
away
with without someone somewhere complaining.  The smaller the key, the more
efficient the B-tree indices become, so smaller would definitely be better.
I've added text to say that:

  Although clients MUST submit a fixed 128-bit value, servers are free to
  utilise as many bits of this value as they require, for example a server
may
  choose to use only the first 40 or 64 or 80 bits for efficiency in
searching
  and maintaining indices.

That should keep everyone happy.

>. I believe the draft should be explicit wrt to attribute certs, even if
it is
>only saying that they are not covered by the specification.

All it really needs is another AIA... is there any demand for an attribute-
cert-specific AIA?  If not, I think the boilerplate IANA considerations
will
cover it.

>. is a client required to implement full HTTP/1.1 and MIME, i.e. is the
server
>allowed to send responses that make use of all the funky features?

I'd prefer to avoid profiling HTTP with anything more than a reference to
RFC
2068... it's really up to clients as to how much they want to implement
beyond
handling "worked"/"didn't work" responses.

>. the security considerations mention the Cache-Control header, but the
main
>document does not say if client and servers MUST/ SHOULD/ MAY send that
>header.

I'd consider it up to the client, the reason I added it in the security
considerations is to let people know the issue exists.  It doesn't affect
interoperability, and I don't know if a MAY would add much.

>. security consideration should state that the server should be considered
>untrusted, e.g. don't use the certificate returned for a email=
>[e-mail] query to send S/MIME encrypted mail without
>verifiying the contents of the certificate.

Again, I consider that to be a client issue.  It's the same as any cert you
get
via any mechanism, you can choose to trust it or not.

Peter.






Received: by above.proper.com (8.11.6/8.11.3) id g0BCUj820029 for ietf-pkix-bks; Fri, 11 Jan 2002 04:30:45 -0800 (PST)
Received: from svart.tajt.se (svart.tajt.se [195.178.183.135]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0BCUg320025 for <[e-mail]>; Fri, 11 Jan 2002 04:30:42 -0800 (PST)
Received: from svart.tajt.se. (svart.tajt.se [195.178.183.135]) by svart.tajt.se (8.11.2/8.11.2) with ESMTP id g0BCUaK01624 for <[e-mail]>; Fri, 11 Jan 2002 13:30:36 +0100
Message-Id: <[e-mail]>
In-Reply-To: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
MIME-Version: 1.0
User-Agent: CAMAS/1.0.6-STABLE1 (CAudium Mail Access System)
From: Tomas Gustavsson <[e-mail]>
To: [e-mail]
Content-Transfer-Encoding: 8bit
Date: Sat, 11 Jan 2002 13:30:36 +0100
Content-Type: text/plain; charset=iso-8859-1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> Hmm, I think the cert store implementation itself should deal with
> these kind of index optimization issues. I vote for just submitting
> search values as is and let the certificate store backend do the bit
> reducing at the server-side if necessary at all. That makes client
> implementations simpler and leaves up decisions about how to deal
> with possible collisions to the server-side cert store
> implementation.

I would agree with this. It simplifies things to use 'real' values and let the backend/middleware do the optimization.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0B8phF29977 for ietf-pkix-bks; Fri, 11 Jan 2002 00:51:43 -0800 (PST)
Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0B8pg329973 for <[e-mail]>; Fri, 11 Jan 2002 00:51:42 -0800 (PST)
Received: from fwd03.sul.t-online.de  by mailout07.sul.t-online.de with smtp  id 16OxPU-0005si-01; Fri, 11 Jan 2002 09:51:36 +0100
Received: from junker.stroeder.com (520010731148-0001@[62.224.170.12]) by fmrl03.sul.t-online.com with esmtp id 16OxPR-0y2R3gC; Fri, 11 Jan 2002 09:51:33 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id B0882157117; Fri, 11 Jan 2002 09:51:31 +0100 (CET)
Message-ID: <[e-mail]>
Date: Fri, 11 Jan 2002 09:51:30 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Gutmann wrote:
> 
> Tomas Gustavsson <[e-mail]> writes:
> 
> >How much space is saved by only using 128 bits from the SHA1 hash?
> 
> The short answer is: It's quite significant (even 128 bits is far larger than
> is optimal, but I figured that was the lower bound of what I could get away
> with.  64 bits would be better).  The space saving on disk is irrelevant,
> what's significant is the space in indices.  The less keys you can fit per
> page, the more pages the index consumes, and the worse performance gets.
> That's still not the full answer, for that I'd recommend any book on database
> design, or the paper I reference in the draft which looks at this in some
> detail.

Hmm, I think the cert store implementation itself should deal with
these kind of index optimization issues. I vote for just submitting
search values as is and let the certificate store backend do the bit
reducing at the server-side if necessary at all. That makes client
implementations simpler and leaves up decisions about how to deal
with possible collisions to the server-side cert store
implementation.

Peter, as I understand your draft it's only an interface definition.
There shouldn't be e.g. database-specific limits in this draft
because they are dependent on the DB backend used by an
implementation. Only limitations imposed by the protocols used for
the interface (HTTP in this case) should be considered.

BTW: I'm not an DB expert but IMHO index generation with hashes of
appropriate size and collision handling is made internally by DB
servers anyway.

> >Is the added chance of collision insignificant when truncating the hash?
> 
> Yes.  I doubt there are more than about 2^20 certs in the whole world, let
> alone 2^64.

You know this famous sentence about "640kByte on DOS systems is
enough"... ;-)

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0B5Xbm13038 for ietf-pkix-bks; Thu, 10 Jan 2002 21:33:37 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0B5XZ313034 for <[e-mail]>; Thu, 10 Jan 2002 21:33:36 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id SAA26158; Fri, 11 Jan 2002 18:33:25 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA204689; Fri, 11 Jan 2002 18:33:24 +1300 (NZDT) (sender [e-mail])
Date: Fri, 11 Jan 2002 18:33:24 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This has since been sorted out in private mail, Michael has suggested a whole
range of useful things which you can do with pre-constructed URIs which I've
added to the draft:

  Note that a single server can handle both CRLDP and AIA/SIA queries provided
  the CRLDP form uses an HTTP URI.  Since CRLDP points to a single static
  location for a CRL, a query can be pre-constructed and stored in the CRLDP
  extension.  Software which uses the CRLDP will retrieve the single CRL which
  applies to the certificate from the server, and software which uses the
  AIA/SIA can retrieve any CRL from the server.  Similar pre-constructed URIs
  may also be useful in other circumstances, for example for links on web
  pages, to place in appropriate locations like the issuerAltName, or even for
  tech support staff to email to users who can't find the certificate
  themselves.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0B5KB412813 for ietf-pkix-bks; Thu, 10 Jan 2002 21:20:11 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0B5K8312809 for <[e-mail]>; Thu, 10 Jan 2002 21:20:08 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id SAA26412; Fri, 11 Jan 2002 18:20:05 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA204211; Fri, 11 Jan 2002 18:20:05 +1300 (NZDT) (sender [e-mail])
Date: Fri, 11 Jan 2002 18:20:05 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Some of these have already been fixed as a result of other feedback or are
straightforward changes which I've applied, I'll coment on what's left...

> . the draft only deals with HTTP, HTTPS may also be useful in some cases and
>should be permitted.

I meant "HTTP" as a generic "HTTP or HTTPS", but I've made it more explicit in
the text.

>. you might want to explicitly state that both the attribute name and value
>are case sensitive

The attribute name isn't case sensitive (unless someone can present a strong
reason for this), but the value is, I've commented on this in the text.

>. the value description says "as it appears in the certificate" even if it
>could also refer to a CRL.

Fixed.

>. "If more than one certificate matches a query, it MUST be returned as a
>multipart response." I assume you mean multipart/mixed? I would definitely
>prefer a SEQUENCE of certificates.

Does anyone else have any thoughts on this?  The comments in the draft on
SEQUENCE OF are:

  This has the advantage that it takes a lot less code to parse, OTOH it may be
  harder to produce if what you're using is a web-enabled database, which is
  what most of them are.

>. Server response in case no certificate/ CRL matches a query is undefined.
>
>. Server error behavior is undefined (invalid request, database temporarily
>unavailable, etc.)
>
>  . server behavior in case of more complex queries should be defined (ignore
>what you don't understand) to allow evolution of the protocol.

This is standard HTTP stuff:

  Responses to unsuccessful queries (for example to indicate a non-match or an
  error conditions) are handled in the standard manner as per [RFC2068].
  Clients should in particular be aware that in some instances servers may
  return HTTP type 3xx redirection requests to redirect queries to another
  server.  Clients receiving this response SHOULD use the returned URI to
  replace their existing one and resubmit the query to the new server.

>. key truncation to 128 bit: if we want to truncate search keys to save space,
>we might as well truncate them to 80 or 96 bits.

See my other reply on this.  I felt that 128 bits is the least I could get away
with without someone somewhere complaining.  The smaller the key, the more
efficient the B-tree indices become, so smaller would definitely be better.
I've added text to say that:

  Although clients MUST submit a fixed 128-bit value, servers are free to
  utilise as many bits of this value as they require, for example a server may
  choose to use only the first 40 or 64 or 80 bits for efficiency in searching
  and maintaining indices.

That should keep everyone happy.

>. I believe the draft should be explicit wrt to attribute certs, even if it is
>only saying that they are not covered by the specification.

All it really needs is another AIA... is there any demand for an attribute-
cert-specific AIA?  If not, I think the boilerplate IANA considerations will
cover it.

>. is a client required to implement full HTTP/1.1 and MIME, i.e. is the server
>allowed to send responses that make use of all the funky features?

I'd prefer to avoid profiling HTTP with anything more than a reference to RFC
2068... it's really up to clients as to how much they want to implement beyond
handling "worked"/"didn't work" responses.

>. the security considerations mention the Cache-Control header, but the main
>document does not say if client and servers MUST/ SHOULD/ MAY send that
>header.

I'd consider it up to the client, the reason I added it in the security
considerations is to let people know the issue exists.  It doesn't affect
interoperability, and I don't know if a MAY would add much.

>. security consideration should state that the server should be considered
>untrusted, e.g. don't use the certificate returned for a email=
>[e-mail] query to send S/MIME encrypted mail without
>verifiying the contents of the certificate.

Again, I consider that to be a client issue.  It's the same as any cert you get
via any mechanism, you can choose to trust it or not.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0B3cKH11518 for ietf-pkix-bks; Thu, 10 Jan 2002 19:38:20 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0B3cI311514 for <[e-mail]>; Thu, 10 Jan 2002 19:38:19 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id QAA24173; Fri, 11 Jan 2002 16:38:02 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA202214; Fri, 11 Jan 2002 16:38:02 +1300 (NZDT) (sender [e-mail])
Date: Fri, 11 Jan 2002 16:38:02 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Tomas Gustavsson <[e-mail]> writes:

>How much space is saved by only using 128 bits from the SHA1 hash?

The short answer is: It's quite significant (even 128 bits is far larger than
is optimal, but I figured that was the lower bound of what I could get away
with.  64 bits would be better).  The space saving on disk is irrelevant,
what's significant is the space in indices.  The less keys you can fit per
page, the more pages the index consumes, and the worse performance gets.
That's still not the full answer, for that I'd recommend any book on database
design, or the paper I reference in the draft which looks at this in some
detail.

>Is the added chance of collision insignificant when truncating the hash?

Yes.  I doubt there are more than about 2^20 certs in the whole world, let
alone 2^64.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0AIltX28175 for ietf-pkix-bks; Thu, 10 Jan 2002 10:47:55 -0800 (PST)
Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0AIlq328169 for <[e-mail]>; Thu, 10 Jan 2002 10:47:52 -0800 (PST)
Received: from fwd11.sul.t-online.de  by mailout11.sul.t-online.de with smtp  id 16OkEp-00035o-03; Thu, 10 Jan 2002 19:47:43 +0100
Received: from junker.stroeder.com (520010731148-0001@[62.224.168.14]) by fmrl11.sul.t-online.com with esmtp id 16OkEb-20evdgC; Thu, 10 Jan 2002 19:47:29 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 88C0E157117; Thu, 10 Jan 2002 19:47:16 +0100 (CET)
Message-ID: <[e-mail]>
Date: Thu, 10 Jan 2002 19:47:16 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Andreas Sterbenz <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Andreas Sterbenz wrote:
> 
>   . "Arbitrary-length binary values are converted into a search key by
> the process described in section 2.1." This seems a bit to vague, please
> clarify. In particular, the certHash is not an arbitrary length binary
> value, does that imply the full 160 bits are used or is it still
> truncated to 128?

I also agree that all sort of hashes should be taken as-is because
they are most times already calculated before the HTTP cert store is
queried.

>   . Server response in case no certificate/ CRL matches a query is
> undefined.
> 
>   . Server error behavior is undefined (invalid request, database
> temporarily unavailable, etc.)

I'd suggest to explore the possibility to just use HTTP response
error code as defined RFC2616, section 6.1.1. Otherwise a message
format for queries and response would have to be defined.

Ciao, Michael.


Received: by above.proper.com (8.11.6/8.11.3) id g0AIHjc27403 for ietf-pkix-bks; Thu, 10 Jan 2002 10:17:45 -0800 (PST)
Received: from mail3.microsoft.com (mail3.microsoft.com [131.107.3.123]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0AIHi327398 for <[e-mail]>; Thu, 10 Jan 2002 10:17:44 -0800 (PST)
Received: from INET-VRS-03.redmond.corp.microsoft.com ([157.54.5.27]) by mail3.microsoft.com with Microsoft SMTPSVC(5.0.2195.4617); Thu, 10 Jan 2002 10:17:40 -0800
Received: from 157.54.5.25 by INET-VRS-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 10 Jan 2002 10:17:40 -0800
Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-hub-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Jan 2002 10:17:40 -0800
Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Thu, 10 Jan 2002 10:17:39 -0800
Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3588.0); Thu, 10 Jan 2002 10:15:40 -0800
X-MimeOLE: Produced By Microsoft Exchange V6.0.6115.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: RE: Name constraints 
Date: Thu, 10 Jan 2002 10:15:40 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Name constraints 
thread-index: AcGJfbKx5JbOW5ExRTO4dmtLMV91swQhLmSQ
From: "Trevor Freeman" <[e-mail]>
To: <[e-mail]>, "Housley, Russ" <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 10 Jan 2002 18:15:40.0792 (UTC) FILETIME=[CFAD0780:01C19A02]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g0AIHi327399
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

IE uses the OS for certificate validation. The first MS OS to support
Name Constraints is Window XP. If you repeat the test using IE 6 on XP,
you will get different results to IE6 on down-level MS OS's. FYI,
Windows XP also fully implements Certificate policy, policy constraints
and policy mapping.

Trevor

-----Original Message-----
From: Michael Helm [mailto:[e-mail]] 
Sent: Thursday, December 20, 2001 9:36 AM
To: Housley, Russ
Cc: [e-mail]
Subject: Re: Name constraints 



"Housley, Russ" writes:
> Part of the slow implementation may be related to the fact that CAs 
> are not
> required to support name constraints.  I think that this is
appropriate 

Curiously, the ca software I was using for this test is from one 
of those browser implementors.  Support decisions are
probably done on completely different bases!

> Son-of-2459 continues to include name constraints.    It says:
> 
>     At a minimum, applications conforming to this profile MUST
recognize
>     4.2.1.7), basic constraints (section 4.2.1.10), name constraints
>     (section 4.2.1.11), policy constraints (section 4.2.1.12), 
> extended

It does seem to be safe to say that at least some of the browser revs
can't meet this profile spec.


Received: by above.proper.com (8.11.6/8.11.3) id g0AFvhF23809 for ietf-pkix-bks; Thu, 10 Jan 2002 07:57:43 -0800 (PST)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0AFvg323805 for <[e-mail]>; Thu, 10 Jan 2002 07:57:42 -0800 (PST)
Received: from ireserver.Ireland.Sun.COM ([129.156.220.7]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06663; Thu, 10 Jan 2002 08:57:04 -0700 (MST)
Received: from sun.com (dhcp-edub03-21 [129.156.220.138]) by ireserver.Ireland.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with ESMTP id PAA12476; Thu, 10 Jan 2002 15:57:21 GMT
Message-ID: <[e-mail]>
Date: Thu, 10 Jan 2002 15:57:20 +0000
From: Andreas Sterbenz <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221
X-Accept-Language: en-us
MIME-Version: 1.0
To: [e-mail]
CC: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter,

some comments, partially overlapping with other people's feedback.

  . the draft only deals with HTTP, HTTPS may also be useful in some 
cases and should be permitted.

  . "Arbitrary-length binary values are converted into a search key by 
the process described in section 2.1." This seems a bit to vague, please 
clarify. In particular, the certHash is not an arbitrary length binary 
value, does that imply the full 160 bits are used or is it still 
truncated to 128?

  . you might want to explicitly state that both the attribute name and 
value are case sensitive

  . the value description says "as it appears in the certificate" even 
if it could also refer to a CRL.

  . "If more than one certificate matches a query, it MUST be returned 
as a multipart response." I assume you mean multipart/mixed? I would 
definitely prefer a SEQUENCE of certificates.

  . Server response in case no certificate/ CRL matches a query is 
undefined.

  . Server error behavior is undefined (invalid request, database 
temporarily unavailable, etc.)

  . key truncation to 128 bit: if we want to truncate search keys to 
save space, we might as well truncate them to 80 or 96 bits.

  . I believe the draft should be explicit wrt to attribute certs, even 
if it is only saying that they are not covered by the specification.

  . is a client required to implement full HTTP/1.1 and MIME, i.e. is 
the server allowed to send responses that make use of all the funky 
features?

  . the security considerations mention the Cache-Control header, but 
the main document does not say if client and servers MUST/ SHOULD/ MAY 
send that header.

  . security consideration should state that the server should be 
considered untrusted, e.g. don't use the certificate returned for a 
email=[e-mail] query to send S/MIME encrypted mail 
without verifiying the contents of the certificate.

  . some examples with full requests and responses may be helpful.

  . server behavior in case of more complex queries should be defined 
(ignore what you don't understand) to allow evolution of the protocol.

Andreas.



Received: by above.proper.com (8.11.6/8.11.3) id g0ACufH17623 for ietf-pkix-bks; Thu, 10 Jan 2002 04:56:41 -0800 (PST)
Received: from svart.tajt.se (svart.tajt.se [195.178.183.135]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0ACub317619 for <[e-mail]>; Thu, 10 Jan 2002 04:56:39 -0800 (PST)
Received: from svart.tajt.se. (svart.tajt.se [195.178.183.135]) by svart.tajt.se (8.11.2/8.11.2) with ESMTP id g0ACuKO13383 for <[e-mail]>; Thu, 10 Jan 2002 13:56:20 +0100
Message-Id: <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
MIME-Version: 1.0
From: Tomas Gustavsson <[e-mail]>
To: [e-mail]
User-Agent: CAMAS/1.0.6-STABLE1 (CAudium Mail Access System)
In-Reply-To: <[e-mail]>
Content-Transfer-Encoding: 8bit
Date: Fri, 10 Jan 2002 13:56:19 +0100
Content-Type: text/plain; charset=iso-8859-1
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

How much space is saved by only using 128 bits from the SHA1 hash?
I expect many databases already contain certificates indexed by a full SHA1 hash, and only using the first 128 bits requires an almost duplicate field (alt. using SQL 'like' things).
Is the added chance of collision insignificant when truncating the hash?

Regards,
Tomas



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g09MeGv02079 for ietf-pkix-bks; Wed, 9 Jan 2002 14:40:16 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09MeF302075 for <[e-mail]>; Wed, 9 Jan 2002 14:40:15 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA18494; Wed, 9 Jan 2002 17:40:14 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ipki-new-rfc2527-01.txt
Date: Wed, 09 Jan 2002 17:40:13 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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 Certificate 
                          Policy and Certification Practices Framework
	Author(s)	: S. Chokhani et al.
	Filename	: draft-ietf-pkix-ipki-new-rfc2527-01.txt
	Pages		: 55
	Date		: 08-Jan-02
	
This document presents a framework to assist the writers of 
certificate policies or certification practice statements for 
participants within public key infrastructures, such as 
certification authorities, policy authorities, and communities of 
interest that wish to rely on certificates.  In particular, the 
framework provides a comprehensive list of topics that potentially 
(at the writer's discretion) need to be covered in a certificate 
policy or a certification practice statement.  This document is 
being submitted to the RFC Editor with a request for publication as 
an Informational RFC.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ipki-new-rfc2527-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g09G3mN20572 for ietf-pkix-bks; Wed, 9 Jan 2002 08:03:48 -0800 (PST)
Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09G3k320568 for <[e-mail]>; Wed, 9 Jan 2002 08:03:47 -0800 (PST)
Received: from fwd10.sul.t-online.de  by mailout04.sul.t-online.de with smtp  id 16OLCY-0006mD-08; Wed, 09 Jan 2002 17:03:42 +0100
Received: from junker.stroeder.com (520010731148-0001@[62.224.165.97]) by fmrl10.sul.t-online.com with esmtp id 16OLCQ-1KkLSqC; Wed, 9 Jan 2002 17:03:34 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 3687D157D03; Wed,  9 Jan 2002 16:58:26 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 09 Jan 2002 16:58:25 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Gutmann wrote:
> 
> Michael Ströder <[e-mail]> writes:
> 
> >IMHO for a low-tech use-case with wide-spread acceptance ;-) it should be
> >possible to create a simple HTML form with the <form>'s attribute action=
> >pointing to the URL of the "HTTP Certificate Store Interface". For this simple
> >scenario pre-processing (hashing) of search values at the client side is
> >unfeasible (except when using Javascript or similar beasty things).
> 
> The human-usable forms are all text-only.  I doubt a user will ever want to
> construct an issuerAndSerialNumber from a hex dump of a cert just to fetch it
> from a directory.

Agreed.

>  In fact users aren't meant to use the interface at this
> level at all.  This interface really isn't meant for use by humans, it's a
> universal interface to a cert store which happens to use HTTP to achieve
> universality.

I already understood that you don't have usage by end-users through
web forms in mind. But the specification is pretty close to enable
it. So why prevent us from querying the cert store with a simple web
form for searching certificates associated to an e-mail address?

> >I'd also suggest that it should be possible to pass a subject DN in RFC2253
> >string representation as (x-www-form-urlencoded) search value.
> 
> [..] It's also a pretty LDAP-specific
> mechanism, you can't just grab a binary string from a cert, hash it, and do a
> lookup, you have to follow fairly complex LDAP name-representation rules.  I'd
> rather leave this to other RFCs which seem to cover it adequately.

We had this discussion about RFC2253 string representation here. It
was not LDAP-specific at all. AFAIR it was triggered by XML-DSIG
specs. Remember?

E.g. OpenSSL already implements getting a RFC2253-compliant
representation of subject and issued DNs. Properly implementing the
DN string matching is a matter of the cert store's implementation
not your specification.

I know that you personally don't like LDAP. But this shouldn't hold
you back from relying on usable parts of the LDAP standard.

> >My suggestion would be to run certificate stores holding e-mail certs
> >associated to e-mail domains.
> 
> That's pretty much how it's meant to work.  If I know your email address is
> @hotmail.com, I'd go to certificates.hotmail.com and ask for your cert.

Ok, understood. You should specify the term "service provider" a
little bit more in detail.

> That's
> also why the draft specifically mentions support for redirects, if you're
> outsourcing the cert-storage task you can point to where the certs really are

Well, I don't object against HTTP redirects but IMHO setting DNS
CNAME RRs are a more practical and efficient solution for
out-sourced installations.

> did I mention in a previous message that there's a bit of practical experience
> in using this? :-).

I know. That's why I'm reading and commenting the draft. Did I
mention that I have also some practical experience using those kind
of things? ;-)

> It's not perfect, but it's good enough, and pretty transparent.

I don't impose that such a thing has to be "perfect" since I don't
know what "perfect" might be.

Unfortunately you did not comment on my inquiry to run such a
service with URL scheme https and port number!=80. From my practical
experience it's sometimes crucial to be flexible in this regard.

Ciao, Michael.


Received: by above.proper.com (8.11.6/8.11.3) id g09G3dj20564 for ietf-pkix-bks; Wed, 9 Jan 2002 08:03:39 -0800 (PST)
Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09G3c320560 for <[e-mail]>; Wed, 9 Jan 2002 08:03:38 -0800 (PST)
Received: from fwd05.sul.t-online.de  by mailout01.sul.t-online.de with smtp  id 16OLCV-0007T8-00; Wed, 09 Jan 2002 17:03:39 +0100
Received: from junker.stroeder.com (520010731148-0001@[62.224.165.97]) by fmrl05.sul.t-online.com with esmtp id 16OLCS-0guB84C; Wed, 9 Jan 2002 17:03:36 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 3735F157D04; Wed,  9 Jan 2002 17:05:11 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 09 Jan 2002 17:05:10 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
Cc: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Gutmann wrote:
> 
> Michael StrM-vder <[e-mail]> writes:
> 
> >While I understand the rationale in section 3.4 that AIA and CRLDP extensions
> >are different in semantics I think the CRL could be retrieved via
> >CRLDistributionPoint as long as the HTTP certificate store interface behaves
> >as expected for CRLDistributionPoint.
> 
> But it doesn't behave that way.  As the rationale points out, CRLDP points at a
> static CRL while the draft uses a general CRL query mechanism.  To put it
> another way, let's say you get a cert with a CRLDP containing a URI:
> 
>   foo.bar.com/qwertyuiop
> 
> What are you supposed to do with this?  If you follow CRLDP semantics, you go
> to foo.bar.com and do a GET /qwertyuiop HTTP/1.0.  If you follow the draft
> semantics you go to foo.bar.com and do a GET /qwertyuiop/search-cgi?iHash=
> <search key> HTTP/1.0 (or whatever key you're using).  Unless you completely
> redefine the semantics of CRLDP to constrain it to follow the functionality in
> the draft, you can't do this.

I still can't see the difference. Even (outdated) RFC 1738
referenced in RFC 2459 allows a query string being part of an URI.
While glancing over RFC 2459 and draft-ietf-pkix-new-part1-11 I
could not find a hint which prevents me from using a query string in
CRLDistributionPoint.distributionPoint.fullName. Therefore I can use

GET /qwertyuiop/search-cgi?iHash=<search key>

with <search key> being a constant uniquely identifying the CRL.

BTW: The "static" URI form

foo.bar.com/qwertyuiop

doesn't mean that the web server serves a static file. Could be also
a web application acting different for path info /qwertyuiop and
/poiuytrewq.

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g09CxDY13484 for ietf-pkix-bks; Wed, 9 Jan 2002 04:59:13 -0800 (PST)
Received: from zolera.com ([63.142.188.177]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09CxB313480 for <[e-mail]>; Wed, 9 Jan 2002 04:59:11 -0800 (PST)
Received: from zolera.com (pool-141-154-58-48.bos.east.verizon.net [141.154.58.48]) by zolera.com (8.11.6/8.11.6) with ESMTP id g09CwHK25040; Wed, 9 Jan 2002 07:58:22 -0500
Message-ID: <[e-mail]>
Date: Wed, 09 Jan 2002 07:59:18 -0500
From: Rich Salz <[e-mail]>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Peter Gutmann <[e-mail]>
CC: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> >This may be off-topic but have you considered a SOAP version of this protocol.

Check out XKMS, a W3C Note and new standards Activity.  It addresses
similar problems (and then some), in a purely XML environment.  Better
to use XKMS than to let the XML nose under the PKIX tent. :)
	/r$
-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com


Received: by above.proper.com (8.11.6/8.11.3) id g09Cj5x13158 for ietf-pkix-bks; Wed, 9 Jan 2002 04:45:05 -0800 (PST)
Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09Cj3313154 for <[e-mail]>; Wed, 9 Jan 2002 04:45:03 -0800 (PST)
Received: from fwd05.sul.t-online.de  by mailout10.sul.t-online.de with smtp  id 16OI6J-0003In-05; Wed, 09 Jan 2002 13:45:03 +0100
Received: from junker.stroeder.com (520010731148-0001@[217.1.21.165]) by fmrl05.sul.t-online.com with esmtp id 16OI6F-1YpxqKC; Wed, 9 Jan 2002 13:44:59 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 8B2C1157D03 for <[e-mail]>; Wed,  9 Jan 2002 13:41:52 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 09 Jan 2002 13:41:51 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: Re: URL schemes in draft-ietf-pkix-new-part1-11
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Michael Ströder wrote:
> 
> draft-ietf-pkix-new-part1-11 references RFC 1778 for ldap URL scheme
> which is LDAPv2. It was decided that LDAPv2 RFCs are shifted to
> historic soon => RFC 2255 should be referenced for LDAP URLs
> instead.

Additionally RFC 1738 (describing URL schemes ftp and http) was
updated by RFC1808, RFC2368, RFC2396.

Ciao, Michael.


Received: by above.proper.com (8.11.6/8.11.3) id g09Bm6t11445 for ietf-pkix-bks; Wed, 9 Jan 2002 03:48:06 -0800 (PST)
Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g09Bm4311441 for <[e-mail]>; Wed, 9 Jan 2002 03:48:05 -0800 (PST)
Received: from fwd10.sul.t-online.de  by mailout01.sul.t-online.de with smtp  id 16OHDA-0002x1-07; Wed, 09 Jan 2002 12:48:04 +0100
Received: from junker.stroeder.com (520010731148-0001@[217.1.24.28]) by fmrl10.sul.t-online.com with esmtp id 16OHD1-2HC3xwC; Wed, 9 Jan 2002 12:47:55 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id B803A157D03 for <[e-mail]>; Wed,  9 Jan 2002 12:47:48 +0100 (CET)
Message-ID: <[e-mail]>
Date: Wed, 09 Jan 2002 12:47:48 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: "[e-mail]" <[e-mail]>
Subject: URL schemes in draft-ietf-pkix-new-part1-11
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

HI!

draft-ietf-pkix-new-part1-11 references RFC 1778 for ldap URL scheme
which is LDAPv2. It was decided that LDAPv2 RFCs are shifted to
historic soon => RFC 2255 should be referenced for LDAP URLs
instead.

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0974eb06645 for ietf-pkix-bks; Tue, 8 Jan 2002 23:04:40 -0800 (PST)
Received: from servere.csc.cuhk.edu.hk (servere.itsc.cuhk.edu.hk [137.189.29.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0974c306635 for <[e-mail]>; Tue, 8 Jan 2002 23:04:39 -0800 (PST)
Received: by servere.itsc.cuhk.edu.hk with Internet Mail Service (5.5.2653.19) id <YYC5CPHP>; Wed, 9 Jan 2002 15:04:42 +0800
Message-ID: <[e-mail]>
From: Jason Yeung <[e-mail]>
To: "'[e-mail]'" <[e-mail]>, [e-mail], [e-mail]
Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard
Date: Wed, 9 Jan 2002 15:04:40 +0800 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

I have tried it successfully, port 318 thru tcp socket.

Rgds,
Jason

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
Sent: Wednesday, January 09, 2002 11:55 AM
To: [e-mail]; [e-mail]
Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard



Scott Mustard <[e-mail]> writes:

>Datum's StampServer is available for test at 64.241.183.87,

Which port, and which protocol?

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0958JG02841 for ietf-pkix-bks; Tue, 8 Jan 2002 21:08:19 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0958I302837 for <[e-mail]>; Tue, 8 Jan 2002 21:08:18 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id SAA27187; Wed, 9 Jan 2002 18:08:12 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA148750; Wed, 9 Jan 2002 18:08:12 +1300 (NZDT) (sender [e-mail])
Date: Wed, 9 Jan 2002 18:08:12 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Michael StrM-vder <[e-mail]> writes:

>While I understand the rationale in section 3.4 that AIA and CRLDP extensions
>are different in semantics I think the CRL could be retrieved via
>CRLDistributionPoint as long as the HTTP certificate store interface behaves
>as expected for CRLDistributionPoint. 

But it doesn't behave that way.  As the rationale points out, CRLDP points at a
static CRL while the draft uses a general CRL query mechanism.  To put it
another way, let's say you get a cert with a CRLDP containing a URI:

  foo.bar.com/qwertyuiop

What are you supposed to do with this?  If you follow CRLDP semantics, you go
to foo.bar.com and do a GET /qwertyuiop HTTP/1.0.  If you follow the draft
semantics you go to foo.bar.com and do a GET /qwertyuiop/search-cgi?iHash=
<search key> HTTP/1.0 (or whatever key you're using).  Unless you completely
redefine the semantics of CRLDP to constrain it to follow the functionality in
the draft, you can't do this.

>But I don't understand this sentence in section 3.4: "In addition CRLDP
>associates other attribute information with a query which is incompatible with
>the simple query mechanisms presented in this document."

You can specify all sorts of stuff like reason flags which can't be accomodated
by a key-and-value lookup mechanism.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g094xmd02569 for ietf-pkix-bks; Tue, 8 Jan 2002 20:59:48 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g094xj302561 for <[e-mail]>; Tue, 8 Jan 2002 20:59:46 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id RAA26095; Wed, 9 Jan 2002 17:59:39 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA148615; Wed, 9 Jan 2002 17:59:39 +1300 (NZDT) (sender [e-mail])
Date: Wed, 9 Jan 2002 17:59:39 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Michael StrM-vder <[e-mail]> writes:

>Maybe it's me (I'm not a native english speaker) but I read it like all search
>values have to be hashed and base64-encoded except subjectKeyIdentifier. How
>about e.g. search attribute email? To avoid misinterpretation I'd prefer
>having a table which states exactly how to treat each search attribute on the
>client side if necessary before submitting the query. Or at least starting
>section 2.1 with "The fields [complete binary attribute list]...are of"
>instead of "Some of the fields...are of".

Done.

>IMHO for a low-tech use-case with wide-spread acceptance ;-) it should be
>possible to create a simple HTML form with the <form>'s attribute action=
>pointing to the URL of the "HTTP Certificate Store Interface". For this simple
>scenario pre-processing (hashing) of search values at the client side is
>unfeasible (except when using Javascript or similar beasty things).

The human-usable forms are all text-only.  I doubt a user will ever want to
construct an issuerAndSerialNumber from a hex dump of a cert just to fetch it
from a directory.  In fact users aren't meant to use the interface at this
level at all.  This interface really isn't meant for use by humans, it's a
universal interface to a cert store which happens to use HTTP to achieve
universality.

>I'd also suggest that it should be possible to pass a subject DN in RFC2253
>string representation as (x-www-form-urlencoded) search value. 

Web-to-LDAP interface issues are already covered in various RFCs, I didn't want
to wander into other people's territory.  It's also a pretty LDAP-specific
mechanism, you can't just grab a binary string from a cert, hash it, and do a
lookup, you have to follow fairly complex LDAP name-representation rules.  I'd
rather leave this to other RFCs which seem to cover it adequately.

>My suggestion would be to run certificate stores holding e-mail certs
>associated to e-mail domains. 

That's pretty much how it's meant to work.  If I know your email address is
@hotmail.com, I'd go to certificates.hotmail.com and ask for your cert.  If you
work for a certain government agency, I'd ask at ...agencysite.gov.  That's
also why the draft specifically mentions support for redirects, if you're
outsourcing the cert-storage task you can point to where the certs really are
(at worst you need to add a single static page pointing to the real server) -
did I mention in a previous message that there's a bit of practical experience
in using this? :-).  It's not perfect, but it's good enough, and pretty
transparent.

(I've added another paragraph to the rationale to cover this).

>I cannot really comment on UPNP and determining net_loc but is net_loc really
>solely an IP address or a DNS name as you described or a host:port location?

It's an IP address or DNS name.  Port is always 80.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g094KnO01588 for ietf-pkix-bks; Tue, 8 Jan 2002 20:20:49 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g094Kk301584 for <[e-mail]>; Tue, 8 Jan 2002 20:20:47 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id RAA26319; Wed, 9 Jan 2002 17:20:35 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id RAA147993; Wed, 9 Jan 2002 17:20:29 +1300 (NZDT) (sender [e-mail])
Date: Wed, 9 Jan 2002 17:20:29 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"Piers Chivers" <[e-mail]> writes:

>This may be off-topic but have you considered a SOAP version of this protocol.
>SOAP messages can be transported over http, hence meeting this requirement,
>but can also be transported over SMTP etc.  This seems to me to be a more
>general approach than the one described here.

I've had comments from people about XML versions ages ago (the certs-over-http
stuff has been in use privately for awhile, which is why some of the stuff in
the draft is based on implementation experience), but I'll leave that to
someone else.  I just wanted to create a lowest-common-denominator gimme-a-cert
mechanism which is as plug-and-play as possible, if anyone wants something more
complex they can profile it or whatever.

(I'm also not too sure what SOAP would add, apart from making it a lot less
 general).

>email       "Email address contained in the certificate..." What does this
>mean? I think you should be more explicit. Will the search be against an email
>attribute in the subject DN, or an attribute in the subject alternative name...

It doesn't matter.  An email address is an email address, they can stuff it in
the keyUsage for all I care.

>"The one exception to this process is the subjectKeyIdentifier..." I hate
>exceptions to rules;)  Why bother with this proviso?  OK, it stops one
>needless hash but it introduces additional coding at both the client and
>server.  Why not just hash the hash?

Actually where it's being used at the moment the hash is hashed, mostly because
sKIDs can have arbitrary lengths and you need a way to make them uniform.  I
didn't do the hash-of-hash because I thought there'd be complaints, but I agree
with you that it's a better way to do it.  I'll fix it in the next draft.

>Although earlier text indicates why, the examples for retrieving a CA cert and
>a CRL are identical in this section.  I think this should be clarified (by
>indicating a query URI appropriately)

Done.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g093tYe00906 for ietf-pkix-bks; Tue, 8 Jan 2002 19:55:34 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g093tW300902 for <[e-mail]>; Tue, 8 Jan 2002 19:55:32 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id QAA25589; Wed, 9 Jan 2002 16:55:28 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA146976; Wed, 9 Jan 2002 16:55:27 +1300 (NZDT) (sender [e-mail])
Date: Wed, 9 Jan 2002 16:55:27 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Scott Mustard <[e-mail]> writes:

>Datum's StampServer is available for test at 64.241.183.87,

Which port, and which protocol?

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08LjC319965 for ietf-pkix-bks; Tue, 8 Jan 2002 13:45:12 -0800 (PST)
Received: from jupiter.bj.co.uk ([195.217.233.100]) by above.proper.com (8.11.6/8.11.3) with SMTP id g08Lj9319960 for <[e-mail]>; Tue, 8 Jan 2002 13:45:10 -0800 (PST)
Received: from 194.72.164.27 by jupiter.bj.co.uk with ESMTP (WorldSecure Server SMTP Relay(WSS) v4.5); Tue, 08 Jan 2002 21:44:43 -0000
X-Server-Uuid: 3da21eb0-4d9e-11d4-96af-00b0d018dd71
Received: by bjex1.bj.co.uk with Internet Mail Service (5.5.2650.21) id <Z0D2J0DW>; Tue, 8 Jan 2002 21:41:44 -0000
Message-ID: <[e-mail]>
From: "Piers Chivers" <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Date: Tue, 8 Jan 2002 21:41:44 -0000
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
X-WSS-ID: 1025B7C166111-01-01
Content-Type: multipart/alternative;  boundary="----_=_NextPart_001_01C1988D.442A8032"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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_01C1988D.442A8032
Content-Type: text/plain; 
 charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter,
This may be off-topic but have you considered a SOAP version of this
protocol.  SOAP messages can be transported over http, hence meeting this
requirement, but can also be transported over SMTP etc.  This seems to me to
be a more general approach than the one described here.
 
Section 2.
email       "Email address contained in the certificate..." 
What does this mean? I think you should be more explicit. Will the search be
against an email attribute in the subject DN, or an attribute in the subject
alternative name...
 
Section 2.1
"The one exception to this process is the subjectKeyIdentifier..." 
I hate exceptions to rules;)  Why bother with this proviso?  OK, it stops
one needless hash but it introduces additional coding at both the client and
server.  Why not just hash the hash?
 
Section 2.2
Although earlier text indicates why, the examples for retrieving a CA cert
and a CRL are identical in this section.  I think this should be clarified
(by indicating a query URI appropriately)
 
Section 2.2 Rational
Typo - should be Section 2.3
I appreciate your rationale but, as a client implementer, I don't want to
care what technology the CA is using to store the certs (RDBMS, LDAP,
whatever). But, as an LDAP zealot, I think there is a requirement to support
cert lookup by a textual representation of the subject DN.  Maybe the LDAP
server vendors can comment?
 
Regards,
Piers
 
 
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 Operational  
                          Protocols: Certificate Store Access via HTTP
      Author(s)   : P. Gutmann
      Filename    : draft-ietf-pkix-certstore-http-01.txt
      Pages       : 
      Date        : 04-Jan-02
      
 
 
 
Piers Chivers
Product Architect
Protek Network Security
[phone]
www.protek.com <http://www.protek.com> 
 

--------------------------------------------------------------------------------
This message is for the named person's use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient.  PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all email communications through its network.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.



------_=_NextPart_001_01C1988D.442A8032
Content-Type: text/html; 
 charset=us-ascii
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">


<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:filelist.xml@01C1988E.29078060">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"date"/>
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[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]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{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";}
span.EmailStyle18
	{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;}
-->
</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";}
table.MsoTableColorful2
	{mso-style-name:"Table Colorful 2";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	border:none;
	border-bottom:solid black 1.5pt;
	mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:gray-20 yellow;
	mso-para-margin:0cm;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
table.MsoTableColorful2FirstRow
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-row;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid maroon;
	mso-tstyle-border-bottom:1.5pt solid black;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	color:white;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2FirstCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:first-column;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:italic;
	mso-bidi-font-style:italic;}
table.MsoTableColorful2LastCol
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:last-column;
	mso-tstyle-shading:white;
	mso-tstyle-pattern:solid silver;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;}
table.MsoTableColorful2SWCell
	{mso-style-name:"Table Colorful 2";
	mso-table-condition:sw-cell;
	mso-tstyle-diagonal-down:0cm none windowtext;
	mso-tstyle-diagonal-up:0cm none windowtext;
	mso-ansi-font-weight:bold;
	mso-bidi-font-weight:bold;
	mso-ansi-font-style:normal;
	mso-bidi-font-style:normal;}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:36.0pt'>

<div class=3DSection1>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Peter,<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>This
may be off-topic but have you considered a SOAP version of this =
protocol.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>SOAP messages can be =
transported over http,
hence meeting this requirement, but can also be transported over SMTP =
etc.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>This seems to me to be a more =
general
approach than the one described here.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DGramE><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>Section 2.</span></font></span><font =
size=3D2
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><span
class=3DGramE><font size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;
font-family:"Courier New"'>email</span></font></span><font size=3D2
face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'> <span
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>&quot;Email address contained in the
certificate...&quot; <o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>What
does this mean? I think you should be more explicit. Will the search be =
against
an email attribute in the subject DN, or an attribute in the subject
alternative name...<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>Section
2.1<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>&quot;The
one exception to this process is the <span =
class=3DSpellE>subjectKeyIdentifier</span>...&quot;
<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span style=3D'font-size:10.0pt;font-famil=
y:"Courier New"'>I
hate exceptions to <span class=3DGramE>rules;</span>)<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Why bother with this =
proviso?<span
style=3D'mso-spacerun:yes'>&nbsp; </span>OK, it stops one needless hash =
but it
introduces additional coding at both the client and server.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Why not just hash the =
hash?<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>Section
2.2<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>Although
earlier text indicates why, the examples for retrieving a CA cert and a =
CRL are
identical in this section.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>I think this
should be clarified (by indicating a query URI =
appropriately)<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>Section
2.2 Rational<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>Typo
- should be Section 2.3<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>I
appreciate your rationale but, as a client implementer, I don't want to =
care
what technology the CA is using to store the <span =
class=3DSpellE>certs</span>
(RDBMS, LDAP, whatever). But, as an LDAP zealot, I think there is a =
requirement
to support cert lookup by a textual representation of the subject =
DN.<span
style=3D'mso-spacerun:yes'>&nbsp; </span>Maybe the LDAP server vendors =
can comment?<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Regards,<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>Piers<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'>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.<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>Title<span =
style=3D'mso-tab-count:2'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>:
Internet X.509 Public Key Infrastructure Operational<span
style=3D'mso-spacerun:yes'>&nbsp; </span><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-spacerun:yes'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>Protocols:
Certificate Store Access via HTTP<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>Author(s)<span style=3D'mso-tab-count:1'>&nbsp;&nbsp; </span>:
P. <span class=3DSpellE>Gutmann</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>Filename<span style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp; =
</span>:
draft-ietf-pkix-certstore-http-01.txt<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>Pages<span =
style=3D'mso-tab-count:2'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span>:
<o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>Date<span =
style=3D'mso-tab-count:2'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span>:
</span></font><st1:date Month=3D"1" Day=3D"4" Year=3D"2002"><font =
size=3D2
 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'>04-Jan-02</span></font></st1:date><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier New"'><span
style=3D'mso-tab-count:1'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
</span><o:p></o:p></span></font></p>

<p class=3DMsoNormal =
style=3D'mso-layout-grid-align:none;text-autospace:none'><font
size=3D2 face=3D"Courier New"><span =
style=3D'font-size:10.0pt;font-family:"Courier =
New"'><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'><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'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoAutoSig><st1:PersonName><font size=3D2 face=3D"Times New =
Roman"><span
 lang=3DEN-GB =
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'>Pier=
s
 Chivers</span></font></st1:PersonName><font size=3D2><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p=
></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'>Prod=
uct
Architect</span></font><span =
style=3D'mso-no-proof:yes'><o:p></o:p></span></p>

<p class=3DMsoAutoSig><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'>Prot=
ek
Network Security<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D2 face=3D"Times New Roman"><span =
lang=3DEN-GB
style=3D'font-size:10.0pt;mso-ansi-language:EN-GB;mso-no-proof:yes'>+44 =
(0)1270
507800<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><u><font size=3D2 color=3D"#0080ff" face=3D"Times =
New Roman"><span
lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;mso-ansi-language:EN-GB;
mso-no-proof:yes'><a =
href=3D"http://www.protek.com">www.protek.com</a></span></font></u><font=

size=3D2 color=3D"#0080ff"><span lang=3DEN-GB =
style=3D'font-size:10.0pt;color:#0080FF;
mso-ansi-language:EN-GB;mso-no-proof:yes'><o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

--------------------------------------------------------------------------------<br>
This message is for the named person's use only.  It may contain confidential, proprietary or legally privileged information.  No confidentiality or privilege is waived or lost by any mistransmission.  If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender.  You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient.  PROTEK Network Management Group and each of its subsidiaries reserve the right to monitor all email communications through its network.  Any views expressed in this message are those of the individual sender, except where the message states otherwise and the sender is authorised to state them to be the views of any such entity.<br>
<br>
<br>

------_=_NextPart_001_01C1988D.442A8032--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08JlCp15679 for ietf-pkix-bks; Tue, 8 Jan 2002 11:47:12 -0800 (PST)
Received: from tiznit.digitaldelivery.com (wks99.digitaldelivery.com [64.241.183.99]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08JlA315675 for <[e-mail]>; Tue, 8 Jan 2002 11:47:11 -0800 (PST)
Received: by TIZNIT with Internet Mail Service (5.5.2653.19) id <Y4G1KHJC>; Tue, 8 Jan 2002 14:47:07 -0500
Message-ID: <C734DAA35F96D511A7BD0002B33B3A050D1AE0@TIZNIT>
From: Scott Mustard <[e-mail]>
To: "PKIX (E-mail)" <[e-mail]>
Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard
Date: Tue, 8 Jan 2002 14:46:58 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Datum's StampServer is available for test at 64.241.183.87.  If your request
includes the certReq field set to true, the time-stamp token will include an
attribute certificate in addition to the required TSA certificate.  Some
decoders cannot handle attribute certificates in the certificate list.  If
you have a problem decoding our response, we can supply the ASN.1 definition
for attribute certificates and for our timing-metrics attribute.


Regards,


Scott Mustard

Datum - Trusted Time Division
http://www.datum.com/tt/
10 Maguire Road Suite 120
Lexington, MA 02421-3110


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08IxVT14130 for ietf-pkix-bks; Tue, 8 Jan 2002 10:59:31 -0800 (PST)
Received: from serv1.is1.u-net.net (serv1.is1.u-net.net [195.102.240.129]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08IxU314126 for <[e-mail]>; Tue, 8 Jan 2002 10:59:30 -0800 (PST)
Received: from [64.24.208.197] (helo=salford.ac.uk) by serv1.is1.u-net.net with esmtp (Exim 3.12 #1) id 16O1T0-0002BU-00 for [e-mail]; Tue, 08 Jan 2002 18:59:23 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Jan 2002 18:52:51 +0000
From: David Chadwick <[e-mail]>
Organization: University of Salford
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: PKIX <[e-mail]>
Subject: SLides for SLC
Content-Type: multipart/mixed; boundary="------------9C2352FA257A15290F380C89"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

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

Steve

I tried to send my slides to you, but the message was bounced from your
site. Perhaps the roving ISP I am using is banned by your administrator
as a perveyor of SPAM? Should I send them to the list?

David

-- 
*****************************************************************

David W. Chadwick, BSc PhD
Professor of Information Systems Security
IS Institute, University of Salford, Salford M5 4WT
Tel: [phone]  Fax [phone]
Mobile: [phone]
Email: [e-mail]
Home Page:  http://www.salford.ac.uk/its024/chadwick.htm
Research Projects: http://sec.isi.salford.ac.uk
Understanding X.500:  http://www.salford.ac.uk/its024/X500.htm
X.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm
Entrust key validation string: MLJ9-DU5T-HV8J
PGP Key ID is 0xBC238DE5

*****************************************************************
--------------9C2352FA257A15290F380C89
Content-Type: text/x-vcard; charset=us-ascii;
 name="d.w.chadwick.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Chadwick
Content-Disposition: attachment;
 filename="d.w.chadwick.vcf"

begin:vcard 
n:Chadwick;David
tel;cell:[phone]
tel;fax:[phone]
tel;home:[phone]
tel;work:[phone]
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[e-mail]
title:Professor of Information Security
adr;quoted-printable:;;The Crescent=0D=0A;Salford;Greater Manchester;M5 4WT;England
note;quoted-printable:Research Projects: http://sec.isi.salford.ac.uk.......................=0D=0A=0D=0AUnderstanding X.500:  http://www.salford.ac.uk/its024/X500.htm .......................=0D=0A=0D=0AX.500/LDAP Seminars: http://www.salford.ac.uk/its024/seminars.htm...................=0D=0A=0D=0AEntrust key validation string: CJ94-LKWD-BSXB ...........=0D=0A=0D=0APGP Key ID is 0xBC238DE5
x-mozilla-cpt:;-4856
fn:David Chadwick
end:vcard

--------------9C2352FA257A15290F380C89--




Received: by above.proper.com (8.11.6/8.11.3) id g08HiqK11175 for ietf-pkix-bks; Tue, 8 Jan 2002 09:44:52 -0800 (PST)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08Hip311169 for <[e-mail]>; Tue, 8 Jan 2002 09:44:51 -0800 (PST)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g08HhEU09251 for <[e-mail]>; Tue, 8 Jan 2002 12:43:14 -0500 (EST)
Message-ID: <[e-mail]>
Date: Tue, 08 Jan 2002 12:43:06 -0500
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]> <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

CRLDP is, IMHO, fundamentally flawed because it combines two
unrelated functions:

1. cryptographically binding a certificate to the specific
partitioned CRL that applies to that certificate, and

2. facilitating retrieval of the CRL from a repository.


PKIX Part 1 Section 6.3.3: CRL Processing gives the algorithm
for determining if a certificate is revoked.  Step 1 is:

  "(1) locate the corresponding CRL in CRL cache, and ..."

The "corresponding CRL" is determined by comparing the CRLDP
extension in the certificate with the IDP extension in the
cached CRLs, using an algorithm that is not completely
specified.  For example, if CRLDP and IDP each contain a
DistributionPointName:fullName with two GeneralName's:
a directoryName that matches and a URI that does not match,
does the CRL correspond to the certificate or not?

I believe that the CRL partitioning algorithm should say
that URI forms of DistributionPointName are *not* compared
when determining if a CRL applies to a particular certificate,
and that other forms of DPN *are* compared.

But since that would be a butt-ugly special-case hack of a
rule, I agree with Peter that AIA should be used to hold
retrieval information, and CRLDP/IDP should be used to hold
only partitioning information.


The next-to-last sentence of Section 6.3.3 is:

  "The verifier must repeat the process above with the
   additional CRLs not specified in a distribution point."

How are those additional CRLs retrieved?  AIA.

Regards,
Dave




Michael Ströder wrote:
> 
> Russel F Weiser wrote:
> >
> > 3. I don't understand why the CRLDP extension could not be leveraged to
> > support URI based queries you discribe in your draft? To me this seems
> > like the logical location to place the CRL query uri.
> 
> While I understand the rationale in section 3.4 that AIA and CRLDP
> extensions are different in semantics I think the CRL could be
> retrieved via CRLDistributionPoint as long as the HTTP certificate
> store interface behaves as expected for CRLDistributionPoint. IMHO
> this mainly depends on what search attributes/values are used for
> forming the URI.
> 
> An additional note could state that the issuer MAY use the URI of
> the issuer's HTTP certificate store interface for generating a URI
> for extension CRLDistributionPoint.distributionPoint.fullName but is
> certainly responsible for generating a URI which works as expected
> for semantics of CRLDistributionPoint.
> 
> But I don't understand this sentence in section 3.4:
> "In addition CRLDP associates other attribute information with a
> query which is
> incompatible with the simple query mechanisms presented in this
> document."
> 
> > I still believe the CRLDP should be used for CRL retrieval.
> 
> Me too. ;-)
> 
> Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08FIZc06021 for ietf-pkix-bks; Tue, 8 Jan 2002 07:18:35 -0800 (PST)
Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08FIY306015 for <[e-mail]>; Tue, 8 Jan 2002 07:18:34 -0800 (PST)
Received: from fwd03.sul.t-online.de  by mailout02.sul.t-online.de with smtp  id 16Ny1F-000509-09; Tue, 08 Jan 2002 16:18:29 +0100
Received: from junker.stroeder.com (520010731148-0001@[217.1.20.12]) by fmrl03.sul.t-online.com with esmtp id 16Ny0z-0N1yyWC; Tue, 8 Jan 2002 16:18:13 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 5C3C0157CE2 for <[e-mail]>; Tue,  8 Jan 2002 16:19:50 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 08 Jan 2002 16:19:49 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Michael Ströder wrote:
> 
> IMHO locating a cert store in the Internet falls into two different
> steps:
> 1. Locating a server name or IP address *and* port of a cert store
> 2. Some well-defined addressing rules once the IP address is known

BTW: Although not necessary for security a service provider running
a HTTP cert store might want to provide this service with SSL for
privacy reasons. Therefore the URL scheme is part of the 1. step.
=> Section 3.2 has to define rules for deriving URL scheme,
   host name/IP address and port number.

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08CfeW26744 for ietf-pkix-bks; Tue, 8 Jan 2002 04:41:40 -0800 (PST)
Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08Cfd326740 for <[e-mail]>; Tue, 8 Jan 2002 04:41:39 -0800 (PST)
Received: from fwd09.sul.t-online.de  by mailout11.sul.t-online.de with smtp  id 16NvZT-0008B6-01; Tue, 08 Jan 2002 13:41:39 +0100
Received: from junker.stroeder.com (520010731148-0001@[62.224.169.127]) by fmrl09.sul.t-online.com with esmtp id 16NvZ9-1TaezAC; Tue, 8 Jan 2002 13:41:19 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id 997C4157CE2 for <[e-mail]>; Tue,  8 Jan 2002 13:42:56 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 08 Jan 2002 13:42:56 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russel F Weiser wrote:
> 
> 3. I don't understand why the CRLDP extension could not be leveraged to
> support URI based queries you discribe in your draft? To me this seems
> like the logical location to place the CRL query uri.

While I understand the rationale in section 3.4 that AIA and CRLDP
extensions are different in semantics I think the CRL could be
retrieved via CRLDistributionPoint as long as the HTTP certificate
store interface behaves as expected for CRLDistributionPoint. IMHO
this mainly depends on what search attributes/values are used for
forming the URI.

An additional note could state that the issuer MAY use the URI of
the issuer's HTTP certificate store interface for generating a URI
for extension CRLDistributionPoint.distributionPoint.fullName but is
certainly responsible for generating a URI which works as expected
for semantics of CRLDistributionPoint.

But I don't understand this sentence in section 3.4:
"In addition CRLDP associates other attribute information with a
query which is
incompatible with the simple query mechanisms presented in this
document."

> I still believe the CRLDP should be used for CRL retrieval.

Me too. ;-)

Ciao, Michael.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g08CJ5U26166 for ietf-pkix-bks; Tue, 8 Jan 2002 04:19:05 -0800 (PST)
Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g08CJ3326161 for <[e-mail]>; Tue, 8 Jan 2002 04:19:03 -0800 (PST)
Received: from fwd03.sul.t-online.de  by mailout09.sul.t-online.de with smtp  id 16NvDV-0003oW-02; Tue, 08 Jan 2002 13:18:57 +0100
Received: from junker.stroeder.com (520010731148-0001@[217.1.20.8]) by fmrl03.sul.t-online.com with esmtp id 16NvDF-100np2C; Tue, 8 Jan 2002 13:18:41 +0100
Received: from stroeder.com (localhost [127.0.0.1]) by junker.stroeder.com (Postfix) with ESMTP id B1F58157CE2 for <[e-mail]>; Tue,  8 Jan 2002 13:19:29 +0100 (CET)
Message-ID: <[e-mail]>
Date: Tue, 08 Jan 2002 13:19:29 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[e-mail]>
Reply-To: [e-mail]
Organization: stroeder.com
X-Mailer: Mozilla 4.79 [en] (X11; U; Linux 2.4.17 i686)
X-Accept-Language: de-DE, de, en
MIME-Version: 1.0
To: [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Sender: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

[e-mail] wrote:
> 
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-certstore-http-01.txt

I have some problems with section 2.1:

Maybe it's me (I'm not a native english speaker) but I read it like
all search values have to be hashed and base64-encoded except
subjectKeyIdentifier. How about e.g. search attribute email? To
avoid misinterpretation I'd prefer having a table which states
exactly how to treat each search attribute on the client side if
necessary before submitting the query. Or at least starting section
2.1 with "The fields [complete binary attribute list]...are of"
instead of "Some of the fields...are of".

IMHO for a low-tech use-case with wide-spread acceptance ;-) it
should be possible to create a simple HTML form with the <form>'s
attribute action= pointing to the URL of the "HTTP Certificate Store
Interface". For this simple scenario pre-processing (hashing) of
search values at the client side is unfeasible (except when using
Javascript or similar beasty things).

I'd also suggest that it should be possible to pass a subject DN in
RFC2253 string representation as (x-www-form-urlencoded) search
value. Maybe your could provide a separate search attribute
rfc2253Name? Even though the length is theoretically unlimited the
usual string length of DNs shouldn't be an issue with today's web
servers. E.g. for security reasons I'm limiting string repr. of DNs
to 1024 bytes in web2ldap and - guess what - never hit the limit. As
long as you don't impose a hard limit in the draft there shouldn't
be a problem with it.

Now off course the really interesting part is "3. Locating HTTP
Certificate Stores":

IMHO locating a cert store in the Internet falls into two different
steps:
1. Locating a server name or IP address *and* port of a cert store
2. Some well-defined addressing rules once the IP address is known

One should not mix these two levels.

The rules in section 3.2 for forming the URIs more or less
sufficiently addresses 2. by defining the well-known PATH_INFO
/search.cgi but fall short for 1.

Your example already shows the problem:
--------------- snip ---------------
  certificates.<domain_name>/search.cgi
  crls.<domain_name>/search.cgi

Service providers SHOULD use these URIs in preference to other
alternatives.
For example if a CA with the domain kiwisign.com were to make its
certificates
available via an HTTP certificate store interface, the "well-known"
query URIs
for certificates and CRLs would be:

  certificates.kiwisign.com/search.cgi
  crls.kiwisign.com/search.cgi"
--------------- snip ---------------

Now what's our use-case here? Most times a user has an e-mail
address of a recipient and wants to obtain the matching certificate
for the recipient's e-mail address. The sender does not know the
issuer of the certificate in advance => the <domain_name> in the
example above is unknown.

Or maybe I misunderstood something? Maybe it's not clear enough what
the term "service provider" means in this context. And that's
exactly the same case where LDAP-based cert stores fall short today.

My suggestion would be to run certificate stores holding e-mail
certs associated to e-mail domains. Like there are DNS MX RRs for
each e-mail domain there could be DNS SRV RRs for the e-mail domains
pointing to the certificate stores' DNS A or CNAME RR and port
number. In this case "service provider" would be the domain name
hoster for the recipient's e-mail address. IMHO
draft-ietf-pkix-pkixrep-00 went in that direction but expired
silently. :-(

I cannot really comment on UPNP and determining net_loc but is
net_loc really solely an IP address or a DNS name as you described
or a host:port location?

I think URI generation for both cases should be unified.

Ciao, Michael.


Received: by above.proper.com (8.11.6/8.11.3) id g087hJY24343 for ietf-pkix-bks; Mon, 7 Jan 2002 23:43:19 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g087hH324333 for <[e-mail]>; Mon, 7 Jan 2002 23:43:17 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id UAA29681; Tue, 8 Jan 2002 20:42:56 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id UAA123185; Tue, 8 Jan 2002 20:42:55 +1300 (NZDT) (sender [e-mail])
Date: Tue, 8 Jan 2002 20:42:55 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russel F Weiser <[e-mail]> writes:

>1. Within the section 2.2 examples the difference from the fetch of the CA
>certificate and the fetch of the CRL is only the URI base. You might want to
>note this difference in the examples just to clarify.

OK.

>2. The latest son of 2459 specifies a SubjectInfoAccess SIA which would be
>another approperiate certificate extension for also encoding the Certificate
>retrieval URI as discussed in 2.2 . I believe that going forward this should
>be the primarily used to access the certificats.

Good idea, I'll mention it in the next draft.

>3. I don't understand why the CRLDP extension could not be leveraged to
>support URI based queries you discribe in your draft? To me this seems like
>the logical location to place the CRL query uri.

It won't work, the rationale in 3.4 explains why.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g0855mD12920 for ietf-pkix-bks; Mon, 7 Jan 2002 21:05:48 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0855e312915 for <[e-mail]>; Mon, 7 Jan 2002 21:05:46 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id SAA26901; Tue, 8 Jan 2002 18:04:50 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id SAA119848; Tue, 8 Jan 2002 18:04:49 +1300 (NZDT) (sender [e-mail])
Date: Tue, 8 Jan 2002 18:04:49 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re:  tsp interop test vector (proposal)
Cc: [e-mail], [e-mail], [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

tho <[e-mail]> writes:

>in trying to organize some interop testing between all the publicly available
>rfc3161 implementations I have begun sketching down a set of test vectors and
>I'd like to discuss the matter with you ;-)

I don't know how well some of the negative-response testing will work.  For
example most of the policies I've seen are either unknown or just randomly-
invented OIDs, so my implementation ignores policies because otherwise it
couldn't interop with anything at all.  Based on the incredible number of bugs
in related stuff like certs (see for example the X.509 style guide) I'm also
extremely flexible with message contents, for example if the field looks more
or less right or doesn't affect the entire operation I just skip it and move
on.  In particular I ignore most of the stream-protocol flags based on the
confusion I saw in CMP interop testing when, no matter what flags were
(presumably erroneously) set, the other side usually just wanted the most basic
request-response operation.  Trying to fiddle with polling when the other side
has lost interest and gone home doesn't make your software look very functional
to the user.

(Aside: I have probably spent about an order of magnitude more time adding
 workarounds for bugs to my cert-handling code than in writing the original
 code itself.  Over time, I've also removed more and more checks on (non-
 security-related) items in order to get it to work with broken certs coming
 from other software.  There are still (security-related) checks in there which
 are rejecting certs which result in people sending me "bug" reports, but I'm
 not going to remove those... as a non-commercial vendor I can afford to lose a
 few users if they think it's a problem).

I would expect that other implementors are also writing code which tries to
DTRT in the face of broken requests and implementations.  This means that a lot
of the negative-response tests you're proposing would fail, because the other
side would look at the problem, decide it's irrelevant to the operation of the
protocol, and continue.  For example my policy OID is:

/* Dummy policy OID for the TSA ('snooze policy, "Anything that arrives, we
   sign") */

and I've never found an implementation which has any problems with this.

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07JHTK03063 for ietf-pkix-bks; Mon, 7 Jan 2002 11:17:29 -0800 (PST)
Received: from bach.digsigtrust.com (host65-54.digsigtrust.com [208.30.65.54]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07JHR303058 for <[e-mail]>; Mon, 7 Jan 2002 11:17:27 -0800 (PST)
Received: from smtp.digsigtrust.com by smtp1.digsigtrust.com  with ESMTP id g07JGm515930; Mon, 7 Jan 2002 12:16:48 -0700 (MST)
Received: from trustdst.com (host192-35-174-247.digsigtrust.com [192.35.174.247]) by smtp.digsigtrust.com with ESMTP id g07JEx028945; Mon, 7 Jan 2002 12:14:59 -0700 (MST)
Message-ID: <[e-mail]>
Date: Mon, 07 Jan 2002 12:16:33 -0700
From: Russel F Weiser <[e-mail]>
Reply-To: [e-mail]
Organization: Digital Signature Trust Co.
X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
CC: Peter Gutmann <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms98A47B4AC9B8F65D9B370C80"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a cryptographically signed message in MIME format.

--------------ms98A47B4AC9B8F65D9B370C80
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Peter, 
Several comments regarding your new draft. 


1. Within the section 2.2 examples the difference from the fetch of the
CA certificate 
and the fetch of the CRL is only the URI base. You might want to note
this difference
in the examples just to clarify. 

2. The latest son of 2459 specifies a SubjectInfoAccess SIA which would 
be another approperiate certificate extension for also encoding the
Certificate 
retrieval URI as discussed in 2.2 . I believe that going forward this
should be
the primarily used to access the certificats. 

3. I don't understand why the CRLDP extension could not be leveraged to
support
URI based queries you discribe in your draft? To me this seems like the
logical location 
to place the CRL query uri.  

It would seem that use the AIA Extension to get the Authority
certificate, SIA 
extension to get the subject extension and then use CRLDP to get the
CRLS would be the
best overall approach. 

If the certificate doesn't populate the SIA then the Client should
utilize the AIA extension to 
query for the Subjects certificate. I still believe the CRLDP should be
used for CRL retrieval. 
Unless you are also thinking of additionally supporting the concept of
allowing queries for a CRL form a particular CA with an added parameter
of asofDATE/TIME which could be a useful way of 
obtaining archived CRLs for use in attempting to valid signed data etc..

cheers
RFW
--------------ms98A47B4AC9B8F65D9B370C80
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIUKgYJKoZIhvcNAQcCoIIUGzCCFBcCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
EiYwggdPMIIGN6ADAgECAhEA0B5HQQAAAnwAAAALAAACQjANBgkqhkiG9w0BAQUFADBdMQsw
CQYDVQQGEwJVUzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRAwDgYD
VQQLEwdUcnVzdElEMRYwFAYDVQQDEw1UcnVzdElEIENBIEExMB4XDTAxMDYxNTAwMDc1MloX
DTAyMDYxNTAwMDc1MlowgeoxCzAJBgNVBAYTAlVTMQ0wCwYDVQQIEwRVdGFoMRcwFQYDVQQH
Ew5TYWx0IExha2UgQ2l0eTEgMB4GA1UEChMXRElHSVRBTCBTSUdOQVRVUkUgVFJVU1QxIDAe
BgNVBAsTF0RJR0lUQUwgU0lHTkFUVVJFIFRSVVNUMRgwFgYDVQQDEw9SdXNzZWwgRiBXZWlz
ZXIxIzAhBgkqhkiG9w0BCQEWFHJ3ZWlzZXJAdHJ1c3Rkc3QuY29tMTAwLgYKCZImiZPyLGQB
ARMgRDAxRTQ3NDEwMDAwMDBFNzE5Njc4NUIyMDAwMDAyNDQwgZ8wDQYJKoZIhvcNAQEBBQAD
gY0AMIGJAoGBAKHHyOSdcBO3q3jEfX6uvJweZNUlICehukslfQPQZ8nWKDHrzPKGQ590X9e7
4Ors0Z907ZgbjkWbbe9FyRNjSzzy+JvopT9eQQDe2xI50/4TFQx7aApT/7Mice5FcBXRM9Bu
X/7we5AmEmYjYuxPY++eFwUF0VMgDllSycRk5jQBAgMBAAGjggP+MIID+jAOBgNVHQ8BAf8E
BAMCBPAwHwYDVR0jBBgwFoAUKqXwfvTw7zTVnacomA8j05+7cwQwggFCBgNVHSAEggE5MIIB
NTCCATEGCmCGSAGG+S8ABgIwggEhMEcGCCsGAQUFBwIBFjtodHRwOi8vd3d3LmRpZ3NpZ3Ry
dXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzaW5kZXguaHRtbDCB1QYIKwYBBQUHAgIw
gcgagcVUaGlzIFRydXN0SUQgQ2VydGlmaWNhdGUgbWF5IG9ubHkgYmUgcmVsaWVkIHVwb24g
YnkgQXV0aG9yaXplZCBSZWx5aW5nIFBhcnRpZXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBU
cnVzdElEIENlcnRpZmljYXRlIFBvbGljeSBmb3VuZCBhdCBodHRwOi8vd3d3LmRpZ3NpZ3Ry
dXN0LmNvbS9jZXJ0aWZpY2F0ZXMvcG9saWN5L3RzaW5kZXguaHRtbDCBjwYDVR0fBIGHMIGE
MIGBoH+gfYZ7bGRhcDovL2xkYXAuZGlnc2lndHJ1c3QuY29tL2NuPVRydXN0SUQgQ0EgQTEs
b3U9VHJ1c3RJRCxvPURpZ2l0YWwgU2lnbmF0dXJlIFRydXN0IENvLixjPVVTP2NlcnRpZmlj
YXRlUmV2b2NhdGlvbkxpc3Q7YmluYXJ5MIHWBglghkgBhvhCAQ0EgcgWgcVUaGlzIFRydXN0
SUQgQ2VydGlmaWNhdGUgbWF5IG9ubHkgYmUgcmVsaWVkIHVwb24gYnkgQXV0aG9yaXplZCBS
ZWx5aW5nIFBhcnRpZXMgaW4gYWNjb3JkYW5jZSB3aXRoIHRoZSBUcnVzdElEIENlcnRpZmlj
YXRlIFBvbGljeSBmb3VuZCBhdCBodHRwOi8vd3d3LmRpZ3NpZ3RydXN0LmNvbS9jZXJ0aWZp
Y2F0ZXMvcG9saWN5L3RzaW5kZXguaHRtbDAfBgNVHREEGDAWgRRyd2Vpc2VyQHRydXN0ZHN0
LmNvbTAdBgNVHQ4EFgQUclmKR82awQP3Rhrn59Zyz6mYyhowgbYGCCsGAQUFBwEBBIGpMIGm
MCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5kaWdzaWd0cnVzdC5jb20wewYIKwYBBQUHMAKG
b2xkYXA6Ly9sZGFwLmRpZ3NpZ3RydXN0LmNvbS9jbj1UcnVzdElEIENBIEExLG91PVRydXN0
SUQsbz1EaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4sYz11cz9jQWNlcnRpZmljYXRlO2Jp
bmFyeTAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwDQYJKoZIhvcNAQEFBQADggEB
AEGFIP1YTvY/sDMMQGKPuq7fBjyRjblAUV9rKhwM3Lm5FcW1L2sciA8NIqRIpacm5jp8M7Wi
LFPfJMzSlRKqbETRUy2faYeXueGYlpSv2oSWVRxUQhqJK4oQa3k7NqERYChR1K6raLLwGgdn
UgfjIa0djWTlXBXXnOfSUohGBetMwOhugCanJT/VmLsSftwzk6oNpx5xK09ZgjBXQJjggudh
Uov5AnmlR9cWN3KsDfp6jH2xo9pLpd+V4Wb3SkUNkmjA5PsF9SY5J5bKy1zbXYMEGZqsEVV3
yE6LGCNCh5yuIyhSIFyORluAdR3krWJbbAXMLJIagG+B9Xkl9PRH/9EwggclMIIGDaADAgEC
AhEA0B5HOAAAAnwAAAACAAAACDANBgkqhkiG9w0BAQUFADA/MSQwIgYDVQQKExtEaWdpdGFs
IFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMTDkRTVCBSb290IENBIFgzMB4XDTAwMTAw
MTAwMDAwNFoXDTA1MTAwMTAwMDAwNFowXTELMAkGA1UEBhMCVVMxJDAiBgNVBAoTG0RpZ2l0
YWwgU2lnbmF0dXJlIFRydXN0IENvLjEQMA4GA1UECxMHVHJ1c3RJRDEWMBQGA1UEAxMNVHJ1
c3RJRCBDQSBBMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALgnPcD1Ny0/gmEg
PkAq5olccaeuuFNWeKWbwJU3iTON3D6wjKQ8/iW0SJbxhnvYFlqR8DlvsoiU0Lu9jIO/sGGf
Xh8n86hSsoe8yazGaQ6Ml73Tgntm7/LLTm+Y7soTzvbbH67lajmIxUhsUZv6GMDKjHFzaQR6
uj5Fmkb2hhuqbN/JUN5NhE/B4iEgOkO45RX/tSa0nWvwgoIwLTvUIgLeSzHA+Zv6YFFbUSFr
NKxAKSfb4IVEBBKeaA06Hnjvmz0A5uiKdyhc6VVT4ul//xp2HvELvKx/TbXbKVleyiLnWQDQ
DmgJV2kb0vajFIJeiXBV/Mj2NiJ1UTbXdBGxjJUCAwEAAaOCA/wwggP4MA8GA1UdEwEB/wQF
MAMBAf8wDgYDVR0PAQH/BAQDAgHGMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAf
BgNVHSMEGDAWgBTEp7Gkeyxx+tvhS5B1/8QVYIWJEDCCAncGA1UdIASCAm4wggJqMIIBMQYK
YIZIAYb5LwAGATCCASEwRwYIKwYBBQUHAgEWO2h0dHA6Ly93d3cuZGlnc2lndHJ1c3QuY29t
L2NlcnRpZmljYXRlcy9wb2xpY3kvdHNpbmRleC5odG1sMIHVBggrBgEFBQcCAjCByBqBxVRo
aXMgVHJ1c3RJRCBDZXJ0aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBvbiBieSBBdXRo
b3JpemVkIFJlbHlpbmcgUGFydGllcyBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIFRydXN0SUQg
Q2VydGlmaWNhdGUgUG9saWN5IGZvdW5kIGF0IGh0dHA6Ly93d3cuZGlnc2lndHJ1c3QuY29t
L2NlcnRpZmljYXRlcy9wb2xpY3kvdHNpbmRleC5odG1sMIIBMQYKYIZIAYb5LwAGAjCCASEw
RwYIKwYBBQUHAgEWO2h0dHA6Ly93d3cuZGlnc2lndHJ1c3QuY29tL2NlcnRpZmljYXRlcy9w
b2xpY3kvdHNpbmRleC5odG1sMIHVBggrBgEFBQcCAjCByBqBxVRoaXMgVHJ1c3RJRCBDZXJ0
aWZpY2F0ZSBtYXkgb25seSBiZSByZWxpZWQgdXBvbiBieSBBdXRob3JpemVkIFJlbHlpbmcg
UGFydGllcyBpbiBhY2NvcmRhbmNlIHdpdGggdGhlIFRydXN0SUQgQ2VydGlmaWNhdGUgUG9s
aWN5IGZvdW5kIGF0IGh0dHA6Ly93d3cuZGlnc2lndHJ1c3QuY29tL2NlcnRpZmljYXRlcy9w
b2xpY3kvdHNpbmRleC5odG1sMH0GA1UdHwR2MHQwcqBwoG6GbGxkYXA6Ly9sZGFwLmRpZ3Np
Z3RydXN0LmNvbS9jbj1EU1QgUm9vdCBDQSBYMyxvPURpZ2l0YWwgU2lnbmF0dXJlIFRydXN0
IENvLj9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0O2JpbmFyeTB8BggrBgEFBQcBAQRwMG4w
bAYIKwYBBQUHMAKGYGxkYXA6Ly9sZGFwLmRpZ3NpZ3RydXN0LmNvbS9jbj1EU1QgUm9vdCBD
QSBYMyxvPURpZ2l0YWwgU2lnbmF0dXJlIFRydXN0IENvLj9jQUNlcnRpZmljYXRlO2JpbmFy
eTAdBgNVHQ4EFgQUKqXwfvTw7zTVnacomA8j05+7cwQwDQYJKoZIhvcNAQEFBQADggEBAKP6
Q5KgNXM9H/ER5y5TncMvmLatjSaNV7ig983MXKfixbSKX77KUUoSL39378RVpNSVeiWvplNL
UDcuvuGMGRgDBXSmokdIjYhhMnaLXdcvqZ2J3SeCz6Muu2z8Ve9IGnNHApReJ82+iKXaxcxo
knk3ObfRtBjwIewELpLbjDiPdCsWuAcnbmcbm8e1dHrOfIwg3n97zLZbX8vRA1+xYCdElbLv
kOf2wIdDzYx2zRkmTHo/HQzXjZN/xF7Xnp8cwGENKtlt0Tgr0ddL7MohJtzzo3Dwe+uOuJV/
YVD57v7kYvVeZ0N7BKWCHQzGlYf5J5GWsSspofuDaZi/Ymr5N00wggOmMIICjqADAgECAhEA
0B5HGgAAAnwAAAAWAAAAAjANBgkqhkiG9w0BAQUFADCBqTELMAkGA1UEBhMCdXMxDTALBgNV
BAgTBFV0YWgxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MSQwIgYDVQQKExtEaWdpdGFsIFNp
Z25hdHVyZSBUcnVzdCBDby4xETAPBgNVBAsTCERTVENBIFgxMRYwFAYDVQQDEw1EU1QgUm9v
dENBIFgxMSEwHwYJKoZIhvcNAQkBFhJjYUBkaWdzaWd0cnVzdC5jb20wHhcNMDAxMDMwMjMy
OTU0WhcNMDgwODI5MjMyOTU0WjA/MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVz
dCBDby4xFzAVBgNVBAMTDkRTVCBSb290IENBIFgzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A
MIIBCgKCAQEA36/pl1AIg1e0zGJl9pCC7MfTLGswylvs2cN9x0DBGBSL4Ogzdkkq4z8hSZOs
Tg6vPkjLZe780yEPZdIq2TKPjOX3d7ASe7WVwImjqbrtcy56DAYyg6J+ihQwzRGg4So4uXkK
Mf1QvYBl37dRY4PI4ohh6kthgexSa7mi4ksaKJ9Io54M2gmOPhcuHt0g31vGKoqrLr1wrcUL
GiWQdHLFe2qrNNYwif/laBN7VAvI1q7sWpySHj1ks4zG37/JQXDsFnLVJuw4VTlD0Pz9GFxA
8Zfr1ZqbjR262iW5xtjfwRUCOqvabvE+LvVcCJw81oNp5BCbGSq2KVfj5T2bn/ACXQIDAQAB
ozIwMDAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBTEp7Gkeyxx+tvhS5B1/8QVYIWJEDAN
BgkqhkiG9w0BAQUFAAOCAQEAIph/TRYnCkJBg7jSj1iqB1rzjl67pxzAZRmN7hpOyX8bXipC
dMN5NMGOnUlSunXGUjw2OP3ickjrHGfYJgzN1G2HCZ8SR9tgBpzgGUywu5XA7KOPa8iCDNDH
28jXeCCUBC5qkIIRcEVMzYH+cpBFxkcwnrbEz2zcYQRmSxXAyVDh8VOyE7p8LxD6DgP9APtQ
JOgpN1UYSryAoZkOzzXwTJDBJpsng1/jSkecD4XHFKWR1fQFdxIf2uVmLlTjs69h91cAptIr
YyQyznHeWPDRoGc0b5Ka3GAHQplYrE32mfxHluW9io6+TNVK6t0PJnLaXymtpGWEdPxKqPSa
cRDD8DGCAcwwggHIAgEBMHIwXTELMAkGA1UEBhMCVVMxJDAiBgNVBAoTG0RpZ2l0YWwgU2ln
bmF0dXJlIFRydXN0IENvLjEQMA4GA1UECxMHVHJ1c3RJRDEWMBQGA1UEAxMNVHJ1c3RJRCBD
QSBBMQIRANAeR0EAAAJ8AAAACwAAAkIwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJ
KoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wMjAxMDcxOTE2MzVaMCMGCSqGSIb3DQEJBDEW
BBQ+pgZjw/LW8ZfjpqQpZ7ZQJXyJtjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4G
CCqGSIb3DQMCAgIAgDAHBgUrDgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAN
BgkqhkiG9w0BAQEFAASBgISL+4Fu3zo7xJaKLZNVdzMiBkYcsm2YP9PtI+mZKgQ9g224jSu8
GGvlSAPyVzc4fWujvHPrHMKT4Kkhl6VnITaGGQZUGj6hVWXcj4wvES8ybiLO65bfPGIVPSLm
pwcYerttjzDr4CnEEwQx0oCulGTUQ4n9GRFzMVkLtmc3F8EF
--------------ms98A47B4AC9B8F65D9B370C80--



Received: by above.proper.com (8.11.6/8.11.3) id g07Ggxi28793 for ietf-pkix-bks; Mon, 7 Jan 2002 08:42:59 -0800 (PST)
Received: from sentry.gw.tislabs.com ([e-mail] [192.94.214.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Ggw328785 for <[e-mail]>; Mon, 7 Jan 2002 08:42:58 -0800 (PST)
Received: by sentry.gw.tislabs.com; id LAA18175; Mon, 7 Jan 2002 11:48:13 -0500 (EST)
Received: from raven.gw.tislabs.com(10.33.1.50) by sentry.gw.tislabs.com via smap (V5.5) id xma018137; Mon, 7 Jan 02 11:47:51 -0500
Received: (from balenson@localhost) by raven.gw.tislabs.com (8.11.6/8.11.6) id g07GgaM29988 for [e-mail]; Mon, 7 Jan 2002 11:42:36 -0500 (EST)
Date: Mon, 7 Jan 2002 11:42:36 -0500 (EST)
Message-Id: <[e-mail]>
From: [e-mail]
To: [e-mail]
Subject: ANNOUNCE: NDSS'02 Early Registration Deadlines Approaching
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

R E G I S T E R   N O W ! !

EARLY REGISTRATION DISCOUNT DEADLINE:  January 11, 2002
HOTEL RESERVATIONS MUST BE MADE BY January 8, 2002


FINAL PROGRAM available at http://www.isoc.org/isoc/conferences/ndss/02/final.shtml.

2002 NETWORK AND DISTRIBUTED SYSTEM SECURITY SYMPOSIUM (NDSS'02) 
hosted by THE INTERNET SOCIETY 
February 6 - 8, 2002 
Catamaran Resort Hotel, San Diego, California

NDSS is the premier event for security experts around the world. Come to 
the 9th Annual NDSS and share in the latest concepts on the Internet 
security front. Southern California's Catamaran Resort Hotel offers 
spectacular views of Mission Bay and the Pacific Ocean, and is a warm sunny 
getaway with opportunities to confer with your security counterparts from 
across the globe.

For more information and on line registration go to the NDSS'02 web site: 
http://www.isoc.org/ndss02.

Questions about registration? Contact Michele Estadt at the Internet 
Society at [phone] ext 104 or send e-mail to 
[e-mail]. Interested in sponsoring a give-away or meal? Contact Martin
Kupres at [phone] or send e-mail to [e-mail].



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07E8AF21219 for ietf-pkix-bks; Mon, 7 Jan 2002 06:08:10 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07E89321215 for <[e-mail]>; Mon, 7 Jan 2002 06:08:09 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14678; Mon, 7 Jan 2002 09:08:07 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Date: Mon, 07 Jan 2002 09:08:07 -0500
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--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 Operational  
                          Protocols: Certificate Store Access via HTTP
	Author(s)	: P. Gutmann
	Filename	: draft-ietf-pkix-certstore-http-01.txt
	Pages		: 
	Date		: 04-Jan-02
	
The protocol conventions described in this document satisfy some of the
operational requirements of the Internet Public Key Infrastructure (PKI). This document specifies the conventions for using the Hypertext Transfer Protocol (HTTP) as an interface mechanism to obtain certificates and certificate revocation lists (CRLs) from PKI repositories (although RFC 2585 covers fetching certificates via HTTP, this merely mentions that certificates may be fetched from a static URL, which doesn't provide a general-purpose interface to a certificate store). Additional mechanisms addressing PKIX operational requirements are specified in separate documents.

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

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

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

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


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

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

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-certstore-http-01.txt

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

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

--OtherAccess--

--NextPart--




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07Dqoe20863 for ietf-pkix-bks; Mon, 7 Jan 2002 05:52:50 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07Dqm320859 for <[e-mail]>; Mon, 7 Jan 2002 05:52:48 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id OAA25610; Mon, 7 Jan 2002 14:53:47 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id OAA17480; Mon, 7 Jan 2002 14:52:16 +0100
Message-ID: <[e-mail]>
Date: Mon, 07 Jan 2002 14:52:21 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: Petra Barzin <[e-mail]>
CC: [e-mail]
Subject: Re: [Fwd: draft-ietf-pkix-dpv-dpd-req-00.txt &  draft-ietf-pkix-dsv-req-00.txt]
References: <[e-mail]>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g07Dqn320860
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Petra,

A new version has been posted last Friday to the web master. It should be
published "soon". While waiting for the publication, here is an answer to
your comments.

> Denis,
> 
> I never received an answer to my mail. Here it is once again!
> 
> I guess my timing of the mail wasn't very good since I posted
> it during the last IETF meeting. With the wrap up of the meeting
> and the christmas season you probably had enough to do.

You guessed very well. :-)

> Could you please answer or comment my questions / remarks now!
> 
> Thanks - Petra
> 
>   ----------------------------------------------------------------------------
> 
> Objet: Re: draft-ietf-pkix-dpv-dpd-req-00.txt & draft-ietf-pkix-dsv-req-00.txt
> Date: Sun, 09 Dec 2001 14:54:28 +0100
> De: Petra Barzin <[e-mail]>
> A: Denis Pinkas <[e-mail]>
> Copies à: pkix <[e-mail]>
> Références: <[e-mail]> <[e-mail]>
> 
> Denis,
> 
> I have three questions/comments regarding your DPV / DPD document:
> 
> - I would like to see the signature to be only optional in a DPV response.
> You require the DPV response to be integrity protected. But you could
> authenticate the server using other means, for example SSL server
> authentication.

The text I have been preparing after the meeting, cares about your concern.

"In order to be able to be confident that the validation of the 
certificate has correctly been done, the client only requires an 
authenticated response. 

In order for the client to prove to another party that trusts the 
same DPV server that the certificate validation was correct, the 
client requires a signed response."
 
> - A DPV or DPD request can only contain one certificate. Shouldn't it be
> possible to include more than one certifiacte in a request?

This has been corrected. The new text is:

"The Delegated Path Validation (DPV) protocol allows a server to 
validate one or more certificates according to a validation policy. "

> - Why do I need the optional requestor name in the DPV request and
> response? 

You do not need an optional requestor name in the DPV request. 
The new text is:

"The server may require client authentication. The authentication 
method to be used may be dependant upon the transport used, and thus 
the client authentication mechanism need not be an integral part of 
the DPV request."

> And why is this requestor name not included in the DPD protocol?

The requestor name will need to be included in the DPD protocol. 
The new text is:

"Policy definition requests SHALL be able to be authenticated so that 
only authorized clients can register policies."

Regards,

Denis
 
> Bye - Petra
> 
> Denis Pinkas schrieb:
> 
> > I have been asked by the co-chairs to prepare a requirements document for
> > DPV/DPD. While doing that task, requirements slighly different have been
> > identified for DSV. As a result of this request, you will find:
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-00.txt
> >
> > a document which describes a protocol for the validation of CERTIFICATES
> > (and for the discovery of certification paths), and
> >
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-dsv-req-00.txt
> >
> > a separate document which describes a protocol for the validation of
> > DIGITAL SIGNATURES.
> >
> > Both documents, which share several common points, will be presented
> > at the next IETF meeting.
> >
> > Denis


Received: by above.proper.com (8.11.6/8.11.3) id g07DDfd19611 for ietf-pkix-bks; Mon, 7 Jan 2002 05:13:41 -0800 (PST)
Received: from fep23-svc.tin.it (mta23-acc.tin.it [212.216.176.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07DDc319603 for <[e-mail]>; Mon, 7 Jan 2002 05:13:39 -0800 (PST)
Received: from skossa.andxor.it ([62.211.207.74]) by fep23-svc.tin.it (InterMail vM.4.01.03.13 201-229-121-113) with ESMTP id <[e-mail]>; Mon, 7 Jan 2002 14:13:22 +0100
Received: (from tho@localhost) by skossa.andxor.it (8.11.3/8.11.3) id g07DCmK01073; Mon, 7 Jan 2002 14:12:48 +0100 (CET) (envelope-from tho)
Date: Mon, 7 Jan 2002 14:12:48 +0100
From: tho <[e-mail]>
To: Denis Pinkas <[e-mail]>, Peter Sylvester <[e-mail]>, Peter Gutmann <[e-mail]>, Taglialagamba Bianca <[e-mail]>, Andrea Caccia <[e-mail]>, Antonio Lioy <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail]
Subject: tsp interop test vector (proposal)
Message-ID: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-Operating-System: FreeBSD
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

hello everybody,
in trying to organize some interop testing between all the publicly available 
rfc3161 implementations I have begun sketching down a set of test vectors and
I'd like to discuss the matter with you ;-)


the first (TSRQ-G_i) is made up of correctly formatted TimeStampReqs which 
we expect to be fulfilled by the TSA. 
Starting from a very basic request, we make vary some parameters:

  o TSRQ-G_001 -> basic request (none of the optional fields)
  o TSRQ-G_002 -> TSRQ-G_001 + nonce 
  o TSRQ-G_003 -> TSRQ-G_001 + reqPolicy{=one supported by the actual TSA} 
  o TSRQ-G_004 -> TSRQ-G_001 + certReq=TRUE 
  ... other

  for all these TimeStampReqs we expect to get the signed receipt of the 
  TSTInfo back from the TSA (which must be then verified in the many ways 
  stated by the rfc)

the second (TSRQ-E_i) is a vector of malformed (in a number of ways) 
TimeStampReqs:

  o TSRQ-E_001 -> bad asn.1 encoding (expected badDataFormat)
  o TSRQ-E_002 -> policy id not recognized (expected unacceptedPolicy)
  o TSRQ-E_003 -> weak or unknown hash algorithm (expected badAlg)
  o TSRQ-E_004 -> wrong protocol version (expected badRequest or badDataFormat)
  o TSRQ-E_005 -> length mismatch in messageImprint (expected badDataFormat)
  o TSRQ-E_006 -> unrecognized extension (expected unacceptedExtension)
  ... other

the third (SBP-E_i) is `Socket Based Protocol' specific (really there should 
be one of these vectors for each of the transport protocols including HTTP, 
SMTP, etc. but for now we can start with `Socket Based Protocol' which seems 
to be the most widely deployed) and consists of the following:

  o SBP-E_001 -> packet with pollRep flag set
  o SBP-E_002 -> packet with pollReq flag set
  o SBP-E_003 -> packet with negPollRep flag set
  o SBP-E_004 -> packet with partialMsgRep flag set
  o SBP-E_005 -> packet with finalMsgRep flag set
  o SBP-E_006 -> packet with errorMsgRep flag set

  for all those above we expect a rejection with failInfo=badRequest 

  o SBP-E_007 -> packet with length discrepancy (or a similar trick to
                 test if there is a time-out mechanism on I/O)
  ... other


I have just tried to use this framework for testing against my own 
implementation, the one from SIA and Peter Sylvester's (no SBP-E_i for him 
since the exposed interface is HTTP) and I've found it quite useful as it 
offers an _unified_ approach and the possibility to automate the procedure.

Surely we can go more in-depth than this, and in fact this is just a starting
point.

tho
--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g07A7bt08222 for ietf-pkix-bks; Mon, 7 Jan 2002 02:07:37 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g07A7Z308212 for <[e-mail]>; Mon, 7 Jan 2002 02:07:36 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2]) by gateway.secude.com (Postfix) with ESMTP id 2617BB6E6; Mon,  7 Jan 2002 11:08:04 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id ZKPQVB5F; Mon, 7 Jan 2002 11:08:03 +0100
Message-ID: <[e-mail]>
Date: Mon, 07 Jan 2002 11:09:12 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: [e-mail]
Cc: [e-mail]
Subject: [Fwd: draft-ietf-pkix-dpv-dpd-req-00.txt &  draft-ietf-pkix-dsv-req-00.txt]
Content-Type: multipart/mixed; boundary="------------E5FF020258A5E3ED0FA6FBC3"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Dies ist eine mehrteilige Nachricht im MIME-Format.
--------------E5FF020258A5E3ED0FA6FBC3
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis,

I never received an answer to my mail. Here it is once again!

I guess my timing of the mail wasn't very good since I posted
it during the last IETF meeting. With the wrap up of the meeting
and the christmas season you probably had enough to do.

Could you please answer or comment my questions / remarks now!

Thanks - Petra

--------------E5FF020258A5E3ED0FA6FBC3
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Received: from gateway.secude.com (gateway.intranet.secude.com [192.168.1.1]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id YN33V841; Sun, 9 Dec 2001 16:22:51 +0100
Received: by gateway.secude.com (Postfix)
	id 420C11710E; Sun,  9 Dec 2001 16:22:51 +0100 (CET)
Received: from above.proper.com (above.proper.com [208.184.76.39])
	by gateway.secude.com (Postfix) with ESMTP
	id B79DE17108; Sun,  9 Dec 2001 16:22:49 +0100 (CET)
Received: by above.proper.com (8.11.6/8.11.3) id fB9DrCV27715
	for ietf-pkix-bks; Sun, 9 Dec 2001 05:53:12 -0800 (PST)
Received: from gateway.secude.com (linux.secude.com [141.12.207.27])
	by above.proper.com (8.11.6/8.11.3) with ESMTP id fB9DrA227711
	for <[e-mail]>; Sun, 9 Dec 2001 05:53:11 -0800 (PST)
Received: from remus.secude.com (remus.intranet.secude.com [192.168.2.2])
	by gateway.secude.com (Postfix) with ESMTP
	id D9D65B745; Sun,  9 Dec 2001 14:54:35 +0100 (CET)
Received: from secude.com (obelix.intranet.secude.com [192.168.1.3]) by remus.secude.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13)
	id YN33V8TW; Sun, 9 Dec 2001 14:54:35 +0100
Delivered-To: [e-mail]
Message-ID: <[e-mail]>
Date: Sun, 09 Dec 2001 14:54:28 +0100
From: Petra Barzin <[e-mail]>
X-Mailer: Mozilla 4.73 [de]C-CCK-MCD DT  (Win95; U)
X-Accept-Language: de
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
Cc: pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-dpv-dpd-req-00.txt & draft-ietf-pkix-dsv-req-00.txt
References: <[e-mail]> <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>


Denis,

I have three questions/comments regarding your DPV / DPD document:

- I would like to see the signature to be only optional in a DPV response.
You require the DPV response to be integrity protected. But you could
authenticate the server using other means, for example SSL server
authentication.

- A DPV or DPD request can only contain one certificate. Shouldn't it be
possible to include more than one certifiacte in a request?

- Why do I need the optional requestor name in the DPV request and
response? And why is this requestor name not included in the DPD protocol?

Bye - Petra

Denis Pinkas schrieb:

> I have been asked by the co-chairs to prepare a requirements document for
> DPV/DPD. While doing that task, requirements slighly different have been
> identified for DSV. As a result of this request, you will find:
>
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dpv-dpd-req-00.txt
>
> a document which describes a protocol for the validation of CERTIFICATES
> (and for the discovery of certification paths), and
>
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-dsv-req-00.txt
>
> a separate document which describes a protocol for the validation of
> DIGITAL SIGNATURES.
>
> Both documents, which share several common points, will be presented
> at the next IETF meeting.
>
> Denis

--------------E5FF020258A5E3ED0FA6FBC3--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g04KkoU21572 for ietf-pkix-bks; Fri, 4 Jan 2002 12:46:50 -0800 (PST)
Received: from mail.tiscalinet.it (mail-7.tiscalinet.it [195.130.225.153]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g04Kkm321567 for <[e-mail]>; Fri, 4 Jan 2002 12:46:48 -0800 (PST)
Received: from polito.it (62.10.37.164) by mail.tiscalinet.it (5.5.053) id 3C0343CC00F4F2EC; Fri, 4 Jan 2002 21:45:58 +0100
Message-ID: <[e-mail]>
Date: Fri, 04 Jan 2002 21:45:53 +0100
From: Antonio Lioy <[e-mail]>
Organization: Politecnico di Torino
X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Denis Pinkas <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
References: <[e-mail]>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms8C35EFC32CA2BD6B2CAAC7AD"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

This is a cryptographically signed message in MIME format.

--------------ms8C35EFC32CA2BD6B2CAAC7AD
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Denis Pinkas wrote:
> 
> As advertised at the last IETF meeting in Salt Lake City, from information
> received on the mail list and directly, there exists at least seven
> experimental implementations of RFC 3161 (i.e. the Time-Stamp Protocol- TSP)
> available for individual testing:
> 
> - four from Italy,
> - one from New-Zealand,
> - one from France,
> - one from Austria.
> 
> The goal is to be able to perform interoperability testing among at least
> two of these implementations, so that we can report on these tests at the
> next IETF meeting in Minneapolis. This is a necessary step to be able to
> progress RFC 3161 from Proposed Standard to Draft Standard.

Here at the Politecnico di Torino we have been testing our
implementation against the following ones:
- SIA
- C&A
- IAIK
- Peter Guttman

We have not been able to test against the Edelweb TSA as it is HTTP
based and not socket based. We are in the process of writing a report
about these tests. Is there any standard IETF format to officially
report these results to progress an RFC to Draft Standard?

> Computer and Network Security Group (CNSG)
> from Politecnico di Torino
> Date: Mon, 03 Dec 2001
> 
> From: Cristian Marinescu <[e-mail]>
> 
> Please take a look to http://security.polito.it/test/tsp/
> 
> Address: tsp.test.polito.it  port:318.  Pure TCP.
> Testing purposes only.
> 
> Contact : [e-mail]

Some more information about this implementation:
- it consists of a server, a client and a library that implements a TS
  API
- everything is available for Win32 and Unix (tried under Solaris and
  Linux)
- current version is pure socket based
- HTTP and SMTP versions are in progress
- the code is based on the cryptographic part of OpenSSL, with some
  modifications
- the contact address [e-mail] is not yet active (it
  will be in a week or so); for the moment, please address everything
  related to our TSA to {lioy,ramunno}@polito.it

In reply to Todd Glassey's request for info about application field: our
TSA code is being tested for application in e-government environments
(by some Italian municipalities as well as by partners of the EuroPKI
and
NASTEC projects), although other applications are surely possible.

Cheers,

Antonio Lioy
Gianluca Ramunno
Cristian Marinescu
--------------ms8C35EFC32CA2BD6B2CAAC7AD
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIRRwYJKoZIhvcNAQcCoIIRODCCETQCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
D0owggV9MIIEZaADAgECAgIA0DANBgkqhkiG9w0BAQUFADBlMQswCQYDVQQGEwJJVDEeMBwG
A1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xpdGVjbmljbyBkaSBU
b3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDExMjIxMTUwMDAwWhcNMDMxMjMx
MDkwMDAwWjB4MQswCQYDVQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5v
MTEwLwYDVQQLEyhEaXBhcnRpbWVudG8gZGkgQXV0b21hdGljYSBlIEluZm9ybWF0aWNhMRYw
FAYDVQQDEw1BbnRvbmlvICBMaW95MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDkq3Ub
EN2iW/2K3GUpgnSEg61e+aVAWWg+62zyROqLFpTglPUxw7JakWgzjuwpwPl9gPZSlMqsV8dP
g6Do0/zs3zAPKpZ8m8mxxY5apkBj0genz+ufqBWYBsfTqKmNATmWKQmGF1bxdHSOB1RcDArF
byJdX3A9+IyIw2BuI9BaswIDAQABo4ICpjCCAqIwgZUGCWCGSAGG+EIBDQSBhxaBhElzc3Vl
ZCB1bmRlciBwb2xpY2llczoKIGh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMv
MS4xLwogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLwogaHR0cDovL2Nh
LnBvbGl0by5pdC9jcHMvMi4xLzARBglghkgBhvhCAQEEBAMCALAwYwYIKwYBBQUHAQEEVzBV
MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcC5ldXJvcGtpLm9yZzo4MDI2MCkGCCsGAQUFBzAC
hh1odHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL2l0LzAyBgNVHR8EKzApMCegJaAjhiFodHRw
Oi8vY2EucG9saXRvLml0L2NybDAyL2NybC5kZXIwDAYDVR0TAQH/BAIwADAxBgNVHREEKjAo
gQ5saW95QHBvbGl0by5pdKAWBgorBgEEAZViAgEBoAgWBjAwMTg0NzCBzQYDVR0gBIHFMIHC
MEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYnaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9j
YS9yb290L2Nwcy8xLjEvMEEGCisGAQQBqQcCAQEwMzAxBggrBgEFBQcCARYlaHR0cDovL3d3
dy5ldXJvcGtpLm9yZy9jYS9pdC9jcHMvMS4xLzA4BgorBgEEAZViAQIBMCowKAYIKwYBBQUH
AgEWHGh0dHA6Ly9jYS5wb2xpdG8uaXQvY3BzLzIuMS8wCwYDVR0PBAQDAgTwMB0GA1UdDgQW
BBSQXcYutVN1s83taHXQY4e0ltUt3DAfBgNVHSMEGDAWgBT0DG1tnl9MYlY5geDe+Y8vN6CE
xTANBgkqhkiG9w0BAQUFAAOCAQEAfJmaMcqwiOSzRcDx6Yby30oHm32+qn6idN6fTpzrKMDP
8fgjD+LQSxxPQzUheVTK2qpOPT4SHfNMZ2iZeplKegDdJc/nrPNfUYdvQHwiEhKhWHvAfsfN
SBtpGeSEr8cBWeD/gjmAylGY2h17WHg/TNd0w3qfUZmfFGvBHVAbxC/Ar2zfvTX+8spF2vNR
CBPmE0o8O2ZQrenZXqeeFPWkqwf94MJ4f3SnKL+TyI6lXCIUwPGmLqC1NHGl4TpXd2xKChra
uR+NTwz6oJBYv0H0UhZdqc7S/JwRetFbO7+eAEx+OGgyBeeNTgddT2ZL4zIBQQSCvQBx9asn
H6Tb7WbRvTCCBT4wggQmoAMCAQICAgFoMA0GCSqGSIb3DQEBBQUAMFExCzAJBgNVBAYTAklU
MRAwDgYDVQQKEwdFdXJvUEtJMTAwLgYDVQQDEydFdXJvUEtJIEl0YWxpYW4gQ2VydGlmaWNh
dGlvbiBBdXRob3JpdHkwHhcNMDExMjE0MTAwMDAwWhcNMDYxMjMxMDkwMDAwWjBlMQswCQYD
VQQGEwJJVDEeMBwGA1UEChMVUG9saXRlY25pY28gZGkgVG9yaW5vMTYwNAYDVQQDEy1Qb2xp
dGVjbmljbyBkaSBUb3Jpbm8gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQD2x9x9Ywb+ZLw7r1ps9+dRZyLpN9SdxKV+zxLOnACyhbX8
4mkZW3GrXIpCs/xaqKLERxlZK+eU5zJGP8LS3PcktApIDKscoZIOSfkx3gcK574vUkdDcFrX
h5A6PusC6AWAT7ot6dMC+C45CXvj+30L3ct2bU1j63UWzfqg+E8lDmKetnoPw/2iXiz95zI+
GFBpTW2KipDLV3TWBdOuYjZ4fpSLQCTJ7FVzEWldHuqe89XuG4T5lMNTvu32PHbiyaYm5LGU
DwdBLwj6oLK0OE5iwqbrvqfVrjCkT1W6ehUCb/7u1qObfVlhrFOeNfz3WR8UagWL8ne0hFzr
u+HwmjL7AgMBAAGjggIKMIICBjB1BglghkgBhvhCAQ0EaBZmSXNzdWVkIHVuZGVyIHBvbGlj
aWVzOgogaHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvCiBodHRwOi8v
d3d3LmV1cm9wa2kub3JnL2NhL2l0L2Nwcy8xLjEvMFwGCCsGAQUFBwEBBFAwTjAoBggrBgEF
BQcwAYYcaHR0cDovL29jc3AuZXVyb3BraS5vcmc6ODAyNjAiBggrBgEFBQcwAoYWaHR0cDov
L3d3dy5ldXJvcGtpLm9yZzA7BgNVHR8ENDAyMDCgLqAshipodHRwOi8vd3d3LmV1cm9wa2ku
b3JnL2NhL2l0L2NybDAyL2NybC5kZXIwgZMGA1UdIASBizCBiDBDBgorBgEEAakHAQEBMDUw
MwYIKwYBBQUHAgEWJ2h0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9vdC9jcHMvMS4xLzBB
BgorBgEEAakHAgEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Ev
aXQvY3BzLzEuMS8wHwYDVR0jBBgwFoAUqjwTyUkLXM240yDgxZWXMzNdJBMwDwYDVR0TAQH/
BAUwAwEB/zALBgNVHQ8EBAMCAfYwHQYDVR0OBBYEFPQMbW2eX0xiVjmB4N75jy83oITFMA0G
CSqGSIb3DQEBBQUAA4IBAQBfHbqCmb+iIbu2Lb57UvCaeqfqOTSKHEjFxxrOhMCNbOrrTH4y
EgmwiBF8a2/lTZfMRZzXlRmu7qyuTxOpy1PoRupExMK3HqbE93pGkqneN6mKAY6TCcmyeONQ
8L+0eZ8kc1yWXdGTprg4i9rOXA6gK5DwPQ32wAa3Hfn5P60DKmE1T3Ie0Ld2m9Ci0uYkWjY+
vqxPLaKMKpCcfEnaxlQQCU0S6coU/zLe49/C8TQUQLuU42RTH5Tv3ICXA+8G8BJSikhA/LsF
D0gy6mSP/UOZS+aX/Tl/4Ni/bHtRuJSWnWSxBfOz5YvEHY0AN+cJo82+qmFHPkqEkY5Mmlzw
Jn5QMIIEgzCCA2ugAwIBAgIBCzANBgkqhkiG9w0BAQUFADBBMRAwDgYDVQQKEwdFdXJvUEtJ
MS0wKwYDVQQDEyRFdXJvUEtJIFJvb3QgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDEx
MjEyMTAwMDAwWhcNMDYxMjMxMTAwMDAwWjBRMQswCQYDVQQGEwJJVDEQMA4GA1UEChMHRXVy
b1BLSTEwMC4GA1UEAxMnRXVyb1BLSSBJdGFsaWFuIENlcnRpZmljYXRpb24gQXV0aG9yaXR5
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA/trLUTLGC/t9bWWmRFPhuWNLcJ/t
nmb8ppelASwxB+KEFe+hxUZWpgJNteXW772tvJVXwy2hpkUTYRv7y0pMDoPZQmlWWfYaKceL
UKz7AhXpLPnnApo3e0rMYzDcv8fcAM2Jii20//+B7dLU/qPRtwaFD+n/E4bOYAu3wIHsoK2f
35UdXwO9yY6qaZBVzKZTP0wI3rxnN8u958CdTNagg3vZ/EkNEbyzMuPUhjEc4+ygtUgPbTIY
N3Kmke1WvXFRjisajmM8K4jv39DE2FB4PJZCjbHaOozedWZVcMVEkiazWPsFam6ISGzRklaR
pBd3b2CYF5mim8wrIBc7dcMO/wIDAQABo4IBdDCCAXAwTAYJYIZIAYb4QgENBD8WPUlzc3Vl
ZCB1bmRlciBwb2xpY3k6CiBodHRwOi8vd3d3LmV1cm9wa2kub3JnL2NhL3Jvb3QvY3BzLzEu
MS8wOAYIKwYBBQUHAQEELDAqMCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcC5ldXJvcGtpLm9y
Zzo4MDI2MDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly93d3cuZXVyb3BraS5vcmcvY2Evcm9v
dC9jcmwvY3JsLmRlcjBOBgNVHSAERzBFMEMGCisGAQQBqQcBAQEwNTAzBggrBgEFBQcCARYn
aHR0cDovL3d3dy5ldXJvcGtpLm9yZy9jYS9yb290L2Nwcy8xLjEvMB8GA1UdIwQYMBaAFIzc
i7GlSpDnTohzGDyd1V5+5LLNMAwGA1UdEwQFMAMBAf8wCwYDVR0PBAQDAgH2MB0GA1UdDgQW
BBSqPBPJSQtczbjTIODFlZczM10kEzANBgkqhkiG9w0BAQUFAAOCAQEAa6mGMlATRFDbx64p
I5ntDhu8aA947xaAaJQeulnq8jb7+SdKqorQBDuPn7i+IYwmCbbHwmdir1ljLWLTAWtgjET8
bZ/DxxbU//ywI3OpOP5I7T/YqknQGS+5NIbavU1N6DprmvrVriNSqni6krG7OC7q6ezD/5GR
TYrOU2bTnck5ywzzZ0g3c0Gv6Fmz/QgWIxbUYkHY/vbblZYMXTU61ByYtiymiJ99Q/LaD6Dg
UPkjEcUcq8IbVv3MeZ8mhoOfnL6RBCkez9khl5TI171QuJ+7caAZAqn2yPpulsZ+NbcsCGEb
ot2F/z4DOLq82bNDAJt6BTbo0VrMSuEtLmoNdDGCAcUwggHBAgEBMGswZTELMAkGA1UEBhMC
SVQxHjAcBgNVBAoTFVBvbGl0ZWNuaWNvIGRpIFRvcmlubzE2MDQGA1UEAxMtUG9saXRlY25p
Y28gZGkgVG9yaW5vIENlcnRpZmljYXRpb24gQXV0aG9yaXR5AgIA0DAJBgUrDgMCGgUAoIGx
MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTAyMDEwNDIwNDU1
M1owIwYJKoZIhvcNAQkEMRYEFIRw15B5Xetnl1Xptz+zKWjYJeZRMFIGCSqGSIb3DQEJDzFF
MEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgFA
MA0GCCqGSIb3DQMCAgEoMA0GCSqGSIb3DQEBAQUABIGAg7GAwxzk5DeGKTVJzgaaRrIBoVhr
LrqtiQxRNzfg/DPQKcxmi9lPCA/zWPrhuB23T5+GLq4NDm2Sg6ha8kZAXRJjAbAkmgFwQgQb
IvMfCBSWtcxrISgzvMHpeS/wxlFuB3p20phuVYS5sAe5MhQxTospfnvnSVF3XJoJk6T0XSk=
--------------ms8C35EFC32CA2BD6B2CAAC7AD--



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g04GPvI12814 for ietf-pkix-bks; Fri, 4 Jan 2002 08:25:57 -0800 (PST)
Received: from smtp3.access.net.id ([202.180.4.65]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g04GPp312808 for <[e-mail]>; Fri, 4 Jan 2002 08:25:51 -0800 (PST)
Received: from MAHATEL.mii.or.id (pteredon99.access.net.id [202.180.2.99]) by smtp3.access.net.id (8.9.3+Sun/8.9.3) with ESMTP id XAA12597; Fri, 4 Jan 2002 23:25:26 -0700 (GMT)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.1
Date: Sat, 05 Jan 2002 11:19:43 +0700
To: "Sanjaya" <[e-mail]>
From: Teddy A Purwadi <[e-mail]>
Subject: Re: Attribute Certificate for IP address allocation object
Cc: <[e-mail]>
In-Reply-To: <00ab01c193eb$981cdab0$d91d0cca@SANJAYA>
References: <[e-mail]> <p05100302b858caac9872@[128.89.88.34]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Sanjaya:
How long will you go with the draft related to
the object to IP indexes? Or no correlations?.
-teddy

At 10:14 AM 1/3/02 +1000, Sanjaya wrote:

>Russ, Stephen,
>Thanks for the offer and pointers!
>I am aware of the draft by Clynn/BBN about PKC extension
>which have the same objective as what we have in mind.
>What is the current status of that draft? I'd be happy to
>discuss that draft further and combine our efforts.
>Also what would be the advantage/disadvantage of using
>X509 ID certs compared to using ACs?
>
>Cheers,
>Sanjaya
>
>----- Original Message -----
>From: "Stephen Kent" <[e-mail]>
>To: <[e-mail]>
>Cc: <[e-mail]>
>Sent: Thursday, January 03, 2002 12:35 AM
>Subject: RE: Attribute Certificate for IP address allocation object
>
>
> > At 8:26 AM -0500 1/2/02, Housley, Russ wrote:
> > >Sanjaya:
> > >
> > >Yes.  You will need to define a new attribute.  You may want to define
>two
> > >attributes, one for IPv4 address blocks and another for IPv6 address
>blocks.
> > >
> > >I will be glad to review the syntax of your new attribute.
> > >
> > >Russ
> > >
> >
> > Sanjaya,
> >
> > My colleagues developed syntax for representing this info, for v4 and
> > v6 addresses, and for AS numbers, as part of the Secure BGP work BBN
> > has been doing under DARPA sponsorship.  We defined these as private
> > extensions for X.509 certs, vs. ACs., but the syntax should be
> > applicable. I'll forward a copy of the proposed syntax.
> >
> > Steve
> >





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g04G7QD12238 for ietf-pkix-bks; Fri, 4 Jan 2002 08:07:26 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g04G7K312231 for <[e-mail]>; Fri, 4 Jan 2002 08:07:21 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id FAA27119; Sat, 5 Jan 2002 05:06:17 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id FAA22477; Sat, 5 Jan 2002 05:06:10 +1300 (NZDT) (sender [e-mail])
Date: Sat, 5 Jan 2002 05:06:10 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re:  Progression of RFC 3161 (TSP) to Draft Standard
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Peter Sylvester <[e-mail]> writes:

>Anyway: I am not sure whether it is sufficient to just test sending 'correct'
>data. I have spend some time sending almost arbitrary data as requests, both
>on the TCP socket layer level and as request PDUs *IN A CLIENT*.

Oh, so you were the one causing all the "Bad data format" entries in the error
log :-).

>I am not sure whether there are client or server implementations that
>voluntarily send back *wrong* data in order to validate whether the different
>MUSTs in the text are respected.

My TSA did that once.  Definitely a deliberate error to test clients, and not
me mis-reading the spec :-).

>- How can one indicate a scket protocol transport with a non default port in a
>  certificate.

I've been using cmp://fqdn:port.

Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g04Etm510651 for ietf-pkix-bks; Fri, 4 Jan 2002 06:55:48 -0800 (PST)
Received: from edelweb.fr (edelweb.fr [212.234.46.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g04Etf310643 for <[e-mail]>; Fri, 4 Jan 2002 06:55:41 -0800 (PST)
Received: from champagne.edelweb.fr (localhost.edelweb.fr [127.0.0.1]) by edelweb.fr with ESMTP id PAA24145; Fri, 4 Jan 2002 15:51:24 +0100 (MET)
Received: from champagne.edelweb.fr (champagne.edelweb.fr [193.51.14.161]) by edelweb.fr (nospam/1.3); Fri, 4 Jan 2002 15:51:24 +0100 (MET)
Received: from emeriau.edelweb.fr (emeriau.edelweb.fr [193.51.14.5]) by champagne.edelweb.fr (8.7.6/8.6.6) with ESMTP id PAA12146; Fri, 4 Jan 2002 15:51:24 +0100 (MET)
From: Peter Sylvester <[e-mail]>
Received: (sylvest@localhost) by emeriau.edelweb.fr (8.7.6/8.6.6) id PAA29651; Fri, 4 Jan 2002 15:51:34 +0100 (MET)
Date: Fri, 4 Jan 2002 15:51:34 +0100 (MET)
Message-Id: <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re:  Progression of RFC 3161 (TSP) to Draft Standard
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> >The goal is to be able to perform interoperability testing among at least two
> >of these implementations, so that we can report on these tests at the next
> >IETF meeting in Minneapolis. This is a necessary step to be able to progress
> >RFC 3161 from Proposed Standard to Draft Standard.
> 
> I've interoperated with Peter Sylvester's TSA and the timeproof.de one.  I've
> never seen the IAIK one running, and there was one at 203.238.37.132:3318 which
> I've got question marks next to so I assume that one was never active either.

The IAIK TSA was riunning from time to time, I have made a few tests with them. 

Anyway: I am not sure whether it is sufficient to just test sending
'correct' data. I have spend some time sending almost arbitrary data
as requests, both on the TCP socket layer level and as request PDUs
*IN A CLIENT*. 

I am not sure whether there are client or server implementations that
voluntarily send back *wrong* data in order to validate whether the
different MUSTs in the text are respected. 

I would like to invite the editor of the text to review the archive
to see whether comments for changes or enhancements had been rejected
with a reason like 'not now, we can do this in the next round,',
'we can do this later, we need a stable text now'. 

I think there are quite a few of them. 

Some questions that come out of my limited memory: 

- alignment of the socket based protocol with the CMP socket transport?

- How can one indicate a scket protocol transport with a non default
  port in a certificate. 

- How can one correctly create a TSA certificate respecting
  the rules set in TSP. How to do POP of the key.

- Can two time stamps be compared? 





Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g03M53m23638 for ietf-pkix-bks; Thu, 3 Jan 2002 14:05:03 -0800 (PST)
Received: from email.nist.gov (email.nist.gov [129.6.2.7]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g03M51323634; Thu, 3 Jan 2002 14:05:02 -0800 (PST)
Received: from cspa06.nist.gov (cspa06.ncsl.nist.gov [129.6.54.23]) by email.nist.gov (8.9.3/8.9.3) with ESMTP id RAA10325; Thu, 3 Jan 2002 17:05:02 -0500 (EST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Thu, 03 Jan 2002 17:06:30 -0500
To: [e-mail], [e-mail]
From: Michael Chernick <[e-mail]>
Subject: Updated Draft of NIST S/MIME V3 Client Profile Now Available
Cc: Michael Chernick <[e-mail]>, Tim Polk <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=====================_17140984==_.ALT"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

--=====================_17140984==_.ALT
Content-Type: text/plain; charset="us-ascii"; format=flowed

FYI,

I have posted a new version of the draft S/MIME V3 Client Profile on the web.
You can find it at: http://csrc.nist.gov/pki/smime/draft_SMIMEProfile.pdf

(See http://www.imc.org/ietf-smime/mail-archive/msg00861.html for previous
message with background on the NIST S/MIME V3 Client profile.)

There is also a description of our work at: 
http://csrc.nist.gov/pki/smime/welcome.htm

NIST has solicited comments from you and we have incorporated almost
all changes requested into the new document.  Most comments received were
editorial in nature, or asked for clarification.

The new draft has these major changes from the previous (May, 2001) draft:

      An Executive Summary for Procurement Officials, Implementers, 
Vendors, and
      Others interested in S/MIME Technology from a less technical 
perspective;

      A clarification (in Clause 2.4.4) that the path building requirements 
are intended to
      require that all S/MIME clients be able to transverse 
non-hierarchical (e.g., bridge
      PKIs) as well as hierarchical PKIs;

      Relaxation of the requirement (in Clause 2.3.2) to always require 
user notification
      when an incoming S/MIME message is signed by a certificate that 
contains an email
      address that does not match the email address used as "From" address. 
(This
      change was prompted by NIST's observation that many new certificates 
will not
      contain email addresses.)

The major unresolved comment on the May draft is the issue of mandating
signed receipt processing support.  (See Clauses 2.2., 2.3, and 3.1.)  NIST 
received
a comment requesting that this mandate be dropped.

The comment argued that including a requirement for signed receipt support 
would add
cost and complexity to S/MIME products, and that the cost of this 
additional functionality
should be bourne by the agencies that require this service, enabling other 
agencies that do
not require the service to obtain less complex and less costly S/MIME v3 
client systems.
Agencies that do not want/need signed receipts should not be required to 
request it in their
purchases of messaging systems.

NIST has felt that the additional cost and complexity were justified by 
ubiquity of signed
receipt support among U.S. Federal Agencies.  We intend to resolve this 
issue very soon
and then publish the S/MIME V3 Client Profile. We have almost completed the 
process
of soliciting U.S. Federal Agencies on this issue.

I will be pleased to receive any further comments on the new draft until the
end of January 2002.

(Note:  The old draft and updated information on the NIST S/MIME program are
available at: http://csrc.nist.gov/pki/smime/welcome.htm).

The NIST S/MIME V3 Test Facility (see 
http://csrc.nist.gov/pki/smime/smtest.htm) is
not yet operational, but it is expected to become operational (with limited 
test
cases at first) during the first quarter of 2002.


Thanks,
    Mike Chernick

----------------------------------------------------------------------------------
C. Michael Chernick
[phone]   [e-mail]
Computer Security Division
National Institute of Standards and Technology (NIST)
----------------------------------------------------------------------------------


--=====================_17140984==_.ALT
Content-Type: text/html; charset="us-ascii"

<html>
FYI,<br>
<br>
I have posted a new version of the draft S/MIME V3 Client Profile on the
web.<br>
You can find it at:
<a href="http://csrc.nist.gov/pki/smime/draft_SMIMEProfile.pdf" eudora="autourl">http://csrc.nist.gov/pki/smime/draft_SMIMEProfile.</a><a href="http://csrc.nist.gov/pki/smime/draft_SMIMEProfile.pdf" eudora="autourl">pdf<br>
<br>
</a>(See http://www.imc.org/ietf-smime/mail-archive/msg00861.html for
previous<br>
message with background on the NIST S/MIME V3 Client profile.)<br>
<br>
There is also a description of our work at:
<a href="http://csrc.nist.gov/pki/smime/welcome.htm" eudora="autourl">http://csrc.nist.gov/pki/smime/welcome.</a><a href="http://csrc.nist.gov/pki/smime/welcome.htm" eudora="autourl">htm<br>
<br>
</a>NIST has solicited comments from you and we have incorporated
almost<br>
all changes requested into the new document.&nbsp; Most comments received
were<br>
editorial in nature, or asked for clarification.<br>
<br>
The new draft has these major changes from the previous (May, 2001)
draft: <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; An Executive Summary for Procurement Officials,
Implementers, Vendors, and<br>
&nbsp;&nbsp;&nbsp;&nbsp; Others interested in S/MIME Technology from a
less technical perspective; <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; A clarification (in Clause 2.4.4) that the path
building requirements are intended to<br>
&nbsp;&nbsp;&nbsp;&nbsp; require that all S/MIME clients be able to
transverse non-hierarchical (e.g., bridge<br>
&nbsp;&nbsp;&nbsp;&nbsp; PKIs) as well as hierarchical PKIs; <br>
<br>
&nbsp;&nbsp;&nbsp;&nbsp; Relaxation of the requirement (in Clause 2.3.2)
to always require user notification<br>
&nbsp;&nbsp;&nbsp;&nbsp; when an incoming S/MIME message is signed by a
certificate that contains an email<br>
&nbsp;&nbsp;&nbsp;&nbsp; address that does not match the email address
used as &quot;From&quot; address. (This<br>
&nbsp;&nbsp;&nbsp;&nbsp; change was prompted by NIST's observation that
many new certificates will not<br>
&nbsp;&nbsp;&nbsp;&nbsp; contain email addresses.) <br>
<br>
The major unresolved comment on the May draft is the issue of mandating
<br>
signed receipt processing support.&nbsp; (See Clauses 2.2., 2.3, and
3.1.)&nbsp; NIST received<br>
a comment requesting that this mandate be dropped. <br>
<br>
The comment argued that including a requirement for signed receipt
support would add<br>
cost and complexity to S/MIME products, and that <font size=2>the cost of
this additional functionality <br>
should be bourne by the agencies that require this service, enabling
other agencies that do<br>
not require the service to obtain less complex and less costly S/MIME v3
client systems. <br>
Agencies that do not want/need signed receipts should not be required to
request it in their <br>
purchases of messaging systems.<br>
<br>
</font>NIST has felt that the additional cost and complexity were
justified by ubiquity of signed<br>
receipt support among U.S. Federal Agencies.&nbsp; We intend to resolve
this issue very soon <br>
and then publish the S/MIME V3 Client Profile. We have almost completed
the process <br>
of soliciting U.S. Federal Agencies on this issue. <br>
<br>
I will be pleased to receive any further comments on the new draft until
the<br>
end of January 2002.<br>
<br>
(Note:&nbsp; The old draft and updated information on the NIST S/MIME
program are<br>
available at: http://csrc.nist.gov/pki/smime/welcome.htm).<br>
<br>
The NIST S/MIME V3 Test Facility (see
http://csrc.nist.gov/pki/smime/smtest.htm) is <br>
not yet operational, but it is expected to become operational (with
limited test<br>
cases at first) during the first quarter of 2002. <br>
<br>
<br>
Thanks,<br>
&nbsp;&nbsp; Mike Chernick<br>
<x-sigsep><p></x-sigsep>
----------------------------------------------------------------------------------<br>
C. Michael Chernick<br>
[phone]&nbsp;&nbsp; [e-mail]<br>
Computer Security Division <br>
National Institute of Standards and Technology (NIST)<br>
----------------------------------------------------------------------------------<br>
<br>
</html>

--=====================_17140984==_.ALT--



Received: by above.proper.com (8.11.6/8.11.3) id g032xcV00503 for ietf-pkix-bks; Wed, 2 Jan 2002 18:59:38 -0800 (PST)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g032xa300498 for <[e-mail]>; Wed, 2 Jan 2002 18:59:36 -0800 (PST)
Received: from tsg1 ([12.81.109.137]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020103025934.QLLL15547.mtiwmhc25.worldnet.att.net@tsg1>; Thu, 3 Jan 2002 02:59:34 +0000
Message-ID: <004b01c19402$991db170$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Peter Gutmann" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
References: <[e-mail]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Date: Wed, 2 Jan 2002 18:58:59 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

yes it does, and for what should be obvious reasons

Todd



----- Original Message -----
From: "Peter Gutmann" <[e-mail]>
To: <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, January 02, 2002 6:14 PM
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard


> "todd glassey" <[e-mail]> writes:
>
> >Denis - do you have any commercial users of the protocol or are the
> >implementers Academic, and if they are academic what are they using the
TSP
> >for.
>
> Does it matter?  The requirement is for two interoperable implementations,
> which we certainly have.
>
> (Just out of interest, it'd be interesting to see who *is* using TSP
>  commercially.  From the list which Denis posted, I'd guess this is only
>  happening in Italy, which has laws requiring it.  The other three are
>  academic/experimental.  My code is available under the Sleepycat license
>  (dual-license, GPL-style or commercial) and I'm not aware of any
commercial
>  users of TSP... actually I'm not aware of any open-source users either,
but
>  since anyone can grab it I can't really tell who's doing what with it,
there
>  may be hordes of people secretly running TSAs in their basements).
>
> Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g032Fv429773 for ietf-pkix-bks; Wed, 2 Jan 2002 18:15:57 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g032Fs329769 for <[e-mail]>; Wed, 2 Jan 2002 18:15:55 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id PAA24371; Thu, 3 Jan 2002 15:14:53 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id PAA502886; Thu, 3 Jan 2002 15:14:53 +1300 (NZDT) (sender [e-mail])
Date: Thu, 3 Jan 2002 15:14:53 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

"todd glassey" <[e-mail]> writes:

>Denis - do you have any commercial users of the protocol or are the
>implementers Academic, and if they are academic what are they using the TSP
>for.

Does it matter?  The requirement is for two interoperable implementations,
which we certainly have.

(Just out of interest, it'd be interesting to see who *is* using TSP
 commercially.  From the list which Denis posted, I'd guess this is only
 happening in Italy, which has laws requiring it.  The other three are
 academic/experimental.  My code is available under the Sleepycat license
 (dual-license, GPL-style or commercial) and I'm not aware of any commercial
 users of TSP... actually I'm not aware of any open-source users either, but
 since anyone can grab it I can't really tell who's doing what with it, there
 may be hordes of people secretly running TSAs in their basements).

Peter.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g030xRd28392 for ietf-pkix-bks; Wed, 2 Jan 2002 16:59:27 -0800 (PST)
Received: from kakapo.cs.auckland.ac.nz (kakapo.cs.auckland.ac.nz [130.216.34.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g030xC328387 for <[e-mail]>; Wed, 2 Jan 2002 16:59:12 -0800 (PST)
Received: from ruru.cs.auckland.ac.nz (firebird.cs.auckland.ac.nz [130.216.34.12]) by kakapo.cs.auckland.ac.nz (8.8.6/8.8.6/cs-master) with ESMTP id NAA24594; Thu, 3 Jan 2002 13:58:02 +1300 (NZDT) (sender [e-mail])
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id NAA501772; Thu, 3 Jan 2002 13:58:01 +1300 (NZDT) (sender [e-mail])
Date: Thu, 3 Jan 2002 13:58:01 +1300 (NZDT)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re:  Progression of RFC 3161 (TSP) to Draft Standard
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis Pinkas <[e-mail]> writes:

>The goal is to be able to perform interoperability testing among at least two
>of these implementations, so that we can report on these tests at the next
>IETF meeting in Minneapolis. This is a necessary step to be able to progress
>RFC 3161 from Proposed Standard to Draft Standard.

I've interoperated with Peter Sylvester's TSA and the timeproof.de one.  I've
never seen the IAIK one running, and there was one at 203.238.37.132:3318 which
I've got question marks next to so I assume that one was never active either.

Peter.



Received: by above.proper.com (8.11.6/8.11.3) id g030EIa27575 for ietf-pkix-bks; Wed, 2 Jan 2002 16:14:18 -0800 (PST)
Received: from cumin.apnic.net (cumin.apnic.net [202.12.29.59]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g030EG327571 for <[e-mail]>; Wed, 2 Jan 2002 16:14:16 -0800 (PST)
Received: from SANJAYA (as-sanjaya.apnic.net [202.12.29.217]) by cumin.apnic.net (8.12.1/8.12.1) with SMTP id g030A6Tl012165 for <[e-mail]>; Thu, 3 Jan 2002 10:10:06 +1000
Message-ID: <00ab01c193eb$981cdab0$d91d0cca@SANJAYA>
From: "Sanjaya" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <p05100302b858caac9872@[128.89.88.34]>
Subject: Re: Attribute Certificate for IP address allocation object
Date: Thu, 3 Jan 2002 10:14:21 +1000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
X-Scanned-By: MIMEDefang 2.1 (www dot roaringpenguin dot com slash mimedefang)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Russ, Stephen,
Thanks for the offer and pointers!
I am aware of the draft by Clynn/BBN about PKC extension
which have the same objective as what we have in mind.
What is the current status of that draft? I'd be happy to
discuss that draft further and combine our efforts.
Also what would be the advantage/disadvantage of using
X509 ID certs compared to using ACs?

Cheers,
Sanjaya

----- Original Message -----
From: "Stephen Kent" <[e-mail]>
To: <[e-mail]>
Cc: <[e-mail]>
Sent: Thursday, January 03, 2002 12:35 AM
Subject: RE: Attribute Certificate for IP address allocation object


> At 8:26 AM -0500 1/2/02, Housley, Russ wrote:
> >Sanjaya:
> >
> >Yes.  You will need to define a new attribute.  You may want to define
two
> >attributes, one for IPv4 address blocks and another for IPv6 address
blocks.
> >
> >I will be glad to review the syntax of your new attribute.
> >
> >Russ
> >
>
> Sanjaya,
>
> My colleagues developed syntax for representing this info, for v4 and
> v6 addresses, and for AS numbers, as part of the Secure BGP work BBN
> has been doing under DARPA sponsorship.  We defined these as private
> extensions for X.509 certs, vs. ACs., but the syntax should be
> applicable. I'll forward a copy of the proposed syntax.
>
> Steve
>



Received: by above.proper.com (8.11.6/8.11.3) id g0306T227319 for ietf-pkix-bks; Wed, 2 Jan 2002 16:06:29 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g0306R327315 for <[e-mail]>; Wed, 2 Jan 2002 16:06:27 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id TAA26813; Wed, 2 Jan 2002 19:05:44 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100315b8594cd92e00@[128.89.88.34]>
In-Reply-To: <001d01c193d9$e37b4ee0$020aff0c@tsg1>
References: <[e-mail]> <[e-mail]> <001d01c193d9$e37b4ee0$020aff0c@tsg1>
Date: Wed, 2 Jan 2002 18:58:36 -0500
To: <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Cc: "pkix" <[e-mail]>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Alfonso,

>----- Original Message -----
>From: "Alfonso De Gregorio" <[e-mail]>
>To: "todd glassey" <[e-mail]>
>Cc: "pkix" <[e-mail]>
>Sent: Wednesday, January 02, 2002 2:05 PM
>Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
>
>
>>
>>  > I have no opposition to this protocol becoming a standard as long as it
>does
>>  > not likewise rule out NTP's use as a time stamping protocol since NTP
>has
>>  > had a standards number reserved for it from a time from before when the
>>  > original TSP I-D was published, oh and NTP  has at least twenty thousand
>>  > commercial implementers.
>>
>>  NTP is not a time stamping protocol in the sense of 3161.
>
>yes it is - it is exactly the same  - The TST is easily encapsulated as an
>optional payload in the NTP service model. The NTP protocol is then exactly
>as capable of being used as a time stamp generator as the TSP. In fact the
>NTP Solution from a trst standpoint is orders of magnitude better  than the
>PKIX effort which is totally arbitrary in its operations. There is no more
>commercial value in the PKIX TSP than looking at the micky mouse watch on
>your wrist and declaring this package to have arrived at some time point.
>The issue is that in a retrospective manner the only value the timestamp has
>is evidentiary in nature. Otherwise if the TS was just used to trigger some
>other digital event there would be no need to keep it. So no need for the
>token itself.

You are right about the mismatch between the semantics for NTP vs. 
TSP; I noted the same thing a private exchange with Todd earlier 
today. TSP is a request/response protocol specifically designed to 
allow a client to request a time stamp for a hash value corresponding 
to some data of interest. NTP is a time distribution protocol that 
has security features designed to ensure authenticity and integrity 
for the time values it distributes, but it is not engineered to 
satisfy the sort of operation that TSP does.

Todd has in mind a model for time stamping that has not been accepted 
by this WG, and which also is not consistent with the models employed 
by other protocol  standards bodies (e.g., ETSI) working in the area. 
His comments have to be interpreted relative to that model. We have 
discussed this difference of opinion on this list many times in the 
past.  See the archives to Todd's description of his model.

Steve


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g02M8Dv24729 for ietf-pkix-bks; Wed, 2 Jan 2002 14:08:13 -0800 (PST)
Received: from mtiwmhc25.worldnet.att.net (mtiwmhc25.worldnet.att.net [204.127.131.50]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02M8B324725 for <[e-mail]>; Wed, 2 Jan 2002 14:08:11 -0800 (PST)
Received: from tsg1 ([12.81.109.137]) by mtiwmhc25.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020102220807.LJKN15547.mtiwmhc25.worldnet.att.net@tsg1>; Wed, 2 Jan 2002 22:08:07 +0000
Message-ID: <001d01c193d9$e37b4ee0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <[e-mail]> <[e-mail]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Date: Wed, 2 Jan 2002 14:07:36 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

----- Original Message -----
From: "Alfonso De Gregorio" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: "pkix" <[e-mail]>
Sent: Wednesday, January 02, 2002 2:05 PM
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard


>
> > I have no opposition to this protocol becoming a standard as long as it
does
> > not likewise rule out NTP's use as a time stamping protocol since NTP
has
> > had a standards number reserved for it from a time from before when the
> > original TSP I-D was published, oh and NTP  has at least twenty thousand
> > commercial implementers.
>
> NTP is not a time stamping protocol in the sense of 3161.

yes it is - it is exactly the same  - The TST is easily encapsulated as an
optional payload in the NTP service model. The NTP protocol is then exactly
as capable of being used as a time stamp generator as the TSP. In fact the
NTP Solution from a trst standpoint is orders of magnitude better  than the
PKIX effort which is totally arbitrary in its operations. There is no more
commercial value in the PKIX TSP than looking at the micky mouse watch on
your wrist and declaring this package to have arrived at some time point.
The issue is that in a retrospective manner the only value the timestamp has
is evidentiary in nature. Otherwise if the TS was just used to trigger some
other digital event there would be no need to keep it. So no need for the
token itself.

That's the whole point - Time Stamping is supposed to be a method of
enstantiating some more credibility than what was there from the testimony
alone of the human representing the event. And it simply doesnt.


>
> > Also - I don't count Academic systems as commercially viable until they
> > migrate their warez into the private sector as there is no real
financial
> > commitment to what a grad-student does by the university. This is an
> > important key to realizing anything in the commercial world, especially
in
> > the defining of a security model in which there is a need for a TTP
based
> > TSP as an evidentiary model and getting it approved for roll out. This
last
>
> AFAIK, there are 3161 commercial users, at least in Italy.

Who are they and what is the operations model - what type of services are
they using and providing and has an auditor ever looked at the system.

>
> Sincerely,
> alfonso



Received: by above.proper.com (8.11.6/8.11.3) id g02K6AK21998 for ietf-pkix-bks; Wed, 2 Jan 2002 12:06:10 -0800 (PST)
Received: from firewall.andxor.it (firewall.andxor.it [195.223.2.2]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02K68321994 for <[e-mail]>; Wed, 2 Jan 2002 12:06:08 -0800 (PST)
Received: from foobar.andxor.it (foobar.andxor.it [195.223.2.236]) by firewall.andxor.it (8.9.2/8.9.2) with ESMTP id VAA06533; Wed, 2 Jan 2002 21:06:08 +0100 (CET) (envelope-from [e-mail])
Received: by foobar.andxor.it (Postfix, from userid 1000) id 0C796F92A; Wed,  2 Jan 2002 23:05:00 +0100 (CET)
Date: Wed, 2 Jan 2002 23:05:00 +0100
From: Alfonso De Gregorio <[e-mail]>
To: todd glassey <[e-mail]>
Cc: pkix <[e-mail]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Message-ID: <[e-mail]>
Reply-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Jan 02, 2002 at 08:48:37PM +0100
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

> I have no opposition to this protocol becoming a standard as long as it does
> not likewise rule out NTP's use as a time stamping protocol since NTP has
> had a standards number reserved for it from a time from before when the
> original TSP I-D was published, oh and NTP  has at least twenty thousand
> commercial implementers.

NTP is not a time stamping protocol in the sense of 3161.
 
> Also - I don't count Academic systems as commercially viable until they
> migrate their warez into the private sector as there is no real financial
> commitment to what a grad-student does by the university. This is an
> important key to realizing anything in the commercial world, especially in
> the defining of a security model in which there is a need for a TTP based
> TSP as an evidentiary model and getting it approved for roll out. This last

AFAIK, there are 3161 commercial users, at least in Italy.

Sincerely,
alfonso


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g02HneE18388 for ietf-pkix-bks; Wed, 2 Jan 2002 09:49:40 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02Hnd318384 for <[e-mail]>; Wed, 2 Jan 2002 09:49:39 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id MAA04212; Wed, 2 Jan 2002 12:46:42 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100309b858f6d6f8bb@[128.89.88.34]>
In-Reply-To: <002a01c193ac$8a3128a0$020aff0c@tsg1>
References: <[e-mail]> <003801c193a7$189194a0$020aff0c@tsg1> <[e-mail]> <002a01c193ac$8a3128a0$020aff0c@tsg1>
Date: Wed, 2 Jan 2002 12:45:07 -0500
To: "todd glassey" <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Cc: "Denis Pinkas" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "pkix" <[e-mail]>, [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 8:42 AM -0800 1/2/02, todd glassey wrote:
>Denis, I am sorry you are not tracking what the people who are implementing
>your protocol are doing with it. Personally  if I were pushing my
>baby-protocol towards Standardization, I would know every use of it while
>its on its way to becoming a standard.
>
>I have no opposition to this protocol becoming a standard as long as it does
>not likewise rule out NTP's use as a time stamping protocol since NTP has
>had a standards number reserved for it from a time from before when the
>original TSP I-D was published, oh and NTP  has at least twenty thousand
>commercial implementers.
>
>Also - I don't count Academic systems as commercially viable until they
>migrate their warez into the private sector as there is no real financial
>commitment to what a grad-student does by the university. This is an
>important key to realizing anything in the commercial world, especially in
>the defining of a security model in which there is a need for a TTP based
>TSP as an evidentiary model and getting it approved for roll out. This last
>thing is the real "ticker of value" for any core protocols that are to
>compete with ANXI X.9.ANSI efforts.

Todd,

The IETF requirement for multiple interoperable implementations of a 
protocol, as a prerequisite for progression, does not differentiate 
between product vs. academic implementations.

NTP is an IETF standard for distribution of time information, but is 
not a time stamping protocol in the sense of TSP, so it is not a 
"competitor" for TSP.

The value of the NTP protocol number is irrelevant to this discussion.

Steve



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g02Ghbj16440 for ietf-pkix-bks; Wed, 2 Jan 2002 08:43:37 -0800 (PST)
Received: from mtiwmhc24.worldnet.att.net (mtiwmhc24.worldnet.att.net [204.127.131.49]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02GhZ316434 for <[e-mail]>; Wed, 2 Jan 2002 08:43:35 -0800 (PST)
Received: from tsg1 ([12.81.64.195]) by mtiwmhc24.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020102164329.DVAT13117.mtiwmhc24.worldnet.att.net@tsg1>; Wed, 2 Jan 2002 16:43:29 +0000
Message-ID: <002a01c193ac$8a3128a0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>
Cc: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, "pkix" <[e-mail]>
References: <[e-mail]> <003801c193a7$189194a0$020aff0c@tsg1> <[e-mail]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Date: Wed, 2 Jan 2002 08:42:57 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis, I am sorry you are not tracking what the people who are implementing
your protocol are doing with it. Personally  if I were pushing my
baby-protocol towards Standardization, I would know every use of it while
its on its way to becoming a standard.

I have no opposition to this protocol becoming a standard as long as it does
not likewise rule out NTP's use as a time stamping protocol since NTP has
had a standards number reserved for it from a time from before when the
original TSP I-D was published, oh and NTP  has at least twenty thousand
commercial implementers.

Also - I don't count Academic systems as commercially viable until they
migrate their warez into the private sector as there is no real financial
commitment to what a grad-student does by the university. This is an
important key to realizing anything in the commercial world, especially in
the defining of a security model in which there is a need for a TTP based
TSP as an evidentiary model and getting it approved for roll out. This last
thing is the real "ticker of value" for any core protocols that are to
compete with ANXI X.9.ANSI efforts.

Todd

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: "todd glassey" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>; "pkix" <[e-mail]>
Sent: Wednesday, January 02, 2002 8:13 AM
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard


Todd,

This is not a question to mee. So I let other people respond.

Thank you for your interest in TSP.

Regards,

Denis

> Denis - do you have any commercial users of the protocol or are the
> implementers Academic, and if they are academic what are they using the
TSP
> for.
>
> Todd Glassey
>
> ----- Original Message -----
> From: "Denis Pinkas" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>;
> <[e-mail]>; <[e-mail]>;
> <[e-mail]>; <[e-mail]>;
> <[e-mail]>; <[e-mail]>
> Cc: "pkix" <[e-mail]>
> Sent: Wednesday, January 02, 2002 3:56 AM
> Subject: Progression of RFC 3161 (TSP) to Draft Standard
>
> As advertised at the last IETF meeting in Salt Lake City, from information
> received on the mail list and directly, there exists at least seven
> experimental implementations of RFC 3161 (i.e. the Time-Stamp Protocol-
TSP)
> available for individual testing:
>
> - four from Italy,
> - one from New-Zealand,
> - one from France,
> - one from Austria.
>
> The goal is to be able to perform interoperability testing among at least
> two of these implementations, so that we can report on these tests at the
> next IETF meeting in Minneapolis. This is a necessary step to be able to
> progress RFC 3161 from Proposed Standard to Draft Standard.
>
> [From section 6.2 of RFC 2026]
>
>    A specification shall remain at the Proposed Standard level for at
>    least six (6) months.
>
> [From section 4.1.2 of RFC 2026]
>
>    A specification from which at least two independent and interoperable
>    implementations from different code bases have been developed, and
>    for which sufficient successful operational experience has been
>    obtained, may be elevated to the "Draft Standard" level.  For the
>    purposes of this section, "interoperable" means to be functionally
>    equivalent or interchangeable components of the system or process in
>    which they are used.(.).
>
>    The requirement for at least two independent and interoperable
>    implementations applies to all of the options and features of the
>    specification.  In cases in which one or more options or features
>    have not been demonstrated in at least two interoperable
>    implementations, the specification may advance to the Draft Standard
>    level only if those options or features are removed.
>
> Hereafter is information about the implementations I have been made
> aware of. If more exist, please let us know.
>
>                     ________________________
>
> C&A experimental TSA service (http://www.com-and.com)
> Date: Fri, 24 Aug 2001
> From: tho <[e-mail]> or <[e-mail]>
>
> If anyone would like another TSA to test here you can find ours:
> http://195.223.2.6:8080
>
> It is a freebsd box with an apache module that acts as a front-end and
> translator to a socket based protocol backend. The backend is still
directly
> reached at address 195.223.2.6 port 3318.
>
> Available interfaces are:
> http at url: http://195.223.2.6:8080/timestamp
> you have to POST a time stamp request wrapped into an
> application/timestamp-query MIME object.
> tcp  at 195.223.2.6, port 3318
>
>                     ________________________
>
> Cryptographic Appliances (Peter Gutman)
> Date: Tue, 21 Aug 2001
> From: [e-mail] (Peter Gutmann)
>
> There's a new TSA available at tsa.cryptoapps.com:3318, running in a FIPS
> 140-1 level 4 device (it's just a demo which runs single-threaded, so if
you
> throw a huge number of concurrent requests at it you may get some refused
> connections, although I doubt it'll be a big issue for now).
> Date: Tue, 28 Aug 2001
>
> I've now updated the TSA to conform to the latest draft (except for the
TSA
> cert, because I'm using a shared generic cert which gets recycled for SSL,
> OCSP, CMP, and everything else).
>
>                     ________________________
>
> SIA (Società Interbancaria per l'Automazione Cedborsa S.p.A)
> Date: Thu, 8 Nov 2001
>
> From: Taglialagamba Bianca <[e-mail]>
>
> We have developed a Time Stamping Authority according with the RFC 3161.
> If you would like to do some interoperability tests with it, the IP
address
> is 193.203.230.166 and the port is 318 (using socket based protocol). The
> service can be available from 9.00 a.m. to 6.00 p.m.
>
>                     ________________________
>
> Computer and Network Security Group (CNSG)
> from Politecnico di Torino
> Date: Mon, 03 Dec 2001
>
> From: Cristian Marinescu <[e-mail]>
>
> Please take a look to http://security.polito.it/test/tsp/
>
> Address: tsp.test.polito.it  port:318.  Pure TCP.
> Testing purposes only.
>
> Contact : [e-mail]
>
>                     ________________________
>
> EdelWeb Experimental
> Time Stamping Service
> Date: Mon, 03 Dec 2001
>
> From: Peter Sylvester <[e-mail]>
>
> See the descriptions in:  http://www.edelweb.fr/tsa.html
>
> This service uses a standard HTTP protocol to communicate.
>
>                     ________________________
>
> Innovery True Time
> Date: Thu, 06 Dec 2001
> From: Andrea Caccia <[e-mail]>
> on, 17 Dec 2001 23:36:18 +0100
> Product name: Innovery True Time. Version: 1.1
>
> Company name & address:
> Innovery srl
> Via Faravelli 8
> 20149 Milano - Italy
>
> Contact person: Andrea Caccia <[e-mail]>
>
>                     ________________________
>
> Graz University of Technology (IAIK -Austria)
> Contact person: [e-mail]
>
>                     ________________________
>
> I encourage "contact persons" to contact themselves. :-)
>
> Denis.
> TSP lead editor.




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g02GDql15364 for ietf-pkix-bks; Wed, 2 Jan 2002 08:13:52 -0800 (PST)
Received: from odin2.bull.net (odin2.bull.net [192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02GDn315356 for <[e-mail]>; Wed, 2 Jan 2002 08:13:50 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id RAA12058; Wed, 2 Jan 2002 17:14:43 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id RAA05818; Wed, 2 Jan 2002 17:13:16 +0100
Message-ID: <[e-mail]>
Date: Wed, 02 Jan 2002 17:13:52 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: todd glassey <[e-mail]>
CC: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], pkix <[e-mail]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
References: <[e-mail]> <003801c193a7$189194a0$020aff0c@tsg1>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g02GDp315360
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Todd,

This is not a question to mee. So I let other people respond.

Thank you for your interest in TSP.

Regards,

Denis

> Denis - do you have any commercial users of the protocol or are the
> implementers Academic, and if they are academic what are they using the TSP
> for.
> 
> Todd Glassey
> 
> ----- Original Message -----
> From: "Denis Pinkas" <[e-mail]>
> To: <[e-mail]>; <[e-mail]>;
> <[e-mail]>; <[e-mail]>;
> <[e-mail]>; <[e-mail]>;
> <[e-mail]>; <[e-mail]>
> Cc: "pkix" <[e-mail]>
> Sent: Wednesday, January 02, 2002 3:56 AM
> Subject: Progression of RFC 3161 (TSP) to Draft Standard
> 
> As advertised at the last IETF meeting in Salt Lake City, from information
> received on the mail list and directly, there exists at least seven
> experimental implementations of RFC 3161 (i.e. the Time-Stamp Protocol- TSP)
> available for individual testing:
> 
> - four from Italy,
> - one from New-Zealand,
> - one from France,
> - one from Austria.
> 
> The goal is to be able to perform interoperability testing among at least
> two of these implementations, so that we can report on these tests at the
> next IETF meeting in Minneapolis. This is a necessary step to be able to
> progress RFC 3161 from Proposed Standard to Draft Standard.
> 
> [From section 6.2 of RFC 2026]
> 
>    A specification shall remain at the Proposed Standard level for at
>    least six (6) months.
> 
> [From section 4.1.2 of RFC 2026]
> 
>    A specification from which at least two independent and interoperable
>    implementations from different code bases have been developed, and
>    for which sufficient successful operational experience has been
>    obtained, may be elevated to the "Draft Standard" level.  For the
>    purposes of this section, "interoperable" means to be functionally
>    equivalent or interchangeable components of the system or process in
>    which they are used.(.).
> 
>    The requirement for at least two independent and interoperable
>    implementations applies to all of the options and features of the
>    specification.  In cases in which one or more options or features
>    have not been demonstrated in at least two interoperable
>    implementations, the specification may advance to the Draft Standard
>    level only if those options or features are removed.
> 
> Hereafter is information about the implementations I have been made
> aware of. If more exist, please let us know.
> 
>                     ________________________
> 
> C&A experimental TSA service (http://www.com-and.com)
> Date: Fri, 24 Aug 2001
> From: tho <[e-mail]> or <[e-mail]>
> 
> If anyone would like another TSA to test here you can find ours:
> http://195.223.2.6:8080
> 
> It is a freebsd box with an apache module that acts as a front-end and
> translator to a socket based protocol backend. The backend is still directly
> reached at address 195.223.2.6 port 3318.
> 
> Available interfaces are:
> http at url: http://195.223.2.6:8080/timestamp
> you have to POST a time stamp request wrapped into an
> application/timestamp-query MIME object.
> tcp  at 195.223.2.6, port 3318
> 
>                     ________________________
> 
> Cryptographic Appliances (Peter Gutman)
> Date: Tue, 21 Aug 2001
> From: [e-mail] (Peter Gutmann)
> 
> There's a new TSA available at tsa.cryptoapps.com:3318, running in a FIPS
> 140-1 level 4 device (it's just a demo which runs single-threaded, so if you
> throw a huge number of concurrent requests at it you may get some refused
> connections, although I doubt it'll be a big issue for now).
> Date: Tue, 28 Aug 2001
> 
> I've now updated the TSA to conform to the latest draft (except for the TSA
> cert, because I'm using a shared generic cert which gets recycled for SSL,
> OCSP, CMP, and everything else).
> 
>                     ________________________
> 
> SIA (Società Interbancaria per l'Automazione Cedborsa S.p.A)
> Date: Thu, 8 Nov 2001
> 
> From: Taglialagamba Bianca <[e-mail]>
> 
> We have developed a Time Stamping Authority according with the RFC 3161.
> If you would like to do some interoperability tests with it, the IP address
> is 193.203.230.166 and the port is 318 (using socket based protocol). The
> service can be available from 9.00 a.m. to 6.00 p.m.
> 
>                     ________________________
> 
> Computer and Network Security Group (CNSG)
> from Politecnico di Torino
> Date: Mon, 03 Dec 2001
> 
> From: Cristian Marinescu <[e-mail]>
> 
> Please take a look to http://security.polito.it/test/tsp/
> 
> Address: tsp.test.polito.it  port:318.  Pure TCP.
> Testing purposes only.
> 
> Contact : [e-mail]
> 
>                     ________________________
> 
> EdelWeb Experimental
> Time Stamping Service
> Date: Mon, 03 Dec 2001
> 
> From: Peter Sylvester <[e-mail]>
> 
> See the descriptions in:  http://www.edelweb.fr/tsa.html
> 
> This service uses a standard HTTP protocol to communicate.
> 
>                     ________________________
> 
> Innovery True Time
> Date: Thu, 06 Dec 2001
> From: Andrea Caccia <[e-mail]>
> on, 17 Dec 2001 23:36:18 +0100
> Product name: Innovery True Time. Version: 1.1
> 
> Company name & address:
> Innovery srl
> Via Faravelli 8
> 20149 Milano - Italy
> 
> Contact person: Andrea Caccia <[e-mail]>
> 
>                     ________________________
> 
> Graz University of Technology (IAIK -Austria)
> Contact person: [e-mail]
> 
>                     ________________________
> 
> I encourage "contact persons" to contact themselves. :-)
> 
> Denis.
> TSP lead editor.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g02G4ha14922 for ietf-pkix-bks; Wed, 2 Jan 2002 08:04:43 -0800 (PST)
Received: from mtiwmhc22.worldnet.att.net (mtiwmhc22.worldnet.att.net [204.127.131.47]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02G4e314916 for <[e-mail]>; Wed, 2 Jan 2002 08:04:41 -0800 (PST)
Received: from tsg1 ([12.81.64.195]) by mtiwmhc22.worldnet.att.net (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20020102160430.MCJB941.mtiwmhc22.worldnet.att.net@tsg1>; Wed, 2 Jan 2002 16:04:30 +0000
Message-ID: <003801c193a7$189194a0$020aff0c@tsg1>
From: "todd glassey" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Cc: "pkix" <[e-mail]>
References: <[e-mail]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Date: Wed, 2 Jan 2002 08:03:59 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Denis - do you have any commercial users of the protocol or are the
implementers Academic, and if they are academic what are they using the TSP
for.

Todd Glassey

----- Original Message -----
From: "Denis Pinkas" <[e-mail]>
To: <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>
Cc: "pkix" <[e-mail]>
Sent: Wednesday, January 02, 2002 3:56 AM
Subject: Progression of RFC 3161 (TSP) to Draft Standard



As advertised at the last IETF meeting in Salt Lake City, from information
received on the mail list and directly, there exists at least seven
experimental implementations of RFC 3161 (i.e. the Time-Stamp Protocol- TSP)
available for individual testing:

- four from Italy,
- one from New-Zealand,
- one from France,
- one from Austria.

The goal is to be able to perform interoperability testing among at least
two of these implementations, so that we can report on these tests at the
next IETF meeting in Minneapolis. This is a necessary step to be able to
progress RFC 3161 from Proposed Standard to Draft Standard.


[From section 6.2 of RFC 2026]

   A specification shall remain at the Proposed Standard level for at
   least six (6) months.

[From section 4.1.2 of RFC 2026]

   A specification from which at least two independent and interoperable
   implementations from different code bases have been developed, and
   for which sufficient successful operational experience has been
   obtained, may be elevated to the "Draft Standard" level.  For the
   purposes of this section, "interoperable" means to be functionally
   equivalent or interchangeable components of the system or process in
   which they are used.(.).

   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.

Hereafter is information about the implementations I have been made
aware of. If more exist, please let us know.

                    ________________________

C&A experimental TSA service (http://www.com-and.com)
Date: Fri, 24 Aug 2001
From: tho <[e-mail]> or <[e-mail]>

If anyone would like another TSA to test here you can find ours:
http://195.223.2.6:8080

It is a freebsd box with an apache module that acts as a front-end and
translator to a socket based protocol backend. The backend is still directly
reached at address 195.223.2.6 port 3318.

Available interfaces are:
http at url: http://195.223.2.6:8080/timestamp
you have to POST a time stamp request wrapped into an
application/timestamp-query MIME object.
tcp  at 195.223.2.6, port 3318

                    ________________________

Cryptographic Appliances (Peter Gutman)
Date: Tue, 21 Aug 2001
From: [e-mail] (Peter Gutmann)

There's a new TSA available at tsa.cryptoapps.com:3318, running in a FIPS
140-1 level 4 device (it's just a demo which runs single-threaded, so if you
throw a huge number of concurrent requests at it you may get some refused
connections, although I doubt it'll be a big issue for now).
Date: Tue, 28 Aug 2001

I've now updated the TSA to conform to the latest draft (except for the TSA
cert, because I'm using a shared generic cert which gets recycled for SSL,
OCSP, CMP, and everything else).

                    ________________________

SIA (Società Interbancaria per l'Automazione Cedborsa S.p.A)
Date: Thu, 8 Nov 2001

From: Taglialagamba Bianca <[e-mail]>

We have developed a Time Stamping Authority according with the RFC 3161.
If you would like to do some interoperability tests with it, the IP address
is 193.203.230.166 and the port is 318 (using socket based protocol). The
service can be available from 9.00 a.m. to 6.00 p.m.

                    ________________________

Computer and Network Security Group (CNSG)
from Politecnico di Torino
Date: Mon, 03 Dec 2001

From: Cristian Marinescu <[e-mail]>

Please take a look to http://security.polito.it/test/tsp/

Address: tsp.test.polito.it  port:318.  Pure TCP.
Testing purposes only.

Contact : [e-mail]

                    ________________________

EdelWeb Experimental
Time Stamping Service
Date: Mon, 03 Dec 2001

From: Peter Sylvester <[e-mail]>

See the descriptions in:  http://www.edelweb.fr/tsa.html

This service uses a standard HTTP protocol to communicate.

                    ________________________

Innovery True Time
Date: Thu, 06 Dec 2001
From: Andrea Caccia <[e-mail]>
on, 17 Dec 2001 23:36:18 +0100
Product name: Innovery True Time. Version: 1.1

Company name & address:
Innovery srl
Via Faravelli 8
20149 Milano - Italy

Contact person: Andrea Caccia <[e-mail]>

                    ________________________

Graz University of Technology (IAIK -Austria)
Contact person: [e-mail]

                    ________________________


I encourage "contact persons" to contact themselves. :-)

Denis.
TSP lead editor.



Received: by above.proper.com (8.11.6/8.11.3) id g02EbZf11641 for ietf-pkix-bks; Wed, 2 Jan 2002 06:37:35 -0800 (PST)
Received: from po1.bbn.com (PO1.BBN.COM [192.1.50.38]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02EbY311637 for <[e-mail]>; Wed, 2 Jan 2002 06:37:34 -0800 (PST)
Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by po1.bbn.com (8.9.1/8.9.1) with ESMTP id JAA02625; Wed, 2 Jan 2002 09:37:11 -0500 (EST)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05100302b858caac9872@[128.89.88.34]>
In-Reply-To:  <[e-mail]>
References: <[e-mail]>
Date: Wed, 2 Jan 2002 09:35:31 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: RE: Attribute Certificate for IP address allocation object
Cc: [e-mail]
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

At 8:26 AM -0500 1/2/02, Housley, Russ wrote:
>Sanjaya:
>
>Yes.  You will need to define a new attribute.  You may want to define two
>attributes, one for IPv4 address blocks and another for IPv6 address blocks.
>
>I will be glad to review the syntax of your new attribute.
>
>Russ
>

Sanjaya,

My colleagues developed syntax for representing this info, for v4 and 
v6 addresses, and for AS numbers, as part of the Secure BGP work BBN 
has been doing under DARPA sponsorship.  We defined these as private 
extensions for X.509 certs, vs. ACs., but the syntax should be 
applicable. I'll forward a copy of the proposed syntax.

Steve


Received: by above.proper.com (8.11.6/8.11.3) id g02DbDO09501 for ietf-pkix-bks; Wed, 2 Jan 2002 05:37:13 -0800 (PST)
Received: from tholian.rsasecurity.com (mail.rsasecurity.com [204.167.112.129]) by above.proper.com (8.11.6/8.11.3) with SMTP id g02DbB309497 for <[e-mail]>; Wed, 2 Jan 2002 05:37:11 -0800 (PST)
Received: from sdtihq24.securid.com by tholian.rsasecurity.com via smtpd (for mail.imc.org [208.184.76.43]) with SMTP; 2 Jan 2002 13:36:53 UT
Received: from ebola.securitydynamics.com (ebola.securid.com [192.168.7.4]) by sdtihq24.securid.com (Pro-8.9.3/Pro-8.9.3) with ESMTP id IAA06123 for <[e-mail]>; Wed, 2 Jan 2002 08:37:11 -0500 (EST)
Received: from exna00.securitydynamics.com (localhost [127.0.0.1]) by ebola.securitydynamics.com (8.10.2+Sun/8.9.1) with ESMTP id g02DbAv28274 for <[e-mail]>; Wed, 2 Jan 2002 08:37:10 -0500 (EST)
Received: by exna00.securitydynamics.com with Internet Mail Service (5.5.2653.19) id <Y61NCSSV>; Wed, 2 Jan 2002 08:37:09 -0500
Received: from HOUSLEY-LAP.rsasecurity.com (HOUSLEY-LAP [10.3.1.90]) by exna00.securitydynamics.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id Y61NCSSQ; Wed, 2 Jan 2002 08:37:03 -0500
Message-ID: <[e-mail]>
From: "Housley, Russ" <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: RE: Attribute Certificate for IP address allocation object
Date: Wed, 2 Jan 2002 08:26:31 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Sanjaya:

Yes.  You will need to define a new attribute.  You may want to define two 
attributes, one for IPv4 address blocks and another for IPv6 address blocks.

I will be glad to review the syntax of your new attribute.

Russ


At 10:18 AM 1/2/2002 +1000, Sanjaya wrote:

>Hi Russ,
>Thanks for the quick response! I have been studying the
>draft but don't have a clue where to put the IP block
>information. Should we just create a new attribute field
>in the AC?
>
>Cheers,
>Sanjaya
>
> > -----Original Message-----
> > From: Housley, Russ [mailto:[e-mail]]
> > Sent: Selasa, Januari 01, 2002 00:01
> > To: Sanjaya
> > Cc: [e-mail]
> > Subject: Re: Attribute Certificate for IP address allocation object
> >
> >
> > Sanjaya:
> >
> > This seems like a straightforward application of
> > draft-ietf-pkix-ac509prof-09.txt.
> >
> > Russ
> >
> >
> > At 11:49 AM 12/31/2001 +1000, Sanjaya wrote:
> >
> > >Hi,
> > >We are investigating the use of Attribute Certificate for IP address
> > >allocation object. The idea is to bind the right to use certain IP
blocks
> > >to the organization that receives the allocation from an IP registry
> > >(e.g APNIC/ARIN/RIPE). This certificate can be validated by
> > >the service provider before inserting the block into the routing table.
> > >
> > >Is this topic within the scope of PKIX working group? Appreciate
> > >any advise. Thanks!
> > >
> > >Happy New Year 2001!
> > >Sanjaya
> > >Senior Project Manager
> > >APNIC (http://www.apnic.net)
> >




============================================================================
================
This e-mail, its content and any files transmitted with it are intended
solely for the addressee(s) and are PRIVILEGED and 
CONFIDENTIAL.  Access by any other party is unauthorized without the express
prior written permission of the sender.  If 
you have received this e-mail in error you may not copy, disclose to any
third party or use the contents, attachments or 
information in any way, Please delete all copies of the e-mail and the
attachment(s), if any and notify the sender. 
Thank You.
============================================================================
================


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g02Buoa02936 for ietf-pkix-bks; Wed, 2 Jan 2002 03:56:50 -0800 (PST)
Received: from odin2.bull.net ([192.90.70.84]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g02BuR302928 for <[e-mail]>; Wed, 2 Jan 2002 03:56:28 -0800 (PST)
Received: from lvt-mail.frlv.bull.fr (lvt-mail.frlv.bull.fr [129.184.62.223]) by odin2.bull.net (8.9.3/8.9.3) with ESMTP id MAA10084; Wed, 2 Jan 2002 12:57:08 +0100
Received: from bull.net (frlva3786.frlv.bull.fr [129.184.37.97]) by lvt-mail.frlv.bull.fr (8.9.2/8.9.1) with ESMTP id MAA16380; Wed, 2 Jan 2002 12:55:28 +0100
Message-ID: <[e-mail]>
Date: Wed, 02 Jan 2002 12:56:12 +0100
From: Denis Pinkas <[e-mail]>
Organization: Integris. A Bull Company
X-Mailer: Mozilla 4.7 [fr] (Win98; I)
X-Accept-Language: fr
MIME-Version: 1.0
To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
CC: pkix <[e-mail]>
Subject: Progression of RFC 3161 (TSP) to Draft Standard
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g02BuT302929
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

As advertised at the last IETF meeting in Salt Lake City, from information
received on the mail list and directly, there exists at least seven
experimental implementations of RFC 3161 (i.e. the Time-Stamp Protocol- TSP)
available for individual testing:

- four from Italy,
- one from New-Zealand,
- one from France,
- one from Austria.

The goal is to be able to perform interoperability testing among at least
two of these implementations, so that we can report on these tests at the
next IETF meeting in Minneapolis. This is a necessary step to be able to
progress RFC 3161 from Proposed Standard to Draft Standard.


[From section 6.2 of RFC 2026]

   A specification shall remain at the Proposed Standard level for at
   least six (6) months.

[From section 4.1.2 of RFC 2026]

   A specification from which at least two independent and interoperable
   implementations from different code bases have been developed, and
   for which sufficient successful operational experience has been
   obtained, may be elevated to the "Draft Standard" level.  For the
   purposes of this section, "interoperable" means to be functionally
   equivalent or interchangeable components of the system or process in
   which they are used.(…).

   The requirement for at least two independent and interoperable
   implementations applies to all of the options and features of the
   specification.  In cases in which one or more options or features
   have not been demonstrated in at least two interoperable
   implementations, the specification may advance to the Draft Standard
   level only if those options or features are removed.

Hereafter is information about the implementations I have been made 
aware of. If more exist, please let us know.

                    ________________________

C&A experimental TSA service (http://www.com-and.com)
Date: Fri, 24 Aug 2001
From: tho <[e-mail]> or <[e-mail]>

If anyone would like another TSA to test here you can find ours:
http://195.223.2.6:8080

It is a freebsd box with an apache module that acts as a front-end and
translator to a socket based protocol backend. The backend is still directly
reached at address 195.223.2.6 port 3318.

Available interfaces are:
http at url: http://195.223.2.6:8080/timestamp 
you have to POST a time stamp request wrapped into an
application/timestamp-query MIME object.
tcp  at 195.223.2.6, port 3318 

                    ________________________

Cryptographic Appliances (Peter Gutman)
Date: Tue, 21 Aug 2001 
From: [e-mail] (Peter Gutmann)

There's a new TSA available at tsa.cryptoapps.com:3318, running in a FIPS
140-1 level 4 device (it's just a demo which runs single-threaded, so if you
throw a huge number of concurrent requests at it you may get some refused
connections, although I doubt it'll be a big issue for now).
Date: Tue, 28 Aug 2001

I've now updated the TSA to conform to the latest draft (except for the TSA
cert, because I'm using a shared generic cert which gets recycled for SSL,
OCSP, CMP, and everything else).  

                    ________________________

SIA (Società Interbancaria per l'Automazione Cedborsa S.p.A)
Date: Thu, 8 Nov 2001

From: Taglialagamba Bianca <[e-mail]>

We have developed a Time Stamping Authority according with the RFC 3161.
If you would like to do some interoperability tests with it, the IP address
is 193.203.230.166 and the port is 318 (using socket based protocol). The
service can be available from 9.00 a.m. to 6.00 p.m.

                    ________________________

Computer and Network Security Group (CNSG)
from Politecnico di Torino
Date: Mon, 03 Dec 2001

From: Cristian Marinescu <[e-mail]>

Please take a look to http://security.polito.it/test/tsp/

Address: tsp.test.polito.it  port:318.  Pure TCP. 
Testing purposes only.

Contact : [e-mail]

                    ________________________

EdelWeb Experimental 
Time Stamping Service
Date: Mon, 03 Dec 2001

From: Peter Sylvester <[e-mail]>

See the descriptions in:  http://www.edelweb.fr/tsa.html

This service uses a standard HTTP protocol to communicate.

                    ________________________

Innovery True Time
Date: Thu, 06 Dec 2001 
From: Andrea Caccia <[e-mail]>
on, 17 Dec 2001 23:36:18 +0100
Product name: Innovery True Time. Version: 1.1

Company name & address:
Innovery srl
Via Faravelli 8
20149 Milano - Italy

Contact person: Andrea Caccia <[e-mail]>

                    ________________________

Graz University of Technology (IAIK -Austria)
Contact person: [e-mail]

                    ________________________


I encourage "contact persons" to contact themselves. :-)

Denis. 
TSP lead editor.


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g020ILO23311 for ietf-pkix-bks; Tue, 1 Jan 2002 16:18:21 -0800 (PST)
Received: from whois3.apnic.net (whois3.apnic.net [203.37.255.102]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g020II323307 for <[e-mail]>; Tue, 1 Jan 2002 16:18:19 -0800 (PST)
Received: from hadrian.staff.apnic.net (hadrian.apnic.net [202.12.29.249]) by whois3.apnic.net (8.9.3/8.9.3) with ESMTP id KAA04073 for <[e-mail]>; Wed, 2 Jan 2002 10:18:20 +1000 (EST)
Received: from sanjaya (localhost [127.0.0.1]) by hadrian.staff.apnic.net (8.9.3/8.9.3) with SMTP id KAA04527 for <[e-mail]>; Wed, 2 Jan 2002 10:17:52 +1000 (EST)
Reply-To: <[e-mail]>
From: "Sanjaya" <[e-mail]>
To: <[e-mail]>
Subject: RE: Attribute Certificate for IP address allocation object
Date: Wed, 2 Jan 2002 10:18:48 +1000
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-pkix.imc.org>

Hi Russ,
Thanks for the quick response! I have been studying the
draft but don't have a clue where to put the IP block
information. Should we just create a new attribute field
in the AC?

Cheers,
Sanjaya

> -----Original Message-----
> From: Housley, Russ [mailto:[e-mail]]
> Sent: Selasa, Januari 01, 2002 00:01
> To: Sanjaya
> Cc: [e-mail]
> Subject: Re: Attribute Certificate for IP address allocation object
>
>
> Sanjaya:
>
> This seems like a straightforward application of
> draft-ietf-pkix-ac509prof-09.txt.
>
> Russ
>
>
> At 11:49 AM 12/31/2001 +1000, Sanjaya wrote:
>
> >Hi,
> >We are investigating the use of Attribute Certificate for IP address
> >allocation object. The idea is to bind the right to use certain IP blocks
> >to the organization that receives the allocation from an IP registry
> >(e.g APNIC/ARIN/RIPE). This certificate can be validated by
> >the service provider before inserting the block into the routing table.
> >
> >Is this topic within the scope of PKIX working group? Appreciate
> >any advise. Thanks!
> >
> >Happy New Year 2001!
> >Sanjaya
> >Senior Project Manager
> >APNIC (http://www.apnic.net)
>