[TLS] Query for consensus on an "experimental/private-use" extension identifier

[Kyle Hamilton <[e-mail]>]

I would like to attempt to initiate the "IETF Consensus" process for
assigning a single "experimental/private-use" extension identifier.  I
can submit an I-D to describe how I feel this could be interoperable
and multiplexable, so that the "private-use" mechanism can be used
between compliant implementations without fear of trampling over each
other.

(I've got a design where multiple extensions are necessary to transfer
information about authentication requirements and authorization
capabilities, while blinding them to the client unless the client has
a trust anchor that can un-blind them).

Would there be interest in this beyond just me?  My current experiment
is an attempt to reduce the amount of information leakage produced by
the "allowed CA names" field, by sending salted hashes of each of
either the CA names or trust anchor AKIDs that the peer is willing to
accept as authenticators, shashed (shash = s(alted )hash) such that an
attacker would need to have the same trust anchor in its repository to
identify exactly which CAs it knows about that can and will be
accepted by the peer.

I would like to suggest 34 as the new extension ID for this, since
according to IANA it's the highest unassigned possible value (35 is
used for SessionTicket).

What is the procedure to attempt to initiate this kind of IETF
consensus, necessary to be able to experiment without fear of smashing
someone else's experiments?

(As I said, I'll draw up an I-D to more concretely define the
semantics of such an extension, including the ability to interleave
multiple types of extensions under the same extension identifier.)

-Kyle H