Subject: rfc3280bis change requested

From: <[email-masked]>
Date: Wed, 23 Jan 2008 21:17:43 -0800

I believe that in section 4.2 there needs to be a statement added to the
effect that extensions MUST be encoded using DER and stored in that encoding
in the extnValue field.

The following scenario demonstrates why I believe this statement needs to be
added.

1.  Assume Alice is a CA and places a private extension in every certificate
that is issued.

2.  Alice creates the certificate using DER encoding throughout, hashes and
signs.

3.  Alice then re-encodes the entire certificate using BER indefinite
encoding (for unknown reasons) and passes the certificate to Bob

4.  Bob attempts to change the encoding of the certificate from BER
indefinite to DER and cannot always do so for the private extension unless
he also knows the syntax associated with it.  Bob will not be able to a)
remove all default values and b) recognize all SET types and sort them.

Example

PrivateExtension ::= SEQUENCE {
       bool   BOOLEAN DEFAULT FALSE,
       iSet   [0] IMPLICIT SET OF INTEGER
}

Jim

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 24 Jan 2008 09:01:53 -0500

> effect that extensions MUST be encoded using DER and stored in that encoding

If there is confusion about whether 3280bis requires extensions to be 
DER encoded and it is not too late to make a clarifying change, then it 
would be a good idea to add something to 3280bis that clearly states 
that extensions must be DER encoded.

This is an X.509 requirement.  The ASN.1 for Extension in X.509 is:

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

I would suggest the following changes to 3280bis:

section 4.1 and appendix A.1 (add a comment to the ASN.1 for Extension):

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

new:
   Extension  ::=  SEQUENCE  {
        extnID      OBJECT IDENTIFIER,
        critical    BOOLEAN DEFAULT FALSE,
        extnValue   OCTET STRING
            -- contains the DER encoding of an ASN.1 value corresponding
            -- to the extension type identified by extnID -- }

section 4.2 (add the word "DER" to "ASN.1 encoded"):

old:
   Each extension includes an OID and an ASN.1 structure.  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.

new:
   Each extension includes an OID and an ASN.1 structure.  When an
   extension appears in a certificate, the OID appears as the field
   extnID and the corresponding ASN.1 DER encoded structure is the value of
   the octet string extnValue.

---

From: Russ Housley <[email-masked]>
Date: Thu, 24 Jan 2008 10:54:10 -0500

I agree with Jim.  This would simply be stating a requirement that 
already exists in X.509.

Russ

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 24 Jan 2008 17:33:29 +0100

X.509 should probably say

   Extension ::= SEQUENCE {
      extnId       EXTENSION.&id ({ExtensionSet}),
      critical       BOOLEAN DEFAULT FALSE,
      extnValue  OCTET STRING CONTAINING 
                 EXTENSION.&ExtnType({ExtensionSet}{@extnId}))

which would mean that when the signature is created DER encoding
is used, but if one uses a XER encoding of the certficate, one would
not see the raw DER octets but the XER encoding of the content.

I am still not sure whether the above is correct ASN.1, at least some
gurus say so.

IMO the text below should say:

Each extension includes an OID and an ASN.1 structure.  When an
  extension appears in a DER encoding of the certificate,
  the OID appears as the field extnID and the corresponding
  ASN.1 DER encoded structure is the value of the octet string extnValue.
  in particuler, DER encoing is used for the calculation of the certficate.

regards

David A. Cooper wrote:
> DER encoded and it is not too late to make a clarifying change, then 
> it would be a good idea to add something to 3280bis that clearly 
> states that extensions must be DER encoded.
>

-- 
To verify the signature, see http://edelpki.edelweb.fr/ 
Cela vous permet de charger le certificat de l'autorité; 
die Liste mit zurückgerufenen Zertifikaten finden Sie da auch.

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 24 Jan 2008 12:15:37 -0500

Peter,

I think your proposed language would lead to confusion.  While you may 
believe that X.509 should allow the contents of extnValue to be encoded 
using encoding rules other than DER in the unlikely case that the 
certificate is not DER encoded, X.509 specifies that extnValue always 
includes a DER encoded value.  As long as X.509 says this, the PKIX 
profile of X.509 should not imply otherwise.

Dave

---

From: Tolga Acar <[email-masked]>
Date: Thu, 24 Jan 2008 09:38:23 -0800

RFC3280 Section 4.1 says (the first paragraph):

The X.509 v3 certificate basic syntax is as follows.  For signature
   calculation, the data that is to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a
   tag, length, value encoding system for each element.

It seems to say clearly that you ought to use DER encoding to get a signed certificate. I'm not sure if that needs to be repeated in the extension definition.

- Tolga

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Sylvester
Sent: Thursday, January 24, 2008 8:33 AM
To: David A. Cooper
Cc: [email-masked]; Sam Hartman; [email-masked]
Subject: Re: rfc3280bis change requested

   Extension ::= SEQUENCE {

regards

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 24 Jan 2008 20:15:35 +0100

> It seems to say clearly that you ought to use DER encoding to get a signed certificate. I'm not sure if that needs to be repeated in the extension definition.

No, it does not. It only says that you need a DER encoding in order a 
signature.
It does not says that you could transfer or store a certficate in any other
form although this is obviously a practical thing to use DER in these
cases, at least when one only considers the BER derivates.

Since X509 predates XML and it also predates CONTAINING constraints
the wordings are quite understandable.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 24 Jan 2008 11:03:09 -0800

Peter,

What happens if it appears in a BER encoding of a certificate?  This is the
problem that I pointed out.

I am not overly worried about supporting of XER encoded certificates as this
is not part of the PKIX standard.

Jim

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Peter Sylvester

---

From: Russ Housley <[email-masked]>
Date: Thu, 24 Jan 2008 16:54:40 -0500

Peter:

I find David's suggested text more clear.  The point is that the 
OCTET STRING MUST contain the DER encoding of the extension value.

Russ

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 24 Jan 2008 23:14:24 -0800

Peter,

A couple of more comments.

1.  The XER encoding would most likely be placed in a Base64 encoding
because of the OCTET STRING wrapper, so I don't know that there is any real
advantange not be DER.

2. Do you have reason to believe that one can successfully convert from an
XER encoding to a DER encoding using just the XML (you don't get to use the
ASN.1).  I believe that I have shown it cannot be done in all cases for BER
to DER, this is the reason for the change.

Jim

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 25 Jan 2008 13:10:39 +0100

> because of the OCTET STRING wrapper, so I don't know that there is any real
My small sentence was grammatically false and also incomplete.

I think the real requirement is
- One must be able to create the DER encoding of the certficate.
- X509 specifies that extensions' content need to be DER encoded
  but I think what is meant is the same as in the previous point.

As you said in another mail. Without knowing the ASN.1 it
is impossible to create a DER encoding from any other encoding
both for the tbsCertficate and extension content. Since extension
are open types and a creator certainly does not know whether
a verifier knows an extension.

I think somewhere in the defining of SIGNED in X.5/6xx it is
said that one should use DER to transport such things.

What about:

  Each extension includes an OID and an ASN.1 structure.  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.
  In order to be sure that a user of a certificate can correctly perform
  signature verification, an encoder MUST use a DER encoding of the
  extension content.

As a result of a the ping pong game of asn1 people defining
octetstring wrappers (CONTAINING constraints) allowing good
parsers to go into the contents, which is what the other camp
tried to avoid by not simply using ANY DEFINED BY, today
one would probably define

      extnValue  EXTENSION.&ExtnType({ExtensionSet}{@extnId}))

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 25 Jan 2008 13:10:39 +0100

What about: