On 2019-05-26 11:54 p.m., Jim Schaad wrote:
Couldn't we send a hash of identity in (2) and (3), and to do this we need
a
new element in the constrained voucher. This I've given the mouthful name
of: proximity-registrar-sha256-of-subject-public-key-info
and: pinned-sha256-of-subject-public-key-info
(knowing that the YANG->SID process will turn this into a small integer).
Fixing on a single hash function would probably be frowned upon by the IESG.
The lack of algorithm flexibility would be an issue.
I've been thinking about this a bit.
Algorithm flexibility involves two things:
1) ability to encode other algorithms. This is easy, write some new
YANG. That involves more than a simple IANA action, but is equivalent
to a more complex action, i.e. "Specification Required". Ultimately, it
involves allocating a SID, which could be a rather simple IANA action.
2) deciding how/when to use the new algorithm.
The voucher-request travels from the pledge to the MASA, with the
Registrar examining, (auditing, encapsulating, signing), but not needing
to understand everything. So a new algorithm goes by without a lot of
trouble. The pledge creates the hash from the AKE.
The voucher travels from MASA to the pledge, and the Registrar again
just observes.
The pledge can be programmed to use whatever algorithms the MASA
supported at the time the pledge is manufactured.
So I feel satisfied that we can be agile.
The manufacturer simply writes new software and installs it. Except for
allocating a SID, it can be done unilaterally.
_______________________________________________
Anima mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/anima
