Is there a standard on how to sign primitive types?

Question

I am designing a protocol to exchange IOUs (digital promissory notes). These should be digitally signed, but the signature should be independent from the data representation (whether its XML, JSON, binary, little or big endian numbers).

Is there any standard on how to sign a list of strings and primitive types (like integers, floating points, booleans)?

Answer 1

The better question is what is the best format for verifying digitally signed Data primitives.

The answer is xml formatted and signed according to the XAdES standard. XAdES is harmonized with the related standards and many implementations participate in interoperability tests hosted by etsi.

Unless it is easy to verify a digitally signed format, the signature has limited value.

You can sign any bit stream and store/maintain the signature as a detached signature. But then you and the relying parties (the recipients) need to deal with two files. One for the data and one for the signature.

The advantage of xml with XAdES is that the format enables the signed xml file to include the digital signature.

You can create an equivalent of XAdES for another data format such as json. But a new format has limited use unless it becomes popular and standardized. XAdES has already accomplished this, so it is the way to go.

Added Re: comment--

I want to provide non-repudiation. I understand that I have to save the information I signed. But I was hoping that I don't have to save it as XML but could rather save all values included in the signature in a database (less verbosely) and uniquely reconstruct the signed string from them before verifying.

Technically, you can do that. You'll need to watch out for spacing issues within the xml. But practically, not a good idea. Why:

Proving non-repudiation requires that you meet the applicable burden of proof that the alleged signer really did sign the data.

You may be trying to convince the original signer of this, an expert third party (an auditor) or non-experts (lawyers and juries). You want to make it easy and simple to convince these people. Schemes such as "re-creating" the signed file are not simple to understand compared with "here is the original signed file. Its signature verifies and it was signed with the digital certificate belonging to Susan Signer."

To keep it simple, I'd suggest signing an XAdES XML file. Then extract the data from the file and use it in your dbms. Hang on to the original signed file in your dbms or elsewhere. In case of a dispute, produce the original file and show that it verifies. A second part of the audit would be to show that your dbms has the same data values as the signed XML.

The programming and storage costs of hanging on to the original, signed, xml file are de minimis, when compared with your goal of proving non-repudiation of the data.

By the way, how is the signer's certificate managed? If it is anything less than a QSCD (Qualified Signature Creation Device), such as storing the cert in the file system, then you have another problem: no way to conclusively prove that the certificate wasn't used by an imposter. Use a secure system for signing such as CoSign (my company) or an equivalent system.

Answer 2

There isn't one standard encoding, but you can specify canonical forms for particular encodings.

• For json you could specify that there is no whitespace outside strings and that keys should be sorted in a particular way.
• For ASN.1 there is DER encoding, which is the canonical form of BER.
• There is Cryptographic Message Syntax (CMS), but I don't know much about it.