> 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 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. 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 DSTCReceived on Friday, 16 March 2001 05:25:14 GMT
This archive was generated by hypermail 2.2.0 + w3c-0.29 : Thursday, 13 January 2005 12:10:12 GMT