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.
Section 4 specifies sets of attributes that must be signed. 'org' is
included as one of these attributes for the as-block, inet[6]num, and
route[6] object types. However, 'org' is not defined in either of the
principal RPSL RFCs (2622 and 4012), and there are current
implementations (e.g. APNIC's) that do not support it. I think the
references to 'org' should be omitted.
Agreed. I will remove 'org' from the listed objects.
Section 4 specifies 'signature' as an attribute that must be signed.
'signature' can appear multiple times in a single object, where e.g.
two different resource holders sign a route[6] object. Given that the
text doesn't explicitly state that only the newest 'signature' must be
signed, it would appear to require that any extant 'signature'
attributes be signed as well. That in turn would prevent previous
signers from re-signing the object independently of the subsequent
signers. I think the text should be changed so that only the new
signature attribute need be signed.
Agreed. I will update the text to explicitly refer to the signature
currently under construction.
Section 2.4 requires that "the Internet number resources present in
[RFC3779] extensions of the certificate referred to in the "c" field
of the signature must cover the resources in the primary key of the
object". This means that it's not possible to sign a route[6] object
for a route where one resource holder has the ASN and another the
prefix. In revision 8 (and earlier), the possibility of there being
multiple signatures, each with a certificate covering a subset of the
primary key resources, was explicitly permitted. I think that the
previous text here should be restored.
I agree that the original text allowing multiple signatures supports the
case where the components of the primary key of the object (i.e.,
prefix+ASN) come from different resource holders. I will restore that text.
(The above points were the product of much discussion of this draft
with Tim and Oleg from RIPE, not that I'm speaking for them. We were
able to write interoperable prototype signer/validator
implementations, so the document is in pretty good shape on the
whole.)
Thanks! Glad to hear this.
Regards,
Brian
signature.asc
Description: OpenPGP digital signature