Re: [Anima-bootstrap] voucher yang

Michael Richardson <> Thu, 02 March 2017 02:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F133F129717 for <>; Wed, 1 Mar 2017 18:39:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ltzTT_V1HO92 for <>; Wed, 1 Mar 2017 18:39:29 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B3F9129407 for <>; Wed, 1 Mar 2017 18:39:29 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 78BED2009E; Wed, 1 Mar 2017 22:01:47 -0500 (EST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id E6CF96381A; Wed, 1 Mar 2017 21:39:27 -0500 (EST)
From: Michael Richardson <>
To: Kent Watsen <>
In-Reply-To: <>
References: <> <>
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: Wed, 01 Mar 2017 21:39:27 -0500
Message-ID: <>
Archived-At: <>
Cc: anima-bootstrap <>
Subject: Re: [Anima-bootstrap] voucher yang
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 02 Mar 2017 02:39:31 -0000

Kent Watsen <> wrote:

    > Hi Michael,

    >> 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.

    > While the registrar can inspect the voucher, it ultimately must pass
    > it to the pledge unmodified.  Also, note that there no "registrar"
    > concept in the NETCONF zerotouch draft.

What I'm saying is that the pledge can't know how the owner was verified.
The pledge actually has to process the same as for "verified" as for
"logged".  It doesn't change the pledge's behaviour.

    >> 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?

    > As the description statement explains, SHA-1 is used because it is
    > interoperable with OpenSSL.  We could hardcode SHA-256, or even allow
    > it be to parameterized, but that would put more code on the pledges,
    > do you want to go this route?

If we have to pick something, let's pick SHA256 for now, or maybe, as I wrote
in the other message I CC to spasm, maybe we should just put the DER itself?

    >> 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.

    > I'm okay with PCRE in theory, but I've read that a compiled stripped
    > library is large, do you know?

I don't know. I don't want either :-)
If I have to pick a regex library (vs shell-style globbing...) then I'd
rather pick PCRE if we can find a stable reference.

    >> leaf nonce {
    >> type string;  // unit64?
    >> I think it should be binary?

    > A 'binary' type would allow the nonce to be any length octet sequence,
    > which is converted to base64 encoded string for JSON.  Is this what
    > you want?

I want as much entropy in as small a space as possible.
string seems to waste 2-bits per byte if it's base64 encoded in a binary
format (CBOR).  If JSON has to base64 encode things, I'm okay with that.

I would assume that integers get network-byte order considerations which
might lead to implementation bugs, where as binary[8] (if such a thing
exists) would not.  I think uint64 might be too small.

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-