Subject: [pkix] OCSP update: ASN.1 syntax for nonce extension

From: "Cooper, David A." <[email-masked]>
Date: Mon, 26 Jul 2010 10:58:00 -0400

All,

After this afternoon's discussion I tried to relocate the messages indicating that some clients populated the extnValue for the nonce extension with an opaque blob rather than the DER encoding of some ASN.1.  The only message that I have found is http://www.ietf.org/mail-archive/web/pkix/current/msg13414.html.

However, I also looked at RFC 5912, and the new ASN.1 specifies that the contents of extnValue MUST be an OCTET STRING:

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

So, I think we can justify defining the syntax for the nonce extension as OCTET STRING based on the fact that RFC 5912 already does this for the OCSP-2009 ASN.1 module.

Of course, RFC 5912 just became an RFC last month, so it may still be worthwhile to note that RFC 2560 did not specify a syntax for the nonce extension and so some clients (or responders) may populate extnValue with something that is not a DER encoded OCTET STRING.

Dave

---

From: Russ Housley <[email-masked]>
Date: Mon, 26 Jul 2010 12:31:29 -0400

I support this way forward, but we should warn people about the
possibility of the missing second OCTET STRING wrapper, and encourage
people to accept it and respond with the same value (missing second
wrapper) when it is encountered.

Russ

On 7/26/2010 10:58 AM, Cooper, David A. wrote:
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: "Carl Wallace" <[email-masked]>
Date: Mon, 26 Jul 2010 13:02:05 -0400

While this draft is in progress, maybe this should be captured in an
errata for RFC 2560.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
Of
> Russ Housley
> Sent: Monday, July 26, 2010 12:31 PM
> To: [email-masked]
> Subject: Re: [pkix] OCSP update: ASN.1 syntax for nonce extension
> 
> > After this afternoon's discussion I tried to relocate the messages
> indicating that some clients populated the extnValue for the nonce
> extension with an opaque blob rather than the DER encoding of some
> ASN.1.  The only message that I have found is
http://www.ietf.org/mail-
> archive/web/pkix/current/msg13414.html.
> >
> > However, I also looked at RFC 5912, and the new ASN.1 specifies that
> the contents of extnValue MUST be an OCTET STRING:
> >
> > So, I think we can justify defining the syntax for the nonce
> extension as OCTET STRING based on the fact that RFC 5912 already does
> this for the OCSP-2009 ASN.1 module.
> >
> > Of course, RFC 5912 just became an RFC last month, so it may still
be
> worthwhile to note that RFC 2560 did not specify a syntax for the
nonce
> extension and so some clients (or responders) may populate extnValue
> with something that is not a DER encoded OCTET STRING.
> >
> > Dave

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 26 Jul 2010 22:17:26 +0200

So far I think I agree to this,

I would however like to hear from implementers of both responders and
clients, what they actually have implemented and what the impact of this
change/correction might be.

/Stefan

On 10-07-26 4:58 PM, "Cooper, David A." <[email-masked]> wrote:

> All,
> 
> After this afternoon's discussion I tried to relocate the messages indicating
> that some clients populated the extnValue for the nonce extension with an
> opaque blob rather than the DER encoding of some ASN.1.  The only message that
> I have found is 
> http://www.ietf.org/mail-archive/web/pkix/current/msg13414.html.
> 
> However, I also looked at RFC 5912, and the new ASN.1 specifies that the
> contents of extnValue MUST be an OCTET STRING:
> 
> So, I think we can justify defining the syntax for the nonce extension as
> OCTET STRING based on the fact that RFC 5912 already does this for the
> OCSP-2009 ASN.1 module.
> 
> Of course, RFC 5912 just became an RFC last month, so it may still be
> worthwhile to note that RFC 2560 did not specify a syntax for the nonce
> extension and so some clients (or responders) may populate extnValue with
> something that is not a DER encoded OCTET STRING.
> 
> Dave

---

From: Dr Stephen Henson <[email-masked]>
Date: Mon, 26 Jul 2010 23:02:16 +0100

> change/correction might be.

For clients and responders using OpenSSL's OCSP code there should be no problems.

OpenSSL treats the nonce extnValue as an opaque blob when copying it from
request to response (so a raw value is tolerated) and always encodes extnValue
as an OCTET STRING.

Ancient versions of OpenSSL OCSP code did encode extnValue as a raw value but
that was changed in OpenSSL 0.9.7d which was released on 17 Mar 2004.

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.