Re: [Anima] creating iDevID certs with openssl
Robert Moskowitz <rgm-sec@htt-consult.com> Fri, 25 August 2017 17:46 UTC
Return-Path: <rgm-sec@htt-consult.com>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256E6132BD3 for <anima@ietfa.amsl.com>; Fri, 25 Aug 2017 10:46:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-ln0MNJ5QWV for <anima@ietfa.amsl.com>; Fri, 25 Aug 2017 10:46:39 -0700 (PDT)
Received: from z9m9z.htt-consult.com (z9m9z.htt-consult.com [50.253.254.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45000132961 for <anima@ietf.org>; Fri, 25 Aug 2017 10:46:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 2265762282; Fri, 25 Aug 2017 13:46:38 -0400 (EDT)
X-Virus-Scanned: amavisd-new at htt-consult.com
Received: from z9m9z.htt-consult.com ([127.0.0.1]) by localhost (z9m9z.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id pGI6SZ09mPmJ; Fri, 25 Aug 2017 13:46:30 -0400 (EDT)
Received: from lx120e.htt-consult.com (unknown [192.168.160.12]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by z9m9z.htt-consult.com (Postfix) with ESMTPSA id 269A86226D; Fri, 25 Aug 2017 13:46:28 -0400 (EDT)
To: Kent Watsen <kwatsen@juniper.net>, Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "anima@ietf.org" <anima@ietf.org>
References: <d64b22cd-807d-2598-7f2d-2ef07534724b@htt-consult.com> <581cee9d-2004-e684-45c3-404f5bbbe297@htt-consult.com> <3748.1503546335@obiwan.sandelman.ca> <b0ed111a-70cf-8ed5-9a5e-001e6d608018@htt-consult.com> <2FF545F0-6618-4CE3-8416-273A5EDD1C53@juniper.net>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <99b486aa-b1ec-d488-13f3-2f7bede32e88@htt-consult.com>
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: <2FF545F0-6618-4CE3-8416-273A5EDD1C53@juniper.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/A1pIyi3DWpAl9VbWwhNJRXAAOuA>
Subject: Re: [Anima] creating iDevID certs with openssl
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=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: https://mta.openssl.org/pipermail/openssl-users/2017-August/006374.html 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. >> https://tools.ietf.org/html/rfc5246#section-7.4.2 >> 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: > https://github.com/netconf-wg/zero-touch/tree/master/openssl-test. For next week. Bob
- [Anima] creating iDevID certs with openssl Robert Moskowitz
- Re: [Anima] creating iDevID certs with openssl Robert Moskowitz
- Re: [Anima] creating iDevID certs with openssl Kent Watsen
- Re: [Anima] creating iDevID certs with openssl Robert Moskowitz
- Re: [Anima] creating iDevID certs with openssl Robert Moskowitz
- Re: [Anima] creating iDevID certs with openssl Robert Moskowitz
- Re: [Anima] creating iDevID certs with openssl Robert Moskowitz
- Re: [Anima] creating iDevID certs with openssl Michael Richardson
- Re: [Anima] creating iDevID certs with openssl Michael Richardson
- Re: [Anima] creating iDevID certs with openssl Michael Richardson
- Re: [Anima] creating iDevID certs with openssl Robert Moskowitz
- Re: [Anima] creating iDevID certs with openssl Kent Watsen
- Re: [Anima] creating iDevID certs with openssl Robert Moskowitz
- Re: [Anima] creating iDevID certs with openssl Michael Richardson
- Re: [Anima] creating iDevID certs with openssl Michael Richardson
- Re: [Anima] creating iDevID certs with openssl Robert Moskowitz
- Re: [Anima] creating iDevID certs with openssl Robert Moskowitz