Re: [Sidrops] feedback on draft-michaelson-rpki-rta

[Job Snijders <[e-mail]>]

Dear group,

On Tue, Dec 29, 2020 at 11:14:12AM +0100, Claudio Jeker wrote:
> There is a big issue with the fact that RTA can be cross signed by
> multiple certs. No other resource in RPKI does that and it causes some
> issues with the validation process. Until now each CA repo could be
> checked independently once ready but now RTA files suddenly have
> interdependencies that need special attention. I would like to know
> why this complication is needed for RTA - what is the actual use case
> where multiple signers are necessary. I currently don't see why this
> is required (especially since the resources (ASnum and IP blocks) need
> to be allowed by all those CA certs.

I agree. Removing subjectKeyIdentifers greatly simplifies the RTA
concept without compromising its application and utility for the use
cases I'd like to deploy. 

With the following new formal definition in mind:

     ResourceTaggedAttestation ::= SEQUENCE {
         version  [0]          INTEGER DEFAULT 0,
         resources             ResourceBlock,
         digestAlgorithm       AlgorithmIdentifer,
         messageDigest         OCTET STRING }

Having the 'resources' listed in the payload (and of course require
those to match what was delegated to the issuing entity, just like is
done with ROAs) makes sense to me, because this way the Relying Party
can understand which of many subordinate resources attested.

For example in the use case I envision for PeeringDB.com:

An entity who have 2 ASNs (199036 and 15562, archived example:
http://console.rpki-client.org/rpki.ripe.net/repository/DEFAULT/ZrvTEk3dw4Cs6zD65ee6glPlruQ.cer.html)
wishes to sign-up for PeeringDB.com. They only want to proof to
PeeringDB they own AS 15562 (so AS 199036 is out of scope in this B2B
process).

The PeeringDB.com interface in the sign-up process generates a file with
some random contents, hashes this random data, and then expects the
Resource Holding entity to put the message digest in a RTA. Also they
expect at least resource 'AS 15562' in the 'resources' field. The
operational benefit is that looking at just the validated RTA payload
one can figure out which resource created the digest.

INR ownership verification process:

  Entity holding resources       <->                    PeeringDB.com
         15562, 199036            |

  ---> Express desire to prove ownership for 15562 -->

                                  | Generate file with some random data
                                  | Generate message digest X for the file
                                  | Store digest X as part of onboarding attempt 

      <--- Request INR holder to create RTA with message digest X <---

  Generate RTA with at least      |
  15562 as resource, and digest X |
  in RTA payload                  |

  ---> send the RTA file via email or webform to PeeringDB --->

                                  | Validate RTA, pull out payload.
                                  | Compare whether the digest in the
                                  | RTA payload matches digest X
                                  | stored as part of the onboarding
                                  | attempt

>From a validation perspective, the above process to me seems sufficient
(and state of the art!) for BYOIP / BYOAS purposes. Even if digest X is
intercepted, the onboarding process is not compromised (assuming the
Trust Anchors are not compromised).

Of note should be that the attested file itself is not even exchanged
between the two parties, merely indicating which digest is expected, and
seeing this partciular digest in a valid current RTA is the attestation.

The advantage of using a message Digest as 'nonce' is that both the use
case of just proving ownership vs attesting digital objects (files). So
that part I like a lot, RTA can be used to both form relations and
attest file contents.

Just like ROAs, Ghost Buster Records, or Manifests *payloads* don't have
a set of additional subjectKeyIdentifers referencing to things in the
outer enveloppe, I think RTAs might be better off without them.

Look forward to feedback from others.

> RFCs like this need some demo resources to play with.

Yes.

Kind regards,

Job