Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document

Benjamin Kaduk <kaduk@mit.edu> Sat, 27 June 2020 23:14 UTC

Return-Path: <kaduk@mit.edu>
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 13EAF3A0822 for <anima@ietfa.amsl.com>; Sat, 27 Jun 2020 16:14:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 vkV3UKNWN0M3 for <anima@ietfa.amsl.com>; Sat, 27 Jun 2020 16:14:10 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D57693A0821 for <anima@ietf.org>; Sat, 27 Jun 2020 16:14:09 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 05RNDqES003793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 27 Jun 2020 19:13:54 -0400
Date: Sat, 27 Jun 2020 16:13:52 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Toerless Eckert <tte@cs.fau.de>, Russ Housley <housley@vigilsec.com>, Michael Richardson <mcr+ietf@sandelman.ca>, Anima WG <anima@ietf.org>
Message-ID: <20200627231352.GM58278@kduck.mit.edu>
References: <a0face89-da68-f75d-4a57-4deb9d0f244d@gmail.com> <20200617024412.GA11992@kduck.mit.edu> <9584c5cd-c68d-ddc3-0704-da672842e359@gmail.com> <FB6127DD-A111-4E40-A095-5E3C03AA6660@vigilsec.com> <9406.1592756905@localhost> <3A92516D-B980-4231-9059-EF7234BA8610@vigilsec.com> <20200627054056.GA35664@faui48f.informatik.uni-erlangen.de> <FF181E1F-2B93-47BB-AB45-7F66D880108B@vigilsec.com> <20200627224640.GA41058@faui48f.informatik.uni-erlangen.de> <CABcZeBN_tQgH8ZZmVg82h8-cthm0uQ6b846N71G9NYFSxdUMRQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBN_tQgH8ZZmVg82h8-cthm0uQ6b846N71G9NYFSxdUMRQ@mail.gmail.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/Nr7yre0_-BYBAo254mTVJwLuO6c>
Subject: Re: [Anima] Russ: Re: rfc822Name use in Autonomic Control Plane document
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: Sat, 27 Jun 2020 23:14:11 -0000

My apologies for commenting before having caught up on the whole thread
(I've been pretty sluggish all week and don't want to get even further
behind.)

On Sat, Jun 27, 2020 at 03:58:21PM -0700, Eric Rescorla wrote:
> 
> Taking a step back from the substantive issue, it seems to me that to the
> extent to which their is debate about the meaning of 5280, this is a
> discussion which cannot be resolved entirely on this list, but instead
> needs to involve the LAMPS WG.

This has been a key point that I've (apparently) been failing to make very
well so far.  E.g., while the ANIMA WG has presumably reached consensus on
the use of rfc822Name years ago, I think we also need consensus from LAMPS
before we can be confident that there is IETF consensus.

Also, making even another step back, it seems that there is a key issue of
the CA model in play here, namely "know what you sign".  If we are asking a
CA to sign an rfc822Name, which the CA treats as having email semantics,
but we assign different semantics to that name, then the CA is not actually
in knowledge of what it's signing.  Accordingly, the CA incurs significant
(e.g., legal and financial) risk by making those signatures, and defining
the field in this way gives the impression that we are trying to make an
end-run around CA policies.

-Ben