Re: [Anima] creating iDevID certs with openssl

Robert Moskowitz <rgm-sec@htt-consult.com> Thu, 24 August 2017 10:02 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 8B1DD1323A6 for <anima@ietfa.amsl.com>; Thu, 24 Aug 2017 03:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 NMN1PnsqJsU7 for <anima@ietfa.amsl.com>; Thu, 24 Aug 2017 03:02:36 -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 94A8E126B71 for <anima@ietf.org>; Thu, 24 Aug 2017 03:02:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by z9m9z.htt-consult.com (Postfix) with ESMTP id 296C16218F; Thu, 24 Aug 2017 06:02:35 -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 Q4opop7ma6Ki; Thu, 24 Aug 2017 06:02:29 -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 954B162165; Thu, 24 Aug 2017 06:02:26 -0400 (EDT)
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: 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>
From: Robert Moskowitz <rgm-sec@htt-consult.com>
Message-ID: <b0ed111a-70cf-8ed5-9a5e-001e6d608018@htt-consult.com>
Date: Thu, 24 Aug 2017 06:02:21 -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: <3748.1503546335@obiwan.sandelman.ca>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/aiHXzrjoMCEsChjDp8LD7wZLots>
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: Thu, 24 Aug 2017 10:02:39 -0000


On 08/23/2017 11:45 PM, Michael Richardson wrote:
> Robert Moskowitz <rgm-sec@htt-consult.com> wrote:
>      > PEM works.  DER does not work.  I have been finding problems with
>      > openssl command line support for DER.  Which brings up a question for
>      > this list:
>
>      > What format do you expect to see for:
>      > draft-ietf-anima-bootstrapping-keyinfra
>
>      > PEM or DER?
>
>      > PEM supports cert chains, DER does not.
>
> I'm confused by this.
> PEM, to me, is base64 encoded DER, probably with the BEGIN CERTIFICATE stuff.
> If you are saying that PEM files can contain multiple certs, there are DER
> ways to that.  TLS just concatenates I believe.

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.

>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
>
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
>
>
>