<div dir="ltr"><br>
<div class="gmail-moz-cite-prefix">On 03/04/2017 07:25 AM, Peter Bowen via Public wrote:</div><div class="gmail-moz-cite-prefix">> 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.</div><div class="gmail-moz-cite-prefix"><br></div>
If you look at <a href="https://www.itu.int/rec/T-REC-X.509-198811-S">X.509 (11/1988)</a> the text does exist, but references X.209 instead of X.690, presumably because the first X.690 specification wasn't published until <a href="https://www.itu.int/rec/T-REC-X.690-199407-S/en">six years later in 1994</a>.<br>
<br>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<br>
<br>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.<div><br></div><div>> 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.</div><div><br>
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."<br>
<br>
<br>
<table dir="ltr" style="table-layout:fixed;font-size:13px;font-family:arial,sans,sans-serif;border-collapse:collapse;border:none" border="1" cellpadding="0" cellspacing="0">
<colgroup><col width="421"><col width="315"></colgroup><tbody><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom">X.509</td><td style="padding:2px 3px;vertical-align:bottom">X.690</td></tr><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom">a) the definite form of length encoding shall be used, encoded in the minimum number of octets;</td><td style="padding:2px 3px;vertical-align:bottom">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).]</td></tr><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom">b) for string types, the constructed form of encoding shall not be used;</td><td style="padding:2px 3px;vertical-align:bottom">10.2 String encoding forms<br>For bitstring, octetstring and restricted character string types, the constructed form of encoding shall not be used.<br>(Contrast with 8.21.6.) </td></tr><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom">c) if the value of a type is its default value, it shall be absent;</td><td style="padding:2px 3px;vertical-align:bottom">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.</td></tr><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom">d) the components of a Set type shall be encoded in ascending order of their tag value;</td><td style="padding:2px 3px;vertical-align:bottom">10.3 Set components<br>The encodings of the component values of a set value shall appear in an order determined by their tags as specified<br>in 8.6 of ITU-T Rec. X.680 | ISO/IEC 8824-1. </td></tr><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom">e) the components of a Set-of type shall be encoded in ascending order of their octet value;</td><td style="padding:2px 3px;vertical-align:bottom">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.</td></tr><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom">f) if the value of a Boolean type is TRUE, the encoding shall have its contents octet set to "FF";</td><td style="padding:2px 3px;vertical-align:bottom">11.1 Boolean values<br>If the encoding represents the boolean value TRUE, its single contents octet shall have all eight bits set to one. (Contrast<br>with 8.2.2.) </td></tr><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom">g) each unused bit in the final octet of the encoding of a Bit String value, if there are any, shall be set to<br>zero; </td><td style="padding:2px 3px;vertical-align:bottom">11.2 Unused bits<br>11.2.1 Each unused bit in the final octet of the encoding of a bit string value shall be set to zero. </td></tr><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom">h) the encoding of a Real type shall be such that bases 8, 10 and 16 shall not be used, and the binary scaling<br>factor shall be zero; </td><td style="padding:2px 3px;vertical-align:bottom">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.</td></tr><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom">i) the encoding of a UTC time shall be as specified in Rec. ITU-T X.690 | ISO/IEC 8825-1; </td><td style="padding:2px 3px;vertical-align:bottom">direct reference 11.8 UTCTime </td></tr><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom">j) the encoding of a Generalized time shall be as specified in Rec. ITU-T X.690 | ISO/IEC 8825-1.</td><td style="padding:2px 3px;vertical-align:bottom">direct reference to 11.7 GeneralizedTime </td></tr><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom"><br>
</td><td style="padding:2px 3px;vertical-align:bottom"><br>
</td></tr><tr style="height:21px"><td style="padding:2px 3px;vertical-align:bottom"><br>
  <br>
  <br>
</td><td style="padding:2px 3px;vertical-align:bottom">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.</td></tr></tbody></table><br></div></div>