| >| I don't think it's a problem, you just take the ASN.1 DigestInfo | >| value, since the trailing garbage isn't part of the DigestInfo, you | >| ignore it. Specifically, the ASN.1 object is entirely | >| self-contained, so you can tell exactly where it ends and what it | >| contains. Anything outside it is beyond the scope of this | >| specification :-). | > | >This is a rather peculiar interpretation of the spec. If I look at a | >C specification and it tells me that an integer is a string of | >digits, when I write a C compiler, am I permitted to say that | >"[EMAIL PROTECTED]&%" can be parsed as an "entirely contained" integer, with the | >"@#&%" "beyond the scope of the specification"? | | No, because the compiler doesn't use a TLV encoding as ASN.1 does. | Take something like an MPEG, JPEG, MP3, or some other piece of data | that uses a TLV encoding with a clearly defined (by the data) end. | Cat some extra garbage onto the end of it, and try and view/play it. | If it's a proper TLV encoding (rather than a TV encoding, i.e. no | explicit length info included) then the decoder/player will ignore the | extra garbage at the end*. That's the whole point of TLV encodings, | you know a priori when to stop, and stop exactly at that point. I have to disagree. The spec describes an entire certificate, not one field inside of it. The issue isn't the TLV encoding of the DigestInfo - fine, that subfield ended. It's the next level in the hierarchy, the D data field I think it was called. TLV-encoded or not, it exists as a called-out entity, since it is what the signature is run over. And we are told that D consists of DigestInfo and a digest value. That's it; no extra bytes at the end. If this were at the end of the certificate, and the code *completely ignored* the random trailing junk - that is, it did *not* include it in the signature - then you might have an argument.
| Peter. | | * There are some that might keep reading in the hope that something | else crops up, I don't know, but the ones I've looked at don't care | if there's extra junk at the end. This goes back at least as far as | CP/M, where you could have extra ^Z's and other junk at the end of | files that apps had to avoid ploughing into. I would expect a file *player* that pretty much linearly scans a file, that's designed to be user-friendly, that runs in the standards-free zone of Windows software, and that doesn't deal with anything particularly critical, to have a "greedy algorithm" that just decodes as it goes along. Compare to Web browsers and their casual acceptance of all kinds of broken HTML. In both cases, I would expect a validator to be much stricter - and I would certainly expect a security-relevant piece of software, or even something like a compiler, to be strict. -- Jerry --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]