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

[Roman Danyliw <[e-mail]>]

Hi Ryan!


From: Ryan Sleevi <[e-mail]>
Sent: Friday, August 13, 2021 4:26 PM
To: Roman Danyliw <[e-mail]>
Cc: Brian Sipos <[e-mail]>; [e-mail]
Subject: Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04



On Fri, Aug 13, 2021 at 4:04 PM Roman Danyliw <[e-mail]<mailto:[e-mail]>> wrote:
I think the current options might be:

(1) Roughly what you said above + Make it clear that this document is NOT using the RFC5280 profile and simply reusing the data structures (but not the validation logic).  Related to this, and excuse my ignorance about DTN, would it be possible to constrain these non-RFC5280-conforming certificates from appear on the internet with some normative phrasing.  Technically, RFC5280 is the _Internet_ PKIX profile.  This document goes to great pains to separate the internet portion of the ACME protocol exchange and the validation happening over DTN (which might be considered a "limited domain" as framed by RFC8799).

(2) Revise RFC5280.  I'm loath to pursue this path unless we really need to.

I suspect that either of these options would be a quick way to doom interoperability. That is, for better or worse, RFC 5280 is _the_ profile of X.509 that is commonly targeted by libraries and implementations. Attempting to diverge here, or special-case exceptions, generally means that implementing an interoperable and spec-compliant implementation are increasingly unlikely, given the extant complexity inherent in X.509 and RFC 5280 to begin with (e.g. as so many implementations overlook RFC 4158 to their own peril - and to the harm of interop)

To that end, is

(3) Express the DTN ID as an otherName within the SAN, rather than a (non-conforming) URI

Not an option? The downside here is the obvious loss of nameConstraints processing (RFC 5280 does not define even a processing algorithm for otherName nameConstraints, which makes sense, given the complexities there vis-a-vis multiple distinct otherNames vs multiple otherNames that make up a single logical name), but if that's an acceptable trade-off, that likely represents the most interoperable path forward.

That's not to say otherName is readily supported "out of the box", although it is in some (e.g. most famously, Active Directory's use of the otherName for the userPrincipalName), but it fits within the "no special cases" goal of promoting interoperability, and lets one build/extend existing RFC 5280 implementations. Here, the lack of nameConstraints processing is a benefit, rather than a limitation - it makes processing and extracting such fields something relatively simple you can build on post-validation, if your library is not extensible or not receptive towards exposing library-level API support specific for DTN node IDs.

[Roman] Thanks for proposing another option.  I’d be interested to hear if this would be viable.  If I’m not mistaken, in addition to changing to otherName here, Section 4.4.1 of draft-ietf-dtn-tcpclv4 would also require revision.

Regards,
Roman