Subject: [Anima-bootstrap] alternate to domain-certificate-identifier missing from voucher yang

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Mar 2017 11:09:00 -0500

The MASA can use the combination of:
    trusted-ca-certificate plus
      (domain-certificate-identifier.subject xor cn-id xor dns-id)

to indirectly point at the JRC's certificate. There could be a series of
certificates in the chain between the trusted-ca-certificate and the
thing the voucher staples down, clearly.

In the yang, we write about trusted-ca-certificate:

            This field is optional because it may not be needed by all
            bootstrapping protocols.

So I was looking for the other way, where one points right at the
JRC's public key.  I didn't find it.  So I thought: OH, of course,
one could specify a certificate chain of zero length, by putting
the JRC's subjectKeyInfo into trusted-ca-certificate!

Or can I?  I don't think we got the reference in trusted-ca-certificate
correct (and I don't have 5280 on the plane with me. Bad me, disk space is
cheap) to check.  I think that:
       An X.509 v3 certificate structure as specified by RFC 5280,
       Section 4

is too much, I think we just wanted the subjectKeyInfo as suggested
by Sean Turner.

(Okay, I will follow up to my email and check)

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 24 Mar 2017 19:07:29 -0400

Michael Richardson <[email-masked]> wrote:
    > correct (and I don't have 5280 on the plane with me. Bad me, disk space
    > is cheap) to check.  I think that: An X.509 v3 certificate structure as
    > specified by RFC 5280, Section 4

Shouldn't it refer to:
          4.2.1.2.  Subject Key Identifier

We can include the literal DER encoding of the the public key, if we want
a *KEY* here.

    > is too much, I think we just wanted the subjectKeyInfo as suggested by
    > Sean Turner.

This is a hash of public key info. It was, again:
   https://tools.ietf.org/html/rfc7093

abstract:

   This document specifies additional example methods for generating Key
   Identifier values for use in the AKI (Authority Key Identifier) and
   SKI (Subject Key Identifier) certificate extensions.

I think that domain-certificate-identifier could be specifying RFC7093 DER.
We have said DER and binary, and when translated to JSON, that results in
base64 encoding, and we sign that with PKCS7, I think.

Note that if we specify hash of public key, we have to use TLS
key agreement processes that include the public key itself. That's not a big
deal, but it would be wirth making sure that we can all of this for RPK.

---

From: Michael Richardson <[email-masked]>
Date: Sat, 25 Mar 2017 12:00:18 -0400

Kent explained the history of how we got to having the full certificate due
to DTLS making that anchor certificate optional.

I also realize that we can use the extensions in
  https://tools.ietf.org/html/rfc7250#section-3

so that we can bind directly to public keys, which makes me happy.

Michael Richardson <[email-masked]> wrote:
    >> Or can I?  I don't think we got the reference in
    >> trusted-ca-certificate correct (and I don't have 5280 on the plane
    >> with me. Bad me, disk space is cheap) to check.  I think that: An
    >> X.509 v3 certificate structure as specified by RFC 5280, Section 4

    > Shouldn't it refer to: 4.2.1.2.  Subject Key Identifier

    > We can include the literal DER encoding of the the public key, if we
    > want a *KEY* here.

    >    This document specifies additional example methods for generating
    > Key Identifier values for use in the AKI (Authority Key Identifier) and

    > I think that domain-certificate-identifier could be specifying RFC7093
    > DER.  We have said DER and binary, and when translated to JSON, that
    > results in base64 encoding, and we sign that with PKCS7, I think.

    > Note that if we specify hash of public key, we have to use TLS key
    > agreement processes that include the public key itself. That's not a
    > big deal, but it would be wirth making sure that we can all of this for
    > RPK.

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