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

From: Roman Danyliw <[email-masked]>
Date: Fri, 13 Aug 2021 20:04:05 +0000

Hi Brian!

> -----Original Message-----
> From: Brian Sipos <[email-masked]>
> Sent: Tuesday, July 27, 2021 5:13 PM
> To: Roman Danyliw <[email-masked]>
> Cc: [email-masked]
> Subject: RE: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04
> 
> Roman,
> Thank you for this thorough review. I want to address the more
> procedural/structural points first; the ones which have implications outside of
> just this document.
> 
> > On the process side, this arrangement is rather unusual.  No quarrels with the
> substance of the update which will improve extensibility.  However, this
> particular document has experimental status and the document being updated
> (draft-ietf-dtn-bpbis) is proposed standard (PS).  Having a lower maturity
> document updating one of higher status is my concern -- "experiments fail".
> Was
> this issue considered?  Discussed with the DTN WG?  I'll note that draft-ietf-
> dtn-bpbis has not yet been published (although it is in the late state of the
> RFCEd queue).  Could the changes just be added there directly?
> 
> BS: I did bring this up in the DTN WG earlier and the BPbis authors were fine
> with the update itself, which didn't require BPbis document changes, but I
> understand the concern about the different document status levels. I have
> brought this new concern up in the DTN WG with options of either a late
> AUTH48
> edit or a separate small Proposed Standard document from the DTN WG. The
> change
> really is not specific to this ACME document but related only to this being the
> first new administrative record type for BPv7.

Thanks for bringing the issue to DTN.  We'll wait to see the next steps.

> > **I need a little help on DTN addressing.  The text notes that that the intent
> is to issue certificates with DTN Node IDs as a URI in subjectAltName.
> > ...
> > Given the constraint of (c) and the flexibility afforded with the definition
> of a node ID in (a)+(b), will DTN Node IDs always satisfy the requirement from
> (c) to be FQDN?  Is language needed to ensure that (likely in a few places in
> the document)?
> 
> BS: This is a good catch regarding conformance to RFC 5280, and unfortunately
> represents a subtle logical conflict with this and another document [1].
> Although Section 4.2.1.6 of RFC 5280 states this requirement about the URI
> authority part it makes no other use of this authority restriction, and although
> RFC 6125 does define a URI-ID which has matching logic based on the authority
> part the certificate profile shared by DTN TCPCLv4 [1] and this document
> explictly avoid using URI-ID in favor of the matching logic defined in [1] for
> NODE-ID.
> So while a "dtn" scheme URI contains an authority part which I believe meets
> the
> intent of the RFC 5280 restriction (a unique and unambiguous name/address) it
> does not meet the letter-of-the-law in that document. The dtn scheme is
> already
> in use and has been for many years; although it resembles a URN in semantics
> it
> does use a URL syntax which may be more of an historical accident than a
> design
> decision (as the "ipn" scheme does not use the URL authority syntax).
> Do you think that explicitly calling this out in this document and in [1] are an
> acceptable way to avoid this logical issue? Meaning any CSR or certificate
> handler for DTN must be aware to ignore that specific RFC 5280 requriement.

I see this is more complicated than I realized.  Thanks for explaining it.

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.

Regards,
Roman

> I think all of your other comments are sensible and I will respond to them
> separately.
> Thank you,
> Brian S.
> 
> [1]
> https://datatracker.ietf.org/doc/html/draft-ietf-dtn-tcpclv4-26#section-4.4.2

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 13 Aug 2021 16:25:31 -0400

On Fri, Aug 13, 2021 at 4:04 PM Roman Danyliw <[email-masked]> wrote:

> (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).
>

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.

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 13 Aug 2021 22:59:20 +0000

Hi Ryan!

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

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

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

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 14 Aug 2021 15:07:53 +0000

I completely agree with Ryan.

  *   Do not touch 5280 as there will be too many competing interests to improve it and interop will be broken or the bis version will be ignored.  (Years ago I wanted to re-open PKIX and I learned what a bad idea that is, and I became ACME co-chair instead.)
  *   There are extension points within 5280 that can be used, at the loss of built-in nameConstraints support. That doesn’t seem like a big loss, especially as the semantics for DTN are not clear.
  *   Do not use the 5280 structures without saying this is PKIX, as that will need to great confusion among open source implementors and their users.

---

From: Russ Housley <[email-masked]>
Date: Sat, 14 Aug 2021 17:09:53 -0400

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 <[email-masked]> wrote:
> 
> Hi Ryan!
>  
>  
> From: Ryan Sleevi <[email-masked] <mailto:[email-masked]>> 
> To: Roman Danyliw <[email-masked] <mailto:[email-masked]>>
> Cc: Brian Sipos <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> On Fri, Aug 13, 2021 at 4:04 PM Roman Danyliw <[email-masked] <mailto:[email-masked]>> wrote:
> _______________________________________________
> Acme mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/acme <https://www.ietf.org/mailman/listinfo/acme>

---

From: Brian Sipos <[email-masked]>
Date: Sat, 14 Aug 2021 18:35:36 -0400

All,
I understand more fully now that the RFC5280 definition for
uniformResourceIdentifier has a more specific purpose than as a general URI
container, and that existing tools likely have additional assumptions baked
in about what services the URIs are to be used for. I was really hoping
that the use of the SAN URI in TCPCLv4 would allow reuse of existing
structure and avoid new OID allocation, but it appears that was over
optimistic.

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.

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.

RE Russ' comment about "dtn" scheme-specific-part structure: unfortunately
the naming portion of BPv7 is more informational than normative at this
point. These URI schemes have been in use for many years across several
implementations; I believe that they are in wide use in DTNs and there
would be little support to change the SSP structure. The interaction of the
URI structure with "other domain" tools like this just was not foreseen.

[2]
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8

On Sat, Aug 14, 2021 at 11:08 AM Salz, Rich <rsalz=
[email-masked]> wrote:

>    - Do not touch 5280 as there will be too many competing interests to
>    improve it and interop will be broken or the bis version will be ignored.
>    (Years ago I wanted to re-open PKIX and I learned what a bad idea that is,
>    and I became ACME co-chair instead.)
>    - There are extension points within 5280 that can be used, at the loss
>    of built-in nameConstraints support. That doesn’t seem like a big loss,
>    especially as the semantics for DTN are not clear.
>    - Do not use the 5280 structures without saying this is PKIX, as that
>    will need to great confusion among open source implementors and their users.
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Ryan Sleevi <[email-masked]>
Date: Sat, 14 Aug 2021 23:45:42 -0400

> 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

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

---

From: "Salz, Rich" <[email-masked]>
Date: Sun, 15 Aug 2021 15:11:01 +0000

*   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.

How would that work?  Let’s take an application using OpenSSL.  It currently calls d2i_X509() to parse the DER into internal format. It does various cert checks along the way. Would you add a new API (because you can’t change the calling sequence it breaks all existing applications), and then pass that flag down through all the call stack?

---

From: Brian Sipos <[email-masked]>
Date: Fri, 20 Aug 2021 15:10:48 -0400

Rich, I see your point. I had made my own assumptions that tools would
validate that the SAN URI contained a valid URI and nothing more. But
because the RFC 5280 requires more about the authority part some
tools/libraries are free to throw out URIs that have some other
(RFC-invalid) authority part.

Unfortunately, the document this most affects is already in the editor
queue. But I think the new otherName type-id OID will be needed to avoid
potential tooling compatibility issues. My plan is to propose adding a new
otherName OID for any DTN Endpoint ID (as a URI) and then use that for DTN
Node IDs as a subset of EIDs. The logic is almost identical to current SAN
URI except for those DNS/IP related restrictions on SAN URI content being
replaced by DTN scheme restrictions.

On Sun, Aug 15, 2021 at 11:11 AM Salz, Rich <[email-masked]> 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.
>
>
>
> How would that work?  Let’s take an application using OpenSSL.  It
> currently calls d2i_X509() to parse the DER into internal format. It does
> various cert checks along the way. Would you add a new API (because you
> can’t change the calling sequence it breaks all existing applications), and
> then pass that flag down through all the call stack?
>
>
>

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 20 Aug 2021 19:22:29 +0000

Hi Brian!

Per the other affected document, draft-ietf-dtn-tcpclv4, while it is in the RFC editor queue, it isn’t published.  Therefore, it could be pulled back to reconcile with this new approach.

Regards,
Roman

From: Brian Sipos <[email-masked]>
Sent: Friday, August 20, 2021 3:11 PM
To: Salz, Rich <[email-masked]>
Cc: Roman Danyliw <[email-masked]>; Ryan Sleevi <[email-masked]>; Brian Sipos <[email-masked]>; [email-masked]
Subject: Re: [Acme] AD Review of draft-ietf-acme-dtnnodeid-04

Rich, I see your point. I had made my own assumptions that tools would validate that the SAN URI contained a valid URI and nothing more. But because the RFC 5280 requires more about the authority part some tools/libraries are free to throw out URIs that have some other (RFC-invalid) authority part.

Unfortunately, the document this most affects is already in the editor queue. But I think the new otherName type-id OID will be needed to avoid potential tooling compatibility issues. My plan is to propose adding a new otherName OID for any DTN Endpoint ID (as a URI) and then use that for DTN Node IDs as a subset of EIDs. The logic is almost identical to current SAN URI except for those DNS/IP related restrictions on SAN URI content being replaced by DTN scheme restrictions.

On Sun, Aug 15, 2021 at 11:11 AM Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Russ Housley <[email-masked]>
Date: Fri, 20 Aug 2021 15:44:42 -0400

Brian:

Is the AD that sponsored that document part of this discussion?  If not, I suggest that we loop them in.

Russ

> On Aug 20, 2021, at 3:10 PM, Brian Sipos <[email-masked]> wrote:
> 
> On Sun, Aug 15, 2021 at 11:11 AM Salz, Rich <[email-masked] <mailto:[email-masked]>> 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.
>  
>

---

From: Brian Sipos <[email-masked]>
Date: Fri, 20 Aug 2021 17:07:44 -0400

Not yet. The document's original AD was Magnus Westerlund, but the new DTN
documents were handed off to new AD Zaheduzzaman Sarker (included on this
message) earlier this year.
My feeling of the DTN WG perspective regarding the PKIX details is: "figure
out the right way to do it," because there is no well established PKI in
that domain that would need to retain compatibility.

For Zahed, the original ACME review which drove this discussion was <
https://mailarchive.ietf.org/arch/msg/acme/7HaJSiLnZ21zppL8p6MMIr6JEaI/>. I
have been posting summaries of this discussion in the DTN mailing list
also, starting at <
https://mailarchive.ietf.org/arch/msg/dtn/xNp_9mFjTadDivhoKZA35B5MNUk/>.