Subject: RE: OCSP identifiers

From: Simon Tardell <[email-masked]>
Date: Thu, 16 Nov 2000 13:54:07 +0100

> > I always thought {Issuer-DN, Subject-DN, Serial#} was 
> relatively short and to
> > the point and unique.
> 
> Not always unique. :-(
> 
> ... in case of an issuing key compromise.

The point made in the RFC (IIRC) is that you cannot gurantee uniqueness of
the issuer DN, so that the responder wouldn't know if the client was really
asking about the same issuer, however the issuer key will be (with a
reasonable degree of certitude) unique. I'm not sure I agree to the validity
of that argument though, the client has to make sure he trusts the correct
issuers in some other way anyway, and the point becomes moot.

I don't see how any of this protects against issuer key compromise (possibly
against issuer of issuer, but...).

Simon.

Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
[email-masked], http://www.smarttrust.com

---

From: Ambarish Malpani <[email-masked]>
Date: Thu, 16 Nov 2000 07:51:32 -0800

Hi Rich,
    Our definition for CertID when from:

(Serial#, IssuerPKHash)
[which was my original suggestion]

to

(Serial#, IssuerPKHash, IssuerDN)
[because of a comment that Steve Kent had made saying that
responders might not index a CA's data based on its PKHash]

to
(Serial#, IssuerPKHash, IssuerDNHash)
[because Mike Myers thought that the IssuerDN was too long to have
in the querry - Mike, please correct me if I have the reason wrong]

The question before us now is: Even though we might not be delighted
with the current definition of CertID, should we change it or continue
on with the current definition.

My argument in the past for inclusion of either the Issuer's public key
or the hash of the Issuer's public key is that I don't believe that we
have any way of guaranteeing uniqueness of DNs. If a OCSP client doesn't
send the whole certificate to the OCSP Responder, the responder has no
way of guaranteeing that the Issuer that the client thinks issued the
certificate is the same one as the one that the responder is responding
for.
Having the client send over the issuer's public key in some way helps us
avoid even the possibility of this problem and if we assume that the client
is checking the signature on the cert, then having it send over the hash
of the issuer's public key isn't placing too stiff a requirement on it.

Hope this helps clarify both the history and the reasoning behind what
happenned with CertIDs.

Again, the question is, should we continue with the current definition or
change it and if so, how.

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: Rich Salz [mailto:[email-masked]]
> Sent: Wednesday, November 15, 2000 5:45 PM
> To: [email-masked]
> Subject: OCSP identifiers
> 
> 
> Be careful of sending the entire cert in a status or validity 
> query.  At a
> previous employer it became pretty clear (with a patent 
> attorney) that this
> violated a patent held by Micali. No, I don't remember the 
> number. But it was
> a good thing that the OCSP syntax changed from the -02 draft. :)
> 
> As for what identifiers to use, I always thought that 
> requiring the issuer's
> cert was onerous, and that sending the hash "for space 
> reasons" was a bogus
> argument. I further agree with Gutmann that it required weird 
> indices on the
> part of many implementors.
> 
> 	/r$

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 17 Nov 2000 06:44:42 (NZDT)

>in the querry - Mike, please correct me if I have the reason wrong]

I would really like to see this fixed, as I pointed out in my earlier message
you can do something with the issuer name and serial number (which as
issuerAndSerialNumber has been found perfectly adequate in the S/MIME world for
years), you can work with hash( iAndS ) (since it's trivial to convert iAndS
into the hashed form), but you can't do anything when one component is in a
hashed form and the other one isn't (well, unless your implementation happens
to use this mixture as a key).  At the moment it's not possible for me to
create an OCSP responder because it doesn't provide any useful/standard way to
identify a cert.

Peter.

---

From: Michael Myers <[email-masked]>
Date: Thu, 16 Nov 2000 14:22:15 -0800

Ambarish,

> On Thursday, November 16, 2000 7:52 you wrote:
>

Basically, this is correct.

Abuse of DN content flexibility (I beleive Peter Gutmann produced an
existence proof on this point) may preclude the cachability of HTTP-based
OCSP responses for environments that wish to comply to Section 2.5 "Response
Pre-production" of RFC2560 due to the object size triggers of well-known
HTTP proxy servers.

I'm eager to hear from the HTTP proxy architects out there if this concern
remains well-founded.  I'm assuming not.

Mike

---

From: Michael Myers <[email-masked]>
Date: Thu, 16 Nov 2000 14:22:15 -0800

Peter,

Your concern is precisely why the OCSPv2 draft proposes what it does.  Have
you any thoughts on the details of the relevant ASN.1?

Mike

> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, November 16, 2000 10:45 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: OCSP identifiers
> 
>

---

From: Michael Myers <[email-masked]>
Date: Fri, 17 Nov 2000 11:58:59 -0800

Margus,

We agree, especially regarding the observation that OCSP isn't and should't
be tied to CRLs.  

I don't see any problem against including cert hash among OCSP's certificate
identification options.  Unless somebody raises a significant objection,
I'll put it in.

Mike

> From: Margus Freudenthal [mailto:[email-masked]]
> Sent: Friday, November 17, 2000 12:52 AM
> To: [email-masked]
> Subject: Re: OCSP identifiers
> 
> 
> Peter Gutmann wrote:
> > 
> > Hmm, it's going to need some profiling in order to reduce 
> the number of choices
> > to a workable subset, I like the issuerSerial and pKCert options 
> 
> I would support including the certificate hash option as well.  It
> provides uniqueness despite the various key compromises.  It is quite
> short as well.  I know, this doesn't allow CRL-based OCSP service, but
> as the name implies OCSP should provide online service instead of CRL
> caching.
> 
> 
> -- 
> Margus Freudenthal                              [email-masked]
> Cybernetica                                     http://www.cyber.ee/
>

---

From: Ambarish Malpani <[email-masked]>
Date: Fri, 17 Nov 2000 13:51:51 -0800

Mike, as you might expect, I would like to raise "serious
objections" to this.

a. I don't think it is helping anybody be putting in a whole set
of methods of identifying certificates - you aren't making the
client application's life any easier and are making the server's
job harder. It will also result in more interop problems.

b. It is very, very valuable to be able to provide OCSP responses
off CRLs - they are a well defined format and enable us to work
with a bunch of different CAs

c. You want to be able to have an OCSP responder be very highly
available. We have been able to provide very highly available and
distributed solutions to people trying to do PKI deployments
based on OCSP in part because the data that had to be replicated
was very simple.

I am not sure whether this would encourage you or discourage you
from adding the certificate hash as an option, but I just thought
you might like to know.

Ambarish

> From: Michael Myers [mailto:[email-masked]]
> Sent: Friday, November 17, 2000 11:59 AM
> To: Margus Freudenthal; [email-masked]

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 18 Nov 2000 16:31:50 (NZDT)

Rich Salz <[email-masked]> writes:

>In a previous message I said that during work at a previous employer we
>determined that this violates a patent by Micali.  I held my nose and did some
>searches this evening, and I believe I found it.  Claims 37ff of US Patent
>5,717,757 filed Nov 96 and issued Feb 98:
>
>        37. A method for providing authenticated information about certificates,
>        comprising the steps of:
>        (a) receiving a request for information about a certificate including
>            a proof that the certificate is issued;
>        (b) verifying that the proof is valid; and
>        (c) in response to the proof being valid, providing the requested
>            information.
>        38. A method according to claim 37, wherein the proof includes providing
>        an entire CA-authenticated certificate.

Oops, that had slipped my mind.  In any case it's trivial to avoid, note the
wording:

>        an entire CA-authenticated certificate.

"The pKCert shall consist of the certificate without the leading SEQUENCE and
 length encoding"

Then it's not the entire CA-authenticated certificate any more, but it's
trivial to reconstruct it from that.  The same thing is already being done for
public keys (you strip off the outer wrappers before hashing them) so it
shouldn't be a big deal.

Peter.

---

From: Simon Tardell <[email-masked]>
Date: Mon, 20 Nov 2000 15:39:24 +0100

> Hello.

Hi.

> Simon Tardell wrote:
> > 
> > CertHash is proposed to solve the problem of compromise of  the issuer
key.
> > It turns the question from a revocation query to an issuance query. It
also
> > turns the responder from being someone who answers on delegation into
> > someone who is an authority on its own (i.e. it can, in  effect,
invalidate
> > the issuer). 
> 
> Well, OCSP response is currently signed by OCSP responder 
> (which may or may not be the CA).  If you do not trust the OCSP responder,
then even
> CRL-based OCSP service can't give you satisfactory answers 
> because they do not contain CA's signature.  If you want assurance given
by CA, you
> should download the CRL and ceck it (and steer clear of the OCSP
> protocol).

Not at all. My trust in the OCSP responder derives from my trust in the CA.
The OCSP responses must (and that's a MUST...) either be signed by the
issuer, or someone authorized (by the issuer) to do so. Other models can be
imagined, such as the one you advocate, but they are very different model.
I'm not against such models, but they should not break the primary mode of
the protocol.

If the issuer revokes the authorization of the responder for whatever
reason, I expect it to revoke the responder keys. That's assurance enough
for most purposes. How the client learn about this is a deployment issue.

Simon.

---

From: "Bland, Graham" <[email-masked]>
Date: Mon, 20 Nov 2000 14:59:08 -0000

Simon,

There is no requirement that I can see for the OCSP responder to be
authorised or trusted by the issuer, I quote

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

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

The second case here implies trust only between the requestor and the
responder.

Also in section 4.2.2.2 local configuration of OCSP signing authority by the
requestor is allowed bypassing any CA authority or involvement.

Graham Bland

-----Original Message-----
From: Simon Tardell [mailto:[email-masked]]
Sent: 20 November 2000 14:39
To: 'Margus Freudenthal'; Simon Tardell; [email-masked]
Cc: 'Michael Myers'
Subject: RE: OCSP identifiers

Hi.

key.
also
invalidate
then even
by CA, you

Simon.

Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
[email-masked], http://www.smarttrust.com
_______________________________________________________________________

This message is confidential and is intended for the addressee only;
unless clearly stated that this disclaimer should not apply, this 
e-mail is not intended to create legally binding commitments on 
behalf of any company in the British Interactive Broadcasting 
Holdings Limited group,  nor do its contents reflect the corporate 
views or policies of any such company. Any unauthorised disclosure, 
use or dissemination, either whole or partial, is prohibited. If you 
are not the intended recipient of the message, please notify the
sender immediately.
_______________________________________________________________________

---

From: Simon Tardell <[email-masked]>
Date: Mon, 20 Nov 2000 16:16:08 +0100

> There is no requirement 

Retracted. I don't know why I wrote that. It's Monday, I suppose.

The point that I'd like to make though, is that there certainly is no
trouble deriving trust in the responder from trust of the issuer (that is,
the issuer can invalidate the responder if it feels like).

Simon.

---

From: "Bland, Graham" <[email-masked]>
Date: Mon, 20 Nov 2000 16:08:48 -0000

Simon,

Sorry but there are still some practical caveats to be applied here.

If the OCSP responder is independent of the CA in question then trust is
entirely between the requestor and the responder, in this case the issuer
has no knowledge of nor involvement in the trust and cannot invalidate the
responder in any way.

In the second case where the responder is a logical part of the CA in
question, the OCSP response is signed with the certificate issuing key.
The only way the CA can invalidate the responder is by revoking its own
issuing key which effectively requires a reconfiguration of the requestor as
the CA key would have to be implicitly trusted.  Practically in this case
the CA can simply shut down the responder.  I cannot see a case where the CA
would allow the use of its key and not have this level of control.

The third case is where the responder is a CA designated responder with a
specially marked certificate directly issued by the CA.
In this case the logistics of the process do not make sense.
Assuming the responder is being used to either:  
1. provide a more timely response than CRLs 
2. avoid having to manage the retrieval of CRLs

In order to validate the OCSP response I must now either retrieve a CRL or
Authority Information access (OCSP?) in order to validate the response.  If
the CRL is required then apart from a possible size reduction in the CRL I
have to implement all the logic required to have verified the certificates
status myself reducing the value of 2. Using a CRL here may not satisfy the
timeliness required by 1.  If Authority Information Access is specified then
I have just entered a loop (assuming this specifies an OCSP responder which
I then have to verify) 

So practically it is very difficult for a CA to invalidate an OCSP responder
apart from by shutting it down, I would guess that specifically trusted
responders or directly CA owned responders (which are effectively implicitly
trusted) are the only practical methods that can be used. (unless anybody
else has any other methods)

Graham Bland

-----Original Message-----
From: Simon Tardell [mailto:[email-masked]]
Sent: 20 November 2000 15:16
To: 'Bland, Graham'; Simon Tardell; [email-masked]
Subject: RE: OCSP identifiers

Simon.

---

From: Simon Tardell <[email-masked]>
Date: Mon, 20 Nov 2000 17:52:02 +0100

> Sorry but there are still some practical caveats to be applied here.
[...]

> issuing key which effectively requires a reconfiguration of 
> the requestor as the CA key would have to be implicitly trusted.
Practically 
> in this case the CA can simply shut down the responder.  I cannot see a 
> case where the CA would allow the use of its key and not have this level
of control.

This obviously works, but there are a number of issues concerning
availability and scalability that would be more difficult to address in this
scenario, so I don't see it as a high-end scenario.

> have to implement all the logic required to have verified the 
> certificates status myself reducing the value of 2. Using a CRL here may 
> not satisfy the timeliness required by 1.  If Authority Information Access
is 
> specified then I have just entered a loop (assuming this specifies an OCSP

> responder which I then have to verify) 
> 
> So practically it is very difficult for a CA to invalidate an 
> OCSP responder apart from by shutting it down, I would guess that 
> specifically trusted responders or directly CA owned responders (which are

> effectively implicitly trusted) are the only practical methods that can be
used. 
> (unless anybody else has any other methods)

"Timeliness" is of course relative to the risk you want to expose yourself
to. But there definitely is a practical method that does not involve CRLs or
OCSP "chains". If the CA that designates the responder gives the responder a
short-lived certificate, and renews that certificate periodically (within
the lifespan), revocation becomes tantamount to stopping reissuance. The
shorter the lifespan, the less the window for a perpetrator. And how short
can the window be anyway, for other reasons? I mean, there are people
involved.

But going back to the original question: Who is it that should be doing the
revoking here? Is it the responder that should be revoking the CA (the
certHash model), or is it the CA that should be revoking the responder? 

Simon.

---

From: Ambarish Malpani <[email-masked]>
Date: Mon, 20 Nov 2000 08:53:24 -0800

Hi Graham,
    Not quite true. There are a bunch of cases, where a root CA
certifies subCAs OCSP responders directly, whose status needs to
be checked by looking up the cert with the root's OCSP responder
(in practice, this second lookup gets optimized out).

Anyway, there are real life models, where a responder is trusted
because of a cert issued by a CA, but not necessarily trusted for
that CA. So it is possible to want to revoke an OCSP responder's
certificate.

Regarding CRLs - these are (as Simon said) a great way of getting
a snapshot of the statuses a CA has assigned. Also, by having CAs
produce and publish new CRLs as soon as there is a revocation event,
this becomes a great way of passing revocation data from a CA to
a responder.

CRLs are not scalable where they need to be distributed to a large number
of clients [read thousands/hundreds of thousands]. They are a perfectly
good way of distributing revocation data to a single client (the
responder), which can then take on the responsibility of:
a. Replicating to other responders
b. Providing OCSP responses to a large number of clients.

Also, there are real deployments where a person normally wants to revoke at
the CA, but desires to, as an emergency action, suspend directly at the
responder - so the responder uses both the CA's data (its CRL) and its own
local database to see what the status of a certificate is.

Hopefully, this helps explain the benefits of using CRLs and OCSP together.

Regards,
Ambarish

> From: Bland, Graham [mailto:[email-masked]]
> Sent: Monday, November 20, 2000 8:09 AM
> To: 'Simon Tardell'; [email-masked]

Agreed.

> the requestor as

Agreed.

> certificates
> OCSP responder

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 20 Nov 2000 11:57:55 -0500

Ambarish:

I do not mean to get in the middle of the debate.  The issues in
architecting a solution for revocation information notification to relying
party are very complex and require consideration of topics such as:

v The communication model, i.e., which class of users are communicating with
which class of users.  For example, if a user communicates with several
users who are subscriber to the same CA, a single CRL from the CA will
provide lot of relevant information and the user.  On the other hand, if a
user is communicating with several users, all belonging to different CA,
each CRL is offering only information relevant to one user.
v The directory architecture in terms of where they are located and what
portions of the directory information is replicated and/or shadowed.
v The communication band-width available.
v The bind time to access the repository
v Size of the revocation response from the repository, e.g. CRL size
v Processing load on the repository, specially for digital signature
generation on the revocation information
v Processing load on the user workstation, specially for digital signature
verification on the revocation information

OCSP suffers from the following drawbacks:

v Since the revocation information is produced at the server, the
communication channel between the relying party and the server must be
secured, most likely by using digital signatures
v Signed operations will limit server scaleability since digital signature
generation is computationally intensive
v Since the revocation information is produced at the server, the scheme
requires a trusted server as opposed to an untrusted repository
v Revocation of server public key requires a method for checking server
public key status.  This method is likely to be using the server public key
as an additional trust anchor or relying on a CRL mechanism.
v There needs to be  non-suppressable mechanism for the CA to provide
revocation information to the trusted server 
v There are no standards in the area of CA to provide non-suppressable
mechanism(s) for the revocation information to the trusted server

From my experience, the most scaleable and versatile revocation notification
means can be achieved by using a combination of the following:

v Use of CRL
v Replication of CA directory entry for fast access to CRL
v Use of ARL
v Consolidation of ARL for all CAs in a domain through the use of
Distribution Points 
v Consolidation of all the reason codes of key compromise for all
certificates in domain through the use of Distribution Point extension.
This CRL can be issued very frequently to meet the freshness requirements of
the domain.  This mechanism makes the CRL mechanism as current as the OCSP
v Partitioning routine revocation information using Distribution Point CRL
if CRLs become too large

There are several other factors that can help improve the CRL retrieval
efficiency.  These include:

v Repositories require the encoded CRL to send to the relying parties.  The
repositories also require decoded CRL to perform searches.  It may desirable
for the repository to store both encoded and decoded form as opposed to
performing encoding or decoding for each request
v Bind operation to repository can be slow if authentication is required.
If the repository does not store any private information, bind operations
for retrieval can be configured to require no authentication'
v CRL size can be reduced by having a short validity period for the
certificates, by using a coarse DN so that reorganization does not
invalidate a name, and not revoking for some reasons such as name change,
transfer, etc.)

I hope this helps.

-----Original Message-----
From: Ambarish Malpani [mailto:[email-masked]]
Sent: Monday, November 20, 2000 11:53 AM
To: 'Bland, Graham'; 'Simon Tardell'; [email-masked]
Subject: RE: OCSP identifiers

Hi Graham,

Regards,
Ambarish

Agreed.

Agreed.

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 20 Nov 2000 11:58:17 -0500 (EST)

> From: Simon Tardell <[email-masked]>
> To: "'Michael Myers'" <[email-masked]>, Margus Freudenthal 
<[email-masked]>, [email-masked]
> Date: Mon, 20 Nov 2000 13:45:07 +0100
> 
> > Margus,
> > 
> > We agree, especially regarding the observation that OCSP 
> > isn't and should't be tied to CRLs.  
> > 
> > I don't see any problem against including cert hash among
> > OCSP's certificate identification options.  Unless somebody
> > raises a significant objection, I'll put it in.
> 
> Mike,
> 
> I object. In principle issuerAndSerial should be enough. 

Mike,

I agree with Simon.  The problem I need to solve is making revocation
status information on 3-6 million subscribers available to perhaps
1 million globally-distributed relying parties with less than 6 hour
latency using the minimum possible network bandwidth.

My strawman solution is to use online status servers situated on
LANs (run by local administrators) and fed by delta CRLs.  If you can
propose a non-CRL-driven solution to my problem that uses less Internet
(WAN) bandwidth, please do so.  Otherwise, CRL-driven responders are a
requirement in my environment, and OCSP products which cannot be fed
by CRLs will not be purchased.

Dave

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 20 Nov 2000 10:32:05 -0700

Has anyone looked into challenging the validity of that patent?  I think a pretty good case could be made for prior art. 

In a series of messages on the pem-dev list in September and October 1993 -- a full three years before Micali's patent was filed -- I discussed at considerable length some of the problems with CRLs in a commercial environment.  On 9/21/93 I first discussed the possibility of a delta-CRL mechanism, and then went on to examine the possibility of a positive response system. On 9/22 I proposed requiring the CA to operate a trusted time-stamping service so that the CA could sign the message digest of a particular message in order to confirm that the certificate corresponding to the digital signature of the message in question was valid at the time of receipt.

I'm not a patent lawyer, but if I were one, I believe that I could convincingly argue that the method I proposed in 1993 provides well-known prior art that satisfies and hence invalidates Micali's claim 37.  Depending on how claim 38 is interpreted, the CA-authenticated certificate is either the certificate of what we would now call the OCSP responder itself, or the certificate that the OCSP responder is validating; but in either case the possibility of including such a certificate in the response, if required for some purpose, would certainly be obvious to anyone skilled in the art.

Regards,

Bob

Robert R. Jueneman
Security Architect
Novell, Inc. -- the leading provider of Net services software.

>>> Rich Salz <[email-masked]> 11/17/00 08:27PM >>>
> You can't get much simpler than a list of cert hashes and a status value...

If you want the OCSP responder to be able to work *only* off CRL's (e.g.,
Valicert -- arguably the OCSP market leader), then cert hash isn't very
useful.

> Probably the easiest option for everyone is to allow the pKCert ...

enjoy.

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 20 Nov 2000 13:35:11 -0500

Bob:

Micali scheme is quiet simply and nifty. I am not a patent attorney either.
It could be considered an improvement since he does not time stamp the hash.

The Micali scheme works as follows.  Let us say that n CRLs will be issued
during the life of the certificate (generally n = life/(CRL periodicity)).
The CA generates two random numbers and hashes them n times and puts them in
a certificate.  One number is the good certificate number and the other is
revoked number.  Each time it is time to update the revocation information
for a certificate, if the certificate is still good, the random number is
hashed one less time and the hash is sent to the directory.  The relying
party can forward hash this to determine the certificate is good.  If the
certificate is revoked, the revocation number is hashed fewer times and
relying party can determine the certificate is revoked.

I generally do not recommend, Micali scheme for the following reasons:

1.  It is patented
2.  It only provides information for one certificate.  You are likely to
communicate with several folks in a CA's subscriber population.
3.  For each user, you may need to get the revocation information and
perform directory bind.

I think CRL size is of concern in band-width challenged environment.  But,
when a user is sitting on a 10mb/sec LAN, number of directory binds may be
the limiting factors.

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, November 20, 2000 12:32 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: OCSP identifiers

Has anyone looked into challenging the validity of that patent?  I think a
pretty good case could be made for prior art. 

In a series of messages on the pem-dev list in September and October 1993 --
a full three years before Micali's patent was filed -- I discussed at
considerable length some of the problems with CRLs in a commercial
environment.  On 9/21/93 I first discussed the possibility of a delta-CRL
mechanism, and then went on to examine the possibility of a positive
response system. On 9/22 I proposed requiring the CA to operate a trusted
time-stamping service so that the CA could sign the message digest of a
particular message in order to confirm that the certificate corresponding to
the digital signature of the message in question was valid at the time of
receipt.

I'm not a patent lawyer, but if I were one, I believe that I could
convincingly argue that the method I proposed in 1993 provides well-known
prior art that satisfies and hence invalidates Micali's claim 37.  Depending
on how claim 38 is interpreted, the CA-authenticated certificate is either
the certificate of what we would now call the OCSP responder itself, or the
certificate that the OCSP responder is validating; but in either case the
possibility of including such a certificate in the response, if required for
some purpose, would certainly be obvious to anyone skilled in the art.

Regards,

Bob

Robert R. Jueneman
Security Architect

In a previous message I said that during work at a previous employer we
determined that this violates a patent by Micali.  I held my nose and did
some
searches this evening, and I believe I found it.  Claims 37ff of US Patent
5,717,757 filed Nov 96 and issued Feb 98:
	37. A method for providing authenticated information about
certificates,
	comprising the steps of: 
	(a) receiving a request for information about a certificate
including
	    a proof that the certificate is issued;
	(b) verifying that the proof is valid; and
	(c) in response to the proof being valid, providing the requested
	    information. 
	38. A method according to claim 37, wherein the proof includes
providing
	an entire CA-authenticated certificate. 

enjoy.

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 20 Nov 2000 12:04:04 -0700

Hi, Santosh,

I was not commenting on the validity or inventiveness of the Micali patent overall, as I haven't read it, but only the existence of prior art relative to claim 37, and by implication claim 38 as posted by Rich.

As I believe the original series of messages made clear, timestamping the message is primarily of value in establishing a correlation with absolute time that can be used at some time in the future.

Most of the time, it would be sufficient to answer the question "Is the certificate corresponding the digital signature on this message currently valid?"  If the answer is yes, then the message should be considered validly signed, since it was obviously signed prior to the request, and certificates are not allowed to revert back to valid from invalid.

If, however, the question was something along the lines of , "Was this digitally post-marked ballot received prior to the closing of the polls at 8:00PM EST, November 7, 2000, AND was the certificate valid at that time?", then a trusted-timestamp would be required.  

The thrust of the 1993 argument was to get away from all of the time notarizing of both the message and the certificates, and the correlation of those events after the fact, by asking the CA to provide a real-time, authoritative response.

Micali may well have a clever scheme for solving some other problem, but the issue concerned including a certificate in a response from a responder that confirm the validity of a certificate (or by implication a signature).  To that extent, I believe that claim 37 is overly broad and invalid, as it involves prior art and is not specifically related to the rest of the patent, i.e., the hashing scheme you described.  And since I believe claim 37 should be rejected, the particular instance of 37 that is claimed by 38 should be rejected as well, as being obvious to those skilled in the art.

Bob

>>> Santosh Chokhani <[email-masked]> 11/20/00 11:35AM >>>
Bob:

1.  It is patented

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Monday, November 20, 2000 12:32 PM
To: [email-masked] 
Cc: [email-masked] 
Subject: Re: OCSP identifiers

Regards,

Bob

Robert R. Jueneman
Security Architect

enjoy.

---

From: Frank Balluffi <[email-masked]>
Date: Mon, 20 Nov 2000 21:06:02 -0800

Also, a relying party may want to be able to prove that it performed a
certain amount of due diligence, which might include asking a validation
server certain questions.

Frank

---

From: Michael Myers <[email-masked]>
Date: Thu, 23 Nov 2000 19:55:37 -0800

Graham,

Practices regarding protection of the corresponding private key come to
mind.

Mike

> Sent: Monday, November 20, 2000 6:59 AM

---

From: Michael Myers <[email-masked]>
Date: Fri, 24 Nov 2000 19:48:14 -0800

Denis,

It's my understanding that IETF WGs are governed by the list, not the floor.
I regret to note that the list to date does not appear to support your
proposed alternative to OCSP certID syntax expansion.  As I've said
repeatedly, I have no other task but to record the WG's consensus.  As lead
author on OCSP, I have to at some point make a call in favor of forward
progress.  It appears to me that we do in fact have rough consensus on the
certID syntax issue.  You're of course free to bring this up on the floor in
San Diego.  That said, would you agree however that a floor consensus isn't
necessarily a WG consensus, given that some in the WG may be constrained in
their travel budgets?

Mike

---

From: Ambarish Malpani <[email-masked]>
Date: Mon, 27 Nov 2000 07:41:53 -0800

Hi Mike,
    Did I miss some mails? Not sure I saw any consensus on
changing the way of identifying the certificate at all.

Once again, if you assume that a client is responsible for
verifying the signature on a certificate, then requiring the
client to send over the hash of a CA's public key is not too
strenuous a requirement. While requiring clients to send over
the hash of the CA's DN was never a good idea, now that we have
it, I think we should just stick with it and proceed forward.

Having multiple possible ways of identifying a certificate will
only lead to more interop issues.

Regards,
Ambarish

> Sent: Friday, November 24, 2000 7:48 PM
> To: Denis Pinkas
> Cc: [email-masked]

---

From: Simon Tardell <[email-masked]>
Date: Tue, 28 Nov 2000 10:17:13 +0100

Mike,

> Among those who spoke on-list regarding OCSPv2's proposal to amend RFC
> 2560's certID syntax, PKIX has:
> 
> 9  in favor
> 2  opposed
> 
> Below is the précis underlying that count.

count me to the opposition then. 

I acknowledge the inelegance of CertID. If we would have done it from
scratch I would have proposed to do it slightly different, but now RFC2560
is there, and there is no fundamental problem with CertID I don't see enough
reason to change this. The changes that are proposed are rather major for
marginal or no gain, as I see it. Maybe it's ugly, but ain't broken.

The certHash option is a special problem. The CHOICE is a choice that the
client makes, not the responder, so if we allow certHash as a primary
identifier we will force responders to always have all certificates at hand
(or, rather, hashes thereof), even if we are only interested in revocation
information. Still, I recognize the need of, under some circumstances,
asking and answering the issuance question, so I propose that we make a
single request/response extension carrying the certHash for this purpose (in
a separate document). The observation here is that certHash should be a
qualification to the certificate identifier, rather than the certificate
identifier per se.

The pkCert and name options would more or less serve the same purpose, hence
I propose that they are put in (single) extensions, if they are needed at
all.

The bottom line is, lets stick with RFC2560, and move on with it.

Regards,

Simon.

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 28 Nov 2000 17:45:36 +0100 (MET)

Mike, you may count me in a similar way as Denis.

On one hand I support Simon Tardells argumentation
about extensions, i.e. for example, if a client or
a server wants to provide a real cert, then this
can be done as a Singlerequestextension. 

On the other hand there is some need to change:
it had been discussed years ago that the certID
syntax always requires that the client need basically
be in possession of the CA cert of the client.

Formally, the semantics of the choice are not described
in the current text, only 4.1.2 mentions the
initial version. Not knowing what 'certHash' and
what 'name' doesn't seem good. 

To come close to an alternative:

Allow a zero length certId which then MUST be accompagnied by
a singleRequestExtension for another identification forms.

You might add some forms in the v2 draft, but then
the semantics need to be explained. 

PS

---

From: Simon Tardell <[email-masked]>
Date: Tue, 28 Nov 2000 18:28:06 +0100

[...]

[...]

Peter,

Wouldn't it suffice to allow to pass a null value for issuer key hash (which
would mean that the responder would have to forego that check, of course)?
While still a modification to the protocol it is quite a bit smaller than
the current OCSP v2 draft... Also, if you don't understand null issuer key
hash values, you would presumably respond "unknown" which seems the correct
answer if you insist on having the issuer key hash sent with the request.

If we allow not to pass issuer and serial we're still in the situation where
the client can choose to pass an identifier which the responder has no
chance of resolving, and it has no way of telling "use this type of
identifier instead" (at least in a way that is distinguishable from "you
botched up your DER-encoding"). 

I think that the extension I am proposing should not have the semantics
"this is the certHash, it can also be used to identify the cert", but rather
"check if the cert identified by CertID has this certHash". The rationale is
that I think it is important that as much as possible of the semantics of
the response is possible to deduce from the response itself. When used in an
online fashion it may be enough that the response is just of a
"go/no-go"-type, but when preserved for posterity, e.g. to include in some
kind of evidence archival of a notarization service, it could be of
importance that you can see the individual assertions ("yes, revocation has
been checked for, but no, the responder did not answer about issuance"). So,
with a request extension of the type "check if the cert identified by CertID
has this certHash" a responder that can perform this kind of check would
return the corresponding response extension with the same certHash and some
status code (yes, no, unknown). OTOH a responder that does not understand
this extension would not return any response extension at all [corresponding
to that particular request extension], but still be able to tell the
revocation status of the cert. 

Simon.

PS Mike, I'd like to remind you of the clarification to RFC 2560 that
Ambarish proposed on this list on Aug 21 (RFC 2560 - OCSP - Clarification).
They are (of course) equally applicable to the would-be OCSP v2 and I think
it would be wise to apply them and reevaluate the certificate identifiers in
the light of those clarifications. DS

Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
[email-masked]
Work smarter! http://www.smarttrust.com/career

---

From: Peter Sylvester <[email-masked]>
Date: Tue, 28 Nov 2000 19:31:42 +0100 (MET)

> would mean that the responder would have to forego that check, of course)?
If I remember it right, this was the option chosen somewhere else in
implementation requirement to support some signature law. There was
also some more or less violent discussion two years ago about this.

I was actually tempted to propose this in my message :-) but a
little provocation with some 'larger' scope seemed more appropriate. 

I would not be against this option.  
 
> answer if you insist on having the issuer key hash sent with the request.
Seems reasonable. 

> botched up your DER-encoding"). 
Right, I am not really convinced that allowing just a few alternatives
as they are now, in particular certhash, name are all what could be
imagined as a service. Are we going to use OCSP as a lookup protocol to
support 'give me the current encryption cert for "name"' for example? 

> "check if the cert identified by CertID has this certHash". The rationale is
Well, you can have both meanings. basically I agree with your principle.

> revocation status of the cert.
Yes.
 
> the light of those clarifications. DS
All people who have followed the discussion seem to get boared about the
small wording changes, that seems the main reason for slow movement.
But one should not forget that there are people who read the text the first
time without ever having participated to the discussions.

---

From: "Covey, Carlin" <[email-masked]>
Date: Tue, 28 Nov 2000 15:51:42 -0800

Mike,

Since we seem to be taking a straw poll here, let me cast my (uncertified) 
vote in favor of OCSPv2's proposal to amend RFC 2560's certID syntax.

Those who are opposed are free to use the version 1 certID syntax in 
their client's queries, and to respond with "malformedRequest" if their 
responder receives some other type of certificate identifier.  

However, going forward it would be nice if there were a more graceful
means for a version 2 responder to tell a client that this responder 
does not recognize the certificate identifier in the client's request.

Regards,

Carlin Covey
Cylink Corp.

> Sent: Monday, November 27, 2000 2:34 PM
> To: Ambarish Malpani; 'Michael Myers'; Denis Pinkas
> Cc: [email-masked]

<snip>

> 2560's certID syntax, PKIX has:

<snip>>

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 29 Nov 2000 11:40:38 +0100 (MET)

Note that the current spec does NOT change the certID syntax
at all, the syntax fortunately adds a wrapper ReqCert,
thus other modules that use certId are not affected,
not that using the certId choice in IMPLICIT ReqCert 
would not give the same encoding as IMPLICIT CertId
(if my memories of asn1 rules are correct).

I repeat that the current spec of OCSPv2 does not give
a definition of what is intended to be specified with
the alternatives. Is this intended or not?

Peter

> Michael,
> 
> I have been working with Rich Ankney on OCSP issues in 
> an X9F3 standard we wished to align with your work and
> definitely support your efforts to amend the certID 
> syntax. If I can be of any help with any ASN.1 related
> issues, please let me know.
> 
> Phil Griffin
> 
> 
> Michael Myers wrote:
> > 
> > Denis,
> > 
> > Regarding the question "Should RFC 2560's certID syntax be amended to
> > accomodate other use cases" you proposed to me offlist and to the WG onlist
> > an ASN.1 syntax to address that need.  Given your actions, I concluded that
> > you favored taking this action.  Please clarify your position so that I may
> > maintain an accurate consensus count.
> >

---

From: Michael Myers <[email-masked]>
Date: Wed, 29 Nov 2000 10:34:05 -0800

Steve,

It's our objective to amend RFC 2560's certID syntax while preserving all
that RFC 2560 has established.  I have always presumed this would lead to a
new RFC number.  We're doing so in order to address known needs to expand
the means by which certificates can be identified in the OCSP bit stream.
Alternatively, we could editorially amend RFC 2560 and so move it from
proposed to draft.  As briefed in Pittsburg however, many of us believe it's
best to take the former course of action.

To that end, the v2 certID syntax is amendend in a fashion that enables v1
interoperability.  Further, both OCSPv2 servers and clients are required to
be capable of backwards interoperablity with their v1 peers.  There's no
need to deprecate the use of v1 if the original certID syntax satisfies
local requirements.  It's only when environments wish to, say, use CMS's
IssuerandSerialNumber vs. original certID that use of the v2 version number
in the bit stream is required.  Other than that,  it's precisely the same
protocol, simply amended to enable its use in other contexts.

Hope that clarifies things.

Mike

> From: Stephen Kent [mailto:[email-masked]]
> Sent: Tuesday, November 28, 2000 3:56 PM
> To: Michael Myers
> Cc: [email-masked]
> . . . . 
> I think there is ample support and technical rationale for this 
> change, but it's significant enough to reset advancement for the OCSP 
> document, i.e., v2 is a new standard.  You'll have to decide if it 
> supercedes v1, etc.  I'm awfully far behind on my e-mail. so maybe 
> I've missed this part of the debate, but what are the plans re OCSP 
> v1, i.e., since we all loathe parallel, mostly equivalent versions of 
> standards, is the proposal to replace v1 with v2, and denigrate the 
> use of v1?
> 
> Just asking ...
> 
> Steve
>