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/>. On Fri, Aug 20, 2021 at 3:44 PM Russ Housley <[email protected]> wrote: > 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 protected]> > wrote: > > 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 protected]> 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? >> >> >> >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
