Re: [saag] post-X509 cryptographic identities

[Henry Story <[e-mail]>]

On 14 Feb 2020, at 23:26, P. Hallam-Baker <[e-mail]> wrote:

> On Fri, Feb 14, 2020 at 3:42 PM Henry Story <[e-mail]> wrote:
>
>> On 14 Feb 2020, at 20:44, Phillip Hallam-Baker <[e-mail]>
>wrote: 
>>> Syntax is the least important part of PKI but it is a part of
>>> the puzzle. Why oh why do people think canonicalization is relevant? If
>>> you want to be able to verify a signature, you have to keep the original
>>> bits that were signed. End of story.
>>
>> The way to make syntax unimportant is to work on the semantic level. 
>> That is in a way what the Semantic Web does by starting from naming, 
>> and leaving syntax decisions open, allowing multiple ones: 
>> RDF/XML, JSON-LD, Turtle, NTriples, Binary RDF, CSV …
>>
>> But once one moves away from syntax it then becomes very important to
>> canonicalize data, exactly so as to move away from being tied to syntax.
>> A Canoncicalisation of a data then allows one even to discard the 
>> original bytes, if one does not wish to keep to versions of 
>> everything around.
>>
>No, it does not become important to canonicalize. We have been trying and
>failing at that for 30 years and there is no reason to believe things will
>change in the future.

It is true that I am not sure what the computational properties 
of the RDF Normalisation algorithm are. Manu Sporny will have more 
to say on that. 
 
 https://json-ld.github.io/normalization/spec/

>
> Digital signatures authenticate the presentation of the data. If you are
> using Schnorr signatures, the usual form of the signature isn't even
> deterministic. So sign the same octet sequence twice and you get two
> different signatures.

(I wonder if we are talking at cross purposes here.) 
If one has a working Normalisation algorithm, one can reconstruct 
the exact byte sequence from the data at any time. Hence there is no
need to keep the signed byte-sequence around. Clearly one should
not discard the signature itself, but add that to the database.

> I have never seen a situation. where discarding the signed octet sequence
> makes the slightest sense. I am currently using a machine with 64GB of RAM
> and 2TB of disk and that isn't uncommon. A RaPi4 comes with up to 4GB 
> these days. Signed assertions (SAML, PKIX, Mesh) are rarely more than 
> a few KB.

Ah I see. You have a hash of a document which you then sign, and that is
no more than a few KB, which one should keep. I am fine with that. 
And you are right that that is probably all you need if you are signing
a document. But what if you are signing data?

The problem there is that in order to verify the hash, one needs to be able 
to reconstruct from the data the same byte-sequence. The data would usually be a lot larger than a few KB. 

Furthermore the data may be stored in any number of formats which I listed
above including binary formats. So you’d rather like to avoid having to
recompute a signature every time someone requests a different format.
If you tie a signature to a data format, then you can never get rid of the
format in which the data was initially signed. On the other hand if it
is not tied to the format, it can be calculated once, and then served up
whatever the requested format.

>
> The immense complexity of canonicalization means that it should be avoided
> wherever possible. Instead we have people swooping in demanding that it
> be required. Well time to put a lid on that.

So it makes sense for documents that are tied to a byte sequence to not
go through canonicalization. But for data it is a different problem.

Henry