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] > <mailto:[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
