"Leichter, Jerry" <[EMAIL PROTECTED]> writes: >| 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. 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. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
