Subject: RE: What happened to the OCSPv2 draft?

From: [email-masked]
Date: Thu, 12 Sep 2002 21:48:44 -0400

As I recall, the OCSPv2 draft was collateral damage in the DPD/DPV wars.  While 
there were some changes to the base specification, the biggest enhancements 
were focused on DPV.   If memory serves, sometimes DPV was in the "core" v2 
specification, and sometimes in a separate document.  (By "core", I mean 
certificate status rather than DPV.)  Either way, the core and DPV tended to be 
worked in tandem.
 
Of course, the DPV portion of the specification got stuck while we discussed 
the requirements document.  There was not a big push to progress the OCSPv2 
specification without the DPV work.

I have the impression that has changed... from this thread, there seems to be 
sufficient interest to resume work on the OCSP core functionality regardless of 
the outcome on DPV.

Please note - I am not choosing sides in the *new* debate (change the base 
message versus only define new extensions).  If the needed functionality can be 
implemented with new extensions, great.  If the basic meesage needs to be 
updated, that's okay too.  (That's why the request syntax has a version number!)

Tim

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 13 Sep 2002 09:46:35 -0700

No, I think it was because we have customers and the customers don't want to
send more data than is required, particularly the ones who are paying by the
kb over wireless links.

If you are using the 2048 bit RSA keys you have 512 bytes of incompressible
crypto information alone in a cert. You are going to struggle to get that
plus protocol packaging into a single ethernet frame.

If there is a point to developing another delegated path discovery and
validation algorithm it is to allow for shorter messages than XKMS in XML
text encoding. Of course we could just develop an efficient encoding for
XML.

		Phill

> -----Original Message-----
> From: Ambarish Malpani [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 8:46 AM
> To: Denis Pinkas
> Cc: [email-masked]
> Subject: RE: What happened to the OCSPv2 draft?
> 
> 
> 
> 
> 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
> 
> 
> 
> > -----Original Message-----
> > From: Denis Pinkas [mailto:[email-masked]]
> > Sent: Friday, September 13, 2002 7:58 AM
> > To: Ambarish Malpani
> > Cc: [email-masked]
> > Subject: Re: What happened to the OCSPv2 draft?
> >
> >
> > Ambarish,
> >
> > > 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.
> >
> > Good. This is a point on which we both agree. :-)
> >
> > > 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.
> >
> > The current ways to specify the certificate are not that easy.
> >
> >    CertID ::=     SEQUENCE {
> >        hashAlgorithm       AlgorithmIdentifier,
> >        issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
> >        issuerKeyHash       OCTET STRING, -- Hash of Issuers 
> public key
> >        serialNumber        CertificateSerialNumber }
> >
> >    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.
> >
> > > For the former, all we need to do is define the extension. That
> > > 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
> >
> > > Regards,
> > > Ambarish
> > >
> > > > -----Original Message-----
> > > > From: [email-masked]
> > > > [mailto:[email-masked]]On Behalf Of Denis Pinkas
> > > > Sent: Thursday, September 12, 2002 1:48 AM
> > > > To: Stephen Kent
> > > > Cc: Peter Williams; [email-masked] '
> > > > Subject: Re: What happened to the OCSPv2 draft?
> > > >
> > > >
> > > >
> > > > 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: [email-masked] (Peter Gutmann)
Date: Mon, 16 Sep 2002 14:00:31 +1200 (NZST)

"Liaquat Khan" <[email-masked]> writes:

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

... except that the issuer DN has been smashed by the hashing, making it
impossible to locate the CRL even if you do know the serialNumber.

Peter.

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 16 Sep 2002 13:56:09 +1200 (NZST)

"Hallam-Baker, Phillip" <[email-masked]> writes:

>>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.
>
>And you foiled the plot by putting a fake timestamp on the moment at which
>the IESG and IAB were convinced?

He foiled the plot by using an X.509 cert from a public CA and having it
verified using COTS software (or was that how Todd started the plot?).

Peter :-).

---

From: "Frank Balluffi" <[email-masked]>
Date: Tue, 17 Sep 2002 08:35:42 -0400

Peter Gutman said:

"The CertID is very hard to get right for implementors (in fact one of the specific changes in 2560-bis is to try and explain it better to help people sort it out)."

How about adding an example to the text?

Frank

                      [email-masked]                                                                                                
                      nd.ac.nz (Peter          To:       [email-masked], [email-masked]                                   
                      Gutmann)                 cc:       [email-masked]                                                             
                      Sent by:                 Subject:  Re: What happened to the OCSPv2 draft?                                        
                      owner-ietf-pkix@m                                                                                                
                      ail.imc.org                                                                                                      

                      09/17/2002 04:45                                                                                                 
                      AM                                                                                                               

Denis Pinkas <[email-masked]> writes:

>   IssuerSerial ::= SEQUENCE {
>        issuer                   GeneralNames,

Urk.  Is this nonstandard variation on issuer+serialNumber really necessary?
That is, is there any situation where this will work and an
IssuerAndSerialNumber won't?  I can think of many situations in which (say) a
GeneralName URI + serial number (or, in general, anything which isn't the cert
issuer DN + serial number) won't work.  Why do you need a SEQUENCE OF
GeneralName in place of the issuer DN?

>ReqCert  ::= CHOICE {
>   certID            CertID,
>   certIDwithHash    [0] ESSCertID,
>   pKCert            [1] Certificate
>   }
>
>When ESSCertID (defined in RFC 2634) is used, then IssuerSerial is mandatory.

I still like the proposed v2 ID's, but I guess I can live with that if it's
what people want, except for the unusual IssuerSerial.  Can anyone explain the
semantics of the GeneralNames in there?  I can't actually see what I'd be
expected to do there, except stick in an issuer DN encoded as a GeneralName.

(I'd also allow the IssuerSerial to be optional, resource-constrained
 environments may want to send nothing more than a cert hash and offload all
 the work to the server (how much can you stuff in an SMS message :-)).

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

Actually I'd like to further comment on Ambarish's original comment.  The
current CertID has two problems, the first of which we've already gone
through, it doesn't identify a cert in a manner which is useful to anything
but OCSP.

The second isn't obvious from the RFC, but can be seen from discussions both
on the PKIX list and in private email: The CertID is very hard to get right
for implementors (in fact one of the specific changes in 2560-bis is to try
and explain it better to help people sort it out).  The people who have "put
in the work in OCSPv1" have got it right through guesswork, requests for help
to the list or to other implementors, or by reverse-engineering other
implementations.  There are CAs who have deployed their own software which gets
the ID wrong and who refuse to change it, citing installed software base as
the reason (I've talked to people who've had to work in this environment, it's
not fun).  Testing is almost impossible, because unless you manage to get it
exactly right you just get a response of "unknown", which may or may not mean
the ID is correct - you just have to keep guessing and trying until something
works.  This is an ongoing problem, and isn't going to get better with time,
because each new implementation has to go through this, and there will
continue to be broken implementations out there who are in a position where
they can refuse to change their code, causing great pain for anyone who has to
work with them.

Compare this with issuerAndSerialNumber or certHash (the 'certificate' option
is left as a trivial exercise for the reader).  Everything in existence does
certHash (as "fingerprint" or "thumbprint" or whatever) [0] and
interop/correctness checking is trivial, just click on the cert in MSIE and
look at the cert details.  issuerAndSerialNumber is similar, anything which
does S/MIME or a number of related protocols already correctly handles this,
so it's easy to find out information on and easy to check you've got it right.

Therefore I would contend that using better cert IDs will not decrease
interoperability, it will increase it, by using practical IDs which are easy
to work with and easy to get right.

Peter.

[0] OK, I haven't looked at every single PKI app in existence, but everything
    I've ever seen does it.

--

This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

---

From: Peter Williams <[email-masked]>
Date: Tue, 17 Sep 2002 11:39:38 -0700

Phil (Griffen),

We could try an exeriment to apply this technique. LDAP
is showing its age; its now harder to implement
than good old DAP. XML directory protocols are growing up very
fast, and support signed operations used in
Allied Directories, unlike LDAP.

What we could do this:  If we take the remote operation 
specification in X.511 we could use your
tool to produce a conformance checker for use
in ACP 133 Border DSAs that support 3 ports: DAP, 
LDAP, and XML-encoded. The border guard would
use XSL filters to control information
dissemnation, with greater granularity,
and using commodity implementation baseline.

We could probably work together to get some military 
research money to make a prototyye, building
on the WDSL for directory services, 
http://www.oasis-open.org/cover/dsml.html. DSML v2
encode LDAP request/responses as XML document
fragments. In this way all the military architectural
work of LDAP can be reused, with a better tool set capable
of generating automatic code, for
field replacement as standards evolve.

-----Original Message-----
From: Hallam-Baker, Phillip
To: [email-masked]'; Hallam-Baker, Phillip; [email-masked];
[email-masked]; [email-masked]
Sent: 9/16/02 8:04 AM
Subject: RE: What happened to the OCSPv2 draft?

Has any party commercial or non-comercial endorsed the 
proposed 'standard' and committed to supporting it?

It is one thing to get a bunch of people to agree to
a proposal, quite another to persuade an industry to
deploy.

I fail to see the value of an XML expression of deployed
X.509 semantics. I fail to see the value of an ASN.1
encoding to rival deployed XML specifications.

		Phill

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, September 13, 2002 4:19 PM
> To: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Of course, there already is a more efficient encoding for XML
> markup. The example at http://asn-1.com/EncodeBiometricSyntaxSets.htm
> shows that an X9.84/XCBF object can be encoded in 500+ bytes in XML,
> and that exactly the same abstract values can be encoded in 
> 50+ bytes in
> DER. The obvious conclusion is that for every canonical DER 
> value there
> is a canonical XER encoding that yields an XMl markup 
> representation of 
> that same value. Clearly messages can be stored and transferrd in DER
>  (which is not a particularly compact ASN.1 encoding, but  
> which enjoys
>  tools are cheap  and readily available) and exploded into 
> XML markup in 
> resource rich environments.
> 
> This is the thrust of the OASIS XML Common Biometric Format, the 2002
> revision of the X9.84 biometric information management and security , 
> the X9.96 XML Cryptographic Message Syntax, and the  X9.95 
> Trusted Time 
> Stamp standards. It is also the core of the NWI proposal in 
> ISO TC68/SC2 
> based on the XMLEncoding Rules and the schema defined in the ASC X9.68
> compressed domain certificate standard that moved forward in 
> ISO this week.
> If passed, this will result in a DER encoded certificate that is much
> smaller
> than the X.509 certificate format it is based on, and a 
> completely XML 
> certificate as well. The possibilities this will create to 
> stir the pot
> will be
>  interesting.
>  
> The idea of this approach is compelling for several reasons. 
> It provides a
> migration path into the XML space for ASN.1 defined specifications, it
> allows
> systems to be built  like my Biolojava tool kit that provide 
> support  for
> both XML
> aware and ASN.1 aware applications, and it provides 
> compression for XML
> values. 
> 
> But the really sweet  fallout of this is the simplicity of the XML
> signature 
> processing. It turns out to be almost equivalent  to the processing
> description used currently for DER in the IETF SMIME standard. 
> Anyone that can do SignedData using DER can, without nearly a
> thought, do the same with XML markup and leverage the browser.
> 
> And there are tools like mine emerging to support  these concepts, and
> standards that will use them.
> 
> Phil

---

From: "Florian B Oelmaier" <[email-masked]>
Date: Wed, 18 Sep 2002 00:01:50 +0200

> A signature has to be checked as soon as possible.

I have heard this requirement in the discussion multiple times now.

Having things like signed logs or other pieces of evidence that one might gather (automatically) in mind - I am not sure if this requirement is a good one.

Thus my question: Is it a requirement within the PKIX-system that every signature has to be checked within a few weeks, because otherwise no evidence regarding the certificate status can be collected?

---

From: [email-masked] (Peter Gutmann)
Date: Wed, 18 Sep 2002 23:04:51 +1200

Denis Pinkas <[email-masked]> writes:

>RFC 3281 mandates only one GeneralName which MUST contain a non-empty
>distinguished name in the directoryName field.

In other words it has converted IssuerSerial into an awkward IssuerAnd-
SerialNumber, which is exactly option (1) that I mentioned.

It's like a self-fulfilling prophecy...

Peter.

---

From: "Housley, Russ" <[email-masked]>
Date: Wed, 18 Sep 2002 10:30:04 -0400

Sounds like a perfect protocol for publication on 1 April 2003!

Peter Gutmann wrote:
>I'm waiting for an RFC which starts with a SEQUENCE OF ANY,

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 18 Sep 2002 17:18:41 +0200 (MET DST)

I had proposed 'Extensions' in the 'simple protocol',
and also an automatic way of detection of different encodings
starting with '0' is BER/DER, '<' is XER, '(' lispish SPKI, any
alpha an 822 header line style. 
 
'0' means null, nothing, nonsense, '<' is inferior,
'(' you always have something else to add, an any alpha
mean lot's of things to tell.

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 19 Sep 2002 03:28:59 +1200

Phil Griffin <[email-masked]> writes:

>Make sure you encapsulate that ANY inside of an OCTET STRING to make it
>lightweight and simple ;-)

Actually it should be an explicitly-tagged OCTET STRING, maybe:

SEQUENCE {
	[0] EXPLICIT OCTET STRING,
	[1] EXPLICIT OCTET STRING,
	[2] EXPLICIT OCTET STRING,
	[3] EXPLICIT OCTET STRING,
	[4] EXPLICIT OCTET STRING
	...
	}

although I'll have to figure out how to do it without the extension marker
since that's much too modern ASN.1 to appear in a PKI RFC.

This is great, I'll have an RFC done in no time :-).

Peter.