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

[Terry Manderson <[e-mail]>]

On 19/07/11 9:15 PM, "Randy Bush" <[e-mail]> 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