Subject: [pkix] Signature Verification and DER requirements

From: Jeffrey Walton <[email-masked]>
Date: Wed, 13 May 2015 17:24:35 -0400

RFC 5280, 4.1. Basic Certificate Fields, states:

    For signature calculation, the data that is to be
    signed is encoded using the ASN.1
    distinguished encoding rules (DER) [X.690].

One of the implications is attributes in a SET OF must be sorted and
provided in ascending order. Refer to X.690, 11.6 Set-of components.

RFC 6125 does not discuss how to verify the signature over
tbsCertifcate modulo the encoding requirement.

What is the expected behavior when complying software that expects DER
consumes a non-DER encoded certificate during signature verification?
Here, assume the attributes are *not* in ascending order per RFC 5280
and X.690.

Thanks in advance.

---

From: [email-masked] (Martin Rex)
Date: Wed, 13 May 2015 23:47:46 +0200 (CEST)

> Here, assume the attributes are *not* in ascending order per RFC 5280

The assumption is that the receiver performs the signature verification
on the data exactly _as_received_, and does not try to decode and
re-encode tbsCertificate before verifying the certificate signature.

This encoding requirement (from section 4.1 of rfc5280) applies to the
sender/creator of the tbsCertificate PDU.

There is an often missed recommendation in rfc5280, section 6.1, 3rd parag.:

  https://tools.ietf.org/html/rfc5280#section-6.1

   While the certificate and CRL profiles specified in Sections 4 and 5
   of this document specify values for certificate and CRL fields and
   extensions that are considered to be appropriate for the Internet
   PKI, the algorithm presented in this section is not limited to
   accepting certificates and CRLs that conform to these profiles.
   Therefore, the algorithm only includes checks to verify that the
   certification path is valid according to X.509 and does not include
   checks to verify that the certificates and CRLs conform to this
   profile.  While the algorithm could be extended to include checks for
*> conformance to the profiles in Sections 4 and 5, this profile
*> RECOMMENDS against including such checks.

i.e. rfc5280 RECOMMEDs against including checks that tbsCertificate
is properly ASN.1 DER encoded when verifying certificate (paths).

-Martin

---

From: Erwann Abalea <[email-masked]>
Date: Wed, 13 May 2015 23:53:29 +0200

Bonsoir,

> provided in ascending order. Refer to X.690, 11.6 Set-of components.

I'd be tempted to say "partly wrong". The tbsCertificate should be properly
DER-encoded for the signature to be applied to, but the outputted
(provided) tbsCertificate doesn't need to be DER-encoded.
But unfortunately, doing so isn't rare. And it would be unwise to force a
RP to re-encode a tbsCertificate before trying to verify the signature :/

> Here, assume the attributes are *not* in ascending order per RFC 5280

DER instead of BER isn't only about ordering SET elements, but it also
implies that DEFAULT values aren't encoded, that strings aren't
constructed, that dates are correctly Zulu-based (UTC) and precise up to
one second, that no indefinite length SEQUENCE/SET is used, and maybe other
things.

Strictly, a compliant RP is free to reject a signature that doesn't verify
the DER-reencoding of a tbsCertificate.

In the real world some CAs encode DEFAULT elements or have produced non
Zulu-based dates in certificates. Yet these certificate are still accepted.

-- 
Erwann.

---

From: Jeffrey Walton <[email-masked]>
Date: Wed, 13 May 2015 18:18:01 -0400

Thanks Martin.

> sender/creator of the tbsCertificate PDU.

That's kind of what I thought. But the use of "calculation" leaves it
a bit open ended, so its not clear whether it applies to the
creator/sender or the verifier/receiver:

    >> For signature calculation, the data that is to be signed..

The "to be signed" kind of implies its the creator/sender. But both
the sender and receiver both use the tbsCertifcate, so "to be signed"
is mildly vague too.

Maybe it would be a good idea to clarify it in RFC 5280 for future
readers? Or maybe clearly state it in RFC 6125?

Jeff

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 14 May 2015 10:23:28 +0200

> Here, assume the attributes are *not* in ascending order per RFC 5280

The only truly safe solution is creating certificates that have the right
attribute sorting order from the beginning.  The other option is go out
and test :-)  Actually, outside of AD there aren't that many certificates
(nowadays) having more than one attribute per RDN.

Anders

>
> Thanks in advance.
>
> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>

---

From: Bruce Stephens <[email-masked]>
Date: Thu, 14 May 2015 11:39:19 +0100

> readers? Or maybe clearly state it in RFC 6125?

I'd have thought that would be simplest.

There's been language in X.509 (section 6.4 in 10/2012) for a while
making it clear that the signers ought to encode using DER and send the
actual octets signed, and that verifiers ought to verify using the
octets they actually receive (rather than their own DER encoding of the
abstract value).

[...]