Re: [sidr] Last Call: <draft-ietf-sidr-rpsl-sig-10.txt> (Securing RPSL Objects with RPKI Signatures) to Proposed Standard

[Tom Harrison <[e-mail]>]

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.

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.

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.

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.

(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.)

-Tom