Skip to main content

Appendix B. DER Expectations

This appendix is informative. Consult the respective standards for the normative rules.

DER is a restricted profile of BER [X.690]; thus, all DER encodings of data values are BER encodings, but just one of the BER encodings is the DER encoding for a data value. Canonical encoding matters when performing cryptographic operations; additionally, canonical encoding has certain efficiency advantages for parsers. There are three principal reasons to encode with DER:

  1. A digital signature is (supposed to be) computed over the DER encoding of the semantic content, so providing anything other than the DER encoding is senseless. (In practice, an implementer might choose to have an implementation parse and digest the data as is, but this practice amounts to guesswork.)

  2. In practice, cryptographic hashes are computed over the DER encoding for identification.

  3. In practice, the content is small. DER always encodes data values in definite-length form (where the length is stated at the beginning of the encoding); thus, a parser can anticipate memory or resource usage up front.

Figure 20 matches the structures in this document with the particular reasons for DER encoding:

Sec.LabelReasons
5CERTIFICATE1 2 ~3
6X509 CRL1
7CERTIFICATE REQUEST1 ~3
8PKCS7*
9CMS*
10PRIVATE KEY3
11ENCRYPTED PRIVATE KEY3
12ATTRIBUTE CERTIFICATE1 ~3
13PUBLIC KEY2 3

Figure 20: Guide for DER Encoding

  • Cryptographic Message Syntax is designed for content of any length; indefinite-length encoding enables one-pass processing (streaming) when generating the encoding. Only certain parts -- namely, signed and authenticated attributes -- need to be DER encoded.

~ Although not always "small", these encoded structures should not be particularly "large" (e.g., more than 16 kilobytes). The parser ought to be informed of large things up front in any event; this is yet another reason to DER encode these things in the first place.