Roman: I think that DTN would conform with RFC 5280 and with RFC 3986 if it used one slash instead of two slashes. Is that a smaller revision than other that have been discussed?
Russ > On Aug 13, 2021, at 6:59 PM, Roman Danyliw <r...@cert.org> wrote: > > Hi Ryan! > > > From: Ryan Sleevi <ryan-i...@sleevi.com <mailto:ryan-i...@sleevi.com>> > Sent: Friday, August 13, 2021 4:26 PM > To: Roman Danyliw <r...@cert.org <mailto:r...@cert.org>> > Cc: Brian Sipos <bsi...@rkf-eng.com <mailto:bsi...@rkf-eng.com>>; > acme@ietf.org <mailto:acme@ietf.org> > Subject: Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04 > > > > On Fri, Aug 13, 2021 at 4:04 PM Roman Danyliw <r...@cert.org > <mailto:r...@cert.org>> 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 > _______________________________________________ > Acme mailing list > Acme@ietf.org <mailto:Acme@ietf.org> > https://www.ietf.org/mailman/listinfo/acme > <https://www.ietf.org/mailman/listinfo/acme>
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
