Re: X509SerialNumber schema

I'm not an X509 expert (or even novice) but I can speak to the XML issues 
and the spec.

At 15:30 3/9/2001 -0500, Ken Goldman wrote:
>1
>
>The DSIG schema says it's type is integer. In XML Schema, an integer
>is a base 10 number, using the characters 0-9.  Is this right?

Basically, yes. Though it could include (+,-) as well.

http://www.w3.org/TR/2000/CR-xmlschema-2-20001024/#integer
3.3.11 integer
[Definition:] integer is derived from decimal by fixing the value of scale 
to be 0. This results in the standard mathematical concept of the integer 
numbers. The value space of integer is the infinite set 
{...,-2,-1,0,1,2,...}. The base type of integer is decimal.
3.3.11.1 Lexical representation
integer has a lexical representation consisting of a finite-length sequence 
of decimal digits (#x30-#x39) with an optional leading sign. If the sign is 
omitted, "+" is assumed. For example: -1, 0, 12678967543233, +100000.
3.3.11.2 Canonical representation
The canonical representation for integer is defined by prohibiting certain 
options from the Lexical representation (§3.3.11.1). Specifically, the 
preceding optional "+" sign is prohibited and leading zeroes are prohibited.


>2
>
>Assuming that (1) is right - If I have an X509SerialNumber from a
>certificate that is a long string of bits (Tom Ginden mentioned back on
>July that some certificates use a hash value of 160 bits) doesn't the
>binary to decimal conversion become computationally painful.
>
>It would seem like this might be often required in verification to
>match the XML to the ASN.1 in the certificate.

The natural language part of xmldsig relies upon the [LDAP-DN] reference 
(RFC2253) to say what the content should be a string.

http://www.w3.org/Signature/Drafts/xmldsig-core/Overview.html#sec-X509Data
>The X509IssuerSerial element, which contains an X.509 issuer distinguished 
>name/serial number pair that SHOULD be compliant with RFC2253 [LDAP-DN],

RFC2253 is concerned with strings, not integer:
http://www.ietf.org/rfc/rfc2253.txt
>This specification defines the string format for representing names, which 
>is designed to give a clean representation of commonly used distinguished 
>names, while being able to represent any distinguished name.


>3
>
>Assuming that (1) is right - I recently received a document claiming to be
>signed using DSIG, which included the following XML fragment:
>
>         <X509SerialNumber>39F497CA</X509SerialNumber>
>
>Is this valid XML DSIG?  Was it valid at one time in the past?

It does not comply with the most recent schema definition of course. It does 
comply with the June version
        http://www.w3.org/TR/2000/WD-xmldsig-core-20000601/
which was then changed to type integery in the July version:
        http://www.w3.org/TR/2000/WD-xmldsig-core-20000711/

This change apparently happened because of discussion in Pittsburgh:
        http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0254.html


>4
>
>Assuming all of the above, why was integer chosen?  It would seem like
>binary, hex or base64 encoded, would be computationally easier when
>handling X509SerialNumber's with many bits.

I don't recall, perhaps Don or Tom could speak to this.


__
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

Received on Monday, 12 March 2001 14:45:20 UTC