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

All,
I understand more fully now that the RFC5280 definition for
uniformResourceIdentifier has a more specific purpose than as a general URI
container, and that existing tools likely have additional assumptions baked
in about what services the URIs are to be used for. I was really hoping
that the use of the SAN URI in TCPCLv4 would allow reuse of existing
structure and avoid new OID allocation, but it appears that was over
optimistic.

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.

On the other hand, I see no reason why a new otherName OID allocation under
the "SMI Security for PKIX Other Name Forms" IANA sub-registry [2] could
not be used with the same value (a Node ID URI) and value encoding
(IA5String). The PKIX profile for DTN is new and I doubt it has much
deployment yet within DTNs. But now's the time to settle this out; the
TCPCLv4 doc defining the profile is still in the RFC editor's queue.

RE Russ' comment about "dtn" scheme-specific-part structure: unfortunately
the naming portion of BPv7 is more informational than normative at this
point. These URI schemes have been in use for many years across several
implementations; I believe that they are in wide use in DTNs and there
would be little support to change the SSP structure. The interaction of the
URI structure with "other domain" tools like this just was not foreseen.

[2]
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.8

On Sat, Aug 14, 2021 at 11:08 AM Salz, Rich <rsalz=
40akamai.com@dmarc.ietf.org> wrote:

> I completely agree with Ryan.
>
>
>
>    - Do not touch 5280 as there will be too many competing interests to
>    improve it and interop will be broken or the bis version will be ignored.
>    (Years ago I wanted to re-open PKIX and I learned what a bad idea that is,
>    and I became ACME co-chair instead.)
>    - There are extension points within 5280 that can be used, at the loss
>    of built-in nameConstraints support. That doesn’t seem like a big loss,
>    especially as the semantics for DTN are not clear.
>    - Do not use the 5280 structures without saying this is PKIX, as that
>    will need to great confusion among open source implementors and their users.
>
>
> _______________________________________________
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>