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

[Ryan Sleevi <[e-mail]>]

On Fri, Aug 13, 2021 at 4:04 PM Roman Danyliw <[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.