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

From: Brian Haberman <[email-masked]>
Date: Wed, 11 May 2016 09:08:43 -0400

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

---

From: Randy Bush <[email-masked]>
Date: Wed, 11 May 2016 18:42:25 +0200

> omitted when a certificate is used to sign RPSL objects.

perhaps you might also include your reasoning for this seemingly odd
choice.

> I agree that the original text allowing multiple signatures supports
> the case where the components of the primary key of the object (i.e.,

this is gonna be really simple; no complications at all i am sure.

btw, was this a consensus of the wg?

randy

---

From: Brian Haberman <[email-masked]>
Date: Wed, 11 May 2016 12:56:53 -0400

Hi Randy,

> perhaps you might also include your reasoning for this seemingly odd

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.

> btw, was this a consensus of the wg?

The original draft supported multiple signature attributes. During WG
review (WGLC?, don't recall), several people suggested simplifying the
approach by only allowing one signature attribute. Given the route[6]
example, we need multiple signatures modulo the proposed text to clarify
the handling/generation of those signatures.

Regards,
Brian

---

From: Sandra Murphy <[email-masked]>
Date: Wed, 11 May 2016 15:09:50 -0400

speaking as one of the wg co-chairs

> single-use nature of the key-pair (section 3.2, point #1), omitting the

Speaking as one of the wg co chairs:

You are suggesting much the same as draft-ietf-sidr-bgpsec-pki-profiles - defining a new EE cert profile.

This draft would have to say that it is updating RFC6485(bis).

Which means making clear what the additions/modification/deletions are.

So that implementations know how to interpret these new certs when they find them in some repository, it must be possible to distinguish these new EE certs from other EE certs.

Etc.

And the wg would have to agree on the changes.

—Sandy, speaking as  one of the wg co-chairs

---

From: Sandra Murphy <[email-masked]>
Date: Fri, 13 May 2016 06:02:11 -0400

I’ve made an error in reference.  Going back through to correct.

> This draft would have to say that it is updating RFC6485(bis).

RFC6485 -> RFC6487.

RFC6485 is about algorithms.  RFC6487 is the document about RPKI certificates.

Sorry for the confusion.

—Sandy