[Anima-bootstrap] Discussion re. encoding of ACP parameters in LDevID

Toerless Eckert <eckert@cisco.com> Tue, 14 June 2016 23:34 UTC

Return-Path: <eckert@cisco.com>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA4C12D19B for <anima-bootstrap@ietfa.amsl.com>; Tue, 14 Jun 2016 16:34:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.947
X-Spam-Level:
X-Spam-Status: No, score=-15.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 Bv79YIGNqy-f for <anima-bootstrap@ietfa.amsl.com>; Tue, 14 Jun 2016 16:34:10 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C192612B053 for <anima-bootstrap@ietf.org>; Tue, 14 Jun 2016 16:34:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3138; q=dns/txt; s=iport; t=1465947250; x=1467156850; h=date:from:to:subject:message-id:mime-version; bh=0bPpMFbFgDFYfNGUzZaCiu9nkooYL3YokHF6r4oTHUc=; b=AiD8QfD0+x++a56rDRQliNeEIIju2Gvp00rNDwC12suJySEud/xw5OiR CNtcLnEDG+0O/ZCyx8OQNUxdnV+Qw1wEpCqhB43/XZK4tgZ8SbpF3fpbL gJFC7cuV27YZcJD6mrxojrP75nNj8LtCZdCea/88NRqlO+6vqnSW+Cniy Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AGAgCLk2BX/5NdJa1dgz6BU7s4I4FWh?= =?us-ascii?q?044FAEBAQEBAQFlJ4UMezQFXIgwnQGgawEKAQEBI48GDwIBhXcFjXB0iX+BMYx?= =?us-ascii?q?uCo8ij3QeNoQOHDKIU4E1AQEB?=
X-IronPort-AV: E=Sophos;i="5.26,473,1459814400"; d="scan'208";a="113329152"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2016 23:34:09 +0000
Received: from mcast-linux1.cisco.com (mcast-linux1.cisco.com [172.27.244.121]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u5ENY90S004153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <anima-bootstrap@ietf.org>; Tue, 14 Jun 2016 23:34:09 GMT
Received: from mcast-linux1.cisco.com (localhost.cisco.com [127.0.0.1]) by mcast-linux1.cisco.com (8.13.8/8.13.8) with ESMTP id u5ENY8wZ017820 for <anima-bootstrap@ietf.org>; Tue, 14 Jun 2016 16:34:08 -0700
Received: (from eckert@localhost) by mcast-linux1.cisco.com (8.13.8/8.13.8/Submit) id u5ENY8tk017819 for anima-bootstrap@ietf.org; Tue, 14 Jun 2016 16:34:08 -0700
Date: Tue, 14 Jun 2016 16:34:08 -0700
From: Toerless Eckert <eckert@cisco.com>
To: anima-bootstrap@ietf.org
Message-ID: <20160614233408.GI31598@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.4.2.2i
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/RrA27bOTGW8GzIqXcwMhzsgcyOk>
Subject: [Anima-bootstrap] Discussion re. encoding of ACP parameters in LDevID
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Jun 2016 23:34:12 -0000

Thanks for starting the discussion about how to encode the parameters
needed for the ACP in the LDevID. Wanted to summarize so folks, especially
those who where not on the weekly call can chime in, and propose one
encoding as well:

So, For the ACP we had agreed a long time ago that we would "somehow"
encode the IPv6 address used by the ACP and the domain-name of the ACP
into the LDevID. The IPv6 address is lifetime stable, aka: an identifier,
so appropriate for the LDevID.

One highly desirable goal of the AN certificate is that it could be used
not only for ACP forming but also for other purposes. Therefore, in an
ideal world the cert parameters used to encode domain-nae and IPv6 address
should be newly defined parameters: This would allow that any other use
of the certificate could freely choose its parameters in the cert and not
be in conflict with the ACP IPv6/domain-name.

During the call Max and MichaelR heavily chimed on a pragmatic approach
where we would not define new parameters, because that could easily break
any pre-existing ASN.1 parser in any code that would see the certificate.

So we ended up discussing which existing parameter would least collide:

'subjectname' and 'ou' parameters are already heavily used so not
good contenders when we want to avoid conflicting data.

MichaelR suggested AltName, which is a list of "names", each one with
a type. IP address and Domain-name are both types. We discussed how those
could be used. 

  - It is very likely that a Domain-Name might already be used for some
    other purpose. Of course it is possible to have multiple Domain-Names,
    but then it wuold be tricky to figure out which of the domain names
    is the one of the ACP (possible, but tricky).
  - An IPv6 address seems to be much less likely to be used, Max was saying some
    systems using certs to authenticate IPsec connections might use them though
    (if i remember correctly)

There are a few other AlName types, but most of them where structured,
eg: similar to subject-name with 'ou' fields or the like.

So: My Favourite is actually the rfc822addr. Aka: An email-address:

     anima.acp+FD99:B02D:8EC3:0:200:0:6400:1@example.org

Aka: The domain part is simply the domain name for the ACP. The
user-name part is a fixed username value of "anima.acp" followed by +,
followed by the IPv6 ACP address.

Not a new field but existing. Very little used. If it was ever used, it
would most likely be informational, aka: not used in any protocol,
except if it was a user-certificate, which is most likely exactly what an
AN domain-certificate is not.

Encoding is choosen to make it explicitly recognizeable by humans and
machine process, in case there is actually another email address.

Worst case: This address format could even be used as an email address,
and given how the IPv6 address is after the +, it actually is to
most modern email systems just a single user (anima.acp) with just a modifier
part (ipv6 address), so easy to set it up to be routed to one mailbox
if anyone desires to do so.

Cheers
    Toerless