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

On Tue, 19 Jul 2011, Tim Bruijnzeels wrote:

>
> 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.

A process reminder here.  Several other documents point to the 
repos-struct draft, some of them specifically regarding the file 
extensions.  Separating out the tagging into a separate document could 
mean some serious review of multiple documents.

--Sandy, speaking as wg chair

>
> 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
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr
>