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

[Brian Sipos <[e-mail]>]

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]> 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?
>
>
>