Exponent 3 damage spreads...

[Leichter, Jerry]

| >| 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
| >"123@#&%" 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 majordomo at metzdowd.com