Subject: RE: What happened to the OCSPv2 draft?

From: Peter Williams <[email-masked]>
Date: Wed, 11 Sep 2002 15:16:00 -0700

Extensions can alter the semantics of a security protocol. In 
IETF we allow private organizations to create new extensions
for both certificates and OCSP, note. We know that cert politcy
qualifiers alter the impact of using (not processing) cert 
chains dramatically, for example, as intended by ISO.

Its not sensible to argue that WG-ratified extensions have
to be controlled (against unwarranted changes to PKIX semantics)
whilst we allow others to perform independently peform such
change of semantics. If we are to accept Steve's logic, we should
alter OCSP to require (non-experimental) extension registration, 
with IANA, to preseve IETF process input. Registered Extensions 
would have to through a WG process then, logically PKIX  - while
PKIX WG exists.

OCSP has no significant IETF-defined compliance rules, note.

-----

I think another valid question is, what do we do with the
SCVP id. Authors?

Peter.

-----Original Message-----
From: Stephen Kent
To: Hallam-Baker, Phillip
Cc: Hallam-Baker, Phillip; [email-masked]
Sent: 9/11/02 2:30 PM
Subject: RE: What happened to the OCSPv2 draft?

At 1:27 PM -0700 9/11/02, Hallam-Baker, Phillip wrote:
>  > By my count, that's two messages in a row from you on the theme of
>>  "let's kill off the PKIX WG."
>
>Congratulations, you spotted the hiddern pattern. Actually the wrong
>one. I have been arguing that the group should split off an extensions
>group and close the main group once all the milestones are complete.

Extensions can dramatically alter the semantics, functionality, and 
security of a base protocol or data structure. So I don't see the 
justification for having a different WG deal with extensions to 
previously developed PKIX standards. If one believed that was an 
appropriate path, then we should have changed WGs going from v1 
certs, to v2 certs, to v3 certs ...

>  > The future of OCSPv2 and its relevance to to the question of the
>>  future of this WG is equally silly.
>
>Why is it silly to ask whether the group should continue to progress
>a draft when the authors and much of the audience appear to have lost
>interest?

I didn't suggest that what you said above was a silly question. I 
suggested it was silly to use the question of extensions to OCSP as a 
basis for creating a new WG, consistent with my comments above. I 
agree with your question, i.e., unless there are supporters for an 
ID, it will not progress. If the authors loose interest then other 
authors have to take over, or the ID dies.  No disagreement there.

>  > Have you been hanging out with Todd?
>
>I was under the impression that Todd was arguing to take on more work
>rather than the reverse.

Todd's most recent effort was directed at removing me as chair of the 
PKIX WG, by persuading someone to take my place, or create a new WG 
for which I was not the chair, or to persuade the IESG or IAB that 
PKIX was broken and needed to be fixed, and then, ultimately, to 
convince the IAB & IESG that the IETF was broken and needed to be 
fixed.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Sep 2002 18:33:13 -0400

>chains dramatically, for example, as intended by ISO.

Well, I think we all agree that vendor-specified extensions to these 
protocols or data structures can cause trouble, and thus I personally 
am not a fan of such things. Ambarish later recalled that I warned 
him about the problems that extensions to OCSP might engender, and he 
agreed that they had come to cause problems.

>would have to through a WG process then, logically PKIX  - while

Extensions that do not carry the imprimatur of a standards body often 
see less widespread deployment (depending on the vendor, of course) 
and thus pose less of a risk than extensions that are approved by a 
standards body. So, on that basis I do think it appropriate to try to 
maintain WG control over extensions to the extent possible.

And yes, I would prefer extensions to be approved by a WG (PKIX in 
this case) before being assigned an OID bu IANA.  Other WGs have 
adopted that tactic for registration for analogous values.

>OCSP has no significant IETF-defined compliance rules, note.

Yor are right. We could have done better.

>I think another valid question is, what do we do with the

I don't think the WG gets to do anything to authors in general :-). 
And, I'm sorry, but I lost track here. I thought we were discussing 
OCSPv2, not SCVP. If someone, you for example, want to assume 
responsibility for OCSPv2, and if the WG is convinced that there is 
good reason to publish a new version, e.g., to fix some problems with 
the old version that require a versin # change, then we can proceed.

Steve

Steve

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 12 Sep 2002 10:47:49 +0200

Steve,

You said:

"Ambarish later recalled that I warned him about the problems that
extensions to OCSP might engender, and he agreed that they had come 
to cause problems."

I do agree we you.

To come back to technical issues, the expired OCSP v2 draft was expanding
its possibilities beyond certificate revocation checking, whereas some
fixing on the deficiencies of RFC 2560 would have been needed, in
particular, as pointed by Peter, more ways to select the certificate to be
checked.

OCSP v2 should NOT expand its possibilities beyond certificate revocation
checking and certainly should NOT try to expand its capabilities to cover
certificate validation.

To be more precise, I do not care about the expired OCSP v2 draft, but I
care about fixing RFC 2560, while sticking to its original functionality:
individual certificate revocation information status check.

Having said that, we should correct the major problem that exists in 
RFC 2560, which is how the certificate can be defined.

The proposal in the last draft (draft-ietf-pkix-ocspv2-02.txt) was fine:

ReqCert  ::= CHOICE {
   certID            CertID,
   issuerSerial      [0] IssuerandSerialNumber,
   pKCert            [1] Certificate,
   name              [2] GeneralName,
   certHash          [3] OCTET STRING}
     
CertID          ::=     SEQUENCE {
   hashAlgorithm       AlgorithmIdentifier,
   issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
   issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
   serialNumber        CertificateSerialNumber }

In addition, RFC 2560 includes a serviceLocator request extension, which
is nice when an OCSP service is supported in the background. However, it
does not include any extension when a CRL is supported in the background.
This means that the OCSP server cannot know in general where the CRL to be
used is located. 

:-(

One way would be to send the whole certificate (this is NOT possible with
RFC 2560) so that the CDP can be extracted by the receiving OCSP responder,
but another possibility would be to use an extension where the CDP
information present in the certificate would copied and pasted in that
extension. Then, using issuerSerial, the OCSP responder can perform the CRL
check and to transform it into an OCSP response.

Such extension would look like:

===========================================================================
8.X     CRL Locator

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

   id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

   CrlLocator ::= CRLDistributionPoints
 
The value for this field is obtained from the corresponding field in the 
subject certificate.

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

So my proposal would be to issue a new OCSP v2 draft, only including these 
two changes. Anything else I forgot ?  

Regards,

Denis

---

From: "Liaquat Khan" <[email-masked]>
Date: Thu, 12 Sep 2002 16:02:09 +0500

Hi,

I think this would be a very useful feature.  A number of PKIs are
hierarchical, and where CRLs are supported at higher levels (for checking
the revocation status of CA certs) and OCSP at lower levels (for checking
the revocation status of end-user certs).  This may be justified for various
reasons.

It should be possible for the OCSP responder to trace the relevant back-end
CRL using the information from the target certificate.  Either the target
certificate should be sent to the OCSP responder in full (so that the CDP
extension can be extracted by the OCSP responder directly) or the relying
party application needs to strip out the CDP extension from the target
certificate and send this in an extension of the OCSP request message as you
mention.

I remember asking for this over a year ago from the authors, and was told
that as OCSPv2 would allow a full certificate to be sent to the OCSP
responder so a special extension would not be needed and I should just wait
for this.  Since then we all know what happend to OCSPv2.

One comment on your post Denis:

>>Then, using issuerSerial, the OCSP responder can perform the CRL

I was thinking the OCSP responder could also use the serialNumber from the
CertID to do this.

Regards,
LK

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Denis Pinkas
Sent: 12 September 2002 13:48
To: Stephen Kent
Cc: Peter Williams; [email-masked] '
Subject: Re: What happened to the OCSPv2 draft?

Steve,

You said:

I do agree we you.

ReqCert  ::= CHOICE {
   certID            CertID,

CertID          ::=     SEQUENCE {

:-(

Regards,

Denis

---

From: Florian Oelmaier <[email-masked]>
Date: Thu, 12 Sep 2002 18:43:00 +0200

> checking and certainly should NOT try to expand its capabilities to cover

Although this bears some odds from a marketing perspective, I can see 
your arguments and agree to them.

> individual certificate revocation information status check.

Agree.

> RFC 2560, which is how the certificate can be defined.

[...]

> two changes. Anything else I forgot ?  

It would be nice to streamline OCSP so that it can be used as some sort 
of "revocation service provider" for one of the upcoming validation 
protocols - I think that is what you all have in mind.

Thus we should add an extension regarding the time of revocation 
checking - to allow the validation protocol to use OCSP while fulfilling 
the DPV-DPD requirements:

"The client can request that the server determine the certificate 
validity at a time other than the current time. The DPV server MUST 
obtain revocation status information for the validation time in the 
client request." - DPV-DPD requirements document

--
Florian Oelmaier
SyTrust

---

From: "Ambarish Malpani" <[email-masked]>
Date: Thu, 12 Sep 2002 11:07:45 -0700

Oops - too many messages just while I am transitioning....

Steve, if I remember correctly, what we agreed on was that
badly designed extensions can screw up a perfectly good
protocol. So can badly designed implementations....

Denis, I like the suggestion about allowing a client to include
the CRLDP extension in requests. I don't like the suggestion of
providing multiple means of identifying certificates - it
adds more interoperability problems and doesn't add much to
the protocol - assuming that we agree that OCSP was meant to
provide the status of a certificate.

For the former, all we need to do is define the extension. That
really doesn't need work on a OCSPv2 at all.

Regards,
Ambarish

> Sent: Thursday, September 12, 2002 1:48 AM
> To: Stephen Kent

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 13 Sep 2002 16:57:01 +0200

Florian,

 
 
> client request." - DPV-DPD requirements document

I do not think that adding a parameter in the request to specify a time in
the past (which is I guess what you are proposing) is necessary.

A signature has to be validated close to the time it was made and thus the
revocation status information has to be captured close to that time. 
We already have the archive cutoff in case an OCSP responder chooses
to retain revocation information beyond a certificate's expiration.

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 13 Sep 2002 16:57:37 +0200

Ambarish,
 
> the CRLDP extension in requests. 

Good. This is a point on which we both agree. :-)

> I don't like the suggestion of

The current ways to specify the certificate are not that easy.

   CertID ::=     SEQUENCE {

   CertificateSerialNumber  ::=  INTEGER

You cannot directly know the DN of the CA. You have to use a list of known
CAs and compute the hash over each of them to perform the match. This is a
severe limitation.
 
> really doesn't need work on a OCSPv2 at all.

I agree that, for defining an extension for handling a CRLDP extension in
requests, we do not need to define a v2 version, since it would be
applicable to v1.

Regards,

Denis

---

From: "Ambarish Malpani" <[email-masked]>
Date: Fri, 13 Sep 2002 08:45:51 -0700

Hi Denis,
    To make this easier to read, I will skip the part we agree on.

Here is the controversial topic: Do we need multiple ways of
identifying a certificate. My contention is no. We need to
decide on one and use that.

I see 2 reasonable options:
1. The current cert serial number and issuer name/key hash
2. The full certificate

I know in the past folks from VeriSign hated the second option. I
believe this was because their certs were pretty large (with
statements about limitations of liability, etc.).

At this stage, given the work that has gone in OCSPv1, I don't
think it is worthwhile digging up this controversy again. The
current option works fine for OCSP as long as you aren't asking
OCSP to also do path creation for you. If you have already
created one or more certificate chains, it isn't very hard
to figure out the CA's public key for any certificate in that
chain.

Makes sense?
Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [email-masked]
http://www.malpani.biz

> From: Denis Pinkas [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 7:58 AM
> To: Ambarish Malpani
> Cc: [email-masked]
> > > The proposal in the last draft
> (draft-ietf-pkix-ocspv2-02.txt) was fine:
> > >
> > > ReqCert  ::= CHOICE {
> > >    certID            CertID,

---

From: Jeff Jacoby <[email-masked]>
Date: Fri, 13 Sep 2002 11:43:15 -0700

> Florian,

[snip]

> the past (which is I guess what you are proposing) is necessary.

I've never quite understood the utility of the archive cutoff value.

I find the "contribute to a proof" arguement, in section 4.4.4, rather
vague.  
So I know the responder archives data for the last 7 years.  

So what?  

If I can't query the responder to see if a cert was revoked 6.5 years
ago
how does knowing the cutoff was 7 year ago really contribute to a proof

I think having a request parameter specify a time in the past better 
enables a client to take advantage of the cutoff information.  I can see 
it's not strictly necessary, but it would be really nice to have.

> revocation status information has to be captured close to that time.

I would argue this is too limiting.  If revocation information is
archived then we shouldn't restrict an RP from getting that information
no matter when the signature was created.

Here's an example (somewhat contrived):  

  - Executive of company E signs some financial documents/contracts.

  - After a short time the certificate is revoked (say, the Executive
    left the company).

  - A year later company E is under investigation for shady financial
    dealings, which may include the above signed document.

Isn't it reasonable for the investigators to determine--a year after the
signature was created--if the cert was revoked then?

> to retain revocation information beyond a certificate's expiration.

My apologies if I've mis-understood some of these issues.

Jeff
-- 
Jeff Jacoby, Principal Programmer                
RSA Security Inc., SMDC                    [email-masked]
2955 Campus Dr., Ste. 400                  (650) 295-7569
San Mateo, CA  94403

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 17 Sep 2002 09:31:48 +0200

Ambarish,

>     To make this easier to read, I will skip the part we agree on.

Fine.
 
> 1. The current cert serial number and issuer name/key hash

The very first question is whether the current way is reasonable: 
i.e. cert serial number + issuer name hash + issuer key hash.

   CertID          ::=     SEQUENCE {

I do not think it is.

It does not allow optimization of path checking. I would like a RP to be
able to send an OCSP request with only the certificate at hand. 

Today a path must first be constructed because the certificate only does not
allow to know the hash of the issuer's public key. 

Then, in order to make sure that the OCSP response is coming from the right
responder (in the case where the CA has designated its OCSP responders by
including id-kp-OCSPSigning in an extendedKeyUsage certificate extension
included in the OCSP response signer's certificates), the RP has to check
that the OCSP name included in the certificate matches the Name included in
the ResponderID: 

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

Alternatively, the RP has to check the KeyHash and for doing this.

In any case, the RP needs the OCSP certificate.
  
The certs field from the BasicOCSPResponse is only optional, and I would
make it mandatory  in the case where the CA has designated its OCSP
responders by including id-kp-OCSPSigning ... It would be nice for that
field to contain not only the OCSP responder certificate, but also the
certification chain. I already see Phill struggling to get that protocol
packaging into a single ethernet frame. Thus it would be nice to be able to
request the full chain, only when needed. This could be done using
requestExtensions.

In this way, the RP could validate the signature from the OCSP responder,
but much more important, when the OCSP request is not forwarded to another 
OCSP server, would get "for free" the certification path the verify the 
certificate that was under the original query, and could even get rid of 
using LDAP.

When the request is forwarded to another OCSP server, certs could include, 
upon request, another certification chain for the certificate under query 
up to a root key. This could be done using singleRequestExtensions.

Now let us come to the conclusion:

Option 1 does not fill the case mentioned above.
Option 2 of course does fill it.

What about an option 3 ?

pkix-rfc2560bis-01.txt defines Request as:

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

The expired OCSPv2 draft was proposing to define: 

Request         ::=     SEQUENCE {
   reqCert                     ReqCert,
   singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

with:

ReqCert  ::= CHOICE {
   certID            CertID,
     
CertID          ::=     SEQUENCE {

In order to identify unambiguously a certificate, RFC 2634 is using the
right syntax:

   ESSCertID ::=  SEQUENCE {
        certHash                 Hash,
        issuerSerial             IssuerSerial OPTIONAL
   }

with:

   IssuerSerial ::= SEQUENCE {
        issuer                   GeneralNames,
        serialNumber             CertificateSerialNumber
   }

This is a very compact form that Phill should like, despite it is in ASN.1. 
:-)

So let us come to my proposal for identifying a certificate:

Request         ::=     SEQUENCE {
   reqCert                     ReqCert,
   singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

with:

ReqCert  ::= CHOICE {
   certID            CertID,
   certIDwithHash    [0] ESSCertID,
   pKCert            [1] Certificate
   }

When ESSCertID (defined in RFC 2634) is used, then IssuerSerial is
mandatory.

> Makes sense?

No. Precisely for the reverse argument that I have used : when you do not
have already created one or more certificate chains, it is very hard to
figure out the CA's public key for any certificate in that chain.

Regards,

Denis

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 17 Sep 2002 09:35:50 +0200

Jeff,

> > I do not think that adding a parameter in the request to specify a time
> > in the past (which is I guess what you are proposing) is necessary.
> 
> 
> vague. So I know the responder archives data for the last 7 years.

It is true that the text is not very explicit. The intent was not an archive
for 7 years.

> ago how does knowing the cutoff was 7 year ago really contribute to a proof
> 
> > A signature has to be validated close to the time it was made and thus
> > the revocation status information has to be captured close to that time.
> 

A signature has to be checked as soon as possible. The problem is that you
can receive a signed e-mail while you are in vacations. I do not assume that
anyone is taking 7 years vacations. :-)

Let us assume that archive cutoff period to be set to a maximum of six
weaks. This means that when you come back for your 4 weeks vacations 
(2 weeks in your country), you can still check the revocation state of 
the certificate, even if the certificate was used the very last day of 
its validity period.
 
Denis