On 19/07/11 9:15 PM, "Randy Bush" <ra...@psg.com> wrote: >> I think there is an easier way, as already suggested. Add the object >> type to the manifest in FileandHash. >> >> 1) the rescert points to the publication point and manifest >> 2) the manifest is mandatory >> 3) the manifest is signed >> 4) the manifest is nicely(?) readable ASN.1 > > so move the deck chairs from coding the type in a directory maintained > by the operating system to one the spec and the programmers write and > maintain? big win there, eh?
The win is to eliminate a threat that has already been identified on the list. Is that not worthwhile? Perhaps consider it from a view of security requirement, than coding ease. > >> Really its a much nicer and more robust solution than either throwing the >> entire structure out or using filename extensions to 'mandate' file/object >> content. > > we've a long tradition of using the file name extensions, formalities > for registering them, ... do we really need to reinvent the wheel? > where is the win? > In the case of a repository system that may over time represent some worth, and looking at this from a point of eventually operating such a repository high up in the tree I have a concern of injecting 2 more paragraphs of text into a organisational risk analysis that could raise eyebrows given a simple solution to an identified threat has been proposed. I can tell now I'll be answering "What the!?!" type questions from people with significantly more influence than I for weeks, if not months. :( >>> i suspect no one else wants to go there, at least no one with code in >>> the game. >> Really... that is a shame. I always thought that coders wanted to make >> their code less susceptible to adverse external influence. > > luckily for me, i do not have to think. they already supported the move > from bcp to ps on this very list. And I can only hope they rethink their position. > > for this to be changed now is not impossible. it just needs some really > solid reasoning and really solid documentation of how and why it should > be changed. > So both Steve and Rob identified that mapping is required to remove a mini DoS threat (and I'm fine with that). Geoff and I have the belief that a mapping based on the extension exposes a CA/Repository related threat given the objects are supposed to be secure in nature. 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. What other documentation are you looking for? If it helps, I can also propose the ASN.1 substitution for the manifest and the necessary paragraph for the IANA considerations section. Cheers Terry _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
