Speaking as regular ol’ wg member (I took the ietf off the cc list - I intended this as a sidr discussion, not an ietf discussion.)
On May 11, 2016, at 9:08 AM, Brian Haberman <[email protected]> wrote: > Hi Tom, > Thanks for the in-depth review and your efforts in creating another > implementation of this draft. Responses to your comments are below... > > On 4/28/16 6:54 PM, Tom Harrison wrote: >> Section 5 requires that an EE certificate be used for the signing of >> the RPSL object. An EE certificate must contain an SIA extension that >> points to an RPKI signed object (RFC 6487 [4.8.8.2]). The draft does >> not define a profile for a new type of object, or specify an existing >> one that may be used instead. There are a number of ways to deal with >> this: for example, by defining a new profile and changing the >> signature URL to suit, or by amending RFC 6487 such that object >> pointers in EE certificates are optional. > > I would propose adding some text to this draft (probably as a > sub-section in section 2) that says that the SIA defined in RFC 6487 is > omitted when a certificate is used to sign RPSL objects. Given the > single-use nature of the key-pair (section 3.2, point #1), omitting the > SIA is straightforward. > wrt Tom’s comment: It is certainly the case that currently existing EE certificates in the RPKI appear in RPKI Signed Objects (i.e. instances of RFC6488) - manifests, ghostbuster records, ROAs. But these aren’t the only possible use of EE certificates - the architecture RFC6480 mentions that there might be other uses of EE certificates. And it is certainly the case that there’s been no intent in this work to put signed RPSL objects into the RPKI repositories. wrt Brian’s suggestion: A similar example: The router certificates draft also omits the SIA field for router EE certificates - probably for similar reasons. On May 11, 2016, at 12:56 PM, Brian Haberman <[email protected]> wrote: > Hi Randy, > > On 5/11/16 12:42 PM, Randy Bush wrote: >>> I would propose adding some text to this draft (probably as a >>> sub-section in section 2) that says that the SIA defined in RFC 6487 is >>> omitted when a certificate is used to sign RPSL objects. >> >> perhaps you might also include your reasoning for this seemingly odd >> choice. > > The SIA in 6487 mandates an rsync URI that points to the object that is > signed with the certificate. I am not aware of any RPSL servers that > support referencing an RPSL object via rsync. “A small matter of programming” - an RPSL database operator could find a way to format an rsync URL so that it could be translated on receipt to a database object retrieval. ( :-) ? ) A new type of EE cert does sound cleaner. It puts the burden on the RPKI implementer rather than the RPSL database operators, of course. I am not an implementer nor operator. —Sandy, speaking as regular ol’ working group member
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
