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

[Job Snijders <[e-mail]>]

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:
> >   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.
> 
> 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