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

From: [email-masked] (Peter Gutmann)
Date: Fri, 1 Feb 2002 15:08:56 +1300 (NZDT)

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

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 1 Feb 2002 15:15:06 +1300 (NZDT)

Paul Hoffman / VPNC <[email-masked]> 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.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 1 Feb 2002 15:50:20 +1300 (NZDT)

Jean-Marc Desperrier <[email-masked]> 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.

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 1 Feb 2002 15:55:17 +1300 (NZDT)

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

Date: Fri, 01 Feb 2002 09:59:50 +0200
From: Margus Freudenthal <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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

Date: Fri, 1 Feb 2002 15:55:17 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 1 Feb 2002 15:50:20 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

Peter.

Date: Fri, 1 Feb 2002 15:15:06 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

Peter.

Date: Fri, 1 Feb 2002 15:08:56 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Peter.

Date: Fri, 1 Feb 2002 15:04:50 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: Comments on draft-ietf-pkix-okid-00.txt
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 1 Feb 2002 14:57:19 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 31 Jan 2002 17:03:15 -0800
To: Jean-Marc Desperrier <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

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

Date: Fri, 01 Feb 2002 00:33:47 +0100
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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.

Date: Fri, 01 Feb 2002 00:28:52 +0100
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

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.

Date: Thu, 31 Jan 2002 17:34:51 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: whoops
Sender: [email-masked]

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

Date: Thu, 31 Jan 2002 17:03:19 -0500
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Space stamping protocol
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 31 Jan 2002 21:55:13 +0000
From: Dr S N Henson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

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: [email-masked] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

Content-return: allowed
Date: Thu, 31 Jan 2002 12:30:37 -0800
From: Ambarish Malpani <[email-masked]>
Subject: Candidate for moving OCSP to a Draft Standard
To: "[email-masked]'" <[email-masked]>
Sender: [email-masked]

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

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

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

   EMail: [email-masked]

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

   Phone: 650.567.5457
   EMail: [email-masked]

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

   EMail: [email-masked]

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

   EMail: [email-masked]

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

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <[email-masked]>

C.2 application/ocsp-response

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

   Intended usage: COMMON

   Author/Change controller:
   Ambarish Malpani <[email-masked]>

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

Date: Thu, 31 Jan 2002 11:53:46 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Thu, 31 Jan 2002 19:38:48 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 31 Jan 2002 18:58:07 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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

Date: Thu, 31 Jan 2002 17:11:00 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Paul Hoffman <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

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

From: "Anders Rundgren" <[email-masked]>
To: "Roberto Opazo Gazmuri" <[email-masked]>, "PKIX \(Grupo de la IETF\)" <[email-masked]>, "Stefan Santesson" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>
Subject: Re: Local regulations about PI's codification
Date: Thu, 31 Jan 2002 13:52:18 +0100
Sender: [email-masked]

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" <[email-masked]>
To: "Roberto Opazo Gazmuri" <[email-masked]>; "PKIX (Grupo de la IETF)" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>
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 ([email-masked])
>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 [[email-masked]]
>
>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 [[email-masked]]
>
>3.- Finland
>PI: Person number (person-number)
>Codification:
>   subject.serialNumber= person-number
>Local authority:
>   ?
>IETF Information provider:
>   Anders Rundgren [[email-masked]]
>
>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 [[email-masked]]
>
>5.- Italy
>PI: Codice Fiscale (CodiceFiscale)
>Codification:
>   subject.CN = LastName/FirstName/CodiceFiscale/CertificateNumber
>Local authority:
>   ?
>IETF Information provider:
>   ARBIA Sig. Stefano [[email-masked]]
>
>6.- Sweden
>PI: person-number
>Codification:
>   subject.serialNumber= person-number
>Local authority:
>   The Swedish standard SS614331
>IETF Information provider:
>   Anders Rundgren [[email-masked]]
>   Henrik Ståhl [[email-masked]]

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-certstore-http-02.txt
Date: Thu, 31 Jan 2002 07:00:40 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Date: Thu, 31 Jan 2002 11:56:53 +0100
From: Massimiliano Pala <[email-masked]>
Organization: OpenCA
To: [email-masked]
Subject: draft-ietf-pkix-pi
Sender: [email-masked]

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: +39 (0)347 7222 365
--------------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

--------------msFFD0E97B747BDD18140713F2--

Date: Thu, 31 Jan 2002 02:17:58 +0100
To: "Roberto Opazo Gazmuri" <[email-masked]>, "PKIX \(Grupo de la IETF\)" <[email-masked]>
From: Stefan Santesson <[email-masked]>
Subject: Re: Local regulations about PI's codification
Cc: Stephen Kent <[email-masked]>
Sender: [email-masked]

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 ([email-masked])
>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 [[email-masked]]
>
>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 [[email-masked]]
>
>3.- Finland
>PI: Person number (person-number)
>Codification:
>   subject.serialNumber= person-number
>Local authority:
>   ?
>IETF Information provider:
>   Anders Rundgren [[email-masked]]
>
>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 [[email-masked]]
>
>5.- Italy
>PI: Codice Fiscale (CodiceFiscale)
>Codification:
>   subject.CN = LastName/FirstName/CodiceFiscale/CertificateNumber
>Local authority:
>   ?
>IETF Information provider:
>   ARBIA Sig. Stefano [[email-masked]]
>
>6.- Sweden
>PI: person-number
>Codification:
>   subject.serialNumber= person-number
>Local authority:
>   The Swedish standard SS614331
>IETF Information provider:
>   Anders Rundgren [[email-masked]]
>   Henrik Ståhl [[email-masked]]

From: "Roberto Opazo Gazmuri" <[email-masked]>
To: "PKIX \(Grupo de la IETF\)" <[email-masked]>
Subject: =?iso-8859-1?Q?Local_regulations_about_PI's_codification?=
Date: Wed, 30 Jan 2002 17:41:53 -0300
Importance: High
Sender: [email-masked]

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

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

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

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

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

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

Date: Wed, 30 Jan 2002 10:47:05 -0800
To: <[email-masked]>
From: Paul Hoffman / VPNC <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

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

From: "Al Arsenault" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Date: Wed, 30 Jan 2002 13:22:55 -0500
Sender: [email-masked]

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

Date: Wed, 30 Jan 2002 10:07:54 -0800
To: [email-masked]
From: Paul Hoffman / VPNC <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

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

Date: Wed, 30 Jan 2002 17:22:03 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: Paul Hoffman / IMC <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

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) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jan 2002 18:14:39 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked]
Sender: [email-masked]

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

Date: Wed, 30 Jan 2002 08:44:33 -0800
To: [email-masked], [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Cc: [email-masked]
Sender: [email-masked]

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

Date: Wed, 30 Jan 2002 08:51:09 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Cautionary Period Straw Poll
Sender: [email-masked]

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

Date: Wed, 30 Jan 2002 11:41:24 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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

Date: Wed, 30 Jan 2002 16:21:04 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: "Housley, Russ" <[email-masked]>
CC: [email-masked]
Subject: Re: Cautionary Period Straw Poll
Sender: [email-masked]

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

Date: Wed, 30 Jan 2002 14:37:14 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-okid-00.txt
Sender: [email-masked]

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

From: "todd glassey" <[email-masked]>
To: "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: Space stamping protocol
Date: Wed, 30 Jan 2002 06:24:00 -0800
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: [email-masked]
Date: Wed, 30 Jan 2002 08:54:34 -0500
Subject: Re: Cautionary Period Straw Poll
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-okid-00.txt
Date: Wed, 30 Jan 2002 07:02:15 -0500
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jan 2002 11:19:36 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked]
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jan 2002 11:01:02 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked]
Sender: [email-masked]

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

Date: Wed, 30 Jan 2002 10:13:26 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: "Housley, Russ" <[email-masked]>
CC: [email-masked]
Subject: Re: Cautionary Period Straw Poll
Sender: [email-masked]

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 <[email-masked]>
>         Todd Glassey <[email-masked]>
> 
> Ought NOT support cautionary period: 14
>         Santosh Chokhani <[email-masked]>
>         Russ Housley <[email-masked]>
>         Ambarish Malpani <[email-masked]>
>         Sanjeev Shukla <[email-masked]>
>         Yuriy Dzambasow <[email-masked]>
>         Paul Hoffman <[email-masked]>
>         Peter Yee <[email-masked]>
>         Stephen Farrell <[email-masked]>
>         Alex Deacon <[email-masked]>
>         Al Arsenault <[email-masked]>
>         Rich Salz <[email-masked]>
>         Tom Gindin <[email-masked]>
>         Trevor Freeman <[email-masked]>
>         Michael Myers <[email-masked]>
>         Sean P. Turner <[email-masked]>
> 
> Other response: 2
>         Denis Pinkas <[email-masked]>
>         Peter Sylvester <[email-masked]>
> 
> 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

content-class: urn:content-classes:message
Subject: dubble O
Date: Wed, 30 Jan 2002 09:44:34 +0100
From: "Haaino Beljaars" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

Date: Wed, 30 Jan 2002 19:31:21 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Brief comment on draft-ietf-pkix-new-part1-12.txt
Sender: [email-masked]

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.

Date: Tue, 29 Jan 2002 16:34:26 -0500
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Space stamping protocol
Cc: "todd glassey" <[email-masked]>, "Eric Norman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

Date: Tue, 29 Jan 2002 17:17:37 -0500
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Space stamping protocol
Cc: "Eric Norman" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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

From: "todd glassey" <[email-masked]>
To: "todd glassey" <[email-masked]>, "Eric Norman" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Space stamping protocol
Date: Tue, 29 Jan 2002 09:05:00 -0800
Sender: [email-masked]

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

Date: Tue, 29 Jan 2002 16:40:34 +0100
From: Massimiliano Pala <[email-masked]>
Organization: OpenCA
To: [email-masked]
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Sender: [email-masked]

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: +39 (0)347 7222 365
--------------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

--------------ms0DB229BAA849EB7C0949BF8E--

From: "todd glassey" <[email-masked]>
To: "Eric Norman" <[email-masked]>, "Stephen Kent" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Space stamping protocol
Date: Tue, 29 Jan 2002 06:48:56 -0800
Sender: [email-masked]

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

Date: Tue, 29 Jan 2002 08:17:35 -0500
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: Re: Cautionary Period Straw Poll
Sender: [email-masked]

Here are the results of the Straw Poll.

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

Other response: 2
	Denis Pinkas <[email-masked]>
	Peter Sylvester <[email-masked]>

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

Date: Tue, 29 Jan 2002 09:41:49 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: "PKIX (Grupo de la IETF)" <[email-masked]>, Stephen Kent <[email-masked]>, Tim Polk <[email-masked]>
CC: Roberto Opazo Gazmuri <[email-masked]>
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Sender: [email-masked]

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

Date: Mon, 28 Jan 2002 21:54:54 -0500
To: Eric Norman <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Space stamping protocol
Cc: [email-masked]
Sender: [email-masked]

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

From: "Roberto Opazo Gazmuri" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: "PKIX \(Grupo de la IETF\)" <[email-masked]>
Subject: RE: "Subject Alternative Name" v/s "Subject/Serial Number"
Date: Tue, 29 Jan 2002 00:15:34 -0300
Importance: High
Sender: [email-masked]

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

From: Richard Culshaw <[email-masked]>
To: "'Roberto Opazo Gazmuri'" <[email-masked]>, "Ietf-Pkix (E-mail)" <[email-masked]>
Subject: RE: "Subject Alternative Name" v/s "Subject/Serial Number"
Date: Tue, 29 Jan 2002 09:32:44 +1100
Sender: [email-masked]

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

From: "Florian Oelmaier" <[email-masked]>
To: <[email-masked]>
Cc: "Denis Pinkas" <[email-masked]>
Subject: RE: OCSP extensions
Date: Mon, 28 Jan 2002 19:03:53 +0100
Importance: Normal
Sender: [email-masked]

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:[email-masked]]
> Sent: Monday, January 28, 2002 3:29 PM
> To: Ambarish Malpani
> Cc: 'Florian Oelmaier'; [email-masked]
> 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.                                  [email-masked]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> > > -----Original Message-----
> > > From: Florian Oelmaier [mailto:[email-masked]]
> > > Sent: Monday, January 21, 2002 4:08 AM
> > > To: Santosh Chokhani; Yuriy Dzambasow; Ambarish Malpani;
> > > 'Deacon, Alex';
> > > [email-masked]
> > > 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.
> > >
> > >
>
>

Date: Mon, 28 Jan 2002 16:25:40 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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

Date: Mon, 28 Jan 2002 15:48:38 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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

Date: Mon, 28 Jan 2002 14:09:31 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Roberto Opazo Gazmuri <[email-masked]>
CC: "PKIX (Grupo de la IETF)" <[email-masked]>
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Sender: [email-masked]

> 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

Date: Mon, 28 Jan 2002 15:29:03 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Ambarish Malpani <[email-masked]>
CC: "'Florian Oelmaier'" <[email-masked]>, [email-masked]
Subject: Re: OCSP extensions
Sender: [email-masked]

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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> > -----Original Message-----
> > From: Florian Oelmaier [mailto:[email-masked]]
> > Sent: Monday, January 21, 2002 4:08 AM
> > To: Santosh Chokhani; Yuriy Dzambasow; Ambarish Malpani;
> > 'Deacon, Alex';
> > [email-masked]
> > 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.
> >
> >

Date: Mon, 28 Jan 2002 11:04:53 +0100
From: Tomas Gustavsson <[email-masked]>
To: [email-masked]
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Sender: [email-masked]

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

From: "Anders Rundgren" <[email-masked]>
To: "Roberto Opazo Gazmuri" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "Peter Gutmann" <[email-masked]>
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Date: Mon, 28 Jan 2002 10:28:21 +0100
Sender: [email-masked]

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" <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, January 28, 2002 05:05
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"

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

Date: Mon, 28 Jan 2002 17:05:54 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Sender: [email-masked]

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

From: "Al Arsenault" <[email-masked]>
To: =?iso-8859-1?Q?Henrik_St=E5hl?= <[email-masked]>, <[email-masked]>
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Date: Sun, 27 Jan 2002 21:13:39 -0500
Sender: [email-masked]

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

Date: Sun, 27 Jan 2002 21:31:18 +0100
From: Henrik =?iso-8859-1?Q?St=E5hl?= <[email-masked]>
Organization: Omegapoint AB
To: [email-masked]
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Sender: [email-masked]

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

From: "Anders Rundgren" <[email-masked]>
To: "Roberto Opazo Gazmuri" <[email-masked]>, "PKIX \(Grupo de la IETF\)" <[email-masked]>
Subject: Re: "Subject Alternative Name" v/s "Subject/Serial Number"
Date: Sun, 27 Jan 2002 09:49:10 +0100
Sender: [email-masked]

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" <[email-masked]>
To: "PKIX (Grupo de la IETF)" <[email-masked]>
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

From: "Roberto Opazo Gazmuri" <[email-masked]>
To: "PKIX \(Grupo de la IETF\)" <[email-masked]>
Subject: "Subject Alternative Name" v/s "Subject/Serial Number"
Date: Sat, 26 Jan 2002 18:31:48 -0300
Importance: High
Sender: [email-masked]

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

Date: Fri, 25 Jan 2002 16:46:31 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: Infinite loop: See loop, infinite
Sender: [email-masked]

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.

Content-return: allowed
Date: Fri, 25 Jan 2002 13:48:18 -0800
From: Peter Williams <[email-masked]>
Subject: RE: Infinite loop: See loop, infinite
To: "[email-masked] '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Fri, 25 Jan 2002 19:34:13 +0100 (MET)
To: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Fri, 25 Jan 2002 19:06:29 +0100 (MET)
To: [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 25 Jan 2002 17:44:42 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Phil Griffin <[email-masked]>
CC: Peter Gutmann <[email-masked]>, [email-masked], [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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.

Date: Sat, 26 Jan 2002 05:42:04 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked]
Subject: RE: Infinite loop: See loop, infinite
Sender: [email-masked]

"Hallam-Baker, Phillip" <[email-masked]> 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.

Date: Fri, 25 Jan 2002 11:32:34 -0500
From: Phil Griffin <[email-masked]>
Organization: Griffin Consulting - http://ASN-1.com
To: Denis Pinkas <[email-masked]>
CC: Peter Gutmann <[email-masked]>, [email-masked], [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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.

From: "Hallam-Baker, Phillip" <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: Infinite loop: See loop, infinite
Date: Fri, 25 Jan 2002 07:49:51 -0800
Sender: [email-masked]

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

------_=_NextPart_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:(781) 245-6996 x227
EMAIL;PREF;INTERNET:[email-masked]
REV:20010214T163732Z
END:VCARD

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

Date: Fri, 25 Jan 2002 15:31:14 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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.

Date: Fri, 25 Jan 2002 23:31:15 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Infinite loop: See loop, infinite
Sender: [email-masked]

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.

Content-return: allowed
Date: Thu, 24 Jan 2002 10:09:38 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: RFC 2560 question
To: "'Sven Heiberg'" <[email-masked]>, [email-masked]
Sender: [email-masked]

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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Sven Heiberg [mailto:[email-masked]]
> Sent: Thursday, January 24, 2002 5:45 AM
> To: [email-masked]
> 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
> 

Date: Thu, 24 Jan 2002 15:44:53 +0200 (EET)
From: Sven Heiberg <[email-masked]>
To: [email-masked]
Subject: RFC 2560 question
Sender: [email-masked]

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

From: "McCutcheon, Mark" <[email-masked]>
To: "'Eric Norman'" <[email-masked]>, [email-masked]
Subject: RE: Space stamping protocol
Date: Wed, 23 Jan 2002 15:37:46 -0800
Sender: [email-masked]

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

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

> -----Original Message-----
> From: Eric Norman [mailto:[email-masked]]
> Sent: Wednesday, January 23, 2002 1:41 PM
> To: [email-masked]
> 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".
> 
> 
> 

From: "todd glassey" <[email-masked]>
To: "Eric Norman" <[email-masked]>, <[email-masked]>
Cc: "Michael McNeil" <[email-masked]>
Subject: Re: Space stamping protocol
Date: Wed, 23 Jan 2002 15:31:09 -0800
Sender: [email-masked]

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

Date: Wed, 23 Jan 2002 15:41:25 -0600 (CST)
From: Eric Norman <[email-masked]>
To: [email-masked]
Subject: Space stamping protocol
Sender: [email-masked]

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

Date: Tue, 22 Jan 2002 07:23:13 -0500
From: "Sean P. Turner" <[email-masked]>
Organization: IECA, Inc.
To: [email-masked]
Subject: Re: Cautionary Period Straw Poll
Sender: [email-masked]

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

From: Santosh Chokhani <[email-masked]>
To: [email-masked]
Subject: RE: SCVP Version 6
Date: Mon, 21 Jan 2002 16:54:41 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Monday, January 21, 2002 3:05 PM
To: [email-masked]
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 
[email-masked] 
(703) 270-3520  (703) 848-0960 (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:[email-masked]]<BR><B>Sent:</B> Monday, January 21, 2002 3:05 
  PM<BR><B>To:</B> [email-masked]<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>[email-masked]</FONT> <BR><FONT face=Arial size=2>(703) 
  270-3520&nbsp; (703) 848-0960 (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--

From: Santosh Chokhani <[email-masked]>
To: [email-masked]
Subject: SCVP Version 6
Date: Mon, 21 Jan 2002 15:04:30 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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
[email-masked]
(703) 270-3520  (703) 848-0960 (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">[email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(703) 270-3520&nbsp; (703) 848-0960 =
(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--

Content-return: allowed
Date: Mon, 21 Jan 2002 09:35:40 -0800
From: Ambarish Malpani <[email-masked]>
Subject: OCSP extensions
To: "'Florian Oelmaier'" <[email-masked]>, [email-masked]
Sender: [email-masked]

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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Florian Oelmaier [mailto:[email-masked]]
> Sent: Monday, January 21, 2002 4:08 AM
> To: Santosh Chokhani; Yuriy Dzambasow; Ambarish Malpani; 
> 'Deacon, Alex';
> [email-masked]
> 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.
> 
> 

From: Santosh Chokhani <[email-masked]>
To: Florian Oelmaier <[email-masked]>, Santosh Chokhani <[email-masked]>, Yuriy Dzambasow <[email-masked]>, Ambarish Malpani <[email-masked]>, "'Deacon, Alex'" <[email-masked]>, [email-masked]
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Mon, 21 Jan 2002 08:47:49 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Monday, January 21, 2002 7:08 AM
To: Santosh Chokhani; Yuriy Dzambasow; Ambarish Malpani; 'Deacon, Alex';
[email-masked]
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:[email-masked]">mailto:[email-masked]</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>[email-masked]</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--

From: "Florian Oelmaier" <[email-masked]>
To: "Santosh Chokhani" <[email-masked]>, "Yuriy Dzambasow" <[email-masked]>, "Ambarish Malpani" <[email-masked]>, "'Deacon, Alex'" <[email-masked]>, <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Mon, 21 Jan 2002 13:07:57 +0100
Importance: Normal
Sender: [email-masked]

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.

Date: Mon, 21 Jan 2002 12:50:55 +0000
From: tho <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-new-part1-12.txt
Date: Mon, 21 Jan 2002 05:10:45 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cautionary Period Straw Poll
Date: Sun, 20 Jan 2002 13:41:58 -0800
Importance: Normal
Sender: [email-masked]

The DPD/DPV protocols being developed by the PKIX working group
ought NOT include support for a cautionary period.

Mike

From: Peter Sylvester <[email-masked]>
Date: Sun, 20 Jan 2002 18:49:30 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Cautionary Period -- STRAW POLL
Cc: [email-masked]
Sender: [email-masked]

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.  

Date: Sat, 19 Jan 2002 17:32:23 +0100
From: Petra Barzin <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: draft-ietf-pkix-dpv-dpd-00.txt
Sender: [email-masked]

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

Date: Sat, 19 Jan 2002 13:56:44 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked]
Sender: [email-masked]

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

Date: Sat, 19 Jan 2002 13:49:37 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

Jean-Marc Desperrier <[email-masked]> 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.

Date: Fri, 18 Jan 2002 19:55:09 +0100
From: "=?iso-8859-1?Q?Jos=E9?= A. =?iso-8859-1?Q?Ma=F1as?=" <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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

From: Santosh Chokhani <[email-masked]>
To: Denis Pinkas <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: Ambarish Malpani <[email-masked]>, [email-masked]
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Fri, 18 Jan 2002 13:39:12 -0500
Sender: [email-masked]

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

------_=_NextPart_001_01C1A04F.6CA0E9B0
Content-Type: text/plain

Denis Please comments in-line.

-----Original Message-----
From: Denis Pinkas [mailto:[email-masked]]
Sent: Friday, January 18, 2002 12:45 PM
To: Santosh Chokhani
Cc: Ambarish Malpani; [email-masked]
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:[email-masked]]
> Sent: Friday, January 18, 2002 9:22 AM
> To: Ambarish Malpani; 'Deacon, Alex'; 'Santosh Chokhani';
> [email-masked]
> 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" <[email-masked]>
> To: "'Deacon, Alex'" <[email-masked]>; "'Santosh Chokhani'"
> <[email-masked]>; <[email-masked]>
> 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.                                  [email-masked]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Deacon, Alex [mailto:[email-masked]]
> > Sent: Thursday, January 17, 2002 11:37 AM
> > To: 'Santosh Chokhani'; Ambarish Malpani; [email-masked] '
> > 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:[email-masked]]
> > Sent: Thursday, January 17, 2002 11:23 AM
> > To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
> > 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:[email-masked]]
> > Sent: Thursday, January 17, 2002 2:08 PM
> > To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
> > 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:[email-masked]]
> > Sent: Thursday, January 17, 2002 2:01 PM
> > To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
> > 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:[email-masked]]
> > Sent: Thursday, January 17, 2002 1:56 PM
> > To: 'Santosh Chokhani'; [email-masked] '
> > 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.                                  [email-masked]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Thursday, January 17, 2002 10:31 AM
> > To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
> > 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:[email-masked]]
> > Sent: Thursday, January 17, 2002 11:53 AM
> > To: 'Denis Pinkas'; [email-masked] '
> > 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.                                  [email-masked]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> >
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[email-masked]]
> > > Sent: Thursday, January 17, 2002 8:50 AM
> > > To: Ambarish Malpani
> > > Cc: 'Santosh Chokhani'; [email-masked] '
> > > 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.
> > > [email-masked]
> > > > 339 N. Bernardo Ave.
> > http://www.valicert.com
> > > Mountain View, CA 94043
> > >
> > > -----Original Message-----
> > > From: Santosh Chokhani [mailto:[email-masked]]
> > > Sent: Wednesday, January 16, 2002 11:50 AM
> > > To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> > > Cc: [email-masked] '
> > > 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:[email-masked]]
> > > Sent: Wednesday, January 16, 2002 2:41 PM
> > > To: 'Denis Pinkas '; 'Santosh Chokhani '
> > > Cc: [email-masked] '
> > > 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: [email-masked]
> > > 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:[email-masked]">mailto:[email-masked]</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; [email-masked]</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:[email-masked]">mailto:[email-masked]</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; [email-masked]</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;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; To: &quot;'Deacon, Alex'&quot; =
&lt;[email-masked]&gt;; &quot;'Santosh Chokhani'&quot;</FONT>
<BR><FONT SIZE=3D2>&gt; &lt;[email-masked]&gt;; =
&lt;[email-masked]&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; =
[email-masked]</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:[email-masked]">mailto:[email-masked]</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; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</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; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</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; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</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; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</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'; [email-masked] =
'</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; =
[email-masked]</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:[email-masked]">mailto:[email-masked]</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'; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</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'; [email-masked] =
'</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; =
[email-masked]</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:[email-masked]">mailto:[email-masked]</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'; =
[email-masked] '</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; [email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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: [email-masked]</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--

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Jan 2002 19:21:00 +0100 (MET)
To: [email-masked]
Subject: meeting minutes and DPV-DPV req draft
Sender: [email-masked]

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

Content-return: allowed
Date: Fri, 18 Jan 2002 09:54:26 -0800
From: Peter Williams <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "[email-masked] '" <[email-masked]>
Cc: "''Santosh Chokhani' '" <[email-masked]>
Sender: [email-masked]

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

Date: Fri, 18 Jan 2002 18:44:47 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Santosh Chokhani <[email-masked]>
CC: Ambarish Malpani <[email-masked]>, [email-masked]
Subject: Re: OCSP RFC and OCSP version 2 ID
Sender: [email-masked]

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:[email-masked]]
> Sent: Friday, January 18, 2002 9:22 AM
> To: Ambarish Malpani; 'Deacon, Alex'; 'Santosh Chokhani';
> [email-masked]
> 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" <[email-masked]>
> To: "'Deacon, Alex'" <[email-masked]>; "'Santosh Chokhani'"
> <[email-masked]>; <[email-masked]>
> 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.                                  [email-masked]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Deacon, Alex [mailto:[email-masked]]
> > Sent: Thursday, January 17, 2002 11:37 AM
> > To: 'Santosh Chokhani'; Ambarish Malpani; [email-masked] '
> > 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:[email-masked]]
> > Sent: Thursday, January 17, 2002 11:23 AM
> > To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
> > 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:[email-masked]]
> > Sent: Thursday, January 17, 2002 2:08 PM
> > To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
> > 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:[email-masked]]
> > Sent: Thursday, January 17, 2002 2:01 PM
> > To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
> > 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:[email-masked]]
> > Sent: Thursday, January 17, 2002 1:56 PM
> > To: 'Santosh Chokhani'; [email-masked] '
> > 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.                                  [email-masked]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Thursday, January 17, 2002 10:31 AM
> > To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
> > 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:[email-masked]]
> > Sent: Thursday, January 17, 2002 11:53 AM
> > To: 'Denis Pinkas'; [email-masked] '
> > 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.                                  [email-masked]
> > 339 N. Bernardo Ave.                          http://www.valicert.com
> > Mountain View, CA 94043
> >
> >
> > > -----Original Message-----
> > > From: Denis Pinkas [mailto:[email-masked]]
> > > Sent: Thursday, January 17, 2002 8:50 AM
> > > To: Ambarish Malpani
> > > Cc: 'Santosh Chokhani'; [email-masked] '
> > > 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.
> > > [email-masked]
> > > > 339 N. Bernardo Ave.
> > http://www.valicert.com
> > > Mountain View, CA 94043
> > >
> > > -----Original Message-----
> > > From: Santosh Chokhani [mailto:[email-masked]]
> > > Sent: Wednesday, January 16, 2002 11:50 AM
> > > To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> > > Cc: [email-masked] '
> > > 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:[email-masked]]
> > > Sent: Wednesday, January 16, 2002 2:41 PM
> > > To: 'Denis Pinkas '; 'Santosh Chokhani '
> > > Cc: [email-masked] '
> > > 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: [email-masked]
> > > 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.
> > >
> >

Date: Fri, 18 Jan 2002 18:40:51 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Peter Sylvester <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP RFC and OCSP version 2 ID
Sender: [email-masked]

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

From: Santosh Chokhani <[email-masked]>
To: Yuriy Dzambasow <[email-masked]>, Ambarish Malpani <[email-masked]>, "'Deacon, Alex'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, [email-masked]
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Fri, 18 Jan 2002 11:52:11 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Friday, January 18, 2002 9:22 AM
To: Ambarish Malpani; 'Deacon, Alex'; 'Santosh Chokhani';
[email-masked]
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" <[email-masked]>
To: "'Deacon, Alex'" <[email-masked]>; "'Santosh Chokhani'"
<[email-masked]>; <[email-masked]>
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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
> -----Original Message-----
> From: Deacon, Alex [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 11:37 AM
> To: 'Santosh Chokhani'; Ambarish Malpani; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 11:23 AM
> To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 2:08 PM
> To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 2:01 PM
> To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 1:56 PM
> To: 'Santosh Chokhani'; [email-masked] '
> 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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 10:31 AM
> To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 11:53 AM
> To: 'Denis Pinkas'; [email-masked] '
> 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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Thursday, January 17, 2002 8:50 AM
> > To: Ambarish Malpani
> > Cc: 'Santosh Chokhani'; [email-masked] '
> > 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.
> > [email-masked]
> > > 339 N. Bernardo Ave.
> http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Wednesday, January 16, 2002 11:50 AM
> > To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> > Cc: [email-masked] '
> > 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:[email-masked]]
> > Sent: Wednesday, January 16, 2002 2:41 PM
> > To: 'Denis Pinkas '; 'Santosh Chokhani '
> > Cc: [email-masked] '
> > 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: [email-masked]
> > 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:[email-masked]">mailto:[email-masked]</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>[email-masked]</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;[email-masked]&gt;</FONT>
<BR><FONT SIZE=3D2>To: &quot;'Deacon, Alex'&quot; =
&lt;[email-masked]&gt;; &quot;'Santosh Chokhani'&quot;</FONT>
<BR><FONT SIZE=3D2>&lt;[email-masked]&gt;; =
&lt;[email-masked]&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; =
[email-masked]</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:[email-masked]">mailto:[email-masked]</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; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</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; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</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; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</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; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 17, 2002 1:56 PM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Santosh Chokhani'; [email-masked] =
'</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; =
[email-masked]</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:[email-masked]">mailto:[email-masked]</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'; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>&gt; Sent: Thursday, January 17, 2002 11:53 =
AM</FONT>
<BR><FONT SIZE=3D2>&gt; To: 'Denis Pinkas'; [email-masked] '</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; =
[email-masked]</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:[email-masked]">mailto:[email-masked]</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'; [email-masked] =
'</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; [email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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: [email-masked]</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--

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Jan 2002 17:53:11 +0100 (MET)
To: [email-masked]
Subject: RE: OCSP RFC and OCSP version 2 ID
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Jan 2002 16:09:25 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: TSP interop update
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 18 Jan 2002 09:48:56 -0500
To: <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: meeting minutes
Sender: [email-masked]

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

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.

Reply-To: "Yuriy Dzambasow" <[email-masked]>
From: "Yuriy Dzambasow" <[email-masked]>
To: "Ambarish Malpani" <[email-masked]>, "'Deacon, Alex'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, <[email-masked]>
Subject: Re: OCSP RFC and OCSP version 2 ID
Date: Fri, 18 Jan 2002 09:21:59 -0500
Organization: Digital Signature Trust
Sender: [email-masked]

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" <[email-masked]>
To: "'Deacon, Alex'" <[email-masked]>; "'Santosh Chokhani'"
<[email-masked]>; <[email-masked]>
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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
> -----Original Message-----
> From: Deacon, Alex [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 11:37 AM
> To: 'Santosh Chokhani'; Ambarish Malpani; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 11:23 AM
> To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 2:08 PM
> To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 2:01 PM
> To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 1:56 PM
> To: 'Santosh Chokhani'; [email-masked] '
> 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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 10:31 AM
> To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
> 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:[email-masked]]
> Sent: Thursday, January 17, 2002 11:53 AM
> To: 'Denis Pinkas'; [email-masked] '
> 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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
>
>
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Thursday, January 17, 2002 8:50 AM
> > To: Ambarish Malpani
> > Cc: 'Santosh Chokhani'; [email-masked] '
> > 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.
> > [email-masked]
> > > 339 N. Bernardo Ave.
> http://www.valicert.com
> > Mountain View, CA 94043
> >
> > -----Original Message-----
> > From: Santosh Chokhani [mailto:[email-masked]]
> > Sent: Wednesday, January 16, 2002 11:50 AM
> > To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> > Cc: [email-masked] '
> > 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:[email-masked]]
> > Sent: Wednesday, January 16, 2002 2:41 PM
> > To: 'Denis Pinkas '; 'Santosh Chokhani '
> > Cc: [email-masked] '
> > 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: [email-masked]
> > 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.
> >
>

Date: Fri, 18 Jan 2002 11:36:00 +0000
From: tho <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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

Date: Fri, 18 Jan 2002 10:25:10 +0100
From: Jean-Marc Desperrier <[email-masked]>
Organization: Certplus
To: [email-masked]
Subject: Re: TSP interop update
Sender: [email-masked]

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.

Date: Fri, 18 Jan 2002 16:51:05 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  TSP interop update
Sender: [email-masked]

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

content-class: urn:content-classes:message
Subject: Cautionary Period Straw Poll
Date: Thu, 17 Jan 2002 15:01:16 -0800
From: "Trevor Freeman" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

Trevor

From: Santosh Chokhani <[email-masked]>
To: Ambarish Malpani <[email-masked]>, "'Deacon, Alex'" <[email-masked]>, Santosh Chokhani <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 15:26:52 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Thursday, January 17, 2002 3:14 PM
To: 'Deacon, Alex'; 'Santosh Chokhani'; [email-masked] '
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Deacon, Alex [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 11:37 AM
To: 'Santosh Chokhani'; Ambarish Malpani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 11:23 AM
To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 2:08 PM
To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; [email-masked] '
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
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:[email-masked]] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; [email-masked] ' 
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.                                  [email-masked] 
339 N. Bernardo Ave.                          http://www.valicert.com 
Mountain View, CA 94043 

> -----Original Message----- 
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; [email-masked] ' 
> 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.                                  
> [email-masked] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com 
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [mailto:[email-masked]] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: [email-masked] ' 
> 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:[email-masked]] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: [email-masked] ' 
> 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: [email-masked] 
> 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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 3:14 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Deacon, Alex'; 'Santosh Chokhani'; =
[email-masked] '</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; =
[email-masked]</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:[email-masked]">mailto:[email-masked]</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 11:37 AM</FONT>
<BR><FONT SIZE=3D2>To: 'Santosh Chokhani'; Ambarish Malpani; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 11:23 AM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani; Ambarish Malpani; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 2:08 PM</FONT>
<BR><FONT SIZE=3D2>To: Santosh Chokhani; Ambarish Malpani; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 2:01 PM</FONT>
<BR><FONT SIZE=3D2>To: Ambarish Malpani; Santosh Chokhani; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 1:56 PM</FONT>
<BR><FONT SIZE=3D2>To: 'Santosh Chokhani'; [email-masked] '</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; =
[email-masked]</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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 10:31 AM</FONT>
<BR><FONT SIZE=3D2>To: Ambarish Malpani; 'Denis Pinkas'; =
[email-masked] '</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:[email-masked]">mailto:[email-masked]</A>] =
</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 11:53 AM </FONT>
<BR><FONT SIZE=3D2>To: 'Denis Pinkas'; [email-masked] ' </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; =
[email-masked] </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:[email-masked]">mailto:[email-masked]</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'; [email-masked] ' =
</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; [email-masked] </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:[email-masked]">mailto:[email-masked]</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: [email-masked] ' </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:[email-masked]">mailto:[email-masked]</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: [email-masked] ' </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: [email-masked] </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--

Content-return: allowed
Date: Thu, 17 Jan 2002 12:13:32 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'Deacon, Alex'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Deacon, Alex [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 11:37 AM
To: 'Santosh Chokhani'; Ambarish Malpani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 11:23 AM
To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 2:08 PM
To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; [email-masked] '
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
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:[email-masked]] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; [email-masked] ' 
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.                                  [email-masked] 
339 N. Bernardo Ave.                          http://www.valicert.com 
Mountain View, CA 94043 

> -----Original Message----- 
> From: Denis Pinkas [mailto:[email-masked]] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; [email-masked] ' 
> 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.                                  
> [email-masked] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com 
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [mailto:[email-masked]] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: [email-masked] ' 
> 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:[email-masked]] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: [email-masked] ' 
> 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: [email-masked] 
> 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. 
> 

From: Santosh Chokhani <[email-masked]>
To: "Deacon, Alex" <[email-masked]>, Santosh Chokhani <[email-masked]>, Ambarish Malpani <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 14:40:34 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Thursday, January 17, 2002 2:37 PM
To: 'Santosh Chokhani'; Ambarish Malpani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 11:23 AM
To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 2:08 PM
To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; [email-masked] '
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
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:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; [email-masked] ' 
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.                                  [email-masked] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 

> -----Original Message----- 
> From: Denis Pinkas [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; [email-masked] ' 
> 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.                                  
> [email-masked] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: [email-masked] ' 
> 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:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: [email-masked] ' 
> 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: [email-masked] 
> 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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 2002 2:37 
  PM<BR><B>To:</B> 'Santosh Chokhani'; Ambarish Malpani; [email-masked] 
  '<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 2002 
    11:23 AM<BR><B>To:</B> Santosh Chokhani; Ambarish Malpani; 
    [email-masked] '<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 2002 
      2:08 PM<BR><B>To:</B> Santosh Chokhani; Ambarish Malpani; 
      [email-masked] '<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 
        2002 2:01 PM<BR><B>To:</B> Ambarish Malpani; Santosh Chokhani; 
        [email-masked] '<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 
          2002 1:56 PM<BR><B>To:</B> 'Santosh Chokhani'; [email-masked] 
          '<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; 
          [email-masked]<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 
            2002 10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas'; 
            [email-masked] '<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:[email-masked]">mailto:[email-masked]</A>]</FONT> 
            <BR><FONT size=2>Sent: Thursday, January 17, 2002 11:53 AM</FONT> 
            <BR><FONT size=2>To: 'Denis Pinkas'; [email-masked] '</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; 
            [email-masked]</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:[email-masked]">mailto:[email-masked]</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'; [email-masked] 
            '</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; [email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked] 
            '</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:[email-masked]">mailto:[email-masked]</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: [email-masked] 
            '</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: [email-masked]</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--

From: "Deacon, Alex" <[email-masked]>
To: "'Santosh Chokhani'" <[email-masked]>, Ambarish Malpani <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 11:37:24 -0800
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Thursday, January 17, 2002 11:23 AM
To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 2:08 PM
To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; [email-masked] '
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
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:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; [email-masked] ' 
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.                                  [email-masked] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 

> -----Original Message----- 
> From: Denis Pinkas [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; [email-masked] ' 
> 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.                                  
> [email-masked] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: [email-masked] ' 
> 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:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: [email-masked] ' 
> 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: [email-masked] 
> 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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 2002 
  11:23 AM<BR><B>To:</B> Santosh Chokhani; Ambarish Malpani; [email-masked] 
  '<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 2002 
    2:08 PM<BR><B>To:</B> Santosh Chokhani; Ambarish Malpani; [email-masked] 
    '<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 2002 
      2:01 PM<BR><B>To:</B> Ambarish Malpani; Santosh Chokhani; 
      [email-masked] '<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 
        2002 1:56 PM<BR><B>To:</B> 'Santosh Chokhani'; [email-masked] 
        '<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; 
        [email-masked]<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 
          2002 10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas'; 
          [email-masked] '<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:[email-masked]">mailto:[email-masked]</A>]</FONT> 
          <BR><FONT size=2>Sent: Thursday, January 17, 2002 11:53 AM</FONT> 
          <BR><FONT size=2>To: 'Denis Pinkas'; [email-masked] '</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; 
          [email-masked]</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:[email-masked]">mailto:[email-masked]</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'; [email-masked] '</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; [email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked] 
          '</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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: 
          [email-masked]</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--

From: Santosh Chokhani <[email-masked]>
To: Santosh Chokhani <[email-masked]>, Ambarish Malpani <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 14:22:38 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Thursday, January 17, 2002 2:08 PM
To: Santosh Chokhani; Ambarish Malpani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; [email-masked] '
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
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:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; [email-masked] ' 
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.                                  [email-masked] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 

> -----Original Message----- 
> From: Denis Pinkas [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; [email-masked] ' 
> 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.                                  
> [email-masked] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: [email-masked] ' 
> 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:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: [email-masked] ' 
> 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: [email-masked] 
> 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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 2002 2:08 
  PM<BR><B>To:</B> Santosh Chokhani; Ambarish Malpani; [email-masked] 
  '<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 2002 
    2:01 PM<BR><B>To:</B> Ambarish Malpani; Santosh Chokhani; [email-masked] 
    '<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 2002 
      1:56 PM<BR><B>To:</B> 'Santosh Chokhani'; [email-masked] 
      '<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; 
      [email-masked]<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, 
        2002 10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas'; 
        [email-masked] '<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:[email-masked]">mailto:[email-masked]</A>]</FONT> 
        <BR><FONT size=2>Sent: Thursday, January 17, 2002 11:53 AM</FONT> 
        <BR><FONT size=2>To: 'Denis Pinkas'; [email-masked] '</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; 
        [email-masked]</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:[email-masked]">mailto:[email-masked]</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'; [email-masked] '</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; [email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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: [email-masked]</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--

From: Santosh Chokhani <[email-masked]>
To: Santosh Chokhani <[email-masked]>, Ambarish Malpani <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 14:08:27 -0500
Sender: [email-masked]

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

------_=_NextPart_001_01C19F8A.58554110
Content-Type: text/plain

Upon further reflection, I think thisUpdate DOES take care of it.

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 2:01 PM
To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; [email-masked] '
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
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:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; [email-masked] ' 
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.                                  [email-masked] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 

> -----Original Message----- 
> From: Denis Pinkas [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; [email-masked] ' 
> 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.                                  
> [email-masked] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: [email-masked] ' 
> 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:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: [email-masked] ' 
> 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: [email-masked] 
> 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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, =
2002 2:01=20
  PM<BR><B>To:</B> Ambarish Malpani; Santosh Chokhani; =
[email-masked]=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:[email-masked]]<BR><B>Sent:</B> Thursday, January =
17, 2002=20
    1:56 PM<BR><B>To:</B> 'Santosh Chokhani'; [email-masked]=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
    [email-masked]<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:[email-masked]]<BR><B>Sent:</B> Thursday, January =
17, 2002=20
      10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas';=20
      [email-masked] '<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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>=20
      <BR><FONT size=3D2>Sent: Thursday, January 17, 2002 11:53 =
AM</FONT>=20
      <BR><FONT size=3D2>To: 'Denis Pinkas'; [email-masked] =
'</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
      [email-masked]</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:[email-masked]">mailto:[email-masked]</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'; [email-masked] '</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; [email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked] =
'</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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: =
[email-masked]</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--

Content-return: allowed
Date: Thu, 17 Jan 2002 11:08:21 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'Santosh Chokhani'" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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

--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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 11:01 AM
To: Ambarish Malpani; Santosh Chokhani; [email-masked] '
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:[email-masked]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; [email-masked] '
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
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:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; [email-masked] ' 
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.                                  [email-masked] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 

> -----Original Message----- 
> From: Denis Pinkas [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; [email-masked] ' 
> 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.                                  
> [email-masked] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: [email-masked] ' 
> 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:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: [email-masked] ' 
> 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: [email-masked] 
> 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
[email-masked]<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, =
2002=20
  11:01 AM<BR><B>To:</B> Ambarish Malpani; Santosh Chokhani; =
[email-masked]=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:[email-masked]]<BR><B>Sent:</B> Thursday, January =
17, 2002=20
    1:56 PM<BR><B>To:</B> 'Santosh Chokhani'; [email-masked]=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
    [email-masked]<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:[email-masked]]<BR><B>Sent:</B> Thursday, January =
17, 2002=20
      10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas';=20
      [email-masked] '<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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>=20
      <BR><FONT size=3D2>Sent: Thursday, January 17, 2002 11:53 =
AM</FONT>=20
      <BR><FONT size=3D2>To: 'Denis Pinkas'; [email-masked] =
'</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
      [email-masked]</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:[email-masked]">mailto:[email-masked]</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'; [email-masked] '</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; [email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked] =
'</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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: =
[email-masked]</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)--

From: Santosh Chokhani <[email-masked]>
To: Ambarish Malpani <[email-masked]>, Santosh Chokhani <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 14:01:04 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Thursday, January 17, 2002 1:56 PM
To: 'Santosh Chokhani'; [email-masked] '
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
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:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; [email-masked] ' 
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.                                  [email-masked] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 

> -----Original Message----- 
> From: Denis Pinkas [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; [email-masked] ' 
> 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.                                  
> [email-masked] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: [email-masked] ' 
> 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:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: [email-masked] ' 
> 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: [email-masked] 
> 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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, =
2002 1:56=20
  PM<BR><B>To:</B> 'Santosh Chokhani'; [email-masked] =
'<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
  [email-masked]<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:[email-masked]]<BR><B>Sent:</B> Thursday, January =
17, 2002=20
    10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas'; =
[email-masked]=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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>=20
    <BR><FONT size=3D2>Sent: Thursday, January 17, 2002 11:53 AM</FONT> =
<BR><FONT=20
    size=3D2>To: 'Denis Pinkas'; [email-masked] '</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
    [email-masked]</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:[email-masked]">mailto:[email-masked]</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'; [email-masked] '</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; [email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked] =
'</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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: [email-masked]</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--

Content-return: allowed
Date: Thu, 17 Jan 2002 10:56:08 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'Santosh Chokhani'" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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

--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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com/> 
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Thursday, January 17, 2002 10:31 AM
To: Ambarish Malpani; 'Denis Pinkas'; [email-masked] '
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:[email-masked]
<mailto:[email-masked]> ] 
Sent: Thursday, January 17, 2002 11:53 AM 
To: 'Denis Pinkas'; [email-masked] ' 
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.                                  [email-masked] 
339 N. Bernardo Ave.                          http://www.valicert.com
<http://www.valicert.com>  
Mountain View, CA 94043 

> -----Original Message----- 
> From: Denis Pinkas [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Thursday, January 17, 2002 8:50 AM 
> To: Ambarish Malpani 
> Cc: 'Santosh Chokhani'; [email-masked] ' 
> 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.                                  
> [email-masked] 
> > 339 N. Bernardo Ave.                          
http://www.valicert.com <http://www.valicert.com>  
> Mountain View, CA 94043 
> 
> -----Original Message----- 
> From: Santosh Chokhani [ mailto:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 11:50 AM 
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani 
> Cc: [email-masked] ' 
> 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:[email-masked]
<mailto:[email-masked]> ] 
> Sent: Wednesday, January 16, 2002 2:41 PM 
> To: 'Denis Pinkas '; 'Santosh Chokhani ' 
> Cc: [email-masked] ' 
> 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: [email-masked] 
> 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
[email-masked]<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:[email-masked]]<BR><B>Sent:</B> Thursday, January 17, =
2002=20
  10:31 AM<BR><B>To:</B> Ambarish Malpani; 'Denis Pinkas'; =
[email-masked]=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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>=20
  <BR><FONT size=3D2>Sent: Thursday, January 17, 2002 11:53 AM</FONT> =
<BR><FONT=20
  size=3D2>To: 'Denis Pinkas'; [email-masked] '</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
  [email-masked]</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:[email-masked]">mailto:[email-masked]</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'; [email-masked] '</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; [email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked] =
'</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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: [email-masked]</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)--

From: Santosh Chokhani <[email-masked]>
To: Ambarish Malpani <[email-masked]>, "'Denis Pinkas'" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 13:30:35 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Thursday, January 17, 2002 11:53 AM
To: 'Denis Pinkas'; [email-masked] '
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 8:50 AM
> To: Ambarish Malpani
> Cc: 'Santosh Chokhani'; [email-masked] '
> 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.                                  
> [email-masked]
> > 339 N. Bernardo Ave.                          
http://www.valicert.com
> Mountain View, CA 94043
> 
> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2002 11:50 AM
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> Cc: [email-masked] '
> 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:[email-masked]]
> Sent: Wednesday, January 16, 2002 2:41 PM
> To: 'Denis Pinkas '; 'Santosh Chokhani '
> Cc: [email-masked] '
> 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: [email-masked]
> 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:[email-masked]">mailto:[email-masked]</A>]<=
/FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, January 17, 2002 11:53 AM</FONT>
<BR><FONT SIZE=3D2>To: 'Denis Pinkas'; [email-masked] '</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; =
[email-masked]</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:[email-masked]">mailto:[email-masked]</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'; [email-masked] =
'</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; [email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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: [email-masked]</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--

From: "Hallam-Baker, Phillip" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, Petra Barzin <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Date: Thu, 17 Jan 2002 10:03:24 -0800
Sender: [email-masked]

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

------_=_NextPart_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.
[email-masked]
781 245 6996 x227

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2002 9:40 AM
> To: Petra Barzin; Denis Pinkas
> Cc: [email-masked]
> 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:(781) 245-6996 x227
EMAIL;PREF;INTERNET:[email-masked]
REV:20010214T163732Z
END:VCARD

------_=_NextPart_000_01C19F81.417D1AC0--

Content-return: allowed
Date: Thu, 17 Jan 2002 08:53:05 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'Denis Pinkas'" <[email-masked]>, "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Thursday, January 17, 2002 8:50 AM
> To: Ambarish Malpani
> Cc: 'Santosh Chokhani'; [email-masked] '
> 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.                                  
> [email-masked]
> > 339 N. Bernardo Ave.                          
http://www.valicert.com
> Mountain View, CA 94043
> 
> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2002 11:50 AM
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> Cc: [email-masked] '
> 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:[email-masked]]
> Sent: Wednesday, January 16, 2002 2:41 PM
> To: 'Denis Pinkas '; 'Santosh Chokhani '
> Cc: [email-masked] '
> 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: [email-masked]
> 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.
>

Date: Thu, 17 Jan 2002 17:49:51 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Ambarish Malpani <[email-masked]>
CC: "'Santosh Chokhani'" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: OCSP RFC and OCSP version 2 ID
Sender: [email-masked]

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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> -----Original Message-----
> From: Santosh Chokhani [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2002 11:50 AM
> To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
> Cc: [email-masked] '
> 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:[email-masked]]
> Sent: Wednesday, January 16, 2002 2:41 PM
> To: 'Denis Pinkas '; 'Santosh Chokhani '
> Cc: [email-masked] '
> 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: [email-masked]
> 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.
>

Date: Thu, 17 Jan 2002 17:29:38 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Petra Barzin <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Sender: [email-masked]

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

From: Carlisle Adams <[email-masked]>
To: Santosh Chokhani <[email-masked]>, "'Ambarish Malpani'" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Thu, 17 Jan 2002 11:18:13 -0500
Sender: [email-masked]

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

------_=_NextPart_001_01C19F72.902D4AA0
Content-Type: text/plain

Hi,

> ----------
> From: 	Ambarish Malpani[SMTP:[email-masked]]
> Sent: 	Wednesday, January 16, 2002 4:38 PM
> To: 	'Santosh Chokhani'
> Cc: 	[email-masked] '
> 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:[email-masked]]</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">[email-masked] '</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--

Date: Thu, 17 Jan 2002 17:15:43 +0100
From: Petra Barzin <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Sender: [email-masked]

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

Date: Thu, 17 Jan 2002 15:12:26 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: "Housley, Russ" <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Sender: [email-masked]

> 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

From: "Housley, Russ" <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Date: Thu, 17 Jan 2002 08:56:48 -0500
Sender: [email-masked]

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

Importance: Normal
Sensitivity: 
Subject: Re: Cautionary Period Straw Poll
To: [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Wed, 16 Jan 2002 16:29:07 -0500
Sender: [email-masked]

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

Date: Thu, 17 Jan 2002 11:05:14 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: "Housley, Russ" <[email-masked]>
CC: Petra Barzin <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Sender: [email-masked]

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

Date: Wed, 16 Jan 2002 21:04:41 -0500
From: Rich Salz <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: Hash values in OCSP
Sender: [email-masked]

> 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

Content-return: allowed
Date: Wed, 16 Jan 2002 17:44:15 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Hash values in OCSP
To: "[email-masked]'" <[email-masked]>, [email-masked]
Sender: [email-masked]

Hi Mars,
    Responses inline.

Regards,
Ambarish

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

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, January 16, 2002 3:47 PM
> To: [email-masked]
> 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

Date: Wed, 16 Jan 2002 19:01:04 -0500
From: Rich Salz <[email-masked]>
To: Peter Williams <[email-masked]>
CC: "'Denis Pinkas '" <[email-masked]>, "'Santosh Chokhani '" <[email-masked]>, "[email-masked] '" <[email-masked]>
Subject: Re: OCSP RFC and OCSP version 2 ID
Sender: [email-masked]

>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

Reply-To: <[email-masked]>
From: [email-masked] (Miguel Angel Rodriguez)
To: <[email-masked]>
Subject: Hash values in OCSP
Date: Wed, 16 Jan 2002 17:46:49 -0600
Importance: Normal
Sender: [email-masked]

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

Date: Wed, 16 Jan 2002 18:34:56 -0500
From: Rich Salz <[email-masked]>
CC: [email-masked]
Subject: Re: Cautionary Period Straw Poll
Sender: [email-masked]

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

From: "Al Arsenault" <[email-masked]>
To: <[email-masked]>
Subject: Re: Cautionary Period Straw Poll
Date: Wed, 16 Jan 2002 17:09:50 -0500
Sender: [email-masked]

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

From: Santosh Chokhani <[email-masked]>
To: Ambarish Malpani <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Wed, 16 Jan 2002 16:45:22 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Wednesday, January 16, 2002 4:38 PM
To: 'Santosh Chokhani'
Cc: [email-masked] '
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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 11:50 AM
To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
Cc: [email-masked] '
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:[email-masked]] 
Sent: Wednesday, January 16, 2002 2:41 PM 
To: 'Denis Pinkas '; 'Santosh Chokhani ' 
Cc: [email-masked] ' 
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: [email-masked] 
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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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; =
[email-masked]</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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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:[email-masked]">mailto:[email-masked]</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: [email-masked] ' </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: [email-masked] </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--

Content-return: allowed
Date: Wed, 16 Jan 2002 13:38:13 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'Santosh Chokhani'" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

-----Original Message-----
From: Santosh Chokhani [mailto:[email-masked]]
Sent: Wednesday, January 16, 2002 11:50 AM
To: Peter Williams; 'Denis Pinkas '; Santosh Chokhani
Cc: [email-masked] '
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:[email-masked]] 
Sent: Wednesday, January 16, 2002 2:41 PM 
To: 'Denis Pinkas '; 'Santosh Chokhani ' 
Cc: [email-masked] ' 
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: [email-masked] 
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. 

From: "Deacon, Alex" <[email-masked]>
To: [email-masked]
Subject: RE: Cautionary Period Straw Poll
Date: Wed, 16 Jan 2002 12:48:13 -0800
Sender: [email-masked]

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

Alex

Date: Wed, 16 Jan 2002 20:06:04 +0000
From: Stephen Farrell <[email-masked]>
Reply-To: [email-masked]
Organization: Baltimore Technologies Ltd.
To: [email-masked]
CC: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Cautionary Period Straw Poll
Sender: [email-masked]

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) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:[email-masked]
Ireland                             http://www.baltimore.com

From: Santosh Chokhani <[email-masked]>
To: Peter Williams <[email-masked]>, "'Denis Pinkas '" <[email-masked]>, Santosh Chokhani <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
Date: Wed, 16 Jan 2002 14:50:25 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Wednesday, January 16, 2002 2:41 PM
To: 'Denis Pinkas '; 'Santosh Chokhani '
Cc: [email-masked] '
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: [email-masked]
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:[email-masked]">mailto:[email-masked]</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: [email-masked] '</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: [email-masked]</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--

Content-return: allowed
Date: Wed, 16 Jan 2002 11:41:27 -0800
From: Peter Williams <[email-masked]>
Subject: RE: OCSP RFC and OCSP version 2 ID
To: "'Denis Pinkas '" <[email-masked]>, "'Santosh Chokhani '" <[email-masked]>
Cc: "[email-masked] '" <[email-masked]>
Sender: [email-masked]

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

From: "Yee, Peter" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Re: Cautionary Period Straw Poll
Date: Wed, 16 Jan 2002 11:06:26 -0800
Sender: [email-masked]

I feel that a cautionary period is NOT something for PKIX
DPV protocols.

					-Peter Yee

Reply-To: "Yuriy Dzambasow" <[email-masked]>
From: "Yuriy Dzambasow" <[email-masked]>
To: <[email-masked]>
Subject: Re: Cautionary Period Straw Poll
Date: Wed, 16 Jan 2002 10:13:04 -0500
Organization: Digital Signature Trust
Sender: [email-masked]

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

Date: Wed, 16 Jan 2002 09:56:18 -0800
To: [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Cautionary Period Straw Poll
Sender: [email-masked]

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

Date: Wed, 16 Jan 2002 11:47:38 -0500
From: Joe Morgan <[email-masked]>
To: [email-masked]
Subject: TSP interop update
Sender: [email-masked]

--------------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
[email-masked]
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>[email-masked]
<br>Software Engineer
<br>Phaos Technology Corp.
<br><A HREF="http://www.phaos.com/">http://www.phaos.com/</A>
<br>&nbsp;</html>

--------------9BE45895AB299668C9DCA245--

From: "Housley, Russ" <[email-masked]>
To: Petra Barzin <[email-masked]>, Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Date: Wed, 16 Jan 2002 09:39:48 -0500
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: Re: Cautionary Period
Date: Wed, 16 Jan 2002 09:24:53 -0500
Sender: [email-masked]

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

From: "Stefan Kraxberger" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, "Todd Glassey" <[email-masked]>, "Tho" <[email-masked]>, "Stephen Kent" <[email-masked]>, "Peter Gutmann" <[email-masked]>, "Peter Sylvester" <[email-masked]>, "Joe Morgan" <[email-masked]>, "Cristian Marinescu" <[email-masked]>, "Bianca Taglialagamba" <[email-masked]>, "A. Caccia" <[email-masked]>
Cc: "PKIX" <[email-masked]>
Subject: IAIK TSA
Date: Wed, 16 Jan 2002 15:32:22 +0100
Importance: Normal
Sender: [email-masked]

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"

----IAIK.SMIME.MAPPER.D1DB3296----

Date: Wed, 16 Jan 2002 12:36:58 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Petra Barzin <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Sender: [email-masked]

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

Date: Wed, 16 Jan 2002 11:51:27 +0100
From: Petra Barzin <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Sender: [email-masked]

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

Date: Wed, 16 Jan 2002 10:08:48 +0100
From: Alfonso De Gregorio <[email-masked]>
To: "Housley, Russ" <[email-masked]>
Cc: [email-masked]
Subject: Re: Cautionary Period Straw Poll
Reply-To: [email-masked]
Sender: [email-masked]

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

Date: Wed, 16 Jan 2002 10:06:19 +0100
From: Alfonso De Gregorio <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: Tom Gindin <[email-masked]>, "Housley, Russ" <[email-masked]>, [email-masked]
Subject: Re: Cautionary Period
Reply-To: [email-masked]
Sender: [email-masked]

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

From: "Sanjeev Shukla (SSD-DELRO-ESCR)" <[email-masked]>
To: [email-masked]
Subject: 
Date: Wed, 16 Jan 2002 14:03:16 +0530
Sender: [email-masked]

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

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Tuesday, January 15, 2002 10:07 AM
> To: [email-masked]
> 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 [email-masked]

Date: Wed, 16 Jan 2002 09:24:54 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Santosh Chokhani <[email-masked]>
CC: "Housley, Russ" <[email-masked]>, [email-masked]
Subject: Re: Cautionary Period Straw Poll
Sender: [email-masked]

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:[email-masked]]
> Sent: Tuesday, January 15, 2002 1:05 PM
> To: [email-masked]
> 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: [email-masked]
>            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

Date: Wed, 16 Jan 2002 09:04:42 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Santosh Chokhani <[email-masked]>
CC: [email-masked]
Subject: Re: OCSP RFC and OCSP version 2 ID
Sender: [email-masked]

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
> [email-masked]
> (703) 270-3520  (703) 848-0960 (fax)
> www.cygnacom.com
> 
> Entrust CygnaCom

Date: Wed, 16 Jan 2002 08:42:49 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: "Housley, Russ" <[email-masked]>
CC: [email-masked]
Subject: Re: Cautionary Period Straw Poll
Sender: [email-masked]

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

Content-return: allowed
Date: Tue, 15 Jan 2002 20:59:45 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Cautionary Period Straw Poll
To: [email-masked]
Sender: [email-masked]

I belive that DPV shouldn't include support for cautionary
period.

Ambarish

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

> -----Original Message-----
> From: Housley, Russ [mailto:[email-masked]]
> Sent: Tuesday, January 15, 2002 10:07 AM
> To: [email-masked]
> 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
> 

Date: Wed, 16 Jan 2002 15:28:12 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  OCSP RFC and OCSP version 2 ID
Sender: [email-masked]

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

From: Santosh Chokhani <[email-masked]>
To: [email-masked]
Subject: OCSP RFC and OCSP version 2 ID
Date: Tue, 15 Jan 2002 19:41:33 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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
[email-masked]
(703) 270-3520  (703) 848-0960 (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">[email-masked]</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">(703) 270-3520&nbsp; (703) 848-0960 =
(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--

Date: Tue, 15 Jan 2002 14:03:35 -0700
From: "Tolga Acar" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Subject: Re: Question about encoding of RSA public Exponent
Sender: [email-masked]

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

Date: Tue, 15 Jan 2002 13:07:04 -0500
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: Re: Cautionary Period Straw Poll
Sender: [email-masked]

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

Russ

From: Santosh Chokhani <[email-masked]>
To: "Housley, Russ" <[email-masked]>, [email-masked]
Subject: RE: Cautionary Period Straw Poll
Date: Tue, 15 Jan 2002 14:03:37 -0500
Sender: [email-masked]

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

------_=_NextPart_001_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:[email-masked]]
Sent: Tuesday, January 15, 2002 1:05 PM
To: [email-masked]
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: [email-masked]
           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:[email-masked]">mailto:[email-masked]=
</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Tuesday, January 15, 2002 1:05 PM</FONT>
<BR><FONT SIZE=3D2>To: [email-masked]</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: [email-masked]</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--

Date: Tue, 15 Jan 2002 13:05:22 -0500
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: Cautionary Period Straw Poll
Sender: [email-masked]

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

Date: Tue, 15 Jan 2002 18:35:32 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Tom Gindin <[email-masked]>
CC: "Housley, Russ" <[email-masked]>, Alfonso De Gregorio <[email-masked]>, [email-masked]
Subject: Re: Cautionary Period
Sender: [email-masked]

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 <[email-masked]>@mail.imc.org on 01/14/2002 04:20:06 AM
> 
> Sent by:    [email-masked]
> 
> To:    "Housley, Russ" <[email-masked]>
> cc:    Alfonso De Gregorio <[email-masked]>, [email-masked]
> 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

Date: Tue, 15 Jan 2002 11:41:43 -0500
From: James Comen <[email-masked]>
To: [email-masked]
Subject: Question about encoding of RSA public Exponent
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-roadmap-07.txt
Date: Tue, 15 Jan 2002 06:29:36 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure: 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Importance: Normal
Sensitivity: 
Subject: Re: Cautionary Period
To: Denis Pinkas <[email-masked]>
Cc: "Housley, Russ" <[email-masked]>, Alfonso De Gregorio <[email-masked]>, [email-masked]
From: "Tom Gindin" <[email-masked]>
Date: Mon, 14 Jan 2002 18:33:24 -0500
Sender: [email-masked]

      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 <[email-masked]>@mail.imc.org on 01/14/2002 04:20:06 AM

Sent by:    [email-masked]

To:    "Housley, Russ" <[email-masked]>
cc:    Alfonso De Gregorio <[email-masked]>, [email-masked]
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

Date: Mon, 14 Jan 2002 19:34:41 +0000
From: Dr S N Henson <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

"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: [email-masked] 
Senior crypto engineer, Gemplus: http://www.gemplus.com/
Core developer of the   OpenSSL project: http://www.openssl.org/
Business Email: [email-masked] PGP key: via homepage.

From: Peter Sylvester <[email-masked]>
Date: Mon, 14 Jan 2002 20:30:06 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Mon, 14 Jan 2002 18:25:27 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Petra Barzin <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ldap-v3-05.txt
Date: Mon, 14 Jan 2002 10:40:27 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Date: Mon, 14 Jan 2002 16:02:25 +0100
From: Petra Barzin <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Sender: [email-masked]

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

Date: Mon, 14 Jan 2002 14:14:40 +0000
From: Andreas Sterbenz <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

Peter Gutmann wrote:

> "Housley, Russ" <[email-masked]> 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.

From: Peter Sylvester <[email-masked]>
Date: Mon, 14 Jan 2002 14:33:27 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: Cautionary Period
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Mon, 14 Jan 2002 12:56:23 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Petra Barzin <[email-masked]>
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Sender: [email-masked]

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

Date: Mon, 14 Jan 2002 11:26:41 +0100
From: Petra Barzin <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Mon, 14 Jan 2002 11:22:44 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: draft-ietf-pkix-dpv-dpd-req-01.txt
Cc: [email-masked]
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Mon, 14 Jan 2002 10:49:00 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: TSP interop
Sender: [email-masked]

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

Date: Mon, 14 Jan 2002 10:20:06 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: "Housley, Russ" <[email-masked]>
CC: Alfonso De Gregorio <[email-masked]>, [email-masked]
Subject: Re: Cautionary Period
Sender: [email-masked]

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

Date: Mon, 14 Jan 2002 10:06:09 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Ambarish Malpani <[email-masked]>
CC: [email-masked]
Subject: Re: Cautionary Period
Sender: [email-masked]

> 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.                                  [email-masked]
> 339 N. Bernardo Ave.                          http://www.valicert.com
> Mountain View, CA 94043
> 
> > -----Original Message-----
> > From: Alfonso De Gregorio [mailto:[email-masked]]
> > Sent: Friday, January 11, 2002 9:06 AM
> > To: [email-masked]; Housley, Russ
> > Cc: [email-masked]
> > 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
> >

Date: Sun, 13 Jan 2002 14:36:47 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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.

Date: Sat, 12 Jan 2002 11:49:06 -0800
To: "Housley, Russ" <[email-masked]>, [email-masked]
From: Paul Hoffman / IMC <[email-masked]>
Subject: Re: Cautionary Period
Sender: [email-masked]

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

Date: Sat, 12 Jan 2002 13:09:24 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

Peter Gutmann wrote:
> 
> "Housley, Russ" <[email-masked]> 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.

Date: Sat, 12 Jan 2002 19:39:09 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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.

Date: Sat, 12 Jan 2002 18:13:17 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [email-masked]
Sender: [email-masked]

"Housley, Russ" <[email-masked]> 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.

Date: Sat, 12 Jan 2002 17:39:45 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [email-masked]
Sender: [email-masked]

Michael StrM-vder <[email-masked]> 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.

Date: Sat, 12 Jan 2002 17:20:15 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re:  TSP interop
Sender: [email-masked]

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

From: "Deacon, Alex" <[email-masked]>
To: "'Housley, Russ'" <[email-masked]>, Alfonso De Gregorio <[email-masked]>
Cc: [email-masked]
Subject: RE: Cautionary Period
Date: Fri, 11 Jan 2002 18:26:44 -0800
Sender: [email-masked]

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:[email-masked]]
> Sent: Friday, January 11, 2002 11:10 AM
> To: Alfonso De Gregorio
> Cc: [email-masked]
> 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.
> ==============================================================
> ==============
> ================
> 

From: "Michael Myers" <[email-masked]>
To: <[email-masked]>
Subject: RE: Cautionary Period
Date: Fri, 11 Jan 2002 14:30:33 -0800
Importance: Normal
Sender: [email-masked]

I agree with Russ.  Simpler is better.  Consider IKE vs. JFK.

Mike

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of 
> Housley, Russ
> Sent: Thursday, January 10, 2002 12:10 PM
> To: [email-masked]
> 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
> 

From: "Housley, Russ" <[email-masked]>
To: Peter Sylvester <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-pkix-dpv-dpd-req-01.txt
Date: Fri, 11 Jan 2002 14:45:24 -0500
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Peter Sylvester <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Date: Fri, 11 Jan 2002 14:41:15 -0500
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: Alfonso De Gregorio <[email-masked]>
Cc: [email-masked]
Subject: Re: Cautionary Period
Date: Fri, 11 Jan 2002 14:09:35 -0500
Sender: [email-masked]

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

Date: Fri, 11 Jan 2002 13:52:54 -0500
From: Joe Morgan <[email-masked]>
To: [email-masked]
Subject: TSP interop
Sender: [email-masked]

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

--------------ms0628B9E204A178C2FD023D44--

Content-return: allowed
Date: Fri, 11 Jan 2002 09:48:22 -0800
From: Ambarish Malpani <[email-masked]>
Subject: RE: Cautionary Period
To: [email-masked]
Sender: [email-masked]

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.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Alfonso De Gregorio [mailto:[email-masked]]
> Sent: Friday, January 11, 2002 9:06 AM
> To: [email-masked]; Housley, Russ
> Cc: [email-masked]
> 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
> 

Date: Fri, 11 Jan 2002 20:42:01 +0100
From: Alfonso De Gregorio <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: [email-masked]
Subject: Re: Cautionary Period
Reply-To: Alfonso De Gregorio <[email-masked]>
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Fri, 11 Jan 2002 18:27:17 +0100 (MET)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Fri, 11 Jan 2002 17:59:08 +0100 (MET)
To: [email-masked], [email-masked]
Subject: draft-ietf-pkix-dpv-dpd-req-01.txt
Sender: [email-masked]

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

Date: Fri, 11 Jan 2002 17:51:44 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Alfonso De Gregorio <[email-masked]>
CC: "Housley, Russ" <[email-masked]>, [email-masked]
Subject: Re: Cautionary Period
Sender: [email-masked]

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

Date: Fri, 11 Jan 2002 08:34:22 -0800
From: Eric Murray <[email-masked]>
To: Peter Gutmann <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Date: Fri, 11 Jan 2002 10:16:25 -0500
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Fri, 11 Jan 2002 17:27:35 +0100 (MET)
To: [email-masked]
Subject: Re: Cautionary Period ...
Sender: [email-masked]

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

Date: Fri, 11 Jan 2002 18:06:26 +0100
From: Alfonso De Gregorio <[email-masked]>
To: [email-masked], "Housley, Russ" <[email-masked]>
Cc: [email-masked]
Subject: Re: Cautionary Period
Reply-To: Alfonso De Gregorio <[email-masked]>
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-dpv-dpd-req-01.txt
Date: Fri, 11 Jan 2002 08:56:54 -0500
Sender: [email-masked]

--NextPart

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

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

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

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

--OtherAccess--

--NextPart--

Date: Thu, 10 Jan 2002 15:10:21 -0500
To: [email-masked]
From: "Housley, Russ" <[email-masked]>
Subject: Cautionary Period
Sender: [email-masked]

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

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: [email-masked] (Peter Gutmann)
Cc: [email-masked], [email-masked]
From: [email-masked]
Date: Fri, 11 Jan 2002 08:10:48 -0500
Sender: [email-masked]

>. 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: 418 521 2100 ext 307
courriel / email: [email-masked]

                    [email-masked]                                                                                  
                    d.ac.nz (Peter            Pour :  [email-masked], [email-masked]                       
                    Gutmann)                  cc :    [email-masked]                                         
                    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=
>[email-masked] 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.

Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
From: Tomas Gustavsson <[email-masked]>
To: [email-masked]
Date: Sat, 11 Jan 2002 13:30:36 +0100
Sender: [email-masked]

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

Date: Fri, 11 Jan 2002 09:51:30 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

Peter Gutmann wrote:
> 
> Tomas Gustavsson <[email-masked]> 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.

Date: Fri, 11 Jan 2002 18:33:24 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [email-masked]
Sender: [email-masked]

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.

Date: Fri, 11 Jan 2002 18:20:05 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [email-masked]
Sender: [email-masked]

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

Date: Fri, 11 Jan 2002 16:38:02 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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

Date: Thu, 10 Jan 2002 19:47:16 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: Andreas Sterbenz <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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.

Content-Class: urn:content-classes:message
Subject: RE: Name constraints 
Date: Thu, 10 Jan 2002 10:15:40 -0800
From: "Trevor Freeman" <[email-masked]>
To: <[email-masked]>, "Housley, Russ" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Thursday, December 20, 2001 9:36 AM
To: Housley, Russ
Cc: [email-masked]
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.

Date: Thu, 10 Jan 2002 15:57:20 +0000
From: Andreas Sterbenz <[email-masked]>
To: [email-masked]
CC: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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

Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
From: Tomas Gustavsson <[email-masked]>
To: [email-masked]
Date: Fri, 10 Jan 2002 13:56:19 +0100
Sender: [email-masked]

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ipki-new-rfc2527-01.txt
Date: Wed, 09 Jan 2002 17:40:13 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Date: Wed, 09 Jan 2002 16:58:25 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

Peter Gutmann wrote:
> 
> Michael Ströder <[email-masked]> 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.

Date: Wed, 09 Jan 2002 17:05:10 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: Peter Gutmann <[email-masked]>
Cc: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

Peter Gutmann wrote:
> 
> Michael StrM-vder <[email-masked]> 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.

Date: Wed, 09 Jan 2002 07:59:18 -0500
From: Rich Salz <[email-masked]>
To: Peter Gutmann <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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

Date: Wed, 09 Jan 2002 13:41:51 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: "[email-masked]" <[email-masked]>
Subject: Re: URL schemes in draft-ietf-pkix-new-part1-11
Sender: [email-masked]

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.

Date: Wed, 09 Jan 2002 12:47:48 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: "[email-masked]" <[email-masked]>
Subject: URL schemes in draft-ietf-pkix-new-part1-11
Sender: [email-masked]

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.

From: Jason Yeung <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard
Date: Wed, 9 Jan 2002 15:04:40 +0800 
Sender: [email-masked]

I have tried it successfully, port 318 thru tcp socket.

Rgds,
Jason

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, January 09, 2002 11:55 AM
To: [email-masked]; [email-masked]
Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard

Scott Mustard <[email-masked]> writes:

>Datum's StampServer is available for test at 64.241.183.87,

Which port, and which protocol?

Peter.

Date: Wed, 9 Jan 2002 18:08:12 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

Michael StrM-vder <[email-masked]> 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.

Date: Wed, 9 Jan 2002 17:59:39 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

Michael StrM-vder <[email-masked]> 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.

Date: Wed, 9 Jan 2002 17:20:29 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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

Date: Wed, 9 Jan 2002 16:55:27 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard
Sender: [email-masked]

Scott Mustard <[email-masked]> writes:

>Datum's StampServer is available for test at 64.241.183.87,

Which port, and which protocol?

Peter.

From: "Piers Chivers" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: RE: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Date: Tue, 8 Jan 2002 21:41:44 -0000
Sender: [email-masked]

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

------_=_NextPart_001_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
+44 (0)1270 507800
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:[email-masked]">
<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--

From: Scott Mustard <[email-masked]>
To: "PKIX (E-mail)" <[email-masked]>
Subject: RE: Progression of RFC 3161 (TSP) to Draft Standard
Date: Tue, 8 Jan 2002 14:46:58 -0500 
Sender: [email-masked]

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

Date: Tue, 08 Jan 2002 18:52:51 +0000
From: David Chadwick <[email-masked]>
Organization: University of Salford
To: PKIX <[email-masked]>
Subject: SLides for SLC
Sender: [email-masked]

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: +44 161 295 5351  Fax +44 161 745 8169
Mobile: +44 77 96 44 7184
Email: [email-masked]
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:+44 77 96 44 7184
tel;fax:+44 1484 532930
tel;home:+44 1484 352238
tel;work:+44 161 295 5351
x-mozilla-html:FALSE
url:http://www.salford.ac.uk/its024/chadwick.htm
org:University of Salford;IS Institute
version:2.1
email;internet:[email-masked]
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--

Date: Tue, 08 Jan 2002 12:43:06 -0500
From: "David P. Kemp" <[email-masked]>
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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.

Date: Tue, 08 Jan 2002 16:19:49 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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.

Date: Tue, 08 Jan 2002 13:42:56 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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.

Date: Tue, 08 Jan 2002 13:19:29 +0100
From: Michael =?iso-8859-1?Q?Str=F6der?= <[email-masked]>
Reply-To: [email-masked]
Organization: stroeder.com
To: [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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

Date: Tue, 8 Jan 2002 20:42:55 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Cc: [email-masked]
Sender: [email-masked]

Russel F Weiser <[email-masked]> 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.

Date: Tue, 8 Jan 2002 18:04:49 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re:  tsp interop test vector (proposal)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Mon, 07 Jan 2002 12:16:33 -0700
From: Russel F Weiser <[email-masked]>
Reply-To: [email-masked]
Organization: Digital Signature Trust Co.
To: [email-masked]
CC: Peter Gutmann <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Sender: [email-masked]

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

--------------ms98A47B4AC9B8F65D9B370C80--

Date: Mon, 7 Jan 2002 11:42:36 -0500 (EST)
From: [email-masked]
To: [email-masked]
Subject: ANNOUNCE: NDSS'02 Early Registration Deadlines Approaching
Sender: [email-masked]

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 +1-703-326-9880 ext 104 or send e-mail to 
[email-masked]. Interested in sponsoring a give-away or meal? Contact Martin
Kupres at +1 41 22 807 1444 or send e-mail to [email-masked].

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-certstore-http-01.txt
Date: Mon, 07 Jan 2002 09:08:07 -0500
Sender: [email-masked]

--NextPart

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

	Title		: Internet X.509 Public Key Infrastructure 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:
	[email-masked].
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="[email-masked]"

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

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

--OtherAccess--

--NextPart--

Date: Mon, 07 Jan 2002 14:52:21 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: Petra Barzin <[email-masked]>
CC: [email-masked]
Subject: Re: [Fwd: draft-ietf-pkix-dpv-dpd-req-00.txt &  draft-ietf-pkix-dsv-req-00.txt]
Sender: [email-masked]

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 <[email-masked]>
> A: Denis Pinkas <[email-masked]>
> Copies à: pkix <[email-masked]>
> Références: <[email-masked]> <[email-masked]>
> 
> 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

Date: Mon, 7 Jan 2002 14:12:48 +0100
From: tho <[email-masked]>
To: Denis Pinkas <[email-masked]>, Peter Sylvester <[email-masked]>, Peter Gutmann <[email-masked]>, Taglialagamba Bianca <[email-masked]>, Andrea Caccia <[email-masked]>, Antonio Lioy <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: tsp interop test vector (proposal)
Sender: [email-masked]

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

Date: Mon, 07 Jan 2002 11:09:12 +0100
From: Petra Barzin <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [Fwd: draft-ietf-pkix-dpv-dpd-req-00.txt &  draft-ietf-pkix-dsv-req-00.txt]
Sender: [email-masked]

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

Date: Sun, 09 Dec 2001 14:54:28 +0100
From: Petra Barzin <[email-masked]>
To: Denis Pinkas <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-dpv-dpd-req-00.txt & draft-ietf-pkix-dsv-req-00.txt
Sender: [email-masked]

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

Date: Fri, 04 Jan 2002 21:45:53 +0100
From: Antonio Lioy <[email-masked]>
Organization: Politecnico di Torino
To: Denis Pinkas <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Sender: [email-masked]

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 <[email-masked]>
> 
> Please take a look to http://security.polito.it/test/tsp/
> 
> Address: tsp.test.polito.it  port:318.  Pure TCP.
> Testing purposes only.
> 
> Contact : [email-masked]

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 [email-masked] is not yet active (it
  will be in a week or so); for the moment, please address everything
  related to our TSA to {lioy,[email-masked]

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

--------------ms8C35EFC32CA2BD6B2CAAC7AD--

Date: Sat, 05 Jan 2002 11:19:43 +0700
To: "Sanjaya" <[email-masked]>
From: Teddy A Purwadi <[email-masked]>
Subject: Re: Attribute Certificate for IP address allocation object
Cc: <[email-masked]>
Sender: [email-masked]

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

Date: Sat, 5 Jan 2002 05:06:10 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re:  Progression of RFC 3161 (TSP) to Draft Standard
Cc: [email-masked]
Sender: [email-masked]

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

From: Peter Sylvester <[email-masked]>
Date: Fri, 4 Jan 2002 15:51:34 +0100 (MET)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re:  Progression of RFC 3161 (TSP) to Draft Standard
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 03 Jan 2002 17:06:30 -0500
To: [email-masked], [email-masked]
From: Michael Chernick <[email-masked]>
Subject: Updated Draft of NIST S/MIME V3 Client Profile Now Available
Cc: Michael Chernick <[email-masked]>, Tim Polk <[email-masked]>
Sender: [email-masked]

--=====================_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
+1-301-975-3610   [email-masked]
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>
+1-301-975-3610&nbsp;&nbsp; [email-masked]<br>
Computer Security Division <br>
National Institute of Standards and Technology (NIST)<br>
----------------------------------------------------------------------------------<br>
<br>
</html>

--=====================_17140984==_.ALT--

From: "todd glassey" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Date: Wed, 2 Jan 2002 18:58:59 -0800
Sender: [email-masked]

yes it does, and for what should be obvious reasons

Todd

----- Original Message -----
From: "Peter Gutmann" <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, January 02, 2002 6:14 PM
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard

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

Date: Thu, 3 Jan 2002 15:14:53 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Cc: [email-masked]
Sender: [email-masked]

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

Date: Thu, 3 Jan 2002 13:58:01 +1300 (NZDT)
From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re:  Progression of RFC 3161 (TSP) to Draft Standard
Cc: [email-masked]
Sender: [email-masked]

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

From: "Sanjaya" <[email-masked]>
To: <[email-masked]>
Subject: Re: Attribute Certificate for IP address allocation object
Date: Thu, 3 Jan 2002 10:14:21 +1000
Sender: [email-masked]

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

Date: Wed, 2 Jan 2002 18:58:36 -0500
To: <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

Alfonso,

>----- Original Message -----
>From: "Alfonso De Gregorio" <[email-masked]>
>To: "todd glassey" <[email-masked]>
>Cc: "pkix" <[email-masked]>
>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

From: "todd glassey" <[email-masked]>
To: <[email-masked]>
Cc: "pkix" <[email-masked]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Date: Wed, 2 Jan 2002 14:07:36 -0800
Sender: [email-masked]

----- Original Message -----
From: "Alfonso De Gregorio" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: "pkix" <[email-masked]>
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

Date: Wed, 2 Jan 2002 23:05:00 +0100
From: Alfonso De Gregorio <[email-masked]>
To: todd glassey <[email-masked]>
Cc: pkix <[email-masked]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Reply-To: [email-masked]
Sender: [email-masked]

> 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

Date: Wed, 2 Jan 2002 12:45:07 -0500
To: "todd glassey" <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Cc: "Denis Pinkas" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "pkix" <[email-masked]>, [email-masked]
Sender: [email-masked]

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

From: "todd glassey" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, "pkix" <[email-masked]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Date: Wed, 2 Jan 2002 08:42:57 -0800
Sender: [email-masked]

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" <[email-masked]>
To: "todd glassey" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>; "pkix" <[email-masked]>
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" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Cc: "pkix" <[email-masked]>
> 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 <[email-masked]> or <[email-masked]>
>
> 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: [email-masked] (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 <[email-masked]>
>
> 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 <[email-masked]>
>
> Please take a look to http://security.polito.it/test/tsp/
>
> Address: tsp.test.polito.it  port:318.  Pure TCP.
> Testing purposes only.
>
> Contact : [email-masked]
>
>                     ________________________
>
> EdelWeb Experimental
> Time Stamping Service
> Date: Mon, 03 Dec 2001
>
> From: Peter Sylvester <[email-masked]>
>
> 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 <[email-masked]>
> 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 <[email-masked]>
>
>                     ________________________
>
> Graz University of Technology (IAIK -Austria)
> Contact person: [email-masked]
>
>                     ________________________
>
> I encourage "contact persons" to contact themselves. :-)
>
> Denis.
> TSP lead editor.

Date: Wed, 02 Jan 2002 17:13:52 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: todd glassey <[email-masked]>
CC: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], pkix <[email-masked]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Sender: [email-masked]

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" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>;
> <[email-masked]>; <[email-masked]>
> Cc: "pkix" <[email-masked]>
> 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 <[email-masked]> or <[email-masked]>
> 
> 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: [email-masked] (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 <[email-masked]>
> 
> 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 <[email-masked]>
> 
> Please take a look to http://security.polito.it/test/tsp/
> 
> Address: tsp.test.polito.it  port:318.  Pure TCP.
> Testing purposes only.
> 
> Contact : [email-masked]
> 
>                     ________________________
> 
> EdelWeb Experimental
> Time Stamping Service
> Date: Mon, 03 Dec 2001
> 
> From: Peter Sylvester <[email-masked]>
> 
> 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 <[email-masked]>
> 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 <[email-masked]>
> 
>                     ________________________
> 
> Graz University of Technology (IAIK -Austria)
> Contact person: [email-masked]
> 
>                     ________________________
> 
> I encourage "contact persons" to contact themselves. :-)
> 
> Denis.
> TSP lead editor.

From: "todd glassey" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: "pkix" <[email-masked]>
Subject: Re: Progression of RFC 3161 (TSP) to Draft Standard
Date: Wed, 2 Jan 2002 08:03:59 -0800
Sender: [email-masked]

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

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

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

Please take a look to http://security.polito.it/test/tsp/

Address: tsp.test.polito.it  port:318.  Pure TCP.
Testing purposes only.

Contact : [email-masked]

                    ________________________

EdelWeb Experimental
Time Stamping Service
Date: Mon, 03 Dec 2001

From: Peter Sylvester <[email-masked]>

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

                    ________________________

Graz University of Technology (IAIK -Austria)
Contact person: [email-masked]

                    ________________________

I encourage "contact persons" to contact themselves. :-)

Denis.
TSP lead editor.

Date: Wed, 2 Jan 2002 09:35:31 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: RE: Attribute Certificate for IP address allocation object
Cc: [email-masked]
Sender: [email-masked]

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

From: "Housley, Russ" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: RE: Attribute Certificate for IP address allocation object
Date: Wed, 2 Jan 2002 08:26:31 -0500 
Sender: [email-masked]

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:[email-masked]]
> > Sent: Selasa, Januari 01, 2002 00:01
> > To: Sanjaya
> > Cc: [email-masked]
> > 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.
============================================================================
================

Date: Wed, 02 Jan 2002 12:56:12 +0100
From: Denis Pinkas <[email-masked]>
Organization: Integris. A Bull Company
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
CC: pkix <[email-masked]>
Subject: Progression of RFC 3161 (TSP) to Draft Standard
Sender: [email-masked]

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

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

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

Please take a look to http://security.polito.it/test/tsp/

Address: tsp.test.polito.it  port:318.  Pure TCP. 
Testing purposes only.

Contact : [email-masked]

                    ________________________

EdelWeb Experimental 
Time Stamping Service
Date: Mon, 03 Dec 2001

From: Peter Sylvester <[email-masked]>

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

                    ________________________

Graz University of Technology (IAIK -Austria)
Contact person: [email-masked]

                    ________________________

I encourage "contact persons" to contact themselves. :-)

Denis. 
TSP lead editor.

Reply-To: <[email-masked]>
From: "Sanjaya" <[email-masked]>
To: <[email-masked]>
Subject: RE: Attribute Certificate for IP address allocation object
Date: Wed, 2 Jan 2002 10:18:48 +1000
Importance: Normal
Sender: [email-masked]

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:[email-masked]]
> Sent: Selasa, Januari 01, 2002 00:01
> To: Sanjaya
> Cc: [email-masked]
> 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)
>