On 21/11/2009, at 8:51 AM, Stephen Kent wrote: > At 11:39 AM +1100 11/18/09, Geoff Huston wrote: >> WG co-chair hat OFF >> >> This is a posting made in my role as a document co-author, and not as a >> co-chair of the WG >> >> In reviewing the manifest document I notice that the document in its current >> version defines a manifest as an RPKI construct. I have two questions about >> this: >> >> 1. Should the manifest document be constrained in this manner as being >> exclusively an RPKI construct, or should the reference to exclusive use by >> the RPKI be removed such that the manifest is defined in a manner that is >> agnostic to the context of the PKI in which the manifest may be used, so >> that any CA may use a manifest? >> >> 2. In the context of the RPKI should the manifest document used a SHOULD to >> specify that the resources in the RPKI EE certificate used to validate the >> manifest's signature be specified using the inherit bit setting of the >> RFC3779 extensions? >> >> Do any of the document's co-authors, or any WG folk, have an opinion of >> either or both of these questions that they'd like to share? >> >> thanks, >> >> Geoff >> >> WG co-chair hat OFF > > I agree that the manifest structure is more general than the RPKI context. > > However, if we choose to make the manifest document generic, we probably need > another document that profiles it for the RPKI. > > Steve
WG co-chair hat OFF This is a posting made in my role as a document co-author, and not as a co-chair of the WG. Thanks for this comment Steve. I am happy to attempt to redraft the manifest as a more generic document that describes a manifest in terms of a list of published products of a CA, with a signature that is verified using an EE certificate that is a subordinate product of that CA. At this stage I'm of the view that the only RPKI-specific profile would be to say that the RPKI EE cert SHOULD use the inherit bit in the RFC3779 extension, and this seeems such a small profile component that it could fit into the res-cert profile draft in its own section. regards, Geoff WG co-chair hat OFF _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
