On 18/07/2011, at 9:42 AM, Terry Manderson wrote: > > > > On 18/07/11 12:53 AM, "Rob Austein" <[email protected]> wrote: > >> This draft defines the mappings from filename extension (.cer, .roa, >> .crl, etc) to ASN.1 object type (X.509 certificate, ROA, CRL, etc). >> >> Without this mapping, relying party tools have no way of knowing what >> they're looking at in most cases, and would have to attempt to decode >> every object in various ways to see which (if any) worked. This would >> be tedious, error prone, and generally a bad idea. >> > > 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.
I don't have an answer - it's a good question. > > (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. > > [1] Remember that the publication point is _just_ an rsync server (at this > stage). I personally feel uncomfortable on standardising a naming scheme from the dim dark prehistory of mainframe filesystems as an intrinsic part of the RPKI - it seems so retrograde! I thought a BCP represented a slightly softer approach, but your question about the manifest contents and type flagging in there is an interesting approach. At one stage there was the though that the manifest would be optional for a CA, but somewhere along the path I think they were made mandatory, but in the forest of SIDR drafts I have no idea which one says that manifests are REQUIRED. Geoff _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
