Re: [Sidrops] [WG ADOPTION] draft-yan-sidrops-roa-considerations - 04/16/2021

[Job Snijders <[e-mail]>]

Hi Tim, working group,

first things first: I support adoption of this draft.

On Mon, Mar 29, 2021 at 04:06:56PM +0200, Tim Bruijnzeels wrote:
> = revocation?
> 
>    A large number of experiments for the process of ROA issuance have
>    been made on our RPKI testbed, it is found that the misconfigurations
>    during the issuance may cause the ROAs which have been issued to be
>    revoked.
> 
> I don't see how the ROAs would be revoked in this context.

Perhaps 'revoked' is the wrong word, maybe 'withdrawn' or 'unpublished'?

I took the third suggestion in 'Section 3' to mean that if the ROA
issuer does not confirm the End-Entity certificate signing the ROA
eContent checks that it is allowed to sign the resources listed in the
eContent, it might end up submitting an invalid object to the
Repository.

The Repository deferences any previous ROA with the same filename,
performs validation on the newly submitted ROA, concludes it is invalid
(because the resources in the eContent overclaim compared to the
resources listed as subordinate on the EE cert) and ends up publishing a
CA Repository without the intended ROA.

I would suggest:

"""
3) A safeguard scheme is essential to protect the process of ROA
   issuance. Before committing to the issuance of a ROA object, the
   signer software should confirm the ipAddrBlocks in the To-Be-Signed
   eContent are fully contained by the RFC 3779 extensions listed on the
   End-Entity certificate used to generate the signature. 
"""

In other words, a signing pipeline would help the operator by performing
RFC 6482 Section 4 validation *before* constructing the ROA, to prevent
constructing ROAs the Repository operator would consider invalid.

Kind regards,

Job