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= [email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
