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

Reply via email to