Thanks to everyone who has worked on this over the past several years, and
thanks to the authors for a timely response to my earlier discuss concerns.
I am leaving the original text of my discuss below for historical reasons,
as it pertains to a larger problem that would ideally be addressed by future
I can see in
https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-26 that the OID 22.214.171.124.5.2 has been reserved for Kerberos v5 objects (a
reservation that appears to have been copied out of RFC 1700). I also see that
RFC 4556 uses 126.96.36.199.5.2.3 and defines three nodes (.1, .2, and .3) underneath
it. Try as I might, I can't find any plausibly authoritative registry that
tracks the reservation of 188.8.131.52.5.2.3, or of its children 184.108.40.206.220.127.116.11,
18.104.22.168.22.214.171.124, and 126.96.36.199.188.8.131.52.
This document then defines the use of 184.108.40.206.220.127.116.11. How do we know that "6"
is free? How will future specifications know that "6" is no longer available?
This document also defines 18.104.22.168.22.214.171.124.1, 126.96.36.199.188.8.131.52.2,
184.108.40.206.220.127.116.11.3, and 18.104.22.168.22.214.171.124.4 for the various hash algorithms.
Assuming this list continues to be added to, how will future specifications
I have a similar question about 126.96.36.199.188.8.131.52.1.
I think my confusion stems from the fact that I was under the impression that
everything under 184.108.40.206 was managed by IANA -- at least, that's my reading of
To be clear: if I understand the situation correctly, I recognize that there
may be a bigger problem here that is beyond the remit of this document to
solve; however, I think it would be reasonable to not make the existing problem
worse. In particular -- and again, I may simply be confused here -- I would
expect this document to at least ask IANA to create a table at
https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml that keeps
track of the children of 220.127.116.11.18.104.22.168.
> When the KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned
> as described in Section 3.2.2 of [RFC4556], implementations
> conforming to this specification can OPTIONALLY send back a list of
The term "OPTIONALLY" is not defined in RFC 2119, although I believe the
intention of this passage is to make a normative statement consistent with the
RFC 2119 definition of "MAY" / "OPTIONAL". Unfortunately, we only get an
auxiliary verb and an adjective from RFC 2119... no adverbs. Please rephrase to
use "OPTIONAL" or "MAY".
> When the client's X.509 certificate is rejected and the
> KDC_ERR_DIGEST_IN_SIGNED_DATA_NOT_ACCEPTED error is returned as
> described in Section 3.2.2 of [RFC4556], implementations conforming
> to this specification can OPTIONALLY send a list of digest algorithms