Magic Signatures [OBSOLETE DRAFT]

Abstract

NOTE: This -00 draft has been superseded by draft-panzer-magicsig-01. Please remove references to this draft, other than historical ones.

This document defines a lightweight, robust mechanism for digitally signing nearly arbitrary messages, along with a basic public key infrastructure for discovering the signing keys.

It is intended to be a building block in the construction of other protocols, providing a commonly agreed upon abstraction layer on top of lower level protocols such as Webfinger/LRDD (Eran, E., “LRDD: Link-based Resource Descriptor Discovery,” .) [LRDD], XRD (Eran, EHL. and WN. Will, “Extensible Resource Descriptor (XRD) Version 1.0, Working Draft 13,” .) [XRD], and PKCS (Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.) [RFC3447].

Table of Contents

1.  Introduction
    1.1.  Requirements Language
2.  Definitions
3.  Magic Envelope Definition
    3.1.  Magic Envelope Parameters
    3.2.  The XML Serialization
    3.3.  The JSON Serialization
4.  Provenance in Atom Entries
5.  Provenance in JSON Data Structures
6.  Standalone Magic Envelope Messages
    6.1.  Syndicating Magic Envelope Messages
7.  Encoding of data and sig using base64url
    7.1.  Encoding
    7.2.  Decoding
8.  Signing Messages
9.  Verifying Messages
10.  Simple Public Key Infrastructure
    10.1.  The application/magic-key MIME type
    10.2.  Discovery
11.  Acknowledgements
12.  IANA Considerations
13.  Security Considerations
14.  References
    14.1.  Normative References
    14.2.  Informative References
Appendix A.  Specification Feedback
§  Authors' Addresses

1.  Introduction

The primary goal of Magic Signatures is to enable lightweight and robust public key signing for messages that may be transformed, converted, stored, and reconstituted in arbitrary ways. In order to make this mechanism useful, it also defines a public key discovery protocol that enables recipients to reliably map between pseudonyms for authors and their corresponding public keys.

This mechanism is an alternative to XML-DSig. In the field, XML-DSig has proven to be problematic in applications such as syndication of feeds. Compared to XML-DSig, Magic Signatures offers the following features:

1. Can handle any data format; not tied to XML.
2. Does not require any canonicalization beyond removal of whitespace, so it is much easier to verify messages correctly.
3. Can survive message disassembly, storage into arbitrary systems, and re-constitution without invalidating the signature.
4. Significantly smaller and simpler specification.

Magic Signatures does not attempt to address every XML-DSig use case, so it is best described as a lightweight, robust, and minimal form of digital signatures that can be used and deployed where XML-DSig cannot be relied on. Note that for XML, it is possible to combine both mechanisms.

1.1.  Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

2.  Definitions

Signature:

A digital signature that provably binds a message to a signer's keypair.

Signer:

In this specification, an arbitrary identifier associated with a keypair used in a signature.

Public Key Infrastructure (PKI)

A set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates. This specification uses a very simple, limited PKI.

3.  Magic Envelope Definition

A "Magic Envelope" comprises a message bundled along with a signature for that message, expressed as a series of parameters, and serialized as either XML or JSON. The envelope specifies the data to be signed, the MIME type of the data, the transfer encoding, and the signature.

3.1.  Magic Envelope Parameters

This section describes the semantics of the parameters which are serializion-independent.

data:

The payload covered by the signature, encoded into an ASCII string. This string is guaranteed to be safe to include without escaping as XML text and in JSON strings.

data_type:

The MIME (Freed, N. and N. Borenstein, “Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies,” November 1996.) [RFC2045] type of the payload prior to encoding.

encoding:

The encoding used to convert between the MIME type and the "data" string. In this specification, encoding MUST be the string "base64url", indicating the url safe base64 encoding as described in RFC 4648 (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) [RFC4648]. All implementations MUST support this encoding.

alg:

The algorithm used for the signature. This specification describes only one signature algorithm, "RSA-SHA256", which all implementations MUST support.

sig:

A generated signature. This is a string in the base64url encoded format as described above. It is generated according to "Signing Messages" [ref], and verified according to "Verifying Messages" [ref]. A Magic Envelope has one or more signatures. Each signature has exactly one associated "keyhash" parameter.

keyhash:

A key identifier attached to each generated signature (sig). A keyhash is the base64url-encoded SHA256 hash of the public signing key's magicsig representation. It is used to fingerprint exactly which of several possible keys were used to produce the associated signature string.

3.2.  The XML Serialization

A Magic Envelope XML Document is defined in terms of the XML Information Set, serialized as XML 1.0 [W3C.REC-xml-20040204] and identified with the "application/magic-envelope+xml" media type. Magic Envelope XML Documents MUST be well-formed XML. This specification does not define a DTD, and thus does not require validity (in the sense used by XML).

When used as a standalone XML document, the root element MUST be me:env. When incorporated as a subtree of another XML document, the root of the subtree MAY be either me:env or me:provenance. The me:provenance form indicates that the data is intended for verification of its sibling DOM nodes; the me:env form merely adds a signed envelope to the DOM without implying any particular semantics.

The parameters are mapped to XML elements and attributes as follows. Each parameter MUST appear exactly once per envelope.

The <me:data> element (REQUIRED):

Contains the "data" payload, an ASCII string, as described in Section 3.1 (Magic Envelope Parameters). The element contains one REQUIRED attribute, "type", which contains the value of the "data_type" parameter.

The <me:encoding> element (REQUIRED):

Contains the value of the "encoding" parameter.

The <me:alg> element (REQUIRED):

Contains the value of the "alg" parameter.

The <me:sig> element (REQUIRED):

Contains the value of the "sig" parameter, an ASCII string. MAY be repeated multiple times to record multiple signatures over the same text. MUST have a keyhash attribute containing the "keyhash" value for the signature.

Additional elements not defined by this specification MAY appear as children of the me:env or me:provenance elements, but MUST NOT appear as children of any other element. Processors MUST ignore elements they do not understand.

Example:

<?xml version='1.0' encoding='UTF-8'?>
<me:env xmlns:me='http://salmon-protocol.org/ns/magic-env'>
  <me:data type='application/atom+xml'>
    PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz4KPGVudHJ5IHhtbG5zPS
    dodHRwOi8vd3d3LnczLm9yZy8yMDA1L0F0b20nPgogIDxpZD50YWc6ZXhhbXBsZS5jb20s
    MjAwOTpjbXQtMC40NDc3NTcxODwvaWQ-ICAKICA8YXV0aG9yPjxuYW1lPnRlc3RAZXhhbX
    BsZS5jb208L25hbWUPHVyaT5hY2N0OmpwYW56ZXJAZ29vZ2xlLmNvbTwvdXJpPjwvYXV0a
    G9yPgogIDx0aHI6aW4tcmVwbHktdG8geG1sbnM6dGhyPSdodHRwOi8vcHVybC5vcmcvc3l
    uZGljYXRpb24vdGhyZWFkLzEuMCcKICAgICAgcmVmPSd0YWc6YmxvZ2dlci5jb20sMTk5O
    TpibG9nLTg5MzU5MTM3NDMxMzMxMjczNy5wb3N0LTM4NjE2NjMyNTg1Mzg4NTc5NTQnPnR
    hZzpibG9nZ2VyLmNvbSwxOTk5OmJsb2ctODkzNTkxMzc0MzEzMzEyNzM3LnBvc3QtMzg2M
    TY2MzI1ODUzODg1Nzk1NAogIDwvdGhyOmluLXJlcGx5LXRvPgogIDxjb250ZW50PlNhbG1
    vbiBzd2ltIHVwc3RyZWFtITwvY29udGVudD4KICA8dGl0bGUU2FsbW9uIHN3aW0gdXBzdH
    JlYW0hPC90aXRsZT4KICA8dXBkYXRlZD4yMDA5LTEyLTE4VDIwOjA0OjAzWjwvdXBkYXRl
    ZD4KPC9lbnRyeT4KICAgIA
  </me:data>
  <me:encoding>base64url</me:encoding>
  <me:alg>RSA-SHA256</me:alg>
  <me:sig keyhash="4k8ikoyC2Xh+8BiIeQ+ob7Hcd2J7/Vj3uM61dy9iRMI=">
    EvGSD2vi8qYcveHnb-rrlok07qnCXjn8YSeCDDXlbhILSabgvNsPpbe76up8w63i2f
    WHvLKJzeGLKfyHg8ZomQ
  </me:sig>
</me:env>

3.3.  The JSON Serialization

Magic Envelope JSON MUST be well formed JSON as defined in [RFC4627] (Crockford, D., “The application/json Media Type for JavaScript Object Notation (JSON),” July 2006.). The parameters are serialized into a JSON object as a sequence of name/value pairs for the parameter names "data", "data_type", "encoding", and "alg". These values are represented as JSON strings. The "sig" parameter is represented as a "sigs" name whose value is an array of objects; each object has a "value" with the signature string, and a "keyhash" with the associated "keyhash" parameter.

Additional name/value pairs MAY appear within the JSON object and processors MUST ignore elements they do not understand.

Example:

{
  "data": "
    PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz4KPGVudHJ5IHhtbG5zPS
    dodHRwOi8vd3d3LnczLm9yZy8yMDA1L0F0b20nPgogIDxpZD50YWc6ZXhhbXBsZS5jb20s
    MjAwOTpjbXQtMC40NDc3NTcxODwvaWQ-ICAKICA8YXV0aG9yPjxuYW1lPnRlc3RAZXhhbX
    BsZS5jb208L25hbWUPHVyaT5hY2N0OmpwYW56ZXJAZ29vZ2xlLmNvbTwvdXJpPjwvYXV0a
    G9yPgogIDx0aHI6aW4tcmVwbHktdG8geG1sbnM6dGhyPSdodHRwOi8vcHVybC5vcmcvc3l
    uZGljYXRpb24vdGhyZWFkLzEuMCcKICAgICAgcmVmPSd0YWc6YmxvZ2dlci5jb20sMTk5O
    TpibG9nLTg5MzU5MTM3NDMxMzMxMjczNy5wb3N0LTM4NjE2NjMyNTg1Mzg4NTc5NTQnPnR
    hZzpibG9nZ2VyLmNvbSwxOTk5OmJsb2ctODkzNTkxMzc0MzEzMzEyNzM3LnBvc3QtMzg2M
    TY2MzI1ODUzODg1Nzk1NAogIDwvdGhyOmluLXJlcGx5LXRvPgogIDxjb250ZW50PlNhbG1
    vbiBzd2ltIHVwc3RyZWFtITwvY29udGVudD4KICA8dGl0bGUU2FsbW9uIHN3aW0gdXBzdH
    JlYW0hPC90aXRsZT4KICA8dXBkYXRlZD4yMDA5LTEyLTE4VDIwOjA0OjAzWjwvdXBkYXRl
    ZD4KPC9lbnRyeT4KICAgIA",
  "data_type": "application/atom+xml",
  "encoding": "base64url",
  "alg": "RSA-SHA256",
  "sigs": [
    {
    "value": "EvGSD2vi8qYcveHnb-rrlok07qnCXjn8YSeCDDXlbhILSabgvNsPpbe76
    up8w63i2fWHvLKJzeGLKfyHg8ZomQ",
    "keyhash": "4k8ikoyC2Xh+8BiIeQ+ob7Hcd2J7/Vj3uM61dy9iRMI="
    }
  ]
}

4.  Provenance in Atom Entries

Magic Envelope parameters may be embedded within an Atom Entry to provide verifiable provenance. In this case the Magic Envelope elements are contained within an "me:provenance" root element to signal their purpose.

Example:

<?xml version="1.0" encoding="utf-8"?>
<entry xmlns="http://www.w3.org/2005/Atom">
  <id>tag:example.com,2009:3897938434</id>
  <author><name>E. Xample</name><uri>acct:test@example.com</uri></author>
  <content>Verify this content via me:provenance.</content>
  <title>A verifiable entry.</title>
  <updated>2009-12-18T20:04:03Z</updated>
  <me:provenance xmlns:me="http://salmon-protocol.org/ns/magic-env">
    <me:data type='application/atom+xml'>
    PD94bWwgdmVyc2lvbj0nMS4wJyBlbmNvZGluZz0nVVRGLTgnPz4KPGVudHJ5IHhtbG5zPS
    dodHRwOi8vd3d3LnczLm9yZy8yMDA1L0F0b20nPgogIDxpZD50YWc6ZXhhbXBsZS5jb20s
    MjAwOTpjbXQtMC40NDc3NTcxODwvaWQ-ICAKICA8YXV0aG9yPjxuYW1lPnRlc3RAZXhhbX
    BsZS5jb208L25hbWUPHVyaT5hY2N0OmpwYW56ZXJAZ29vZ2xlLmNvbTwvdXJpPjwvYXV0a
    G9yPgogIDx0aHI6aW4tcmVwbHktdG8geG1sbnM6dGhyPSdodHRwOi8vcHVybC5vcmcvc3l
    uZGljYXRpb24vdGhyZWFkLzEuMCcKICAgICAgcmVmPSd0YWc6YmxvZ2dlci5jb20sMTk5O
    TpibG9nLTg5MzU5MTM3NDMxMzMxMjczNy5wb3N0LTM4NjE2NjMyNTg1Mzg4NTc5NTQnPnR
    hZzpibG9nZ2VyLmNvbSwxOTk5OmJsb2ctODkzNTkxMzc0MzEzMzEyNzM3LnBvc3QtMzg2M
    TY2MzI1ODUzODg1Nzk1NAogIDwvdGhyOmluLXJlcGx5LXRvPgogIDxjb250ZW50PlNhbG1
    vbiBzd2ltIHVwc3RyZWFtITwvY29udGVudD4KICA8dGl0bGUU2FsbW9uIHN3aW0gdXBzdH
    JlYW0hPC90aXRsZT4KICA8dXBkYXRlZD4yMDA5LTEyLTE4VDIwOjA0OjAzWjwvdXBkYXRl
    ZD4KPC9lbnRyeT4KICAgIA
    </me:data>
    <me:encoding>base64url</me:encoding>
    <me:alg>RSA-SHA256</me:alg>
    <me:sig>
    EvGSD2vi8qYcveHnb-rrlok07qnCXjn8YSeCDDXlbhILSabgvNsPpbe76up8w63i2f
    WHvLKJzeGLKfyHg8ZomQ
    </me:sig>
  </me:provenance>
</entry>

5.  Provenance in JSON Data Structures

A Magic Envelope JSON data structure may be embedded within any JSON structure. When this is done to verify the provenance of associated data by augmenting an existing object, the object SHOULD use the key name "provenance" for the object containing the Magic Envelope fields.

6.  Standalone Magic Envelope Messages

The application/magic-envelope+{atom,json} data structures MAY be used standalone, as a drop-in replacement for the data that is encoded in the data element. This would be appropriate where the recipient understands the Magic Envelope specification and can automatically decode the data to recover the original format. For example, instead of POSTing an application/atom+xml type entry to create a new blog post, a client could POST an application/magic-envelope+xml with data of type application/atom+xml.

6.1.  Syndicating Magic Envelope Messages

It may be useful to syndicate Atom entries which have been enveloped and signed. This can be done in two ways: By adding a me:provenance element to the existing Atom entry and essentially duplicating its content in a signed me:data element, or by completely replacing each signed Atom entry with the corresponding me:env element.

Feed processors who understand Magic Signatures SHOULD treat me:env elements which verify correctly as if the underlying Atom entry had been sent. The semantics of me:env elements whose signatures cannot be verified are undefined by this specification; processors MAY ignore them, produce an error, attach a warning, or perform other actions as required by their security model. [TODO5] (JP: Talk about security models somewhere; clearly delineate where this spec leaves off and referencing specs need to provide a model.)

7.  Encoding of data and sig using base64url

The data and sig fields of a Magic Envelope are encoded as armored ASCII strings using a procedure chosen to be robust in the face of various types of transports and storage systems. Specifically, the encoded form is safe to include directly as text in XML, a string in JSON, a parameter in URLs, or as form data, without escaping. This section defines the mapping between arbitrary binary data (a stream of octets) and the armored form (an ASCII string). The ASCII string is also chosen so as to be a valid and equivalent UTF-8 string.

7.1.  Encoding

The basic procedure is to use the URL and Filename safe variant of the base64 encoding as described in RFC 4648 (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) [RFC4648], section 5, hereafter known as "base64url" encoding. The result is a string that consists only of the ASCII alphanumeric characters along with '-' and '_', and possibly '='. In regular expression form, this is "^[A-Za-z0-9\-_]*=?=?=?$". This is the normalized form of the encoded data, and is the basis for the octet sequence that is used to generate the digital signature. Implementations and transports MAY add arbitrary whitespace (ASCII values 0x09-0x0D and 0x20) anywhere in this string after signing but before output so as to, e.g., comply with line length restrictions in certain environments.

7.2.  Decoding

The basic procedure is the reverse of encoding, with the additional step that whitespace from the input should be ignored. This is necessary for robustness because some transports may insert whitespace, and is useful to allow for human readable formatting of documents in any case.

1. Normalize the string by removing all whitespace characters from input.
2. Base64url decode the resulting string to produce the original binary data.

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.

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 alternative 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).

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).

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).

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"

11.  Acknowledgements

TODO.

12.  IANA Considerations

This specification introduces three new media types.

The MIME media type for the XML serialization of a Magic Envelope is application/magic-env+xml.

Type name: application

Subtype name: magic-env+xml

Required parameters: n/a

Optional parameters: n/a

The MIME media type for the unique JSON serialization of a Magic Envelope is application/magic-env+json, though application/json is also appropriate.

Type name: application

Subtype name: magic-env+json

Required parameters: n/a

Optional parameters: n/a

The MIME media type for key(pairs) is application/magic-key.

Type name: application

Subtype name: magic-key

Required parameters: n/a

Optional parameters: n/a

13.  Security Considerations

TODO. See RFC 3552 (Rescorla, E. and B. Korver, “Guidelines for Writing RFC Text on Security Considerations,” July 2003.) [RFC3552] for a guide.

14.  References

14.1. Normative References

14.2. Informative References

Appendix A.  Specification Feedback

The primary driver of this specification is the Salmon protocol. Feedback on this specification is thus welcomed via the salmon-discuss mailing list, salmon-protocol@googlegroups.com. For more information, see the Salmon discussion group.

Authors' Addresses