> 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 [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
