Subject: [pkix] DER encoding of certificates

From: "Erik Andersen" <[email-masked]>
Date: Wed, 6 Jul 2011 08:34:39 +0200

Hi folks,

In contrast to RFC 5280,  X.509 does not require DER encoding. It only
requires that the signature is generated across a DER encoded certificate,
but the itself certificate may be encoded using BER.

Should we add a sentence somewhere in X.509 and possibly in RFC 5280
specifying that when verifying a signature a relying party shall decode and
then encode the certificate in DER to verifying the signature? 

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490

e-amail: [email-masked]

Skype: andersen-erik

 <http://www.x500.eu/> http://www.x500.eu/

 <http://www.x500standard.com/> http://www.x500standard.com/

 <http://dk.linkedin.com/in/andersenerik>
http://dk.linkedin.com/in/andersenerik

---

From: Carl Wallace <[email-masked]>
Date: Wed, 06 Jul 2011 08:01:14 -0400

No.  For one reason, verifiers may not know how to DER encode some
extensions.  It'd be better to require DER or require verification to use
toBeSigned bytes as they appear (be they BER or DER).

From:  Erik Andersen <[email-masked]>
Date:  Wed, 6 Jul 2011 08:34:39 +0200
To:  Directory list <[email-masked]>, SG17-Q11
<[email-masked]>, PKIX <[email-masked]>
Subject:  [pkix] DER encoding of certificates

> requires that the signature is generated across a DER encoded certificate, but
> the itself certificate may be encoded using BER.
>  
> e-amail: [email-masked] <[email-masked]>
> Skype: andersen-erik
> http://www.x500.eu/ <http://www.x500.eu/>
> http://www.x500standard.com/ <http://www.x500standard.com/>
> _______________________________________________ pkix mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/pkix

---

From: Martin Rex <[email-masked]>
Date: Wed, 6 Jul 2011 15:40:00 +0200 (MEST)

> toBeSigned bytes as they appear (be they BER or DER).

Expecting verifiers to parse and re-encode certs before being able
to verify a digital certificate seems like a very bad idea with
respect to performance, reliability and complexity.

The other problem is that there are too many defective ASN.1 encoders
out there, some of them actively used by certificate issuers.
GlobalSign has been distributing a RootCA cert in browsers that
was using incorrect ASN.1 DER -- and that caused verification
failures on some occasions.  IIRC, the bug was in the ASN.1
encoding of the KeyUsage BIT STRING, which is a NamedBitList
(and according to X.690 11.2 + X.680 21.7 tailing 0 bits must
be removed in ASN.1 DER from a NamedBitList during encoding.)

-Martin

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 6 Jul 2011 09:56:43 -0400

Do not need to re-encode.  Always keep the blob around.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Rex
Sent: Wednesday, July 06, 2011 9:40 AM
To: Carl Wallace
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] DER encoding of certificates

-Martin
_______________________________________________
pkix mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/pkix

---

From: Peter Rybar <[email-masked]>
Date: Wed, 6 Jul 2011 08:52:04 +0200

Erik,

detail information is in ITU-T X.509
http://www.itu.int/rec/T-REC-X.509-200508-I

RFC 5280 is only a profile for Internet on-line services like TSL/SSL, ...

ITU-T Rec. X.509 (08/2005)
6.1 Digital signatures
The value of the bit string is generated by taking the octets which form the
complete encoding (using the ASN.1 Basic Encoding Rules – ITU-T Rec. X.690
(2002) | ISO/IEC 8825-1:2002) of the value of the ToBeEnciphered type and
applying an encipherment procedure to those octets.

New certificates for any test or use you can generate in "Utility" tab, "New
Key" button.
http://lockitin.webnode.sk/products/produkt-1/

Peter Rybar

National Security Authority
Information Security and Electronic Signature Department
Budatinska 30, 850 07 Bratislava 57, Slovak Republic
tel.: +421 2 6869 2163
mob.: +421 902 891 155
fax: +421 2 6869 1701
e-mail: [email-masked]
e-mail: [email-masked]

2011/7/6 Erik Andersen <[email-masked]>

> http://www.x500.eu/
> http://www.x500standard.com/
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 6 Jul 2011 11:37:29 -0400

Don't you then run into the question of whether the DER blob is the same as the non-DER bits?

--Richard

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 6 Jul 2011 11:40:48 -0400

(BTW, messages to one mail list seem to get rejected).

I do not see an issue.  The signer signs something.  You verify it.  You keep and transmit the blob and signature.  You or anyone can decode the blob and as long as decoding is definitive (which to my knowledge is), no problems or ambiguities should be encountered.

-----Original Message-----
From: Richard L. Barnes [mailto:[email-masked]] 
Sent: Wednesday, July 06, 2011 11:37 AM
To: Santosh Chokhani
Cc: [email-masked]; Carl Wallace; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [pkix] DER encoding of certificates

--Richard

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Jul 2011 13:03:21 -0400

At 8:52 AM +0200 7/6/11, Peter Rybar wrote:
><http://www.itu.int/rec/T-REC-X.509-200508-I>http://www.itu.int/rec/T-REC-X.509-200508-I
>

not quite sure what you mean by "on-line services." Look at the LTANS 
WG, which deals with long term storage of signed data. Their RFCs 
cite 5280 (or its predecessor, 3280) as normative.

Steve

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 7 Jul 2011 08:44:02 +0200

Hi Steven, Santosh, and others

6.1 of X.509 the HASH information object states that

-- shall be the result of applying a hashing procedure to the DER-encoded
octets --
			-- of a value of --ToBeHashed

The ENCRYPTED-HASH also states

-- shall be the result of applying a hashing procedure to the DER-encoded
(see 6.1) octets --

The SIGNATURE information object class refers to ENCRYPTED-HASH.

Already the 1988 edition required signatures based on DER encoding.

Clearly, the X.509 requires and have always required signatures to be
performed over the DER encoded data.

I have a problem with requiring the standard to take into account
non-conforming implementations. However, my proposal was partly a
provocation to see the reaction.

I see three possible solutions:

1)	The decoding and re-encoding in DER as it has been discussed
2)	Remove the DER requirements from 6.1 of X.509
3)	Mandate use of DER encoding for certificates and other similar data
types. This would also include signed operations. Implementations will then
always perform signature check over the "blob" (which could be BER encoded).
We will still have non-conformant implementations, but they would work and
X.509 would be consistent.

For some peculiar reasons, Extensions shall always be DER encoded. This
requirement was introduced already in 1997, when the concept of extensions
was introduced.  

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: Steven Legg [mailto:[email-masked]] 
Sendt: 6. juli 2011 09:22
Til: [email-masked]
Cc: Erik Andersen
Emne: [Spam] Re: [x500standard] DER encoding of certificates

Erik,

> In contrast to RFC 5280, X.509 does not require DER encoding. It only
requires that the signature is
> generated across a DER encoded certificate, but the itself certificate may
be encoded using BER.
> Should we add a sentence somewhere in X.509 and possibly in RFC 5280
specifying that when verifying a
> signature a relying party shall decode and then encode the certificate in
DER to verifying the signature?

That would cause more problems than it solves because all too often in
the real world signatures are calculated over the BER encoding that is
transmitted rather than the DER encoding it is supposed to be calculated
over.

Erik Andersen wrote:
 > If the RDN is part of a primary distinguished name, the
primaryDistinguished
 > component is TRUE and the valueWithContext shall not be included. If in
addition,
 > the primaryDistnguished component is absent taking the default value, the
encoding
 > of a 5280 certificate and the encoding of an X.509 certificate are
identical.
 > However, if the primaryDistingished component is present and takes the
value TRUE,
 > a X.509 certificate will be different from a 5280 certificate and may not
be
 > accepted by all systems. Apparently, some tool will always add the
primaryDistingished
 > component with the value TRUE.

Is this an observed problem or a theoretical one ? A decoder using the 5280
definition may well treat the AttributeTypeAndValue type as implicitly
extensible, in which case the primaryDistinguished component will be an
unknown extension that is gracefully ignored. The certificate couldn't be
re-encoded in DER, but that's not a wise thing to do anyway for the reason
above.

Regards,
Steven

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 07 Jul 2011 11:14:37 +0200

removing a DER requirement is unacceptable. Most implementations tolerate
certain deviations from DER (the second half of point a below for example)
are probably not prepared to handle a violation of the first part of 
point a.

I think the following text in X/509 is sufficiently clear (assuming that 
we are all in THE directory):

In 6.1 : (draft version 2008):

Generating a distinguished encoding requires the abstract syntax of the 
data to be encoded to be fully understood. The Directory may be required 
to sign data or check the signature of data that contains unknown 
protocol extensions or unknown attribute syntaxes. The Directory shall 
follow these rules:

-- It shall preserve the encoding of received information whose abstract 
syntax it does not fully know and which it expects to subsequently sign;

-- When signing data for sending, it shall send data whose syntax it 
fully knows with a distinguished encoding and any other data with its 
preserved encoding, and shall sign the actual encoding it sends;

-- When checking signatures in received data, it shall check the 
signature against the actual data received rather than its conversion of 
the received data to a distinguished encoding.

== too bad that this doesn't work if one wants to work with XER only.

The text above in 6.1 (with comments inline)

SIGNED { ToBeSigned } ::= SEQUENCE {

*toBeSigned ToBeSigned,*

*COMPONENTS OF SIGNATURE { ToBeSigned } }*

In order to enable the validation of *SIGNED* and *SIGNATURE* types in a 
distributed environment, a distinguished encoding is required.

PS: == a distinguished encoding is only required if one decodes and 
reencodes which is not
what is recommended later. Nevertheless, this is not a reason to remove the
requirement for the encoding and open it to an arbitrary BER.

A distinguished encoding of a *SIGNED* or *SIGNATURE* data value shall 
be obtained by applying the Basic Encoding Rules defined in ITU-T Rec. 
X.690 (2002) | ISO/IEC 8825-1:2002, with the following restrictions:

a) the definite form of length encoding shall be used, encoded in the 
minimum number of octets;

b) for string types, the constructed form of encoding shall not be used;

c) if the value of a type is its default value, it shall be absent;

d) the components of a Set type shall be encoded in ascending order of 
their tag value;

e) the components of a Set-of type shall be encoded in ascending order 
of their octet value;

f) if the value of a Boolean type is true, the encoding shall have its 
contents octet set to "FF"16;

g) each unused bit in the final octet of the encoding of a Bit String 
value, if there are any, shall be set to zero;

h) the encoding of a Real type shall be such that bases 8, 10, and 16 
shall not be used, and the binary scaling factor shall be zero.

i) the encoding of a UTC time shall be as specified in ITU-T Rec. X.690 
(2002) | ISO/IEC 8825-1:2002;

j) the encoding of a Generalized time shall be as specified in ITU-T 
Rec. X.690 (2002) | ISO/IEC 8825 1:2002.

PS: == the points above are just a description of DER? This part of the 
text shouldn't be there and simply reference DER (which is actually done 
in the comments like in

*ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING ( CONSTRAINED BY {*

/-- shall be the result of applying a hashing procedure to the 
DER-encoded (see 6.1) octets --/

*/-- of a value of -- ToBeSigned -- and then applying an encipherment 
procedure to those octets -- /})
*

A very bad style to define meaning in comments IMO (without doing it in 
the text).

> 1)	The decoding and re-encoding in DER as it has been discussed
X.509 does not require this and recommends against. (see above)
> 2)	Remove the DER requirements from 6.1 of X.509
This will break any conformant and strict verifiers,
and many tolerant verifiers.
> always perform signature check over the "blob" (which could be BER encoded).
Isn't that exactly what X.509 says.
> X.509 would be consistent.
Consistency and compatibility in time is not exactly where X standards
are the best. (x400 84 vs 88, well that's old)

recent X.509 keyusage changes breaks XER decoders
(Non Repudiation vs Contentcommitment).
Since two names are allowed for the same bit there is no longer
a distinguished XML encoding possible.

> requirement was introduced already in 1997, when the concept of extensions

It is for exactly the same reason, to have a distinguished encoding.
With extensions it has become even impossible to decode
them and reencode completely.

regards
Peter Sylvester

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 7 Jul 2011 07:19:14 -0400

I would say that the order of preference should be 3, 2, and 1. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Thursday, July 07, 2011 2:44 AM
To: [email-masked]; SG17-Q11; PKIX
Subject: [x500standard] SV: [Spam] Re: DER encoding of certificates

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: Steven Legg [mailto:[email-masked]] 
Sendt: 6. juli 2011 09:22
Til: [email-masked]
Cc: Erik Andersen
Emne: [Spam] Re: [x500standard] DER encoding of certificates

Erik,

be encoded using BER.

primaryDistinguished
addition,
encoding
identical.
value TRUE,
be
primaryDistingished

Regards,
Steven

> http://dk.linkedin.com/in/andersenerik

-----
www.x500standard.com: The central source for information on the X.500 Directory Standard.

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 7 Jul 2011 13:27:01 +0200

I have come to the same conclusion. It is clear by now that the text is
already there (if you can find it). So what is needed is some text here and
there to clarify the issue.

During the August meeting we will try to come up with pieces of text to be
included in the next edition.

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af
Santosh Chokhani
Sendt: 7. juli 2011 13:19
Til: [email-masked]; SG17-Q11; PKIX
Emne: Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of certificates

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Erik Andersen
Sent: Thursday, July 07, 2011 2:44 AM
To: [email-masked]; SG17-Q11; PKIX
Subject: [x500standard] SV: [Spam] Re: DER encoding of certificates

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: Steven Legg [mailto:[email-masked]] 
Sendt: 6. juli 2011 09:22
Til: [email-masked]
Cc: Erik Andersen
Emne: [Spam] Re: [x500standard] DER encoding of certificates

Erik,

be encoded using BER.

primaryDistinguished
addition,
encoding
identical.
value TRUE,
be
primaryDistingished

Regards,
Steven

> http://dk.linkedin.com/in/andersenerik

-----
www.x500standard.com: The central source for information on the X.500
Directory Standard.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Jul 2011 08:11:01 -0400

Removing a DER requirement is perfectly fine by me.

Removing the requirement that the encoder emit the bit stream that was
signed is the issue. That would be totally ridiculous

* X.500 is obsolete. No matter what the technical merits there is no example
in our industry of a 20 year old technology that has had minimal success
eclipsing a successor.

* Even LDAP is of limited use unless an enterprise writes its own
applications to pull information from it.

* Breaking a cert up to store the attributes in a directory and then
reassembling is guaranteed to fail. It was nonsense when first proposed

If we made any change here at all it should be to require applications  to
accept PKIX certificates that are encoded using any valid BER encoding and
drop mention of DER altogether. I believe that this has been the defacto
requirement in any case.

On Thu, Jul 7, 2011 at 5:14 AM, Peter Sylvester
<[email-masked]>wrote:

> **
> are probably not prepared to handle a violation of the first part of point
> a.
>
> I think the following text in X/509 is sufficiently clear (assuming that we
> are all in THE directory):
>
> data to be encoded to be fully understood. The Directory may be required to
> sign data or check the signature of data that contains unknown protocol
> extensions or unknown attribute syntaxes. The Directory shall follow these
> rules:
>
> – It shall preserve the encoding of received information whose abstract
> – When signing data for sending, it shall send data whose syntax it fully
> knows with a distinguished encoding and any other data with its preserved
> encoding, and shall sign the actual encoding it sends;
>
> – When checking signatures in received data, it shall check the signature
> against the actual data received rather than its conversion of the received
> data to a distinguished encoding.
>
> * toBeSigned ToBeSigned,*
>
> * COMPONENTS OF SIGNATURE { ToBeSigned } }*
>
> A distinguished encoding of a *SIGNED* or *SIGNATURE* data value shall be
> obtained by applying the Basic Encoding Rules defined in ITU-T Rec. X.690
> (2002) | ISO/IEC 8825-1:2002, with the following restrictions:
>
> e) the components of a Set-of type shall be encoded in ascending order of
> their octet value;
>
> h) the encoding of a Real type shall be such that bases 8, 10, and 16 shall
> not be used, and the binary scaling factor shall be zero.
>
> j) the encoding of a Generalized time shall be as specified in ITU-T Rec.
> X.690 (2002) | ISO/IEC 8825 1:2002.
>
>
> text shouldn't be there and simply reference DER (which is actually done in
> the comments like in
>
> * -- shall be the result of applying a hashing procedure to the
> DER-encoded (see 6.1) octets --*
>
> * -- of a value of -- ToBeSigned -- and then applying an encipherment
> procedure to those octets -- })
> *
>
> A very bad style to define meaning in comments IMO (without doing it in the
> text).
>
> Skype: andersen-erikhttp://www.x500.eu/http://www.x500standard.com/http://dk.linkedin.com/in/andersenerik
>
>
> Fra: Steven Legg [mailto:[email-masked] <[email-masked]>]
> pkix mailing [email-masked]://www.ietf.org/mailman/listinfo/pkix
>
>
>

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 7 Jul 2011 08:16:15 -0400

I chose 4 or 5:

4) Eliminate the DER encoding requirement completely
5) Do nothing at all

PKIX is written to serve the needs of Internet applications. Canonical
encoding of certs has no value for those applications.

---

From: Peter Sylvester <[email-masked]>
Date: Thu, 07 Jul 2011 14:57:26 +0200

Hi all.

*toBeSigned ToBeSigned,*

regards
Peter Sylvester

> e-amail:[email-masked]
> Til:[email-masked]
> Cc: Erik Andersen
>> e-amail:[email-masked]

---

From: Santosh Chokhani <[email-masked]>
Date: Thu, 7 Jul 2011 09:10:42 -0400

Phillip,

So, you are saying, do not transmit the payload; do not reassemble the pay and do not require to do DER.

Whow.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phillip Hallam-Baker
Sent: Thursday, July 07, 2011 8:11 AM
To: Peter Sylvester
Cc: [email-masked]; SG17-Q11; PKIX
Subject: Re: [pkix] [Spam] Re: [x500standard] DER encoding of certificates

Removing the requirement that the encoder emit the bit stream that was signed is the issue. That would be totally ridiculous

* X.500 is obsolete. No matter what the technical merits there is no example in our industry of a 20 year old technology that has had minimal success eclipsing a successor.

* Even LDAP is of limited use unless an enterprise writes its own applications to pull information from it.

* Breaking a cert up to store the attributes in a directory and then reassembling is guaranteed to fail. It was nonsense when first proposed

If we made any change here at all it should be to require applications  to accept PKIX certificates that are encoded using any valid BER encoding and drop mention of DER altogether. I believe that this has been the defacto requirement in any case.

On Thu, Jul 7, 2011 at 5:14 AM, Peter Sylvester <[email-masked]<mailto:[email-masked]>> wrote:

removing a DER requirement is unacceptable. Most implementations tolerate
certain deviations from DER (the second half of point a below for example)
are probably not prepared to handle a violation of the first part of point a.

I think the following text in X/509 is sufficiently clear (assuming that we are all in THE directory):

Generating a distinguished encoding requires the abstract syntax of the data to be encoded to be fully understood. The Directory may be required to sign data or check the signature of data that contains unknown protocol extensions or unknown attribute syntaxes. The Directory shall follow these rules:

- It shall preserve the encoding of received information whose abstract syntax it does not fully know and which it expects to subsequently sign;

- When signing data for sending, it shall send data whose syntax it fully knows with a distinguished encoding and any other data with its preserved encoding, and shall sign the actual encoding it sends;

- When checking signatures in received data, it shall check the signature against the actual data received rather than its conversion of the received data to a distinguished encoding.

toBeSigned ToBeSigned,

COMPONENTS OF SIGNATURE { ToBeSigned } }

In order to enable the validation of SIGNED and SIGNATURE types in a distributed environment, a distinguished encoding is required.

PS: == a distinguished encoding is only required if one decodes and reencodes which is not
what is recommended later. Nevertheless, this is not a reason to remove the
requirement for the encoding and open it to an arbitrary BER.

A distinguished encoding of a SIGNED or SIGNATURE data value shall be obtained by applying the Basic Encoding Rules defined in ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002, with the following restrictions:

a) the definite form of length encoding shall be used, encoded in the minimum number of octets;

d) the components of a Set type shall be encoded in ascending order of their tag value;

e) the components of a Set-of type shall be encoded in ascending order of their octet value;

f) if the value of a Boolean type is true, the encoding shall have its contents octet set to "FF"16;

g) each unused bit in the final octet of the encoding of a Bit String value, if there are any, shall be set to zero;

h) the encoding of a Real type shall be such that bases 8, 10, and 16 shall not be used, and the binary scaling factor shall be zero.

i) the encoding of a UTC time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IEC 8825-1:2002;

j) the encoding of a Generalized time shall be as specified in ITU-T Rec. X.690 (2002) | ISO/IEC 8825 1:2002.

PS: == the points above are just a description of DER? This part of the text shouldn't be there and simply reference DER (which is actually done in the comments like in

ENCRYPTED-HASH { ToBeSigned } ::= BIT STRING ( CONSTRAINED BY {

-- shall be the result of applying a hashing procedure to the DER-encoded (see 6.1) octets --

-- of a value of -- ToBeSigned -- and then applying an encipherment procedure to those octets -- })

A very bad style to define meaning in comments IMO (without doing it in the text).

octets --

(see 6.1) octets --

was introduced.

regards
Peter Sylvester

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490<tel:%2B45%202097%201490>

e-amail: [email-masked]<mailto:[email-masked]>

Skype: andersen-erik

http://www.x500.eu/

-----Oprindelig meddelelse-----

Til: [email-masked]<mailto:[email-masked]>

Cc: Erik Andersen

Erik,

Hi folks,

be encoded using BER.

over.

primaryDistinguished

addition,

encoding

identical.

value TRUE,

be

primaryDistingished

above.

Regards,

Steven

Erik Andersen

Andersen's L-Service

Elsevej 48,

DK-3500 Vaerloese

Denmark

Mobile: +45 2097 1490<tel:%2B45%202097%201490>

e-amail: [email-masked]<mailto:[email-masked]>

Skype: andersen-erik

http://www.x500.eu/

pkix mailing list

[email-masked]<mailto:[email-masked]>

_______________________________________________
pkix mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pkix

---

From: David Wilson <[email-masked]>
Date: Thu, 07 Jul 2011 10:01:30 +0100

On Thu, 2011-07-07 at 08:44 +0200, Erik Andersen wrote:
> Implementations will then

This is already specified in X.509 (end of section 6):

"When checking signatures in received data, [the Directory] shall check
the signature against the actual data received rather than its
conversion of the received data to a distinguished encoding."

So, for generators of signed objects, the octets sent must be the octets
used to generate the signature.

For SIGNATURE rather than SIGNED, the requirement means that the
verifier needs to preserve the received encoding of the object(s) to be
used.

However, signers should use DER, in case a verifier does not follow
this, and does decode+re-encode in DER.

David

---

From: "Erik Andersen" <[email-masked]>
Date: Thu, 7 Jul 2011 18:03:47 +0200

I agree and I feel the issue is sufficiently resolved. 

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af David
Wilson
Sendt: 7. juli 2011 11:02
Til: [email-masked]
Cc: PKIX; SG17-Q11
Emne: [Spam] Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of
certificates

David

---

From: Stephen Kent <[email-masked]>
Date: Thu, 7 Jul 2011 13:16:45 -0400

Erik,

Thanks. I agree that the text you cited is unambiguous. It does seem to be
a slight change from what I remember of X.509, where presentation 
layer transformation of data was a motivation (in part) for DER 
encoding of
signed directory data. The notion of "send what you signed and verify
what was received" is simple, but it does not accommodate the possibility
of some "helpful" intermediate system altering what was sent (in a 
reversible fashion).

As other have noted, the assumption is that the signer did render the'
data into DER before hashing and signing. If we augment that assumption
with the notion that the signer also sent what it signed, then life is easy
for RPs.

I do not agree with PHB's suggestion to remove the DER encoding requirement.
We should observe that in some cases an RP will want to use some
of the fields extracted from a cert to match against ACLs (or their 
moral equivalent). It is easier to do this if the cert fields have 
been encoded in
a canonical fashion, because the RP can then compare against ACL data 
that is also DER-encoded.

Steve

---

From: "Kyle Hamilton" <[email-masked]>
Date: Thu, 7 Jul 2011 17:05:07 -0700 (Pacific Daylight Time)

> encoding of certs has no value for those applications.

Canonical encoding of certificates greatly reduces (but does not completely eliminate) the capacity for malicious actors to find hash collisions which will also be valid.

I suggest that either 5 or 3 is appropriate, 1 is already existing practice, and 4 and 2 are unacceptable.  1 causes me to wonder, "doesn't anyone care about CPU cycles and/or memory requirements?"  My order of preference would be (from the options proposed by this OP and Erik Andersen) 5, 3.

5) Do nothing
4) remove DER mandate completely
3) Mandate DER (AFAICT, already the case)
2) Remove DER mandate from 6.1 of X.509 (undesirable for the same reason that 4 is)
1) Mandate decoding/re-encoding (already the case for conversion between different encoding rules)

Please, stop overthinking it.

As for XER and its inability to produce a canonical encoding given the dual names, I suggest accepting and transmitting either.  ITU messed it up, and we now have to live with the consequences.  Since there are two possible canonical encodings, it still mitigates the hash-collision possibility issue, albeit with twice the potential collision capacity.

(This is, of course, unless everyone WANTS to do away with the Certificate definition, which would leave everyone who supports legacy systems -- that is, most of us -- out in the cold.)

-Kyle H

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 08 Jul 2011 16:19:29 +1200

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

>[...]

+1 throughout. Saved me having to type up the same thing.

(I would prefer to keep the DER requirement though because certs can already
get garbled enough without telling developers that they don't even have to
make an effort).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 08 Jul 2011 16:33:55 +1200

David Wilson <[email-masked]> writes:

>"When checking signatures in received data, [the Directory] shall check the
>signature against the actual data received rather than its conversion of the
>received data to a distinguished encoding."

Just to be pedantic, I guess I should point out that since X.509 seems to be
written in terms of some fantasy entity called The Directory, it doesn't apply
to anything that actually exists.  Applying a strict interpretation, nothing
is actually bound by X.509 in this case.

Peter.

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 08 Jul 2011 06:59:07 +0200

Why should PKIX bother with a document that isn't normative for
PKI anymore?

For a PKIX-version of this topic I would make a difference between
"certificate producers" that indeed SHOULD/MUST generate DER
encoding while "certificate consumers" SHOULD NOT break due to
incorrect decoding.  Certificate consumers in browsers are already
dealing with pretty broken certificates.

--anders

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 8 Jul 2011 10:32:34 +0200

So far, we have no plans within ITU-T to suggest XER encoding of
certificates. This would certainly require a lot of considerations.

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: Kyle Hamilton [mailto:[email-masked]] 
Sendt: 8. juli 2011 02:05
Til: Phillip Hallam-Baker
Cc: Erik Andersen; [email-masked]; SG17-Q11; PKIX
Emne: [Spam] Re: [pkix] [Spam] Re: [x500standard] DER encoding of
certificates

> encoding of certs has no value for those applications.

Canonical encoding of certificates greatly reduces (but does not completely
eliminate) the capacity for malicious actors to find hash collisions which
will also be valid.

I suggest that either 5 or 3 is appropriate, 1 is already existing practice,
and 4 and 2 are unacceptable.  1 causes me to wonder, "doesn't anyone care
about CPU cycles and/or memory requirements?"  My order of preference would
be (from the options proposed by this OP and Erik Andersen) 5, 3.

5) Do nothing
4) remove DER mandate completely
3) Mandate DER (AFAICT, already the case)
2) Remove DER mandate from 6.1 of X.509 (undesirable for the same reason
that 4 is)
1) Mandate decoding/re-encoding (already the case for conversion between
different encoding rules)

As for XER and its inability to produce a canonical encoding given the dual
names, I suggest accepting and transmitting either.  ITU messed it up, and
we now have to live with the consequences.  Since there are two possible
canonical encodings, it still mitigates the hash-collision possibility
issue, albeit with twice the potential collision capacity.

(This is, of course, unless everyone WANTS to do away with the Certificate
definition, which would leave everyone who supports legacy systems -- that
is, most of us -- out in the cold.)

-Kyle H

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 8 Jul 2011 10:49:00 +0200

I know that X.509 has a life outside directories and that X.509 in some
places makes unnecessary references to Directory.

Directory is not a fantasy. There many thousands or maybe millions of
Microsoft Active Directories spinning every day. A lot of other LDAP systems
are out there. All Identity Management System have a directory, mostly LDAP,
as a major component.

X.500 is also very much alive and kicking.  

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af Peter
Gutmann
Sendt: 8. juli 2011 06:34
Til: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Emne: Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of certificates

>signature against the actual data received rather than its conversion of
the

Just to be pedantic, I guess I should point out that since X.509 seems to be
written in terms of some fantasy entity called The Directory, it doesn't
apply
to anything that actually exists.  Applying a strict interpretation, nothing
is actually bound by X.509 in this case.

Peter.

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 8 Jul 2011 10:56:42 +0200

You should bother as X.509 is the recommendation most downloaded of all
ITU-T Recommendations and is an important PKI/PMI player. When updating
X.509 it is important to consult also the PKIX experts.

Erik Andersen
Andersen's L-Service
Elsevej 48,
DK-3500 Vaerloese
Denmark
Mobile: +45 2097 1490
e-amail: [email-masked]
Skype: andersen-erik
http://www.x500.eu/

-----Oprindelig meddelelse-----
Fra: [email-masked] [mailto:[email-masked]] På vegne af Anders
Rundgren
Sendt: 8. juli 2011 06:59
Til: [email-masked]; [email-masked]; [email-masked]
Emne: [Spam] Re: [pkix] [x500standard] SV: [Spam] Re: DER encoding of
certificates

--anders