Subject: Re: [pkix] Signature Verification and DER requirements

From: Peter Gutmann <[email-masked]>
Date: Thu, 14 May 2015 17:57:35 +0000

Jeffrey Walton <[email-masked]> writes:

>What is the expected behavior when complying software that expects DER
>consumes a non-DER encoded certificate during signature verification? 

The expected behaviour is random, some will accept it, some will reject it.
When I say "random" I mean it really is a coin-toss, you should be OK with not
sorting the attributes in a SET OF, but there are implementations out there
that check for it and will complain about it.  My code sorts (in order to deal
with said implementations), but doesn't check for sortedness when processing
things.

Peter.

---

From: "Erik Andersen" <[email-masked]>
Date: Fri, 15 May 2015 16:12:32 +0200

As Peter states. It is confusing, and I am not sure how to get it right.

RFC 5280 in 4.1 say: For signature calculation, the data that is to be
signed is encoded using the ASN.1 distinguished encoding rules (DER). This
sentence could be read that the certificate when transmitted does not have
to be DER encoded.

Both RFC 5280 and X.509 requires an extension, which is encapsulated in  an
octet string, to be DER encoded.

We tried to make the DER encoding mandatory in a technical corrigendum, but
we got a ballot comment from Japan saying:

"The proposed change will break the backward
compatibility.
In the current (from the first to the seventh)
edition, the TBSCertificate data type may be
encoded using the BER, if it is temporally
encoded using the DER during the HASH and the
ENCRYPTED-HASH calculation.
The mandate of DER encoding will exclude such
certificates."

The Japene comment suggested the following text:

"It shall be encoded using the BER or the DER,
though the DER encoding is required when the
validation of SIGNED type is performed. It is
(strongly) recommended to use the DER at all
times, if no attention to the backward compatibility
with the earlier editions of this specification is
necessary."

Since 1997 the following has been included in X.509.

"Generating distinguished encoding requires the abstract syntax of the data
to be encoded to be fully understood. An entity may be required to sign data
or check the signature of data that is already signed or contains unknown
protocol extensions or unknown attribute syntaxes. The entity 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."

This text seems to assume that a certificate shall always be DER encoded

I am interested in comments.

Kind regards,

Erik

-----Oprindelig meddelelse-----
Fra: pkix [mailto:[email-masked]] På vegne af Peter Gutmann
Sendt: 14 May 2015 19:58
Til: IETF PKIX
Emne: Re: [pkix] Signature Verification and DER requirements

The expected behaviour is random, some will accept it, some will reject it.
When I say "random" I mean it really is a coin-toss, you should be OK with
not sorting the attributes in a SET OF, but there are implementations out
there that check for it and will complain about it.  My code sorts (in order
to deal with said implementations), but doesn't check for sortedness when
processing things.

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

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 May 2015 15:28:52 +0100

> I am interested in comments.

Loooong ago there used be a few circumstances in which people
unwisely BER encoded certificates. The only one I can recall
that approached not being plain silly was X.400 security where
there might be giant ASN.1 things to send around that required
indefinite length encoding. Streaming video was I think the
example people used to justify that, not that I recall anyone
actually sending secure X.400 mails like that.

In such a case your code might be presented with a BER encoding
of a certificate (in the envelope) and have to reconstruct the
DER encoding. I'd say it was a dumb idea even then but I think
we ran into it. IIRC most other cases were really bugs, where
people used the wrong inputs to ASN.1 encoders because they
didn't know better or were lazy.

I would guess/hope all such code is long gone now though.

S.

---

From: [email-masked] (Martin Rex)
Date: Fri, 15 May 2015 20:32:08 +0200 (CEST)

Stephen Farrell wrote:
> unwisely BER encoded certificates.
>
>  [...]
> 

One of the (allegedly) popular public CAs (for TLS webserver certs)
seemed to be issuing non-ASN.1-DER certificate about a year ago.

http://www.ietf.org/mail-archive/web/tls/current/msg11845.html

But the more confusing issue about X.509 is that they managed
to screw up the definition of X.509v2 CRLs (with the
specified semantics for the optional TBSCertList version field),
that there exist two _different_ canonical ASN.1 DER encodings.

-Martin

---

From: Jeffrey Walton <[email-masked]>
Date: Fri, 15 May 2015 15:40:06 -0400

On Fri, May 15, 2015 at 10:12 AM, Erik Andersen <[email-masked]> wrote:
> ...
Maybe the easiest course is to side-step the issue altogether. The
issue here is verification, so focus on it.

Leave things the way they are related to encoding the certificate and
signing the certificate (or more correctly, tbsCertificate).

Then be explicit about how to verify it. That is, explicitly state
bits should be verified as they are received; and they should not be
rearranged to comply with anything because that will usually (always?)
invalidate the signature.

Allowing the bits to be rearranged during verification just seems
wrong. It effectively creates a potential for a DoS when there's no
need for one to exist. The security goals were met earlier, when the
identity was bound to the public key.

I also think you should give an implementation a choice during
verification: they can choose to reject a non-DER encoded certificate
because that's how things are written. But they should reject for the
proper reason: reject because its no-DER encoded; and not becuase they
re-arranged bits that caused a signature failure.

Allowing a receiver to rearrange bits and then claim the signature
verification failed is just plain wrong. They may as well have
performed 'certificate[0] XOR 0x01' and claimed the certificate was
tampered. There's no difference.

Jeff

---

From: Santosh Chokhani <[email-masked]>
Date: Fri, 15 May 2015 20:45:29 +0000

+1

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Jeffrey Walton
Sent: Friday, May 15, 2015 3:40 PM
To: Erik Andersen
Cc: IETF PKIX
Subject: Re: [pkix] Signature Verification and DER requirements

> I am interested in comments.
Maybe the easiest course is to side-step the issue altogether. The issue here is verification, so focus on it.

Leave things the way they are related to encoding the certificate and signing the certificate (or more correctly, tbsCertificate).

Then be explicit about how to verify it. That is, explicitly state bits should be verified as they are received; and they should not be rearranged to comply with anything because that will usually (always?) invalidate the signature.

Allowing the bits to be rearranged during verification just seems wrong. It effectively creates a potential for a DoS when there's no need for one to exist. The security goals were met earlier, when the identity was bound to the public key.

I also think you should give an implementation a choice during
verification: they can choose to reject a non-DER encoded certificate because that's how things are written. But they should reject for the proper reason: reject because its no-DER encoded; and not becuase they re-arranged bits that caused a signature failure.

Allowing a receiver to rearrange bits and then claim the signature verification failed is just plain wrong. They may as well have performed 'certificate[0] XOR 0x01' and claimed the certificate was tampered. There's no difference.

Jeff

---

From: "Erik Andersen" <[email-masked]>
Date: Sat, 16 May 2015 09:15:55 +0200

It appears for me that the Japanese comment should be rejected. I will bring
that up on our own list, as that is the decision making list for X.509.

The Japanese comment implies (as I read it), as you do not whether a
received cert is DER or non-DER encoded, you need to decode it and encode it
in DER before checking the signature. In a constrained environment this
seems an unnecessary burden to put on an RP.

Jeff write that you could reject a cert because it is non-DER encoded. How
do detect that without analysing the cert in details. If you do minimum
processing, you will just discover the signature validation failed.

I brought the issue up on this list due to the level of expertise on this
list and because a thread was going on this issue.

Kind regards,

Erik

-----Oprindelig meddelelse-----
Fra: Santosh Chokhani [mailto:[email-masked]] 
Sendt: 15 May 2015 22:45
Til: [email-masked]; Erik Andersen
Cc: IETF PKIX
Emne: RE: [pkix] Signature Verification and DER requirements

+1

-----Original Message-----
From: pkix [mailto:[email-masked]] On Behalf Of Jeffrey Walton
Sent: Friday, May 15, 2015 3:40 PM
To: Erik Andersen
Cc: IETF PKIX
Subject: Re: [pkix] Signature Verification and DER requirements

> I am interested in comments.
Maybe the easiest course is to side-step the issue altogether. The issue
here is verification, so focus on it.

Then be explicit about how to verify it. That is, explicitly state bits
should be verified as they are received; and they should not be rearranged
to comply with anything because that will usually (always?) invalidate the
signature.

Allowing the bits to be rearranged during verification just seems wrong. It
effectively creates a potential for a DoS when there's no need for one to
exist. The security goals were met earlier, when the identity was bound to
the public key.

I also think you should give an implementation a choice during
verification: they can choose to reject a non-DER encoded certificate
because that's how things are written. But they should reject for the proper
reason: reject because its no-DER encoded; and not becuase they re-arranged
bits that caused a signature failure.

Allowing a receiver to rearrange bits and then claim the signature
verification failed is just plain wrong. They may as well have performed
'certificate[0] XOR 0x01' and claimed the certificate was tampered. There's
no difference.

Jeff

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 18 May 2015 12:48:30 -0400

Hi Erik,

> processing, you will just discover the signature validation failed.

If I was implementing this, here's how I would approach it:

  (1) verify the signature on the certificate without "deeply" parsing
the certificate.
  (2) accept BER/CER/DER because they are just presentation formats

I can get away with (1) because I already know the signer and the
signer's key. I don't use the browser/internet security model, and I
don't need to go rummaging around for signers and keys.

Many others can get away without rummaging for signers and keys, too.
A well configured server sends the certificates required for a chain
in a particular order. They do that to avoid the "which directory"
problem. So the answers are often at your fingertips without the need
to go hunting for signers and keys.

For (2), BER/CER/DER is just a presentation format. It adds nothing to
the security goals, and it takes nothing away from the security goals.
The best I can tell, its useless criteria because it has 0 impact on
security.

For what its worth, I would reject an end-entity certificate if a
server did *not* send the proper chain. We often need the chain to
avoid the "which directory" and the "deep parsing" problems. To me,
that's a valid reason to reject because it affects our ability to
verify a signature, which is completely security related.

Jeff