Subject: RE: What happened to the OCSPv2 draft?

From: "[email-masked]" <[email-masked]>
Date: Fri, 13 Sep 2002 19:19:18 -0400

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

Original Message:
-----------------
From: Hallam-Baker, Phillip [email-masked]
Date: Fri, 13 Sep 2002 09:46:35 -0700
To: [email-masked], [email-masked], [email-masked]
Subject: RE: What happened to the OCSPv2 draft?

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

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

---

From: "Steven Legg" <[email-masked]>
Date: Tue, 17 Sep 2002 11:36:03 +1100

> that same value.

It is important to note that it is a many-to-one mapping. For each
canonical XER encoding there are, in general, many DER encodings.
This comes about because the DER/BER encoding of TeletexString provides
many ways to represent the same string of abstract characters, and
all these alternatives have exactly the same representation in XER.

Consequently, taking a DER encoding, re-encoding in XER, and then
re-encoding in DER is not guaranteed to reproduce exactly the original
DER encoding. However, taking a canonical XER encoding, re-encoding in DER,
and then re-encoding in canonical XER will reproduce the original
canonical XER encoding.

Regards,
Steven

---

From: Phil Griffin <[email-masked]>
Date: Tue, 17 Sep 2002 06:53:09 -0400

Steven,

An interesting observation on how the text in the
DER standard can be interpreted. But really, any
TeletextString users have much bigger problems.

Phil