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

[Rob Austein <[e-mail]>]

At Mon, 18 Jul 2011 07:41:40 +1000, Geoff Huston wrote:
> On 18/07/2011, at 12:53 AM, Rob Austein wrote:
> 
> But wouldn't the CMS (and ASN.1 for that matter) effectively tell
> the RP what the object was intended to be?

As I said: "attempt to decode every object in various ways to see
which (if any) worked".  Not all objects are CMS.  The outermost
layers of ASN.1 on most of them are sequences of sequences of blah
blah blah.  Yes, if one peers at these things long enough it becomes
obvious what they are, assuming no encoding errors, but it's not like
there's a trivial tag in each one saying "this an X.509 certificate",
"this is a CMS object", or "this is a CRL".

> It strikes me that the file name extension is a bit of syntactic
> sugar rather than an essential and necessary component, so I'm
> curious to understand what has changed in this particular PKI that
> makes the filename extension such a necessary attribute.

Most PKIs aren't deep trees distributed over an arbitrarily large
number of distinct servers and directories, in most cases one knows
exactly what an object purports to be when one attempts to validate
it, and in most cases one is not attempting to validate tens of
thousands of objects at once.

> If this is the case would a rogue CA be able to mount an effective
> DOS attack for all RPs by deliberately mis-naming objects?

No.  The names are hints as to the intended decoding.  If the encoding
doesn't match the hint, the decode fails pretty quickly.  The
difference here is that the RP tries exactly one decode, and if that
doesn't work, the object is toast.

A MITM attack on rsync could of course whack the filenames, but it
could also corrupt the objects themselves, with pretty much the same
effect, so it's not a new threat.