[cabfpub] Certificate encoding

Jacob Hoffman-Andrews jsha at letsencrypt.org
Sun Mar 12 01:14:17 UTC 2017


On 03/04/2017 07:25 AM, Peter Bowen via Public wrote:
> X.509 (10/2012) Section 6.3 (Distinguished encoding of Basic Encoding
Rules) says " In order to enable the validation of SIGNED and SIGNATURE
types in a distributed environment, a distinguished encoding is required. A
distinguished encoding of a SIGNED or SIGNATURE data value shall be
obtained by applying the Basic Encoding Rules defined in Rec. ITU-T X.690 |
ISO/IEC 8825-1, with the following restrictions[…]” This language has been
present since X.509 (11/1988). However RFC 5280 says the the Distinguished
Encoding Rules in X.690 (07/2002) must be used.

If you look at X.509 (11/1988)
<https://www.itu.int/rec/T-REC-X.509-198811-S> the text does exist, but
references X.209 instead of X.690, presumably because the first X.690
specification wasn't published until six years later in 1994
<https://www.itu.int/rec/T-REC-X.690-199407-S/en>.

X.509 (11/1988)> A distinguished encoding of a SIGNED or SIGNATURE data
value shall be obtained by applying the Basic Encoding Rules defined in
Recommendation X.209

My guess is that these rules were inlined into X.509 because X.209 didn't
have them, and X.690 didn't yet exist. Presumably they were never cleaned
up once X.690 was written. In terms of authorial intent, I'm pretty sure
"Distinguished encoding of Basic Encoding Rules" was what became formalized
in X.690 as DER. Probably the next revision of X.509 should rewrite section
6.3 to simply refer to X.690.

> While "Distinguished encoding of Basic Encoding Rules” and "Distinguished
Encoding Rules” sound very similar, they are not the same. I _think_ that
DER is a subset of DeoBER, but I’m not 100% sure.

I made a comparison table. They are almost identical, except DER is
slightly more permissive with encoding of Reals, and DER specifies a
restriction on GeneralString not present in X.509's "Distinguished encoding
of Basic Encoding Rules."


X.509 X.690
a) the definite form of length encoding shall be used, encoded in the
minimum number of octets; 10.1 Length forms The definite form of length
encoding shall be used, encoded in the minimum number of octets. [Contrast
with 8.1.3.2 b).]
b) for string types, the constructed form of encoding shall not be used; 10.2
String encoding forms
For bitstring, octetstring and restricted character string types, the
constructed form of encoding shall not be used.
(Contrast with 8.21.6.)
c) if the value of a type is its default value, it shall be absent; 11.5
Set and sequence components with default value The encoding of a set value
or sequence value shall not include an encoding for any component value
which is equal to its default value.
d) the components of a Set type shall be encoded in ascending order of
their tag value; 10.3 Set components
The encodings of the component values of a set value shall appear in an
order determined by their tags as specified
in 8.6 of ITU-T Rec. X.680 | ISO/IEC 8824-1.
e) the components of a Set-of type shall be encoded in ascending order of
their octet value; 11.6 Set-of components The encodings of the component
values of a set-of value shall appear in ascending order, the encodings
being compared as octet strings with the shorter components being padded at
their trailing end with 0-octets. NOTE – The padding octets are for
comparison purposes only and do not appear in the encodings.
f) if the value of a Boolean type is TRUE, the encoding shall have its
contents octet set to "FF"; 11.1 Boolean values
If the encoding represents the boolean value TRUE, its single contents
octet shall have all eight bits set to one. (Contrast
with 8.2.2.)
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; 11.2 Unused bits
11.2.1 Each unused bit in the final octet of the encoding of a bit string
value 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; 11.3.1 If the encoding represents a real value whose
base B is 2, then binary encoding employing base 2 shall be used. Before
encoding, the mantissa M and exponent E are chosen so that M is either 0 or
is odd. NOTE – This is necessary because the same real value can be
regarded as both {M, 2, E} and {M', 2, E'} with M ≠ M' if, for some
non-zero integer n: M' = M × 2–n E' = E + n In encoding the value, the
binary scaling factor F shall be zero, and M and E shall each be
represented in the fewest octets necessary.
i) the encoding of a UTC time shall be as specified in Rec. ITU-T X.690 |
ISO/IEC 8825-1; direct reference 11.8 UTCTime
j) the encoding of a Generalized time shall be as specified in Rec. ITU-T
X.690 | ISO/IEC 8825-1. direct reference to 11.7 GeneralizedTime





11.4 GeneralString values The encoding of values of the GeneralString type
(and all other restricted character string types defined by reference to
the International Register of Coded Character Sets) shall generate escape
sequences to designate and invoke a new register entry only when the
register entry for the character is not currently designated as the G0, G1,
G2, G3, C0, or C1 set. All designations and invocations shall be into the
smallest numbered G or C set for which there is an escape sequence defined
in the entry of the International Register of Coded Character Sets to be
used with Escape Sequences. NOTE 1 – For the purposes of the above clause,
G0 is the smallest numbered G set, followed by G1, G2, and G3 in order. C0
is the smallest numbered C set, followed by C1. NOTE 2 – Each character in
a character string value is associated with a particular entry in the
International Register of Coded Character Sets.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170311/6291d13f/attachment-0003.html>


More information about the Public mailing list