Kathleen Wilson <[email protected]> writes:
>The encoding of the Issuer field in the CRL should be byte-for-byte
>equivalent with the encoding of the Issuer in the certificate; that is, using
>the exact same string types and field contents. The specs (RFC 2459, RFC 3280,
>RFC 5280) permit them to mismatch, but that causes compatibility issues with
>various clients -- in such cases client software might not find the entry for
>the revoked certificate in the CRL.
That's a specific case of the more general rule that there is only one
encoding mechanism and that is memcpy(), and by extension that there is only
one name/ID-comparison mechanism and that is memcmp() [0]. With a corollary
that anything that decides it's going to try and re-encode identifier fields
in a manner it considers more cromulent will quickly discover the universal
encoding mechanism.
So perhaps a better way to put it where you don't need to re-state it for
every case where it crops up is that a field or value, once encoded, should
never be re-encoded, but copied across byte-for-byte from wherever it's been
encoded to the destination location where it's used.
Peter.
[0] Anyone who wants to dispute this can go away and try and implement the
X.500 name comparison rules. Hint: These are impossible to implement
correctly, so I'm expecting a long wait...
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
