IETF Logo Mail Archive

Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 17 June 2020 16:10 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034213A093C; Wed, 17 Jun 2020 09:10:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQmHtd0hhGuc; Wed, 17 Jun 2020 09:10:12 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37F123A0948; Wed, 17 Jun 2020 09:10:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C78338A08; Wed, 17 Jun 2020 12:07:34 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DLFzGBnHtwIV; Wed, 17 Jun 2020 12:07:30 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 27BB1389EF; Wed, 17 Jun 2020 12:07:30 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 41CF4FAC; Wed, 17 Jun 2020 12:10:05 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Eliot Lear <lear@cisco.com>
cc: Benjamin Kaduk <kaduk@mit.edu>, draft-ietf-anima-bootstrapping-keyinfra@ietf.org, tte+ietf@cs.fau.de, anima-chairs@ietf.org, The IESG <iesg@ietf.org>, anima@ietf.org
In-Reply-To: <9B1718CC-EA1F-44E9-B175-B489B5BE7418@cisco.com>
References: <157132132983.10248.1050846253932775557.idtracker@ietfa.amsl.com> <20191018012352.GB43312@kduck.mit.edu> <22000.1572299410@localhost> <20191029031843.GO69013@kduck.mit.edu> <32493.1572639262@localhost> <9B1718CC-EA1F-44E9-B175-B489B5BE7418@cisco.com>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Wed, 17 Jun 2020 12:10:05 -0400
Message-ID: <4603.1592410205@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/uZERkUyn_hMlgbVbt86EWsXANaY>
Subject: Re: [Anima] Benjamin Kaduk's Discuss on draft-ietf-anima-bootstrapping-keyinfra-28: (with DISCUSS and COMMENT)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Jun 2020 16:10:14 -0000

Eliot Lear <lear@cisco.com> wrote:
    > Could we recap a bit on this?  I have commented on the use of the
    > rfc822Name myself, and was a bit concerned about misuse and
    > misinterpretation prior to rfcSELF being present.

The rational for rfc822Name (which I fought against 4 years ago), is that:
  a) it gets through existing CA infrastructure without changes
  b) the human presentation format is *the* format

If ACP needs to wait for upgrades to the Enterprise CA that nobody wants to
touch, because it's voodoo, then ACP is dead.  This is hard enough to get
deployed as it is.


    > Now that it is it represents a new convention.  The question at hand is
    > whether the information found on the LHS could be subject to
    > misinterpretation by non-participants.  I wonder if we could add an EKU
    > as a SHOULD to break the logjam.

Because EKUs are so much easier to get into CAs than otherName is?
Seriously, how does that help at all?

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-

v2.15.0 | Report a Bug | By Email