[SCITT] Constraints on unprotected data in receipt...

[Ray Lutz <[e-mail]>]

Hi SCITT list:

Henk asked me a question the other day and I had more time to think 
about it, and so I am providing these ideas to the list.

The question is: Should the public key appear in the unprotected portion 
of the receipt, or can it be an id of the public key.

The answer I think is driven by a rule I think is appropriate for the 
design of the SCITT architecture.
This rule is that the receipt should be testable without consulting any 
other resource, to a great extent, but indeed not fully.
If the public key is included in the receipt, then we can check the 
consistency of the receipt without an internet connection, and even in 
an air-gapped environment.
If we have only a "public key ID," then that may not comply with this 
rule, bc then the public key has to be looked up using the ID and that 
may not
be possible. Thus, including the public key in the receipt of the SCITT 
service would be the best course.

Given a SCITT receipt, it should be possible to check the consistency 
using the public key without any other information.
Later, and if the user is no longer in an air-gapped isolated network, 
the certificates can be checked etc. to further substantiate the data.

Further, I notice in the architecture docs the idea that the public key 
and private key of a SCITT service has to be consistent for a long 
period of time.
That is obviously not a good idea, as we will need the option of 
rotating keys and upgrading algorithms. So that should not be an 
underlying assumption.
But it also means that there may be a set of keys and with each the 
signing algorithm that need to be maintained to allow the older receipts 
are to be validated.

--Ray




-- 
-------
Ray Lutz
Citizens' Oversight Projects (COPs)
http://www.citizensoversight.org
619-820-5321