[kitten] Adam Roach's Discuss on draft-ietf-kitten-pkinit-alg-agility-05: (with DISCUSS and COMMENT)

[Datatracker on behalf of Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-ietf-kitten-pkinit-alg-agility-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-kitten-pkinit-alg-agility/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks to everyone who has worked on this over the past several years. I have
one "discuss DISCUSS" that I suspect may be a misunderstanding on my part
about how Kerberos deals with OIDs in general. If so, please bear with my
ignorance.  I just want to make sure something important isn't being
overlooked.

I can see in
https://www.iana.org/assignments/smi-numbers/smi-numbers.xml#smi-numbers-26
that the OID 1.3.6.1.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 1.3.6.1.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 1.3.6.1.5.2.3, or of its children 1.3.6.1.5.2.3.1,
1.3.6.1.5.2.3.2, and 1.3.6.1.5.2.3.3.

This document then defines the use of 1.3.6.1.5.2.3.6. How do we know that "6"
is free? How will future specifications know that "6" is no longer available?

This document also defines 1.3.6.1.5.2.3.6.1, 1.3.6.1.5.2.3.6.2,
1.3.6.1.5.2.3.6.3, and 1.3.6.1.5.2.3.6.4 for the various hash algorithms.
Assuming this list continues to be added to, how will future specifications
avoid collisions?

I have a similar question about 1.3.6.1.5.2.4.5.1.

I think my confusion stems from the fact that I was under the impression that
everything under 1.3.6.1 was managed by IANA -- at least, that's my reading of
RFC 1155.

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 1.3.6.1.5.2.3.6.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

§4:

>  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".

---------------------------------------------------------------------------

§5:

>  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

Same comment as above.