Re: [Anima] representing ACP info in X.509 certs
Toerless Eckert <tte@cs.fau.de> Sat, 27 June 2020 23:10 UTC
Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 AD1223A0808 for <anima@ietfa.amsl.com>; Sat, 27 Jun 2020 16:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.87
X-Spam-Level:
X-Spam-Status: No, score=-0.87 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no 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 rWdpjLi9P6eO for <anima@ietfa.amsl.com>; Sat, 27 Jun 2020 16:10:31 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D1313A07B6 for <anima@ietf.org>; Sat, 27 Jun 2020 16:10:31 -0700 (PDT)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 5A358548068; Sun, 28 Jun 2020 01:10:26 +0200 (CEST)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 449A2440043; Sun, 28 Jun 2020 01:10:26 +0200 (CEST)
Date: Sun, 28 Jun 2020 01:10:26 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Stephen Kent <stkent@verizon.net>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, "Owen Friel (ofriel)" <ofriel@cisco.com>, Eric Rescorla <ekr@rtfm.com>, rfcSELF+fd89b714F3db00000200000064000000+area51.research@acp.example.com, Anima WG <anima@ietf.org>
Message-ID: <20200627231026.GB41058@faui48f.informatik.uni-erlangen.de>
References: <ece7aed3-ede3-5546-4586-1d98d3f71183.ref@verizon.net> <ece7aed3-ede3-5546-4586-1d98d3f71183@verizon.net> <CABcZeBMncZSQOfYsoVS-ZZoSbqZGOg+vQ41OdzAejrRfVozhyQ@mail.gmail.com> <MN2PR11MB3901DD5D6176FEEA43EB9D72DB940@MN2PR11MB3901.namprd11.prod.outlook.com> <6981a76f-76f1-e9b2-319d-473c7a4bc847@verizon.net> <6c4e402f-cce6-daff-aa16-6159340f0802@gmail.com> <9c09debe-3463-a574-46cf-cee86a2c68af@verizon.net> <20200627141911.GA49753@faui48f.informatik.uni-erlangen.de> <e6a46fb5-491e-61cf-1dde-ffaca5988d0b@verizon.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <e6a46fb5-491e-61cf-1dde-ffaca5988d0b@verizon.net>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/BDBgin0BGb3Rp7wDjmO4HIyNKkA>
Subject: Re: [Anima] representing ACP info in X.509 certs
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:10:34 -0000
On Sat, Jun 27, 2020 at 12:35:35PM -0400, Stephen Kent wrote: > Toerless, > > Dear Stephen, > > > > Thank you very much for your thoughts, but i do not think we can move > > the discussion ahead when it stops with non-technical opinion dropping > > statements like "lets not play games" (you) or "i do not think this > > is the right thing to do" (Ben/Russ). > > > > Could you please explain your assertion with technical arguments ? > > The ID goes to great lengths to justify the use of the rfc822Name field for > this context, rather than defining a new data type. If this was the obvious > "right" thing to do, there would not need to be so much text justifying the > choice ("The lady doth protest too much, methinks"). Seriously ? Because some people people do not like it and the text goes to great length to technically explain the choices, your conclusion is that it must be wrong ? Do you call that a technical argument ? > I am not an AD; I don't have a vote on this. The IETF does not vote. We supposedly have rough consensus. I thought that means that it needs to have a sufficient community to be interested work (we hae that, ANIMA WG), and it needs to pass technical challenges. It should IMHO NOT mean that people who do not have a technical arrgument should be able to just succeed by creating a flash mob rejecting the choice and arguing "The lady doth protest too much". Aka: Yes, you did miss the timeline (just about 5 years ongoing) to argue your preference how to encode in the WG before last call. You and everybody ense in this discussion should IMHO stick to providing technical challenges why the ANIMA WG choice can technically not appropriate or suggest better technical choices. But such proposed better technical choices can not simply ignore the requirements described by the solution, and those include the long list that you like to refer to in the negative without (i think) even having read them. (section 6.1.2 numbered lists). > If PKIX were still an active > WG, and if someone came to me and asked about the choice of identifier in > the ACP context, I would say that it was a questionable choice, given 25+ > years of experience with PKI standards and technologies. How about ANY technical argument. If you hae experience, you would be able to make a technical argument. > As I noted in a prior message, when Netscape elected to shove a DNS name > into the common name field, it was a questionable choice, and we have had to > live with the result for 20+ years. If your example was actually applicable to this case, you wuld be able to describe the problem without that example. I replied to your prior email stating that i think that eample is non-applicable to this case. > Elliot Lear's messages suggest that this choice was motivated, > at least in part, by expediency, but he believes > that sometimes expediency is an OK justification in these matters. > Personally, I don't, but, ... What experience do you have with backbone/WAN router/switches and NOC software ecosystems ? If you had any idea how fragmented/duplicated/ and ossified the target deployment environment is, you too would look for appropriate solutions that avoid unnecessary forklift upgrade requirements. Thats exactly what new attribute types introduce to achieve the same degree of ecosystem support as using existing cert attributes. Of course, this means that the solution to use an existing attribute must accordingly match the requirements for such use. So now this document has a long list of explanations why this is the case, and the only rejections we are getting are opinions, but no technical arguments. > Steve > -- --- tte@cs.fau.de
- [Anima] representing ACP info in X.509 certs Stephen Kent
- Re: [Anima] representing ACP info in X.509 certs Eric Rescorla
- Re: [Anima] representing ACP info in X.509 certs Michael Richardson
- Re: [Anima] representing ACP info in X.509 certs Eric Rescorla
- Re: [Anima] representing ACP info in X.509 certs Owen Friel (ofriel)
- Re: [Anima] representing ACP info in X.509 certs Stephen Kent
- Re: [Anima] representing ACP info in X.509 certs Brian E Carpenter
- Re: [Anima] representing ACP info in X.509 certs Stephen Kent
- Re: [Anima] representing ACP info in X.509 certs Michael Richardson
- Re: [Anima] representing ACP info in X.509 certs Eliot Lear
- Re: [Anima] representing ACP info in X.509 certs Toerless Eckert
- Re: [Anima] representing ACP info in X.509 certs Eliot Lear
- Re: [Anima] representing ACP info in X.509 certs Toerless Eckert
- Re: [Anima] representing ACP info in X.509 certs Eric Rescorla
- Re: [Anima] representing ACP info in X.509 certs Toerless Eckert
- Re: [Anima] representing ACP info in X.509 certs Stephen Kent
- Re: [Anima] representing ACP info in X.509 certs Toerless Eckert