Subject: Re: RE: ASN.1 syntax for OCSP nonce value?

From: Wendsomde Evariste Sosthene Yameogo <[email-masked]>
Date: Mon, 20 May 2002 12:44:59 +0200

Hi Geoff, Hi Ambarish,

>Ambarish Malpani <[email-masked]> schrieb am 20.05.02:
> Hi Geoff,
>     Yes, the syntax for the value of a nonce is an OCTET STRING
> (because the nonce is specified as an extension and the value
> of an extension is always encoded in an OCTET STRING).

What do you exactly mean hier?
because the extension value is defined as 

extnValue  OCTET STRING

extnValue is always encoded as an OCTET STRING. 
But what about *THE CONTENT OF extnValue(The value of extnValue in the TLV encoding)* ? RFC2459(Section 4.2) states that
"..the corresponding ASN.1 encoded value is the value of the OCTET STRING extnValue".

This means that whatever we put in extnValue, it MUST be an *ASN.1 encoded value*. So if we have an extension where the extension value is a Certificate, we will have the encoded Certificate as the value of the OCTET STRING extnValue. As value I mean what remains when you remove the Type and Length bytes from the encoding.

This implies that in the case of the nonce we must first *Encode the Nonce as some ASN.1 structure*. We should NOT just take the nonce bytes and put them into the Value field of the OCTET STRING extnValue, because the nonce bytes don t represent any ASN.1 structure. So we have to encode the Nonce as an OCTET STRING (or BIT STRING if nonces with arbitrary number of bits are allowed, not only byte arrays) and then encode the result in extnValue. The OCSP specification should actually specify HOW TO encode the
nonce bytes(bits), which is NOT the case. I think there is something like

Nonce ::= OCTET STRING or Nonce ::= BIT STRING or 
Nonce ::= WHATEVER-WE-WANT-TO-PUT-IN-THERE

missing in section 4.4.1 of rfc2560.

While Testing my OCSP Implementation against others I noticed that all responders/clients I tested(excepted one) are using the wrong encoding(a simple OCTET STRING as extnValue, where the value of the TLV encoding represents the bytes of the nonce).
So for the sake of interoperabibility I modified my implementation altough I m conscious that this is wrong.

Regards,

Wendsomde

________________________________________________________________
Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! 
Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13

---

From: Geoff Elgey <[email-masked]>
Date: Tue, 21 May 2002 09:05:44 +1000

G'day,

Wendsomde Evariste Sosthene Yameogo wrote:

<snip>
> This means that whatever we put in extnValue, it MUST be an *ASN.1 encoded value*. So if we have an extension where the extension value is a Certificate, we will have the encoded Certificate as the…

RFC2560 imports the Extensions type from PKIXExplicit88, defined in RC2459.

Section 4.1 of RFC 2459 states that an extension has the following format:

Extension  ::=  SEQUENCE  {
      extnID      OBJECT IDENTIFIER,
      critical    BOOLEAN DEFAULT FALSE,
      extnValue   OCTET STRING  }

However, as you point out, section 4.2 mentions that "When an extension 
appears in a certificate, the OID appears as the field extnID and the 
corresponding ASN.1 encoded structure is the value of the octet string 
extnValue."

This is confirmed by the ASN.1 definition for Extension in Appendix B, 
as follows:

Extension         ::=   SEQUENCE {
    extnId            EXTENSION.&id ({ExtensionSet}),
    critical          BOOLEAN DEFAULT FALSE,
    extnValue         OCTET STRING }
                 -- contains a DER encoding of a value of type
                 -- &ExtnType for the
                 -- extension object identified by extnId --

In ASN.1 2002 syntax, this should probably be defined as follows:

Extension         ::=   SEQUENCE {
    extnId            EXTENSION.&id ({ExtensionSet}),
    critical          BOOLEAN DEFAULT FALSE,
    extnValue         OCTET STRING (
         CONTAINING EXTENSION.&ExtnType({ExtensionSet}{@extnId})
         ENCODED BY {joint-iso-itu-t asn1(1) ber-derived(2) 
distinguished-encoding(1)})
    }

This implies that a "nonce" must have some ASN.1 syntax, the complete 
DER-encoding of which is encapsulated as the value part of an OCTET 
STRING encoding.

 > This implies that in the case of the nonce we must first *Encode the 
Nonce as
 > some ASN.1 structure*. We should NOT just take the nonce bytes and 
put them
 > into the Value field of the OCTET STRING extnValue, because the nonce 
bytes
 > don t represent any ASN.1 structure. So we have to encode the Nonce 
as an OCTET
 > STRING (or BIT STRING if nonces with arbitrary number of bits are 
allowed, not only
 > byte arrays) and then encode the result in extnValue. The OCSP 
specification should
 > actually specify HOW TO encode the nonce bytes(bits), which is NOT 
the case.
 >
 > I think there is something like
 >

It would be nice if the supported extensions in RFC 2560 could be 
defined as object sets:

OCSPExtensionSet EXTENSIONS ::= {
   nonce |
   crlReference |
   acceptableResponseTypes |
   archiveCutoff |
   serviceLocator |
    ... -- for further extensions
}

nonce EXTENSION ::= {
   OCTET STRING IDENTIFIED BY id-pkix-ocsp-nonce
}

crlReference EXTENSION ::= {
   CrlID IDENTIFIED BY id-pkix-ocsp-crl
}

However, this would seem to break interoperability.

> So for the sake of interoperabibility I modified my implementation altough I m conscious that this is wrong.

Basically, what we have with existing OCSP extensions is the following 
ASN.1 type:

OCSPExtensions ::= SEQUENCE OF OCSPExtension

OCSPExtension ::= SEQUENCE {
   extnId EXTENSION.&id({OCSPExtensionSet}),
   critical BOOLEAN DEFAULT FALSE,
   extnValue OCTET STRING
     -- If extnId is id-pkix-ocsp-nonce, then nonce value is the
     -- given OCTET STRING.
     --
     -- Otherwise, the value octets of the OCTET STRING contain
     -- the DER-encoding of the ASN.1type associated with the
     -- value in extnId.
     --
     -- This can be formally defined in ASN.1 2002 syntax as:
     --
     -- OCTET STRING (
     --   CONTAINING EXTENSION.&ExtnType({OCSPExtensionSet}{@extnId})
     --  ENCODER BY {joint-iso-itu-t asn1(1) ber-derived(2) 
distinguished-encoding(1)})
     --
     -- See OCSPExtensionSet for the identification of ASN.1 syntaxes 
with OCSP
     -- object identifiers.
}

I would suggest that RFC2560 uses the above definition of an extension 
instead of the RFC2459 definition, or use the RFC 2459 definition and 
note that some implementations handle nonce differently.

Cheers,
Geoff