Re: [Sidrops] Fwd: New Version Notification for draft-ymbk-9020-update-00.txt

[Job Snijders <[e-mail]>]

Dear Randy, others,

Thank you for working on this.

On Tue, Dec 06, 2022 at 10:19:27AM -0800, Randy Bush wrote:
> Name:		draft-ymbk-9020-update
> Revision:	00
> Title:		A Minor Update to Finding and Using Geofeed Data
> Document date:	2022-12-06
> Group:		Individual Submission
> Pages:		23
> URL:            https://www.ietf.org/archive/id/draft-ymbk-9020-update-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-ymbk-9020-update/
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-ymbk-9020-update
> 
> Abstract:
>    This document specifies how to augment the Routing Policy
>    Specification Language inetnum: class to refer specifically to
>    geofeed data comma-separated values (CSV) files and describes an
>    optional scheme that uses the Routing Public Key Infrastructure to
>    authenticate the geofeed data CSV files.

Looking at the RFC 9092 vs draft-ymbk-9020-update-00 diff the proposed
update indeed seems very small:
https://author-tools.ietf.org/diff?doc_1=rfc9092&doc_2=draft-ymbk-9020-update-00

I reported on the issue of RFC9092 being underspecified
https://mailarchive.ietf.org/arch/msg/opsawg/JXjxCA14BkW4DWyVoUMwqDvB17I/
and I'm happy to see this step forward to disallow 'inherit' elements. 
However, I'd like to see two additional constraints incorporated in an
9092-update:

1/ disallow AS Identifiers Delegation extensions in Geofeed EE certs.
2/ disallow SubjectInformationAccess extensions in Geofeed EE certs.

Elaboration:

1/ The motivation to disallow AS Identifiers stems from the observation
that 'the other option' (to ignore the extension if present) may lead to
interopability issues.

Imagine a scenario where an ASId listed in the Geofeed EE cert is not
covered by its parent. Some Geofeed validator implementations might
ignore the extension (and the erroneous ASId value contained therein)
altogether; and some implementations cannot trivially ignore the AS
Identifiers extension (for example consumers of libcrypto's
X509_verify_cert()), which leads to inconsistent results.

Thus, I propose adding something along the lines of:

    "The Autonomous System Identifier Delegation Extension [RFC3779] MUST
     be absent."

2/ Because Geofeed authenticators are not distributed through the global
RPKI repository system, the Subject Information Access (SIA) extension
makes no sense in the Geofeed authenticator's X.509 EE certificate. The
authenticator cannot be retrieved at the URIs in the SIA.

To simplify the profile for both producers and consumers, I'd suggest to
incorporate the following:

    "The SubjectInformationAccess Extension [RFC5280] MUST be absent."

Finally, ...

I've attached a .diff file which can be applied to draft-ymbk-9020-update-00.xml
to update the example TA/CA/EE certificates, CRLs, and CMS signatures to
conform to both RFC 9092, the additional 'inherit' constraint in
draft-ymbk-9020-update-00, and the two constraints I listed above;
additionally, a minor issue with the Basic Constraints extension is
fixed.

The new example is cryptographically valid.

    $ rpki-client -t example-ta.tal -f geofeed.csv
    File:                     geofeed.csv
    Hash identifier:          13Imr3rnt7OY9NRvCUKycaL7CGoIdvghtRnua9UuzwU=
    Subject key identifier:   07:E9:9A:FE:A1:8E:1C:B6:E1:5C:2D:D6:B8:8A:7E:B8:1C:7D:83:C0
    Certificate serial:       0
    Authority key identifier: 38:16:01:03:46:A3:40:E1:75:DA:15:50:0A:C8:BA:EA:9A:18:4E:FC
    Authority info access:    rsync://rpki.example.net/repository/3C6B33E5709C073A868C95D955B0F56E37821D7B.cer
    Geofeed valid until:      Dec 07 10:19:15 2023 GMT
    Geofeed CSV records:
        1: IP: 2001:db8::/32 (NL,,,)
        2: IP: 2001:db8::/48 (NL,NL-NH,Amsterdam,)
    Validation: OK
    
Kind regards,

Job