On 07/08/2017 16:54, Peter Bowen wrote:
On Mon, Aug 7, 2017 at 12:53 AM, Franck Leroy via dev-security-policy
<dev-security-policy@lists.mozilla.org> wrote:
Hello

I checked only one but I think they are all the same.

The integer value of the serial number is 20 octets, but when encoded into DER 
a starting 00 may be necessary to mark the integer as a positive value :

    0 1606: SEQUENCE {
    4 1070:   SEQUENCE {
    8    3:     [0] {
   10    1:       INTEGER 2
          :       }
   13   21:     INTEGER
          :       00 A5 45 35 99 1C E2 8B 6D D9 BC 1E 94 48 CC 86
          :       7C 6B 59 9E B3

So the serialNumber (integer) value is 20 octets long but lenght can be more 
depending on the encoding representation.

Here is ASCII (common representation when stored into a database: 
"A54535991CE28B6DD9BC1E9448CC867C6B599EB3" it is 40 octets long, VARCHAR(40) is 
needed.

The text from 5280 says:

" CAs MUST force the serialNumber to be a non-negative integer, that
    is, the sign bit in the DER encoding of the INTEGER value MUST be
    zero.  This can be done by adding a leading (leftmost) `00'H octet if
    necessary.  This removes a potential ambiguity in mapping between a
    string of octets and an integer value.

    As noted in Section 4.1.2.2, serial numbers can be expected to
    contain long integers.  Certificate users MUST be able to handle
    serialNumber values up to 20 octets in length.  Conforming CAs MUST
    NOT use serialNumber values longer than 20 octets."

This makes it somewhat whether the `00'H octet is to be included in
the 20 octet limit or not. While I can see how one might view it
differently, I think the correct interpretation is to include the
leading `00'H octet in the count.  This is because
CertificateSerialNumber is defined as being an INTEGER, which means
"octet" is not applicable.  If it was defined as OCTET STRING, similar
to how KeyIdentifier is defined, then octet could be seen as applying
to the unencoded value.  However, given this is an INTEGER, the only
way to get octets is to encode and this requires the leading bit to be
zero for non-negative values.

That being said, I think that it is reasonable to add "DER encoding of
Serial must be 20 octets or less including any leading 00 octets" to
the list of ambiguities that CAs must fix by date X, rather than
something that requires revocation.


(Thinking in a multi-year future perspective):

Given the age of RFC5280 and the (suspicious) fact that 20 is also the
length of SHA-1 hashes, maybe there should be work in CAB/F and
implementations to actually raise this maximum (and one day perhaps the
minimum) to a larger value, such as 64 plus optional zero.

Doing so would allow future requirements to increase the minimum serial
entropy to more than 160 bits, should a relevant attack scenario emerge.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Jeremy Rowley via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Matt Palmer via dev-security-policy
              • ... Jakob Bohm via dev-security-policy
              • ... Matthew Hardeman via dev-security-policy
              • ... Peter Gutmann via dev-security-policy
              • ... Ryan Sleevi via dev-security-policy
              • ... Ryan Sleevi via dev-security-policy
      • Re: Certificates ... Jakob Bohm via dev-security-policy
      • Re: Certificates ... Ryan Sleevi via dev-security-policy
      • Re: Certificates ... Matthew Hardeman via dev-security-policy
  • Re: Certificates with inva... okaphone.elektronika--- via dev-security-policy

Reply via email to