Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04

[Ryan Sleevi <[e-mail]>]

On Sat, Aug 14, 2021 at 6:18 PM Brian Sipos <[e-mail]> wrote:

> Does it seems like it's at all reasonable, from the perspective of the
> security area and focus on PKIX (documents and tools), for an application
> profile like this to say to conform to "... RFC 5280 with the exception of
> the FQDN/IP-address restriction on URI authority part". It's not exactly an
> update to RFC 5280 but I don't know how valid or typical it is for one RFC
> to relax requirements from a normative reference.
>

I think that would be specifically ill-advised, and most likely harm
interoperability. The reality is implementations by and large don't offer
the flexibility being described here, and would see it as a security issue
to do so (given how constraints work with URIs), so the net effect is to
encourage implementers of this spec to "fork" RFC 5280, and, by nature,
fork the libraries or implementations due to a respectable unwillingness of
upstream to accept such relaxations.

So no, it's atypical, and not at all recommended.

Given that URI SANs / nameConstraints are already a security and
interoperability disaster [1] [2], avoiding building on them is absolutely
the way to go, even if the URI itself was conforming.

[1]
https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf
[2] https://datatracker.ietf.org/doc/html/draft-ruby-url-problem-01


> On the other hand, I see no reason why a new otherName OID allocation
> under the "SMI Security for PKIX Other Name Forms" IANA sub-registry [2]
> could not be used with the same value (a Node ID URI) and value encoding
> (IA5String). The PKIX profile for DTN is new and I doubt it has much
> deployment yet within DTNs. But now's the time to settle this out; the
> TCPCLv4 doc defining the profile is still in the RFC editor's queue.
>

Yes. This is a 'happy path' that supports interop with a number of existing
libraries and tools.