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

[Theo Buehler <[e-mail]>]

On Wed, Dec 07, 2022 at 01:49:10PM -0500, Russ Housley wrote:
> > 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.
> 
> I really do not see what we want to limit these aspects of the certificate.

EE certs are tightly constrained which makes checking them easy. Job is
working hard to keep the ecosystem clean with as little variability as
needed and this is part of these efforts. Apart from the rpkiNotify
issue in the SIA extension that was reported as an erratum for RFC 8182,
I'm not aware of anything that was allowed that shouldn't have been.

The ASID extension is critical. It should therefore only be used if it
contains information that needs to be processed. As you wrote, there's
nothing to do with it here, so clearly it doesn't belong here.

Similarly, the SIA extension makes no sense here.

Underspecification can lead to variances between implementations since
absence of clear guidance means implementors may or may not decide to do
something with these extensions and what they do may or may not make
sense. Explicitly disallowing them provides clarity.

What's the actual argument for implicitly allowing them?

Please don't invoke Postel a third time.