If we change the registry but none of the semantics of any existing allocations (i.e., we make a deep copy initially), then I think this is just fine regarding the updating rules (since nothing should of this should affect on the wire interoperability).
We should be careful with the wording. The hash algorithm is used for calculating a fingerprint of some data, it is not really tied to the mechanisms of specific security protocols (or specific versions of security protocols). My personal observation is that sharing IANA registries has proven to be complicated and it may thus be best to create a rather specific registry for exactly this use case. Yes, this may require to have multiple registrations if new hash algorithms come along (rare) but it avoids problems of (unwanted) side effects if registries are used in multiple different contexts. /js On Mon, Feb 28, 2022 at 08:28:21AM -0600, Kenneth Vaughn wrote: > To OPSAWG, especially MIB doctors and SNMP-experts: > > We have contacted the TLS community about potentially allowing for the > continued use and maintenance of the IANA TLS HashAlgorithm Registry (RFC > 5246) in the update to RFC 6353 so that we do not have to redefine its > fingerprint algorithm. The TLS community expressed a valid concern that if > the registry is maintained by adding new values, it would imply that those > new values could be used within TLS 1.2; thus our proposal to continue to > reference the existing table was not accepted. > > We now have two potential options as follows: > 1. Deprecate and replace the existing fingerprint algorithm with a new one. > The fingerprint algorithm is used in the index of most of the tables within > the RFC 6353 MIB; as a result, deprecating the fingerprint algorithm requires > deprecating the assocaited tables; in practice, this results in redefining > the entire MIB in RFC 6353. > > 2. Revise the DESCRIPTION clause of SnmpTLSFingerprint to refer to a new, > parallel HashAlgorithm Registry. Specifically, we would replace the second > paragraph of its DESCRIPTION clause, which currently reads: > > > An SnmpTLSFingerprint value is composed of a 1-octet hashing algorithm > > identifier followed by the fingerprint value. The octet value encoded is > > taken from the IANA TLS HashAlgorithm Registry (RFC 5246). The remaining > > octets are filled using the results of the hashing algorithm. > > > To something like the following: > > > An SnmpTLSFingerprint value is composed of a 1-octet hashing algorithm > > identifier followed by the fingerprint value. The octet value encoded is > > based on the IANA TLS HashAlgorithm Registry (RFC 5246), However, this > > registry is only applicable to (D)TLS protocol versions prior to 1.3, which > > are now designated as "obsolete" and are not expected to ever support > > additional values. To allow the fingerprint algorithm to support additional > > hashing algorithms that might be used by later versions of (D)TLS, the > > octet value encoded is taken from IANA SnmpTLSFingerprintAlgorithm > > Registry, The initial values within this registry are identical to the > > values in the TLS HashAlgorithm registry but can be extended to support new > > hashing algorithms as needed. > > > While option 2 greatly simplifies the update, the question is whether this > can be considered a valid revision to the MIB. Per RFC 2578 Section 10, the > DESCRIPTION clause can only be updated with "clarifications and additional > information ... Otherwise, if the semantics of any previously defined object > are changed (i.e., if a non-editorial change is made to any clause other than > those specifically allowed above), then the OBJECT IDENTIFIER value > associated with that object must also be changed." > > So our question to the group is "Does option 2 qualify as a valid > "clarification and additional information" or are we forced into option 1?". > Option 1 would require a complete replacement MIB with corresponding impacts > to existing code to support the new TLS version, so I believe Option 2 would > be preferred, if allowed. > > Regards, > Ken Vaughn > > Trevilon LLC > 6606 FM 1488 RD #148-503 > Magnolia, TX 77354 > +1-936-647-1910 > +1-571-331-5670 cell > [email protected] > www.trevilon.com > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg -- Jürgen Schönwälder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
