Signature encoding
DiME, the open and trust-based data format building secure Application-based Public-Key Infrastructures (APKIs) in a breeze.
Last updated
DiME, the open and trust-based data format building secure Application-based Public-Key Infrastructures (APKIs) in a breeze.
Last updated
DiME supports multiple signatures for any item. This enables the use of many different types of public-key networks, from classic trust trees to Web-of-Trust models.
Any signed DiME item, including envelopes, has a signature attached at the end. For envelopes this is indicated by a final colon (‘:’) followed by a signature package, where other items include the signature package after the final dot (‘.’).
Here is an example of a DiME key item signed by three different keys:
Copy pasting the Base64 encoded string following the final dot (‘.’) gives:
By Base64 decoding this string gives the actual signatures, each HEXADECIMAL encoded and separated by a colon (‘:’):
The basic components of a signature, separated by a dot (‘.’) are:
Key name – an identifier for the public key that may be used to verify the signature
Signature – a digital signature encoded using HEXADECIMAL
The key name is generated by the cryptographic suite associated with the key and may thus have different lengths and formats.
Including the name of the key makes it easier to find the key needed to verify the signature and avoids unnecessary verification with keys that does not match the name.
The signature scope defines the set of data that is integrity protected by a digital signature. This scope is different depending if the signature if for an envelope or an individual item. For envelopes the scope is for all items that are attached to it, and for items the scope is only for its own data.
All signatures that may be attached to an item or envelope are always excluded from the scope.
Note that the character separating the item and the signature(s) is not included in the generation and verification of signatures. For envelopes this refers to the final colon (‘:’) and for other items to the final dot (‘.’).
The signature scope is then hashed, creating a thumbprint of the item, which is then used to generate the signature.
This means that in most cases envelopes and items do not need to be decoded for generation and verification of signatures. An exception to this may be when a public key, or key identifier, needs to be reteived from the item iself before verifying a signature.
