On 18/07/11 11:29 AM, "Geoff Huston" <g...@apnic.net> wrote:
> On 18/07/2011, at 9:42 AM, 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.
>
>
> I don't have an answer - it's a good question.
>
Certainly one to consider, and touches more on my personal philosophical
point that while the 'directory and file' structure that is promulgated in
the RPKI work at this stage has utility, primarily based on 'what works now'
design choices - longer term I am far more comfortable in thinking toward an
object structure.
whereas now we see RSYNC://rpki.blah.org/something/xyzzy.roa one day in the
future when it is palatable to think along such lines something like
HTTPS://rpki.blah.org/something/subject?ROA might also validly exist.
<climbs down from soapbox>
>
> 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.
I believe draft-ietf-sidr-res-certs section 4.8.8.1.
"This extension MUST have an instance of an AccessDescription with an
accessMethod of id-ad-rpkiManifest"
Terry
_______________________________________________
sidr mailing list
sidr@ietf.org
https://www.ietf.org/mailman/listinfo/sidr
