Subject: [Sidrops] I-D Action: draft-ietf-sidrops-rpki-rsc-06.txt

From: [email-masked]
Date: Sat, 12 Feb 2022 06:56:08 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the SIDR Operations WG of the IETF.

        Title           : Resource Public Key Infrastructure (RPKI) object profile for Signed Checklist (RSC)
        Authors         : Job Snijders
                          Tom Harrison
                          Ben Maddison
	Filename        : draft-ietf-sidrops-rpki-rsc-06.txt
	Pages           : 15
	Date            : 2022-02-12

Abstract:
   This document defines a Cryptographic Message Syntax (CMS) profile
   for a general purpose listing of checksums (a 'checklist'), for use
   with the Resource Public Key Infrastructure (RPKI).  The objective is
   to allow an attestation, in the form of a listing of one or more
   checksums of arbitrary digital objects (files), to be signed "with
   resources", and for validation to provide a means to confirm a
   specific Internet Resource Holder produced the Signed Checklist.  The
   profile is intended to provide for the signing of an arbitrary
   checksum listing with a specific set of Internet Number Resources.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidrops-rpki-rsc/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-sidrops-rpki-rsc-06.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidrops-rpki-rsc-06

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

---

From: Ties de Kock <[email-masked]>
Date: Mon, 14 Feb 2022 09:47:47 +0100

Hi all,

> On 12 Feb 2022, at 15:56, [email-masked] wrote:
> 
> 

While this draft discusses the validity of the RSC object in isolation, it would
probably be good to clarify and/or add constraints on when a RSC object should
be considered valid.

I think this is especially important because a CA has no visibility into what
RSCs are out there for a private key (and there are multiple solutions for this,
e.g. certificate transparency for the EE certs or requiring RSC objects to be on
a current, valid manifest).

For example, from the current draft, it is not clear if the CA certificates that
form the valid certification path from a trust anchor to the EE certificate (6488)
need to be on current, valid manifests. I think they do, but clarification would
help :).

Furthermore, when evaluating a RSC at a point in time, you need assurance that
(a) the RSC itself is not backdated and that (b) the CA path was in place at
that point in time.

In practice, it may only be feasible to verify a RSC that "has been signed
recently" and is valid at this point [in time]. Only considering the current
state of the RPKI tree also solves the problems posed by key-rolls, resource
transfers, etc.

Kind regards,
Ties

---

From: Job Snijders <[email-masked]>
Date: Mon, 14 Feb 2022 16:47:42 +0100

Dear Ties, WG,

Thanks for taking the time to review this draft and provide feedback.

On Mon, Feb 14, 2022 at 09:47:47AM +0100, Ties de Kock wrote:
> While this draft discusses the validity of the RSC object in
> isolation, it would probably be good to clarify and/or add constraints
> on when a RSC object should be considered valid.
> 
> I think this is especially important because a CA has no visibility
> into what RSCs are out there for a private key (and there are multiple
> solutions for this, e.g. certificate transparency for the EE certs or
> requiring RSC objects to be on a current, valid manifest).

In my mind the above 'problem' is not too dissimilar from what RPKI
operators already face with all existing object types. So hopefully a CA
keeps track of/keeps tabs on the subordinate CAs it allows to exist, and
is in control of any RSC objects (or other object types) issued under
its auspices? In this sense I see now difference to Manifests or ROAs
(as in, I believe that the problem you describe is not unique to RSC, it
also applies to MFTs or ROAs, no RP has full visibility, a CA could
present different views to different RPs).

As RSCs are distributed out-of-band, this means that - by design -
general visibility is limited. About listing on current valid manifests,
this is explicitly forbidden logically following from Section 2:

"""
   RSC follows the Signed Object Template for the RPKI [RFC6488] with
   one exception.  Because RSCs MUST NOT be distributed through the
   global RPKI Repository system, the Subject Information Access (SIA)
   extension MUST be omitted from the RSC's X.509 End-Entity (EE)
   certificate.
"""
(https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc-06.html#section-2)

It isn't feasible to add Certificate Transparency as a prerequisite to
progress RSC, as CT in context of RPKI still is in its infancy. However,
if in the years to come CT does become available, I suspect operations
related to all Signed Object types could see improvement, including RSC.

> For example, from the current draft, it is not clear if the CA
> certificates that form the valid certification path from a trust
> anchor to the EE certificate (6488) need to be on current, valid
> manifests. I think they do, but clarification would help :).

I'll contrast RTA and RSC to hopefully clarify: the RTA concept has the
notion of carrying a chain of certificates and CRLs in the CMS
Certificates & CRLs Fields, even up to and including the self-signed
trust-anchor. This is a novelty in context of the RPKI ecosystem.

The purported advantage of the RTA object design would be that all an RP
needs to verify the RTA is a "fully populated CMS cert & crl enveloppe",
and the Trust Anchor Locator with the Public Key of the TA certificate
packed in the RTA CMS. However, the RTA Signed Object definition is the
"odd duck" here, because RFC 6488 section 3 clearly stipulates that the
SignedData field only contains one EE certificate.

The RSC internet-draft does not deviate from the Signed Object template
in this regard. RSC is similar to MFT, ROA, GBR: the CA must exist on a
valid current manifest, because an RSC issuer can't put the intermediate
CA certificate in the RSC itself. I'm hesitant to repeat (redundant) RFC
6488 information into the RSC draft.

Consequently, any CA issuing a RSC EE cert, will be present in one or
more of the global RPKI trees, on a valid current manifest. I think this
characteristic makes implementation and debugging easier.

> Furthermore, when evaluating a RSC at a point in time, you need
> assurance that (a) the RSC itself is not backdated and that (b) the CA
> path was in place at that point in time.

I am not sure I follow the above paragraph: the moment a RP performs
verification, the RSC's EE certificate must be 'current' (e.g. RP's
notion of time must be within the RSC's EE certificate's validity
window), and the RSC EE cert must not be revoked. Additional
verification steps are outlined in draft-ietf-sidrops-rpki-rsc Section
5.

> In practice, it may only be feasible to verify a RSC that "has been
> signed recently" and is valid at this point [in time]. Only
> considering the current state of the RPKI tree also solves the
> problems posed by key-rolls, resource transfers, etc.

Indeed, that is my understanding as well. This follows from RFC 6488
(mainly section 3). Is there any text in the current RSC -06
internet-draft that would suggest otherwise?

Please let the authors know if the above answers your questions.
Suggestions for text to improve the readability are welcome.

Kind regards,

Job