Re: [Anima] creating iDevID certs with openssl

Robert Moskowitz <> Fri, 25 August 2017 17:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 256E6132BD3 for <>; Fri, 25 Aug 2017 10:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c-ln0MNJ5QWV for <>; Fri, 25 Aug 2017 10:46:39 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 45000132961 for <>; Fri, 25 Aug 2017 10:46:39 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2265762282; Fri, 25 Aug 2017 13:46:38 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with LMTP id pGI6SZ09mPmJ; Fri, 25 Aug 2017 13:46:30 -0400 (EDT)
Received: from (unknown []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 269A86226D; Fri, 25 Aug 2017 13:46:28 -0400 (EDT)
To: Kent Watsen <>, Michael Richardson <>
Cc: "" <>
References: <> <> <> <> <>
From: Robert Moskowitz <>
Message-ID: <>
Date: Fri, 25 Aug 2017 13:46:24 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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 17:46:46 -0000

On 08/25/2017 09:36 AM, Kent Watsen wrote:
>> 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
> chains.

Please read:

VIktor gives his views of what works in the field.  I have found Viktor 
to be a great help, and tends to really know what works. Besides on the 
openssl-user list, he is on the postfix-user list.
>> 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.

Most systems running netconf have the storage capacity for this.  I 
would think.

In my auto meetings, many of the devices they are discussing do not have 
this option.

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

I think PKCS is mentioned twice in the bootstrap draft.  Nothing about 
iDevID format, for example.  802.1AR does not say anything about iDevID 
(or lDevID) format.

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

For next week.