Re: X509SerialNumber schema

> Date: Mon, 12 Mar 2001 14:43:57 -0500
> From: "Joseph M. Reagle Jr." <reagle@w3.org>
> 
> 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:
> 
> >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.
> [snip]

I don't think RFC2253 is relevant, as it talks about the distinguished
name, not the serial number.

> >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

I didn't see anything in that discussion. I found

	http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0029.html

which was a very brief "it's an integer in ASN.1, so we'll make it an
integer."  Tom Gindin mentioned the 160 bit serial number problem, but
the discussion died there.

It's true that it's an integer in ASN.1, but that integer is actually
an unbounded number of binary bits, not a XML decimal integer.  It's
the same word, but with an entirely different meaning.

David Solo mentioned CryptoBinary (binary - base64 encoded) as an alternative.
Either that or (binary - hex) encoded seem reasonable to me.  

Integer, with the difficult conversion from binary, doesn't seem as
good a choice.

Is there any possibility of revisiting this?

> >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.

-- 
Ken Goldman   kgold@watson.ibm.com   914-784-7646

Received on Monday, 12 March 2001 16:50:56 UTC