On Jul 19, 2011, at 3:59 PM, Rob Austein wrote: > At Tue, 19 Jul 2011 05:51:50 -0700, Terry Manderson wrote: >> >> The win is to eliminate a threat that has already been identified on the >> list. > > What threat? Please describe it. > > The only "threat" I saw discussed is, in my opinion, a non-issue: an > attacker can mangle filenames in the unprotected data stream, thus > causing objects to fail validation. An attacker who can do that can > also mangle the objects themselves in the unprotected data stream, > which will also cause the objects to fail validation, so being able to > change the filenames doesn't give the attacker anything new. > >> The suggestion of adding the mapping/type into the Manifest (while >> awkward in ietf processing) gives both the mapping result, and >> removes the CA/Repository threat identified. > > The file types are already in the manifest, because the file types are > encoded in the filenames, which are in the manifest.
and to add to this: Objects may appear in the repository but not on the manifest (manifest doc 8.5). So having the type as a field in the manifest does not help. I am sorry if I am oversimplifying or missing the point but my impression is that: - some people don't like file extension mapping for reasons that are not technically convincing to me. - other people say that having them will actually make it much easier to solve problems between RPs and publishers. Like I said I am happy to have this mapping as a standard elsewhere if the repos-struct draft has other stuff in it preventing this from going to standards track. And if we can't have standard I suppose we will just trial-error-parse-it-all and say 'Can't understand your "object"', instead of something useful... Regards, Tim _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
