Subject: [Spasm] SHA1 usage in Anima-bootstrap voucher yang

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Mar 2017 20:52:51 -0500

In the ANIMA ownership voucher YANG model, the absolute latest which you can
currently see at:
   https://github.com/anima-wg/voucher/blob/master/draft-ietf-anima-voucher-01.txt

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 4.1.2.6, 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'
              output.";
}

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

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:
    https://www.ietf.org/archive/id/draft-richardson-anima-idevid-cert-00.txt

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

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Russ Housley <[email-masked]>
Date: Fri, 3 Mar 2017 15:43:04 -0500

> On Mar 1, 2017, at 8:52 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

Michael:

I’m sure you know that there are three important properties for hash
functions.  The are:

(1) collision resistance: it is computationally infeasible to find two
    different inputs that hash to the same output; that is, it is really
    hard to find a and b such that H(a) = H(b).

(2) preimage resistance: it is computationally infeasible to find any
    input that hashes to a given output; that is, given y, it is really
    hard to find x such that H(x) = y.

(3) second-preimage resistance: it is computationally infeasible to find
    a second input which has the same output as a specified input; that
    is, given x, it is really hard to find y such that H(x) = H(y).

Google has announced a collision for SHA-1.  They found to PDF files
that produce the same SHA-1 hash value.

In the system you describe, it seems that an attacker would need to
find a preimage.  For SHA-1, we do not know of a way to do that yet,
but the 160-bit have value produced by SHA-1 is probably not big enough
to be considered safe in today's computing environment.

It seems very odd to be developing a new standards that is using a hash
function that was deprecated at the end of 2010 by NIST.

My personal recommendation ould be to move from SHA-1 to SHA-256.

Russ

---

From: Sean Turner <[email-masked]>
Date: Fri, 3 Mar 2017 16:06:21 -0500

> On Mar 3, 2017, at 15:43, Russ Housley <[email-masked]> wrote:
> 
>> 

And, there’s an RFC for that (TM) :)
https://datatracker.ietf.org/doc/rfc7093/

spt

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Mar 2017 17:51:57 -0500

> I’m sure you know that there are three important properties for hash

Yes.

    > My personal recommendation ould be to move from SHA-1 to SHA-256.

Yes, I agree completely.

What I'm asking for, is if there is a good, well-established container that
we can reference, that essentially gives us the agility to move from SHA1 to
SHA256, and to SHA3 if we have to.

Alternatively, for the use case involved, which is to refer to a certificate
by reference-to-CA + reference-to-DN, if there is some other construct that
would better do what we want, and *also* provide us with the agility we would
like.

(Some ownership vouchers may sit in filing cabinets for a few decades in
a warehouse somewhere)

---

From: Russ Housley <[email-masked]>
Date: Mon, 6 Mar 2017 10:54:42 -0500

> (Some ownership vouchers may sit in filing cabinets for a few decades in

As Sean said, RFC 7093 gives ways that the CA can compute the Subject Key Identifier, and the CA can migrate from SHA-256 if needed in the future.

Russ