[kitten] Adam Roach's No Objection on draft-ietf-kitten-pkinit-alg-agility-05: (with COMMENT)
Datatracker on behalf of Adam Roach <ietf-secretariat-reply@ietf.org> Wed, 06 March 2019 17:08 UTC
Return-Path: <ietf-secretariat-reply@ietf.org>
X-Original-To: kitten@ietf.org
Delivered-To: kitten@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DA951311B5; Wed, 6 Mar 2019 09:08:31 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Datatracker on behalf of Adam Roach <ietf-secretariat-reply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-kitten-pkinit-alg-agility@ietf.org, Robbie Harwood <rharwood@redhat.com>, kitten-chairs@ietf.org, rharwood@redhat.com, kitten@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.93.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <155189211126.358.17565788131106935834.idtracker@ietfa.amsl.com>
Date: Wed, 06 Mar 2019 09:08:31 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/ZgYag5BNEyfEEBVbvGsBMowiWjU>
Subject: [kitten] Adam Roach's No Objection on draft-ietf-kitten-pkinit-alg-agility-05: (with COMMENT)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Mar 2019 17:08:32 -0000
Adam Roach has entered the following ballot position for draft-ietf-kitten-pkinit-alg-agility-05: No Objection 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- 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 work. --------------------------------------------------------------------------- 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. --------------------------------------------------------------------------- §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.
- [kitten] Adam Roach's No Objection on draft-ietf-… Datatracker on behalf of Adam Roach