[Anima-bootstrap] Max: voucher terminology / explanations in next draft round

Toerless Eckert <tte@cs.fau.de> Tue, 13 December 2016 16:59 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
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 51BFB129AE4 for <anima-bootstrap@ietfa.amsl.com>; Tue, 13 Dec 2016 08:59:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.095
X-Spam-Level:
X-Spam-Status: No, score=-7.095 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 qBUr9XnxcMVk for <anima-bootstrap@ietfa.amsl.com>; Tue, 13 Dec 2016 08:59:21 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3E23129B6C for <anima-bootstrap@ietf.org>; Tue, 13 Dec 2016 08:59:04 -0800 (PST)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 72F6658C4AE; Tue, 13 Dec 2016 17:59:03 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 56163B0B0EF; Tue, 13 Dec 2016 17:59:03 +0100 (CET)
Date: Tue, 13 Dec 2016 17:59:03 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: "Max Pritikin (pritikin)" <pritikin@cisco.com>
Message-ID: <20161213165903.GA13281@faui40p.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/VVC9s20bRfJWiAJLXzUSoD910-I>
Cc: "anima-bootstrap@ietf.org" <anima-bootstrap@ietf.org>
Subject: [Anima-bootstrap] Max: voucher terminology / explanations in next draft round
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, 13 Dec 2016 16:59:25 -0000

Hi Max, *:

Wrt to the new text you are trying to work out for voucher terminology,
that is captured in todays notes on the etherpad:

I think that the voucher terminology will be confusing as long
as the name "audit" (voucher) implies the use of a public key (line 144
in etherpad), and the "ownership" (voucher) implies the use of
a certificate (via DN of certificate). audit vs. ownership are
just describing the type of assertion. Whether i want to use
public-key or Cert-DN is IMHO orthogonal (i think we already allow
that in the voucher draft), and it could help if we are also
clearer in the language.

Aka: 
  - classical anima voucher, call it:   public key audit voucher
  - classical netconf voucher, call it: certificate ownership voucher

  - Can i have a certificate audit voucher ? Absolutely!
  - Can i have a public key ownersip voucher ? Absolutely!
  - Can i have a certificate or public key  audit AND ownership voucher ?
    I think yes, but that would be icing on the cake.
    
Which IMHO leaves to explain the differences semantically:
- ownership vs. audit i think is simple
  - ownership: strong assertion by vendor. Can be pricy to support by vendor.
  - audit: lightweight assertion by vendor.

- certificate vs. public key
  - low end solutions may want to be lightweight and not rely fully
    on a certificate system. Just using public key is more lightweight.
  - Even if a system wants to use certificates, relying only on
    public key decouples enrolment from PKI. Aka: more modular design:
    use public key enrolment, and use normal PKI Cert enrolment afterwards
    (using the trust relationship established via the public key). This
    is the option that ANIMA chooses because EST already provides such
    a standalone enrolment method.
  - Including certificate in the voucher allows those vouchers to 
    lie around at an owner much longer. Their validity is as long as that
    of the included CA certificate (eg: >= 10 years). The validity of
    a public key is typically much shorter (eg: <= 1 year).
  - If vouchers are handled "offline" shipped via sneakernet/usb-sticks
    vendor->registrar in a solution where certificates are used (all
    the way into the pledge), certificate vouchers are the complete data
    needed. public key vouchers would require the certificate data to
    be encoded on the side too.

Hope all four are correct. Thats high level how i'd try to explain the
difference. Even if not correct, i hope it makes sense trying to figure
out these type of explanations of differences in the choices our voucher
solution offers.

Cheers
    Toerless