Re: X509SerialNumber schema

Given that there are a number of interoperable implementations and
none of the implementors seem to want to change, the specification
should stay the same but I do have some responses to your comments.

From:  Thomas Maslen <maslen@dstc.edu.au>
Message-Id:  <200103161024.f2GAOMJ21749@piglet.dstc.edu.au>
To:  "Donald E. Eastlake 3rd" <dee3@torque.pothole.com>
cc:  w3c-ietf-xmldsig@w3.org
In-reply-to:  Your message of "Wed, 14 Mar 2001 14:52:12 EST."
	                  <200103141952.OAA0000035578@torque.pothole.com> 
Date:  Fri, 16 Mar 2001 20:24:57 +1000

>> X.509v3 defines CertificateSerialNumber as INTEGER.  
>
>Right.
>
>A number (no pun intended) of other ASN.1 INTEGER values from X.509 are also 
>mapped into xmldsig constructs, including:
>
>    6.4.1:  DSAKeyValue P, Q, G, Y, J, Seed and PgenCounter are all Base64
>
>    6.4.2:  PKCS#1 SignatureValue.
>
>    6.4.2:  RSAKeyValue Modulus and Exponent are both Base64

While these values can appear in an X.509 certificate, their occurance
in XML DSIG is not in any way tied to ASN.1 or X.509 certificates.
They can appear in XML DSIG entirely in the absence of any X.509
certificates anywhere in the system using XML DSIG.  So I don't see
why they would be constrained by type declaration in the X.509 ASN.1.
On the other hand, X509SerialNumber always referes to an X.509
Certificate so it seems to make more sense to look at its X.509 ASN.1
type.

>Section 6.4.2 also contains a paragraph that reads:
>
>        Arbitrary-length integers (e.g. "bignums" such as RSA modulii) are 
>        represented in XML as octet strings.  The integer value is first 
>        converted to a "big endian" bitstring. The bitstring is then padded 
>        with leading zero bits so that the total number of bits == 0 mod 8 
>        (so that there are an even number of bytes). If the bitstring 
>        contains entire leading bytes that are zero, these are removed (so 
>        the high-order byte is always non-zero). This octet string is then 
>        base64 [MIME] encoded. (The conversion from integer to octet string
>        is equivalent to IEEE 1363's I2OSP [1363] with minimal length).
>
>Given this, encoding the X509SerialNumber element as an xml-schema integer 
>seems pretty inconsistent with the rest of the xmldsig spec.
>
>> But it isn't our fault that instead of just numbering their certificates 
>> 1, 2, 3, ... as was presumably the original concept, some CA's seem to want 
>> to encode lots of private extension information and the kitchen sink into 
>> this field or use a hash or whatever.
>
>We may not like it, but for better or worse it is an arbitrary-length integer
>and has to be treated as one.
>
>> We need feedback from implementors.
>
>An xmldsig implementation already needs code to handle Base64 (simple);
>requiring (more complex) bignum-to-decimal and decimal-to-bignum code as well,
>just to make small-integer certificate serial numbers look nice in the XML,
>would be unfortunate.  Not a big deal on a desktop machine, where code bloat
>is the order of the day, but possibly the last straw for trying to make 
>xmldsig useful on a PDA.

Well, the deciding factor is whether existing implementations want to
change but the complexity just seems insignificant to me compared with
the XML parsing, ASN.1 parsing, crypto crunching, etc.  (By the way, I
have architected are written about a third of a full SET
implementation so I think I have some idea what I'm talking about.)

>By the way, is that paragraph from section 6.4.2 intended to apply to all 
>bignums, e.g. the DSA ones in section 6.4.1?
>
>Thomas Maslen
>DSTC

Donald
===================================================================
 Donald E. Eastlake 3rd                    dee3@torque.pothole.com
 155 Beaver Streeet                         lde008@dma.isg.mot.com
 Milford, MA 01757 USA     +1 508-634-2066(h)   +1 508-261-5434(w)

Received on Wednesday, 28 March 2001 09:50:03 UTC