Re: [Anima] creating iDevID certs with openssl

Kent Watsen <> Fri, 25 August 2017 13:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 37378132BF0 for <>; Fri, 25 Aug 2017 06:36:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Status: No, score=-2.02 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=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 ccMClod6enui for <>; Fri, 25 Aug 2017 06:36:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 91208132BED for <>; Fri, 25 Aug 2017 06:36:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=htUskCnbfE9e28uQN/1lAk15UMGP6JKJk/fKTJx2yZg=; b=djuO9I6Ck7Tq2S94jaKekRIs2GfbErOGhZJOo0XEP3TApqPdSW/X1r+7TkaHSE6yvaA7nW1HWiLTBXoUZNqFO01lBv8ojvlB/8gSdyeoUFzp46F8t4u/PFzY0JLWWBP1zoIVlp22KrHir6HEk09Pp0igWIVACz+lpjQNvYUXrE8=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id; Fri, 25 Aug 2017 13:36:46 +0000
Received: from ([]) by ([]) with mapi id 15.20.0013.005; Fri, 25 Aug 2017 13:36:46 +0000
From: Kent Watsen <>
To: Robert Moskowitz <>, Michael Richardson <>
CC: "" <>
Thread-Topic: [Anima] creating iDevID certs with openssl
Thread-Index: AQHTFSUlAUd6DuxmKkeSAjMNgXmwoaKR7E2AgAEAS4CAAGlEgIABiy0A
Date: Fri, 25 Aug 2017 13:36:45 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.20.0.170309
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1252; 6:plwSTlDEhCxpBKFQfhjkCTxyQbiBuUDv+RGPiTq6w5HWCaWQhtTwDHDJNjVSCXrNHYR6cM0/v2hLNxqEaXusVuxi8btvVkFkrdTBvy247dygnwEwNq5Mfl4NqEtiTHBF+XHDWkZSvCr8i+884oB28lSpRNkSmC1BkddnJicqwS1VZbzP7Xk8NW3ksbzpar10G4PKlfVXmBcc/FlNtXbUMWKV3y1tzMI7KIcLb/Ywa7kiOyHnou11w9DIa/a2mBOThZXJcAtE866JQVjnQBdxS9AYgrCX0G0Cq79oY7lvlfp0q9bCoWTh9nlOfiR4fFzblg3feCSLgQwiRtAgpqQ0BA==; 5:rQ2UBtq43MZ0cC67Fp424YJjDLawZAusuduvuUP6Y132f/8COTUAQe05A7aX+hdkzEMnn62FGCytlGXAlAjTtqbeHkfyBQknO/ZXJpOfp8SRicycorDepy4YX44DHfmFg4vllEHWccs63czZTW85hw==; 24:8DfLgUYKbQbkKyZd5eBwu8GatSh5+UAvu1I1S8sjG6QGK0lzQU9a8g0eAOrPuWAGBKKBrQGmegyOEu2AoZk+kF1IRd2V+tn6zRoYAb0KOS4=; 7:3U2q3XS9vDfl6ZU6W3OmJUZefzvGY5+9255+xYtcy71WqT1uIcLi55D4EefhAiwdAs13ru3NYsmQvofgPFEdBuA3aC3mI4ZJ7Ogg6mrZeGv9BJCRpUaLPdeQ2peVI9NPeg0SZAt6RYRB/MyBMzQgin3Y0BRxJLJpSwxA9jBJsUk1cDwNXkf+uK9vxHGI0nBekp8j7E1sPwHO4ezyL/v1EHrgxy3cIkXiUYdlkDjFqtk=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 30109f4e-7a56-43a5-87bf-08d4ebbe5481
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254152)(300000503095)(300135400095)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506095)(300135500095); SRVR:BN3PR0501MB1252;
x-ms-traffictypediagnostic: BN3PR0501MB1252:
x-exchange-antispam-report-test: UriScan:(166708455590820);
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BN3PR0501MB1252; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BN3PR0501MB1252;
x-forefront-prvs: 041032FF37
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(199003)(189002)(6436002)(8936002)(81166006)(8676002)(83506001)(83716003)(229853002)(2906002)(77096006)(6486002)(2900100001)(101416001)(76176999)(54356999)(50986999)(2950100002)(5660300001)(81156014)(105586002)(6506006)(3280700002)(106356001)(6116002)(102836003)(3660700001)(3846002)(53936002)(66066001)(36756003)(478600001)(6512007)(6306002)(33656002)(97736004)(6246003)(966005)(189998001)(99286003)(82746002)(86362001)(4326008)(14454004)(4001350100001)(68736007)(93886005)(7736002)(25786009)(305945005)(551544002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1252;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
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: 25 Aug 2017 13:36:45.9077 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1252
Archived-At: <>
Subject: Re: [Anima] creating iDevID certs with openssl
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 25 Aug 2017 13:36:50 -0000

> On the openssl-user list, the claim was made that concatinating DER 
> certs for a cert chain like you do with PEM does not work with 
> applications.  You have to use PKCS#12, but that includes the private 
> key and is passworded.  I should be able to get the pointer to Viktor's 
> post about this.

Concatenating PEM encodings into a single file is a hack, albeit a super
convenient one.  Instead of PKCS#12, have you looked into PKCS#7? - this
is what is used in the netconf-zerotouch draft for binary certificate

> Here is where you'd find objects in BRSKI:
> 1) TLS ClientCertificate.
>     This should be just the IDevID blob, and in TLS, it's in DER format,
>     if the Registrar needs anything else in the chain, it must chase them down
>     itself.

FWIW, the netconf-zerotouch draft specifies that the device possesses the
IDevID cert *and* all the intermediate certs leading to the manufacturer's
well-known trust-anchor, all of which it provides during crypto handshake.

> 2) TLS ServerCertificate.
>       Note: PKCS #7 [PKCS7] is not used as the format for the certificate
>       vector because PKCS #6 [PKCS6] extended certificates are not used.
>       Also, PKCS #7 defines a SET rather than a SEQUENCE, making the task
>       of parsing the list more difficult.

I don't understand how this relates to PKCS#6.  True about the SET, but this
is minor relative to the tradeoffs.  Can you say some more about this?

> 3) The plege's Voucher Request may be signed using JOSE (using the IDevID)
>     The IDevID is not sent, it's the one from ClientCertificate.
> 4) The registar's Voucher Request may be signed using JOSE, using the
>     Domain Owner's key.  That might not be the same key the Registrar uses
>     to form the EST connection to the MASA (if the Registrar uses client
>     authentication at all).
>     The Domain Owner is within the pinned-domain-cert field.
>     We define it as being DER binary.  In JSON format, that turns into base64
>     encoded.  The reason we go there is that we do not want the
>     ----BEGIN... stuff in there for JSON, in another encoding (CBOR), binary
>     is just fine.

Correct, putting PEM-text into protocols is inappropriate.

> 5) The resulting voucher also uses pinned-domain-cert as well, now signed
>     by the MASA.
>      > What format are the various bootstrap objects (eg vouchers)?  Has
>      > anyone built any of these for PoC?
> PoC?

Aren't the formats defined in the drafts?  E.g., the voucher draft
says it’s a PKCS#7.

Regarding PoC, here's some code to create/validate vouchers: