[Anima-bootstrap] voucher yang

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 28 February 2017 18:14 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 AB05C129667 for <anima-bootstrap@ietfa.amsl.com>; Tue, 28 Feb 2017 10:14:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 8hZDn2395pWU for <anima-bootstrap@ietfa.amsl.com>; Tue, 28 Feb 2017 10:14:47 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02AB3129664 for <anima-bootstrap@ietf.org>; Tue, 28 Feb 2017 10:14:47 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E88EE2056F for <anima-bootstrap@ietf.org>; Tue, 28 Feb 2017 13:36:59 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 12ABC6381A for <anima-bootstrap@ietf.org>; Tue, 28 Feb 2017 13:14:45 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: anima-bootstrap <anima-bootstrap@ietf.org>
X-Attribution: mcr
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.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-sha256; protocol="application/pgp-signature"
Date: Tue, 28 Feb 2017 13:14:45 -0500
Message-ID: <18454.1488305685@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/HzaBS0dfnE-sEMGtlQKJUOUtL5Y>
Subject: [Anima-bootstrap] voucher yang
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, 28 Feb 2017 18:14:48 -0000

Kent, thanks for the updates to the YANG for the voucher.
Some comments:

      leaf assertion {
        description
          "The assertion is a statement from the MASA regarding how
           the owner was verified.   This statement enables pledges
           to support more detailed policy checks.  Pledges MUST
           ensure that the assertion provided is acceptable before
           processing the voucher.";

I think that it's more about the registrar than the pledge activity.


        leaf subject-hash {
          type binary;
          description

Will there be an update to RFC5280 that will unlock us from SHA-1?
Are all of subject-hash/cn-id/dns-id required, or is it one of the above?

      leaf-list device-identifier {
        type string;
        min-elements 1;
        description
          "A non-empty list of POSIX regular expressions, each
           identifying one or more device identifiers (e.g., serial
           numbers). For instance, the expression could match just
           a single serial number, or it might match a range of
           serial numbers.

           When processing a vouchers, pledges MUST ensure that their
           unique identifier matches at least one regular expression in
           the list.  If no matching regular expression is found, the
           pledge MUST NOT process this voucher.";

Oh, wow. I'd really rather not have a regex here!
I'm more worried about the possible Turing-completeness of the regex rather
than the code space issue.  I think in IoT, if the device hasn't got a
regex parser, then the vendor just won't issue vouchers with regex in them,
so that is okay.
If we have to, I guess I'd rather have a PCRE if we can find a specification
for that.

      leaf nonce {
        type string;  // unit64?

I think it should be binary?


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