Re: [Anima] Pinning of raw public keys in Constrained Vouchers

[Michael Richardson <[e-mail]>]

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.