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."
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
Precedence: list

--=-=-=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable


>   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-0=
3,
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 k=
ey
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.
=20=20=20=20=20
  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.
=20=20=20=20=20
  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.

=2D-=20
]               Never tell me the odds!                 | ipv6 mesh network=
s [=20
]   Michael Richardson, Sandelman Software Works        | network architect=
  [=20
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails  =
  [=20
=09


--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJZZzuiAAoJEJVM4Vb9/EKQsLAH/iM6Q4b5D1tjBgGlqLUmAOzU
TMXlX6uEIM0dVm9mIqgDLfIfM7TuHSDuwyI18fpyObe7ZJO7yEWy4pyljpXSceAv
p8MN13lpMxuNKQtBkGf6Snt/kEBHgWN6yA8GcDqZKO0nYdQ0+sWbxC4AfCLeZRNs
3Z4oD0TanX8iGOmomEJ3zUb2HPjmfhleMKGclib/7kV5xwWa5E8n/cGj166VJXEQ
IzMZGxJJ6nREqKdmnebjIBQ3HVEdwGYGntk9PtGri3gL7NqCj0TIoKOV8FPFzWlb
Y74HXMNvfYJ3b9KG5MMJQbrDtVhiqdip5ew7mf8niaTijjslpCdVxbxDVYOvIIU=
=Ydx0
-----END PGP SIGNATURE-----
--=-=-=--