Re: [sidr] draft-ietf-sidr-repos-struct to Standards Track

[Tim Bruijnzeels <[e-mail]>]

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