Re: [Anima] pinned-domain-certificate and other BRSKI comments

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 13 July 2017 13:53 UTC

Return-Path: <mcr@sandelman.ca>
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 2B624131A70 for <anima@ietfa.amsl.com>; Thu, 13 Jul 2017 06:53:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.308
X-Spam-Level:
X-Spam-Status: No, score=-0.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 9Fq6c2SbvzEL for <anima@ietfa.amsl.com>; Thu, 13 Jul 2017 06:53:15 -0700 (PDT)
Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49B84131A88 for <anima@ietf.org>; Thu, 13 Jul 2017 06:53:12 -0700 (PDT)
Received: from dooku.sandelman.ca (ip-94-113-76-12.net.upcbroadband.cz [94.113.76.12]) by relay.sandelman.ca (Postfix) with ESMTPS id 6F68C1F91C for <anima@ietf.org>; Thu, 13 Jul 2017 13:53:10 +0000 (UTC)
Received: by dooku.sandelman.ca (Postfix, from userid 179) id 8D028694; Thu, 13 Jul 2017 05:21:38 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: anima <anima@ietf.org>
In-reply-to: <9183.1499933298@dooku.sandelman.ca>
References: <9183.1499933298@dooku.sandelman.ca>
Comments: In-reply-to Michael Richardson <mcr+ietf@sandelman.ca> message dated "Thu, 13 Jul 2017 10:08:18 +0200."
X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha1"; protocol="application/pgp-signature"
Date: Thu, 13 Jul 2017 11:21:38 +0200
Message-ID: <16456.1499937698@dooku.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/HcjbFTFp_Yi39NnGXrRUIi1vabA>
Subject: Re: [Anima] pinned-domain-certificate and other BRSKI comments
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, 13 Jul 2017 13:53:16 -0000

>   The 'pinned-domain-cert' element of the voucher contains the domain
>   CA's public key.  The Pledge MUST use the 'pinned-domain-cert' trust
>   anchor to immediately complete authentication of the provisional TLS
>   connection.

At some point we have the option of having just the public key that
we wanted to pin, without any need for a certificate. This was in voucher-03,
as:

       "domain-certificate-identifier": {
         "subject": "base64-encoded Subject DER"
       },

because, I think that the "Subject DER" was a SubjectPublicKeyInfo object.
We have lost this along the way.   I really wanted this. The usage scenario
is a constrained pledge.  It sends it's IDevID as an opaque blob for
it's TLS ClientCertificate, and the Registrar uses a raw public key to
authenticate.  Once the Pledge gets the voucher, it finds the same public key
in the voucher, and it's good.  SubjectPublicKeyInfo is pretty the smallest
structure that can contain a public key.

You may ask, but, what's the point of doing EST at all if you can't speak
enough certificate to actually do an enrollment?  Well, there are three
things that appeal:
  1) if no ACP, an LDevID may not be a goal, the secured EST channel might
     be used for other things. (Such as RESTCONF like session reversal)
     It could be used as an ACE RS/AS connection, and there might be
     symmetric key bound assertions returned and/or evaluated.
     
  2) it could be that IDevID and the MASA/Registrar identies are in RSA,
     (DSA?), or uses bigger/safer ECDSA or EdDSA keys that the Pledge doesn't
     understand, but enrollment will use some simpler subset.
     
  3) the "LDevID" might not be in a PKIX format at all. CWT can do it all.

Am I off the ANIMA scope? Yes.

Can we deal with putting enough ASN1 parsing to pull a public key out
of a self-signed certificate?  Probably... but it will have a cost.

Can we add another field that contains just the public key? Yes.
I'm not sure we can remove the pinned-domain-certificate though, so
we'll be burning those bytes across the link.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [