Subject: Re: [sidr] using RPKI keys to sign RPSL data

From: Stephen Kent <[email-masked]>
Date: Tue, 27 Aug 2013 23:52:49 -0400

I am sympathetic to the concerns that Randy has cited.  In particular, I 
am uncomfortable
with the ability of a signer to enumerate an unconstrained list of 
object types that
are signed.  We need to consider the semantic of each object that can be 
covered by a
sig and decide whether they are consistent with what the RPKI certifies. 
If not, then
that object type must be excluded.  If we can come to agreement on a 
scheme of this
sort, I might be supportive of this proposal.

Steve

p.s. I have raised this concern in the past. If the current version of 
the doc,
which I have not reviewed recently, has addresses this issue, then maybe 
we're
OK.

---

From: Geoff Huston <[email-masked]>
Date: Wed, 28 Aug 2013 18:45:58 +1000

Could we not use the work done in RFC2725? I suspect that the delta is remarkably small, and a quick scan right now conforms that impression for me (that the delta is not great).

Geoff

On 28/08/2013, at 1:52 PM, Stephen Kent <[email-masked]> wrote:

> I am sympathetic to the concerns that Randy has cited.  In particular, I am uncomfortable
> with the ability of a signer to enumerate an unconstrained list of object types that
> are signed.  We need to consider the semantic of each object that can be covered by a
> sig and decide whether they are consistent with what the RPKI certifies. If not, then
> that object type must be excluded.  If we can come to agreement on a scheme of this
> p.s. I have raised this concern in the past. If the current version of the doc,
> which I have not reviewed recently, has addresses this issue, then maybe we're
> OK.

---

From: "Murphy, Sandra" <[email-masked]>
Date: Wed, 28 Aug 2013 16:13:54 +0000

Speaking as a regular ol' member

>sort, I might be supportive of this proposal.

[[First, terminology clarification.  RPSL has objects that have attributes.  The draft talks about producing a signature for an object.  So when you say "object type" I think you mean attributes of an object.]]

The draft includes a list of the minimum attributes, per object type(*), that must be included in a signature,.  It does specify per object type what the relationship must be between the resources mentioned in the cert and the resources in the object.  It also allows the maintainer to specify other attributes in the object that are included in the signature.

That last part I think is where you are concerned.

We do have the example of the ghostbuster record, where the information being signed has no relationship to the resources included in the certificate that verifies the signature.  There's probably a reason that ghostbusters was an acceptable set of information to be signed, with no call for it to be "consistent with what the RPKI certifies".  I have a guess that the reason might be in the ghostbusters security consideration section that says:

   Relying parties are hereby warned that the data in a Ghostbusters
   Record are self-asserted.  These data have not been verified by the
   CA that issued the CA certificate to the entity that issued the EE
   certificate used to validate the Ghostbusters Record.

Would that same sort of warning relieve your concern here?

OTOH. The ghostbusters record content is much more constrained than the attributes in RPSL objects, which might put the RPSL signatures in a whole other league.

--Sandy, speaking as regular ol' member

(*)(Though not all object types?  There are other RPSL object types beyond those included in this draft.)