10.  Simple Public Key Infrastructure

This section defines a public key infrastructure based on URI discovery, as defined in [ref LRDD]. Specifically, given a URI such as “acct:bob@example.com” or “http://example.com/bob”, the corresponding public key(s) for that identifier can be found via Webfinger/LRDD discovery for links of type rel=”magic-public-key”. This specification defines a new MIME type for simple RSA public key(pairs).

---

TOC

10.1.  The application/magic-key MIME type

The application/magic-key format is a very minimal format for representing public key data. It consists of a string of ASCII text, separated into 3 components, with components separated by a “.” (0x2E) character. The first component is the key type; this specification only defines the “RSA” key type for future upgradeability. Thus a magic key consists of the string “RSA.modulus(n).exponent(e)” The pair (n, e) is used as input to RSASSA-PKCS1-V1_5-VERIFY.

Each of the components is first represented as an integer in network byte order (big endian) and encoded via the “base64url” mechanism described in Section 3.1 (Magic Envelope Parameters).

---

TOC

10.2.  Discovery

This section defines how to map from a URI based identifier to a public signing key for that identifier. Though the exact mechanism for a verifier to determine the identifier of the signer is outside the scope of this specification, the identifier MUST appear within the “data” parameter and therefore be covered by the signature, and the public key ultimately discovered using the identifier MUST hash to the “keyhash” parameter associated with the signature. (Note that the latter requirement is is for efficiency rather than security.) Many existing formats contain authorship or sender fields and these SHOULD be used or extended. Specifications which rely on this one for digital signatures MUST specify a format-dependent model for determining potential signer URIs given the signed data. This specification describes the subsequent step: How to take a general URI and map it to a public signing key.

Given an identifier such as acct:bob@example.com or http://example.org/, first perform discovery per Webfinger/LRDD (Eran, E., “LRDD: Link-based Resource Descriptor Discovery,” .) [LRDD]. Once an XRD for the identifier is located, retrieve the href value(s) for all links with rel=”magic-public-key”. Each identified resource is a valid public signing key.

Note that the data: URI scheme MAY be used, so that a public key can be embedded completely within an XRD file (and covered by its security). Alternatively the key can be stored elsewhere and retrieved via a secure connection.

Among the keys found, select the key to use for verification by using the one whose SHA-256 hash matches the “keyhash” parameter of the signature being processed. Note that it is possible for one signature to be verified but others to fail, and for only one of several potential signers to actually have a verified signature. Specifications which rely on this one MUST specify the semantics in these cases.

Example: href=”data:application/magic-public-key,RSA.mVgY8RN6URBTstndvmUUPb4UZTdwvwmddSKE5z_jvKUEK6yk1u3rrC9yN8k6FilGj9K0eeUPe2hf4Pj-5CmHww.AQAB”

9.  Verifying Messages

Verifying a message signature consists of verifying that “sig” is a valid signature for “data” using “alg”. This specification defines only the “RSA-SHA256” verification algorithm, meaning the RSASSA-PKCS1-v1_5 verification algorithm from RFC 3447 (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) [RFC3447] section 8.2.1.

The verification is performed by executing RSASSA-PKCS1-V1_5-VERIFY ((n, e), M, S), where (n ,e) comprise the public key, M is the message string documented in Section 8 (Signing Messages), and S is the decoded value of a selected “sig”. (Note that this algorithm creates the emsa byte sequence as in Section 8 (Signing Messages) and then performing RSA verification using (n, e), emsa, and S.)

The scope of the verification covers only the contents of the Magic Envelope itself. In some cases, e.g., when using envelope data as provenance for enclosing data, the decoded “data” value must be checked against or override the enclosing data. A secure if lossy mechanism is to throw away the enclosing information and replace it with the output of the decoded “data”. Another altnernative is to compare trees, override with signed information where there are conflicts, and annotate signed parts. The correct mechanism depends on the security model required by the processor and is outside the scope of this specification.

The public key (n, e) is obtained using the simple public key infrastructure described by Section 10 (Simple Public Key Infrastructure).

8.  Signing Messages

Signing a message consists of signing the contents of “data” using the “alg”. This specification defines only the “RSA-SHA256” algorithm, meaning the RSASSA-PKCS1-v1_5 signature algorithm from RFC 3447 (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) [RFC3447] section 8.2, also known as PKCS#1, using SHA-256 as the hash function for EMSA-PKCS1-v1_5.

The signature is computed as signature_octets = RSASSA-PKCS1-V1_5-SIGN (K, M), where K is the private signing key and M is the message string given below.

M is produced by concatenating the following substrings together, separated by periods (ASCII 0x2E):

1. The armored string for “data” produced by Section 7.1 (Encoding)
2. The Base64url encoding of the “data_type” parameter
3. The Base64url encoding of the “encoding” parameter
4. The Base64url encoding of the “alg” parameter

For example, if the armored data is “Tm90IHJlYWxseSBBdG9t” with MIME type application/atom+xml, then m would be the string: “Tm90IHJlYWxseSBBdG9t.YXBwbGljYXRpb24vYXRvbSt4bWw=.YmFzZTY0dXJs.UlNBLVNIQTI1Ng==”

For convenience we summarize the steps for the required EMSA-PKCS1-v1_5 with RSA-SHA256 algorithm here. In the following, ‘+’ means string concatenation.

1. Let hash = the SHA256 hash digest of M
2. Let prefix = the constant byte sequence [NOTE1] (JP: The octets are Elvish, of an ancient mode, but the language is that of ASN.1, which I will not utter here. But this in the Common Tongue is what is said, close enough:) [0x30, 0x31, 0x30, 0xd, 0x6, 0x9, 0x60, 0x86, 0x48, 0x1, 0x65, 0x3, 0x4, 0x2, 0x1, 0x5, 0x0, 0x4, 0x20]
3. Let k = the number of bytes in the public key modulus
4. Let padding = ‘\xFF’ repeated (k - length(prefix+hash) - 3) times
5. Let emsa = ‘\x00’ + ‘\x01’ + padding + ‘\x00’ + prefix + hash
6. RSA sign the emsa byte sequence

The signature is then encoded as in Section 7.1 (Encoding) and the resulting ASCII armored string stored as a “sig” signature. The associated “keyhash” is the base64url encoded respresentation of the SHA-256 hash of public key’s application/magic-key representation.