CINXE.COM

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html lang="en"><head><title>JSON Simple Sign 1.0 draft 01</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <meta name="description" content="JSON Simple Sign 1.0 draft 01"> <meta name="keywords" content="Signature, Draft"> <meta name="generator" content="xml2rfc v1.35 (http://xml.resource.org/)"> <style type='text/css'></style> </head> <body> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1"> <tr><td class="header">OpenID Artifact Binding Working</td><td class="header">J. Bradley</td></tr> <tr><td class="header">Group</td><td class="header">Protivity Government Services</td></tr> <tr><td class="header">Internet-Draft</td><td class="header">N. Sakimura (Editor)</td></tr> <tr><td class="header">Intended status: Informational</td><td class="header">Nomura Research Institute</td></tr> <tr><td class="header">Expires: April 3, 2011</td><td class="header">September 30, 2010</td></tr> </table></td></tr></table> <h1><br />JSON Simple Sign 1.0 draft 01<br />json-simple-sign-1_0</h1> <h3>Abstract</h3> <p>This specification defines a very simple signing mechanism to be used for JSON. The signature related parameters together with parameters to be signed are made into a JSON envelope. The signature is calculated over the ascii armoured version of the envelope and the result is recorded either as another JSON object or a string concatenated by a period ".". </p> <h3>Requirements Language</h3> <p>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 <a class='info' href='#RFC2119'>RFC 2119<span> (</span><span class='info'>Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.</span><span>)</span></a> [RFC2119]. </p> <h3>Status of this Memo</h3> <p> This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.</p> <p> Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.</p> <p> Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”</p> <p> This Internet-Draft will expire on April 3, 2011.</p> <h3>Copyright Notice</h3> <p> Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> <p> This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.</p> <a name="toc"></a><br /><hr /> <h3>Table of Contents</h3> <p class="toc"> <a href="#anchor1">1.</a>  Definitions<br /> <a href="#anchor2">2.</a>  Signature Parameters<br />     <a href="#anchor3">2.1.</a>  JSON Serialization<br />     <a href="#anchor4">2.2.</a>  Web Token Serialization<br /> <a href="#anchor5">3.</a>  Creating Signature<br /> <a href="#anchor6">4.</a>  Serialization<br />     <a href="#anchor7">4.1.</a>  JSON Serialization<br />     <a href="#anchor8">4.2.</a>  Web Token Serialization<br /> <a href="#verification">5.</a>  Signature Verification<br /> <a href="#discovery">6.</a>  Key Discovery and the Trust<br />     <a href="#skey">6.1.</a>  Shared key in HMAC-SHA256<br />     <a href="#x509">6.2.</a>  X.509 Certificates<br /> <a href="#IANA">7.</a>  IANA Considerations<br /> <a href="#Security">8.</a>  Security Considerations<br /> <a href="#Acknowledgements">9.</a>  Acknowledgements<br /> <a href="#rfc.references1">10.</a>  References<br />     <a href="#rfc.references1">10.1.</a>  Normative References<br />     <a href="#rfc.references2">10.2.</a>  Informative References<br /> <a href="#anchor11">Appendix A.</a>  An Appendix<br /> <a href="#rfc.authors">§</a>  Authors' Addresses<br /> </p> <br clear="all" /> <a name="anchor1"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.1"></a><h3>1.  Definitions</h3> <p> </p> <p></p> <blockquote class="text"><dl> <dt>Signature</dt> <dd>A digital signature that provably binds a message to a signer's keypair or Hash-based Message Authentication Code that can be used to verify both the data integrity and the authenticity of a message. </dd> <dt>Thumbprint</dt> <dd>A SHA1 of the DER encoded certificate. </dd> <dt>Base64url Encoding</dt> <dd>The URL and Filename safe variant of the base64 encoding as described in <a class='info' href='#RFC4648'>RFC4648<span> (</span><span class='info'>Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.</span><span>)</span></a> [RFC4648], section 5. </dd> <dt>HMAC-SHA256</dt> <dd>Hash-based Message Authentication Code using SHA-256 as the hash function. </dd> <dt>RSA-SHA256</dt> <dd>RSASSA-PKCS1-v1_5 signature algorithm from <a class='info' href='#RFC3447'>RFC3447<span> (</span><span class='info'>Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.</span><span>)</span></a> [RFC3447] section 8.2, also known as PKCS#1, using SHA-256 as the hash function for EMSA-PKCS1-v1_5. </dd> </dl></blockquote> <a name="anchor2"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.2"></a><h3>2.  Signature Parameters</h3> <p>To create signatures, signature parameters that states information such as signature algorithm, certificate location etc. are required. Following is the list of such parameters. </p> <p></p> <ul class="text"> <li>algorithm - OPTIONAL. A String that identifies the algorithm used. This specification defines the following: "HMAC-SHA256", "RSA-SHA256". Defaults to "RSA-SHA256". </li> <li>thumprint - OPTIONAL. A SHA1 of the DER encoded certificate. </li> <li>certs_uri - REQUIRED for "RSA-SHA256". An URI that points to the X.509 public key certificates that can be used to verify the signature. </li> <li>key_id - Used for "HMAC-SHA256". A string that act as a key hint for HMAC-SHA256 signatures. REQUIRED unless it is absolutely clear from the context. </li> </ul> <p>This specification defines two types of serialization for these parameters. They are JSON Serialization and Web Token serialization. </p> <p> </p> <a name="anchor3"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.2.1"></a><h3>2.1.  JSON Serialization</h3> <p>JSON serialization stores these parameters in an array of JSON Objects that holds signature parameters described above. </p> <p> <p>Following is a non-normative example of such envelope for HMAC-SHA256 </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>[ { "key_id": "example.com", "algorithm": "HMAC-SHA256" } ]</pre></div> <p> </p> <p> <p>Following is a non-normative example of such envelope for RSA-SHA256 </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>[ { "certs_uri": "https://example.com/mycerts.pem" }, { "algorithm": "RSA-SHA1", "certs_uri": "https://example.org/mycerts.pem" } ]</pre></div> <p> </p> <a name="anchor4"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.2.2"></a><h3>2.2.  Web Token Serialization</h3> <p>To convert the JSON Serialization in Section 2.1 into Web Token Serialization, base64url eoncode the JSON Object. The result is called "ascii armoured sig_params". </p> <p> <p>Following is a non-normative example of such envelope for HMAC-SHA256. </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>W3sia2V5X2lkIjogImV4YW1wbGUuY29tIiwiYWxnb3JpdGhtIjogIkhNQUMtU0hBMjU2In1d</pre></div> <p> </p> <a name="anchor5"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.3"></a><h3>3.  Creating Signature</h3> <p>The basic steps of creating the string with the signature is as follows: </p> <p></p> <ol class="text"> <li>Base64url encode the data to be signed to obtain "ascii armoured payload". </li> <li>Apply signature over the "ascii armoured payload" by the specified algorithm to obtain the signature. </li> <li>Base64url encode the signature to obtain the "signature string". </li> </ol> <a name="anchor6"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.4"></a><h3>4.  Serialization</h3> <p>This specification defines two types of serialization </p> <a name="anchor7"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.4.1"></a><h3>4.1.  JSON Serialization</h3> <p>JSON Serialization is done by putting the "signature string" and "ascii armoured payload" into the following JSON Envelop. </p> <p></p> <ul class="text"> <li>type - (Optional) URI that signifies the type of this JSON Object. http://openid.net/specs/ab/1.0#jss </li> <li>data - the "ascii armoured payload" </li> <li>data_type - the MIME type OR the Type URL of the "ascii armoured payload" prior to encoding </li> <li>sig_params - An array of signature parameters described in Section 3. </li> <li>sigs - An array of signatures that matches the elements of sig_params. </li> </ul> <p><p>Following is the non-normative example for HMAC-SHA256 signature. Line breaks are for display purposes only. </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{ "type": "http://openid.net/specs/ab/1.0#jss", "data_type": "application/json", "data": "eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsIjAiOiJwYXlsb2FkIn0", "sig_params": [ { "key_id": "example.com", "algorithm": "HMAC-SHA256" } ], "sigs": [ "cfXgu64BQGFSQrY0ZcJBZASMvYvTHu9GQ0YM9rjPSso" ] } </pre></div> <p> </p> <p>Following is the non-normative example. Line breaks and indentations are for display purposes only. </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>{ "type": "http://openid.net/specs/ab/1.0#jss", "data_type": "application/json", "data": "ewogICAgImF1ZGllbmNlIjogImh0dHBzOi8vZXhhbXBsZS1jbGllbnQuY29tL3Jl ZGlyZWN0X3VyaSIsCiAgICAib2F1dGhfdG9rZW4iOiAiYXNkZmprbHNkZmp3b0lq ZmsiLAogICAgIm5vdF9hZnRlciI6IDEyMzQ1Njc4LAogICAgInVzZXJfaWQiOiAi MTIyMyIsCiAgICAicHJvZmlsZV9pZCI6ICIxMjIzIgp9", "sig_params": [ { "certs_uri": "https://example.com/mycerts.pem" }, { "algorithm": "RSA-SHA1", "certs_uri": "https://example.org/mycerts.pem" } ] , "sigs": [ "wm21w_Ppdil0f1HrSyiftu5pWrESclxxC2ON4-Vd1bJj3wlkFb3aoIWrT8TjMiey QKkHNgYwezeyvB_EuXnlOR2LZICXrsfAh65gHHynKI_NEgHHVFTt6msqP-wUru6f hV1cNAzRgZ6iFoNz6fRkWld1Guh5W6mncBfzWooq4OiAWt1JoHQz_pBc1a2cuGIM m5T9T_D8IxKYxnU6H7S56Be0hoaUV37PTbXSAG08_lkl84oSJtJ1Zvxh4c9ycXCd cg-VZ5isJsRnKjAqYeexPKg9683CG3iAB3Y7ZdZelstehpOEvkg9bn8BjkhjoOLk efeN_vZsXJGPvYJIeFav3A", "phLdlfjLEcA5-WOIoIu_CK_eIQV6Mswf9QfDTcpiehiptvDAAIkXo6oyJXVGIB7E RxaZ95-3okshSSj0mG4tFunTmV55nBV8zPoHQoxtWrWiksiVMYyG_yRG11xuCXkp XVper_fsJ1VJkP8FStYA3DY5E4e4FoV_wZsRvMMot88IPIFcFBmlBBGrdfEVkQBD -1sS0PWCLGFOQXrOWZysS9TfiRicPHtmW5gH9hOhGA97n4RwaIMXCjLVjpqvDhT7 8akYpSQSN53PyaSlo99ffgDpc8Asy0FKNVSQpCqYg6G6BFTj12tt0JTIcH5U8RnI fN8bVrcu578pDx1-bwfVkg" ] } </pre></div> <p> </p> <a name="anchor8"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.4.2"></a><h3>4.2.  Web Token Serialization</h3> <p>Web Token Serialization is done by concatenating the "signature string", "ascii armoured sig_params", and "ascii armoured payload" with a period "."(ASCII 0x2E). "ascii armoured sig_params". </p> <p> <p>Following is the non-normative example. Line breaks are for display purposes only. </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>98024bab1652fcc65b4948e71473d19a572ff969e11be10eb1b1deee415dea27 . W3sia2V5X2lkIjogImV4YW1wbGUuY29tIiwiYWxnb3JpdGhtIjogIkhNQUMtU0hBMjU2In1d . ewogICAgImF1ZGllbmNlIjogImh0dHBzOi8vZXhhbXBsZS1jbGllbnQuY29tL3Jl ZGlyZWN0X3VyaSIsCiAgICAib2F1dGhfdG9rZW4iOiAiYXNkZmprbHNkZmp3b0lq ZmsiLAogICAgIm5vdF9hZnRlciI6IDEyMzQ1Njc4LAogICAgInVzZXJfaWQiOiAi MTIyMyIsCiAgICAicHJvZmlsZV9pZCI6ICIxMjIzIgp9 </pre></div> <p> </p> <p>If the sig_params are known out of band, then the "ascii armoured sig_params" can be ommitted. </p> <p> <p>Following is the non-normative example. Line breaks are for display purposes only. </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>98024bab1652fcc65b4948e71473d19a572ff969e11be10eb1b1deee415dea27 . ewogICAgImF1ZGllbmNlIjogImh0dHBzOi8vZXhhbXBsZS1jbGllbnQuY29tL3Jl ZGlyZWN0X3VyaSIsCiAgICAib2F1dGhfdG9rZW4iOiAiYXNkZmprbHNkZmp3b0lq ZmsiLAogICAgIm5vdF9hZnRlciI6IDEyMzQ1Njc4LAogICAgInVzZXJfaWQiOiAi MTIyMyIsCiAgICAicHJvZmlsZV9pZCI6ICIxMjIzIgp9 </pre></div> <p> </p> <p>If multiple sigantures are used where sig[1], sig[2] etc. are the sequence of the signatures created by the respective keys in the signature parameters, signature strings are concatenated with a perid, and then the "ascii armored payload" is concatinated. In this case, "ascii armoured sig_params" MUST NOT be ommitted. Thus, in multiple signatures case, there always are more than four segments. </p> <p> <p>Following is the non-normative example. Line breaks are for display purposes only. </p><div style='display: table; width: 0; margin-left: 3em; margin-right: auto'><pre>wm21w_Ppdil0f1HrSyiftu5pWrESclxxC2ON4-Vd1bJj3wlkFb3aoIWrT8TjMiey QKkHNgYwezeyvB_EuXnlOR2LZICXrsfAh65gHHynKI_NEgHHVFTt6msqP-wUru6f hV1cNAzRgZ6iFoNz6fRkWld1Guh5W6mncBfzWooq4OiAWt1JoHQz_pBc1a2cuGIM m5T9T_D8IxKYxnU6H7S56Be0hoaUV37PTbXSAG08_lkl84oSJtJ1Zvxh4c9ycXCd cg-VZ5isJsRnKjAqYeexPKg9683CG3iAB3Y7ZdZelstehpOEvkg9bn8BjkhjoOLk efeN_vZsXJGPvYJIeFav3A . phLdlfjLEcA5-WOIoIu_CK_eIQV6Mswf9QfDTcpiehiptvDAAIkXo6oyJXVGIB7E RxaZ95-3okshSSj0mG4tFunTmV55nBV8zPoHQoxtWrWiksiVMYyG_yRG11xuCXkp XVper_fsJ1VJkP8FStYA3DY5E4e4FoV_wZsRvMMot88IPIFcFBmlBBGrdfEVkQBD -1sS0PWCLGFOQXrOWZysS9TfiRicPHtmW5gH9hOhGA97n4RwaIMXCjLVjpqvDhT7 8akYpSQSN53PyaSlo99ffgDpc8Asy0FKNVSQpCqYg6G6BFTj12tt0JTIcH5U8RnI fN8bVrcu578pDx1-bwfVkg . WwogICAgewogICAgICAgICJjZXJ0c191cmkiOiAiaHR0cHM6Ly9leGFtcGxlLmNv bS9teWNlcnRzLnBlbSIgCiAgICB9LAogICAgewogICAgICAgICJhbGdvcml0aG0i OiAiUlNBLVNIQTEiLAogICAgICAgICJjZXJ0c191cmkiOiAiaHR0cHM6Ly9leGFt cGxlLm9yZy9teWNlcnRzLnBlbSIgCiAgICB9IApd . ewogICAgImF1ZGllbmNlIjogImh0dHBzOi8vZXhhbXBsZS1jbGllbnQuY29tL3Jl ZGlyZWN0X3VyaSIsCiAgICAib2F1dGhfdG9rZW4iOiAiYXNkZmprbHNkZmp3b0lq ZmsiLAogICAgIm5vdF9hZnRlciI6IDEyMzQ1Njc4LAogICAgInVzZXJfaWQiOiAi MTIyMyIsCiAgICAicHJvZmlsZV9pZCI6ICIxMjIzIgp9 </pre></div> <p> </p> <a name="verification"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.5"></a><h3>5.  Signature Verification</h3> <p>To verify the signature, the verifier MUST have an access to a trusted signature verification key. Trusted key MAY BE established in the following ways: </p> <p></p> <ol class="text"> <li>If the algorithm is HMAC-SHA256, the key MUST BE pre-shared. </li> <li>If the algorithm is asymetric, the key is defined in X.509 certificate. The key MUST be either obtained through the Discovery mechanism defined in Section 6 or looked up in a local key store using the thumbprint. </li> </ol> <p>The verification involves the following steps: </p> <ol class="text"> <li>If the serialization is JSON, parse it. </li> <li>If the serialization is Web Token, split the JSON Token by a period "."(ASCII 0x2E) to obtain the signatures, "ascii armoured sig_params", and the "ascii armoured payload". </li> <li>Base64url decode both the "signature string" and the "ascii armoured payload" to obtain the signature and the envelope respectively. </li> <li>If the algorithm is "HMAC-SHA256", calculate the signature from the payload using the client_secret. </li> <li>If the algorithm is "RSA-SHA256" or "RSA-SHA1", find the corresponding "signature" from "certs_uri" which was found inside "data". Then use RSASSA-PKCS1-v1_5 verification algorithm from <a class='info' href='#RFC3447'>RFC3447<span> (</span><span class='info'>Jonsson, J. and B. Kaliski, “Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1,” February 2003.</span><span>)</span></a> [RFC3447] section 8.2.1. to verify the Signature. </li> </ol> <a name="discovery"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.6"></a><h3>6.  Key Discovery and the Trust</h3> <p>To verify the signature, the trusted key MUST be found by the verifier first. This specification defines three such methods. </p> <a name="skey"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.6.1"></a><h3>6.1.  Shared key in HMAC-SHA256</h3> <p>When HMAC-SHA256 is specified as the algorithm, the client_secret must be pre-shared by the parties. The exact method of performing such key exchange is out of scope of this specification. </p> <a name="x509"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.6.2"></a><h3>6.2.  X.509 Certificates</h3> <p>X.509 Certificates are found from the uri in 'certs_uri' field. The uri MUST return a X.509 file in PEM format with "application/x-pem-file" as the mime-type. It MAY contain the certificate chain. The CN of the obtained certificate MUST match the uri found in the 'signer' field. Other attributes in the X.509 certificates SHOULD be checked to verify the validity of the certificates. </p> <a name="IANA"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.7"></a><h3>7.  IANA Considerations</h3> <p>This document makes no request of IANA. </p> <a name="Security"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.8"></a><h3>8.  Security Considerations</h3> <p>Authors strongly recommend against using RSA-SHA1. It is depricated and is there only for backword compatibility. </p> <a name="Acknowledgements"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.9"></a><h3>9.  Acknowledgements</h3> <p>This specification is heavily influenced by the <a class='info' href='#magic_signatures'>Magic Signatures<span> (</span><span class='info'>Panzer, J. and B. Laurie, “Magic Signatures,” February 2010.</span><span>)</span></a> [magic_signatures] and JSON Token draft specifications. </p> <p>The authors would like Dirk Balfanz (Google), George Fletcher (AOL), Yaron Goland (Microsoft), Ryo Ito (Yahoo! Japan), Mike Jones (Microsoft), Tony Nadalin (Microsoft), John Panzar (Google), David Recordon (Facebook), Luke Shephard (Facebook), Paul Tarjan (Facebook) for their valuable inputs. </p> <a name="rfc.references"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.10"></a><h3>10.  References</h3> <a name="rfc.references1"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <h3>10.1. Normative References</h3> <table width="99%" border="0"> <tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td> <td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” BCP 14, RFC 2119, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2119.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2119.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2119.xml">XML</a>).</td></tr> <tr><td class="author-text" valign="top"><a name="RFC3447">[RFC3447]</a></td> <td class="author-text">Jonsson, J. and B. Kaliski, “<a href="http://tools.ietf.org/html/rfc3447">Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1</a>,” RFC 3447, February 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3447.txt">TXT</a>).</td></tr> <tr><td class="author-text" valign="top"><a name="RFC4648">[RFC4648]</a></td> <td class="author-text">Josefsson, S., “<a href="http://tools.ietf.org/html/rfc4648">The Base16, Base32, and Base64 Data Encodings</a>,” RFC 4648, October 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4648.txt">TXT</a>).</td></tr> </table> <a name="rfc.references2"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <h3>10.2. Informative References</h3> <table width="99%" border="0"> <tr><td class="author-text" valign="top"><a name="magic_signatures">[magic_signatures]</a></td> <td class="author-text">Panzer, J. and B. Laurie, “<a href="http://salmon-protocol.googlecode.com/svn/trunk/draft-panzer-magicsig-00.html">Magic Signatures</a>,” February 2010.</td></tr> </table> <a name="anchor11"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <a name="rfc.section.A"></a><h3>Appendix A.  An Appendix</h3> <p> </p> <a name="rfc.authors"></a><br /><hr /> <table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> <h3>Authors' Addresses</h3> <table width="99%" border="0" cellpadding="0" cellspacing="0"> <tr><td class="author-text"> </td> <td class="author-text">John Bradley</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Protivity Government Services</td></tr> <tr cellpadding="3"><td> </td><td> </td></tr> <tr><td class="author-text"> </td> <td class="author-text">Nat Sakimura (Editor)</td></tr> <tr><td class="author-text"> </td> <td class="author-text">Nomura Research Institute</td></tr> </table> </body></html>