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
