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

[Stephen Kent <[e-mail]>]

At 4:42 PM -0700 7/17/11, Terry Manderson wrote:
>...
>
>This actually makes me wonder why the manifest (
>draft-ietf-sidr-rpki-manifests) in:
>
>FileAndHash ::=     SEQUENCE {
>       file            IA5String,
>       hash            BIT STRING
>       }
>
>Doesn't have a RPKIObjectIdentifier that tells the relying party what the
>object it has just retrieved is in terms of ROA/CERT/etc, as a signed
>attestation.

the filename extension, which is part of the "file" data type above, 
conveys the needed info. yes, one could add an OID here, but 
ultimately an RP will check the syntax and know which file is what 
type. Som, adding an OID doesn't seem to help much in a manifest.

>(and then an appropriate IANA registry for RPKIObjectIdentifier could then
>be created and populated as a standards track)
>
>If repos-struct was standards track and the naming scheme was the prime
>mapping system then if a RPKI repository publication [1] point is
>compromised (or even MiTM!) it would be a trivial exercise to perform some
>substitutions on the filename to confuse (routing security downgrade DoS)
>the relying party.

if there are no mandated filename extensions, then every pub point is 
a mini-DoS attack, as Rob noted. We can't prevent a rogue pub point 
manager (or CA) from mislabelling files relative to the 3-char 
extension, but why invite chaos :-)?

An earlier draft of this doc called the extensions mere 
recommendations.  I persuaded Geoff to make them mandatory. The 
arguments I made then still
apply, which is why STD vs. BCP seems appropriate, to me.

Steve