On 08/10/2010, at 11:32 PM, Rob Austein wrote: > At Fri, 8 Oct 2010 23:03:19 +1100, Geoff Huston wrote: >> >> If I scrub the HTTPS constructs from the draft what I'm left with >> are "naked" CMS objects > > I would have thought we'd be left with CMS objects wrapped in HTTP, > replacing CMS objects wrapped in HTTPS. Strictly speaking, what we're > doing here is removing the TLS encapsulation of HTTP.
ok - I can do that > >> (and they look a lot like rpki-signed objects, but they are not >> signed by keys certified by rpki certificates so I guess that >> technically they are NOT spki-signed-objects). > > Different CMS eContentType OIDs too: > > 1.2.840.113549.1.9.16.1.24 id-ct-routeOriginAttestation > 1.2.840.113549.1.9.16.1.26 id-ct-rpkiManifest > 1.2.840.113549.1.9.16.1.28 id-ct-xml that too! I assume that in addition to the CMS requirement that: "The signing-time attribute MUST be present" there is an additional requirement that reads (approximately) "Each party MUST ensure that the signing-time attribute value is strictly greater than the signing-time attribute value of the previous message sent to the same recipient. Messages received with a signing-time value less than that of the most recently received and accepted message from the same sender MUST be rejected." I'm also pretty sure that this text is inadequate in various corner cases, and of there are suggestions on how to improve this skeletal text to allow he CMS signing-time attribute as a reasonable form of replay attack protection would be appreciated. thanks Geoff _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
