W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > April to June 2001

ds:CryptoBinary vs. base64Binary

From: Brian LaMacchia <bal@microsoft.com>
Date: Sat, 14 Apr 2001 16:12:09 -0700
Message-ID: <BCDB2C3F59F5744EBE37C715D66E779CEAB659@red-msg-04.redmond.corp.microsoft.com>
To: "IETF/W3C XML-DSig WG" <w3c-ietf-xmldsig@w3.org>
Cc: "Joseph M. Reagle Jr." <reagle@w3.org>
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 Saturday, 14 April 2001 19:12:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:10:04 UTC