First, both NSS and OpenSSL are now using the same algorithm to compute fingerprints - on the entire certificate encoding, not the signed part.
I didn't require that :-)
I believe this also means you use the same alg as Microsoft CAPI which makes things simpler for everybody.
I was thinking more about having two different fingerprint based cert comparison algorithms for different usages, but maybe this is not adequate.
Second, certificates are supposed to be DER-encoded, which means Distinguished Encoding Rules, precisely so that there can only be one possible encoding for them.
The signed part of them should. The unsigned part is not required to.
In fact, openssl used to produce all certs with some BER elements in the unsigned part in the earlier versions (0.9.4).
And as many CA don't issue truly DER encoded certificate, every toolkit just has no choice but to support it. Cases similar to <http://www.imc.org/ietf-pkix/old-archive-01/msg00683.html> are just too frequent to have a choice but to adapt to it.
That message happens to show a sample case of the exact rules for DER bit string and pad bit encoding.
In the value BITS = "1100 0110 0", bit with order value 0, 1, 5 and 6 are set to one (this means big endian at the *bit* level), and the correct DER encoding is :
03 (BIT STRING) 02 (of length 2) 01 (with 1 pad bit) C6 (BITS as above)
The two last zero bits are not encoded, one is removed by shortening the length to one byte, and the other by setting 1 pad bit.
Inside our sample, the bit string ends with the value "fe", all bit are 1 except the last one.
This zero bit is the bit that is removed by setting the pad value to one.
Therefore, opposite to what I thought before watching in exact details, the version that has one unused bit set is the correct DER encoding version, and the one that does not set one unused bit, but instead includes it with a value of zero, is BER encoding and not DER encoding.
The decoded value of the signature is exactly the same in the two case, so it's normal that signature verification does not fail.
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
