Matthew Hardeman via dev-security-policy <[email protected]> writes:
>I merely raise the point that IF the framers of the 20 bytes rule did, in >fact, simultaneously intend that arbitrary SHA-1 hash results should be able >to be stuffed into the serial number field AND SIMULTANEOUSLY that the DER >encoded integer field value must be a positive integer and that insertion of >a leading 0x00 byte to ensure that the high order bit would be 0 (thus >regarded as a positive value per the coding), THEN it must follow that at >least in the minds of those who engineered the rule, that the inserted 0x00 >byte must not be part of the 20 byte maximum size of the value AS legitimate >SHA-1 values of 20 bytes do include values where the high order bit would be >1 and without pre-padding the proper interpretation of such a value would be >as a negative integer. That sounds like sensible reasoning. So you need to accept at least 20 + 1 bytes, or better yet just set it to 32 or 64 bytes and be done with it because there are bound to be implementations out there that don't respect the 20-byte limit. At the very least though you'd need to be able to handle 20 + 1. Peter. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
