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

[Ties de Kock <[e-mail]>]

Hi all,

> On 12 Feb 2022, at 15:56, [e-mail] wrote:
> 
> 
> 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.
> 


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