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

[Russ Housley <[e-mail]>]

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