Re: ds:CryptoBinary vs. base64Binary

     I have some comments on this, although I agree with your conclusions.
You can assume that any DER-encoded value imported will not start with a
zero byte.
     We need more detail on the SKI, since its example in 4.4.4 is no real
help because it looks like the hex representation of a 32-bit integer
rather than anything else - it may be legal base 64 but it would be
atypical at best.  If it is the base 64 representation of the unwrapped
value of the SKI extension, we should say so and give an example that
represents it.  If it represents the wrapped value, we should do the same.

          Tom Gindin


"Brian LaMacchia" <bal@microsoft.com>@w3.org on 04/14/2001 07:12:09 PM

Sent by:  w3c-ietf-xmldsig-request@w3.org


To:   "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
cc:   "Joseph M. Reagle Jr." <reagle@w3.org>
Subject:  ds:CryptoBinary vs. base64Binary


Folks,

After we decided to keep CryptoBinary around, Joseph asked me to take a
look at all the elements that are currently specified as CryptoBinary
and determine whether they really should be.  Currently, we've denoted
each of the following elements as CryptoBinary:

SignatureValue
DigestValue

X509Data/X509SKI
X509Data/X509Certificate
X509Data/X509CRL

PGPKeyData/PGPKeyPacket

SPKIData/SPKISexp

RSAKeyValue/Modulus
RSAKeyValue/Exponent

DSAKeyValue/P
DSAKeyValue/Q
DSAKeyValue/G
DSAKeyValue/Y
DSAKeyValue/J
DSAKeyValue/Seed
DSAKeyValue/PgenCounter

However, I believe that the only ones that we can guarantee should
always be CryptoBinary are the RSAKeyValue and DSAKeyValue ones.  The
rest should be converted back to base64Binary.  This is because
CryptoBinary implies that the encoded quantity is a bignum and cannot
have leading zero bytes, and this isn't true for the other types:

1) SPKISexp, PGPKeyPacket, X509Certificate and X509CRL are binary
structures, not bignums, so they should never be typed as
CryptoBinaries, even though we could probably prove that no encoding of
these types could ever have leading zeros and thus would be valid.

2) X509SKI also needs to be base64Binary because in PKIX Part 1 it is
specified simply as an OCTET STRING, not an INTEGER, and thus could have
leading zero bytes (in fact, this would occur on average 1/256th of the
time if method (1) of PKIX Part 1 Section 4.2.1.2 was used to generate
the value).

3) DigestValue, being the hash value of a transformed reference, will
also have a leading zero byte on average 1/256th of the time if the hash
value is uniform.

4) SignatureValue's format depends on the signature algorithm being
used.  If the signature algorithm is RSA or DSA then SignatureValue
represents a bignum and could be CryptoBinary.  However, if HMAC-SHA1 is
used then SignatureValue is the output of a hash function and could have
leading zero bytes.  Thus SignatureValue also needs to be just
base64Binary.

So, I propose that we change the schema types back for everything except
the RSAKeyValue and DSAKeyValue components.

                                                    --bal

Received on Sunday, 15 April 2001 15:10:56 UTC