Re: [Anima-bootstrap] voucher yang

Kent Watsen <> Thu, 02 March 2017 19:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BD58512960D for <>; Thu, 2 Mar 2017 11:13:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id K4aYIGjlScye for <>; Thu, 2 Mar 2017 11:13:00 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4A6C81293EC for <>; Thu, 2 Mar 2017 11:13:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N2GvwEbtf7m5aKO8A0uKGDwDYSqpDluvvnZsYnVXE7I=; b=JgHHBQl/QOPmohIvVzc1q7bEpAfM+AnDcumuX73zXhQZudhJLPUv1sIr2PbNHCCQnfctqL6vdh1Jn55t9NE2ljMHfbsVGO04z6bQRSx/HTWZTPRlNi5ibtprYmVXigkxzdnZQO64eh4pqK35/H4o+mNZs0MR6/ApgT2rq28l7KE=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.2; Thu, 2 Mar 2017 19:12:58 +0000
Received: from ([]) by ([]) with mapi id 15.01.0947.011; Thu, 2 Mar 2017 19:12:58 +0000
From: Kent Watsen <>
To: Michael Richardson <>
Thread-Topic: [Anima-bootstrap] voucher yang
Thread-Index: AQHSke6O/yztceHfnUmp6ovkVBK+rqGAOr6AgACd0ICAAMHCAA==
Date: Thu, 02 Mar 2017 19:12:57 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.1f.0.170216
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 22882381-952b-45da-3bff-08d461a02350
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN3PR0501MB1442;
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:I203doETPTYPuWB+glzXniEe/Kk3qSRwbbuD94mc2tpE6B7eqcckDoDfE9kKPeYu763+2tVKlme71Vu4iiyMmIkqH8KbvQ9l7yyFGaxoFHwK3OTT1HyKFmbK2R0jV6UM/fubxNFcfhteU0AJQGEsrSOOeYxnjCMgNtW2hhk8Vk0ahXU0Eighxyh/IzBtoEbDhX05E/exu2B5unSVH413eOUvLBo0uHZ3L8tP1d5ZeCsYmAHkkhnCtMaOgyb4miHpHdUAjrL+6fT3inye+PJlDiOAbUsskn2wqv9n/Y+IuaYqPu1fLAIw/2BuNhOQ+x5vHcO7QU7/v1DCetX957JF1A==
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123564025)(20161123558025)(20161123562025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442;
x-forefront-prvs: 023495660C
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39450400003)(39860400002)(39840400002)(33656002)(7736002)(6246003)(2900100001)(83506001)(36756003)(122556002)(3660700001)(305945005)(25786008)(6512007)(3846002)(6116002)(6486002)(77096006)(6436002)(4326008)(2950100002)(99286003)(102836003)(6506006)(3280700002)(2906002)(92566002)(189998001)(110136004)(38730400002)(4001350100001)(5660300001)(76176999)(229853002)(8676002)(50986999)(54356999)(8936002)(81166006)(66066001)(53936002)(86362001)(106116001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2017 19:12:57.9954 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442
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 19:13:02 -0000

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

But it does.  Some pledges may be coded to only support 'verified' vouchers.

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

The DER itself works for me (the privacy concern seems minor).  It's also more
code (relative to just using an openssl command line option), but actually it's
one step less code than calculating the SHA256 fingerprint.

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

As discussed in another thread, I'm beginning to think that we should
do away with having a single voucher for many devices, because we'd
want revocations to be as granular as possible.

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

Okay, let's change the nonce to a binary type.