[Anima-bootstrap] SHA1 usage in Anima-bootstrap voucher yang

Michael Richardson <mcr+ietf@sandelman.ca> Thu, 02 March 2017 01:52 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9008B129479; Wed, 1 Mar 2017 17:52:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nLU1ch8BUknt; Wed, 1 Mar 2017 17:52:55 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2ED031293F5; Wed, 1 Mar 2017 17:52:55 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id BF7B0E20F; Wed, 1 Mar 2017 21:15:10 -0500 (EST)
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5596F6381A; Wed, 1 Mar 2017 20:52:51 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: SPASM <SPASM@ietf.org>
In-Reply-To: <18454.1488305685@obiwan.sandelman.ca>
References: <18454.1488305685@obiwan.sandelman.ca>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 01 Mar 2017 20:52:51 -0500
Message-ID: <14573.1488419571@obiwan.sandelman.ca>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/AFLHo1WARkRjlF32h3bTFW9L9kw>
Cc: anima-bootstrap <anima-bootstrap@ietf.org>
Subject: [Anima-bootstrap] SHA1 usage in Anima-bootstrap voucher yang
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 Mar 2017 01:52:56 -0000

In the ANIMA ownership voucher YANG model, the absolute latest which you can
currently see at:

we write at line 574:

leaf subject-hash {
    type binary;
    description "The certificate's entire subject field MUST
              match this value.  This value is calculated as the SHA-1
              hash over the TBSCertificate's subject structure, as
              specified by RFC 5280 Section, encoded using
              the ASN.1 distinguished encoding rules (DER), as
              specified in ITU-T X.690.

              Note: by using the SHA-1 algorithm, the result can be
              easily compared to OpenSSL's 'subject_hash'

The voucher is a signed artifact (PKCS7? JWT? CWT? TBD) which indicates to a
particular device who the devices owner is. ("Are you my mummy?" for Dr.Who Fans)

For reasons of key hygiene and longevity, in many cases we do not want to
point at the public key of the registrar directly, but rather indicate that
it's DN=Foo, as signed by CA=Bar.   It seems like there ought be a better way
to do this kind of thing than what we specify above, which is annoyingly SHA1

Can SPASM offer any advice?

We could list the actual DER itself. Encoded, it might actually not be bigger
than a SHA256, for instance.  That might have privacy implications though,
which we'd need to think through.

Some time ago, I proposed replicating the SIDR artifact (RFC3779), and copy
and pasted it to make:

but, we didn't really want to go exactly that way.

Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-