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
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
