<!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 00</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="description" content="JSON Simple Sign 1.0 draft 00">
<meta name="keywords" content="Signature, Draft">
<meta name="generator" content="xml2rfc v1.35 (http://xml.resource.org/)">
<style type='text/css'><!--
body {
font-family: verdana, charcoal, helvetica, arial, sans-serif;
font-size: small; color: #000; background-color: #FFF;
margin: 2em;
}
h1, h2, h3, h4, h5, h6 {
font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
font-weight: bold; font-style: normal;
}
h1 { color: #900; background-color: transparent; text-align: right; }
h3 { color: #333; background-color: transparent; }
td.RFCbug {
font-size: x-small; text-decoration: none;
width: 30px; height: 30px; padding-top: 2px;
text-align: justify; vertical-align: middle;
background-color: #000;
}
td.RFCbug span.RFC {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: bold; color: #666;
}
td.RFCbug span.hotText {
font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
font-weight: normal; text-align: center; color: #FFF;
}
table.TOCbug { width: 30px; height: 15px; }
td.TOCbug {
text-align: center; width: 30px; height: 15px;
color: #FFF; background-color: #900;
}
td.TOCbug a {
font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
font-weight: bold; font-size: x-small; text-decoration: none;
color: #FFF; background-color: transparent;
}
td.header {
font-family: arial, helvetica, sans-serif; font-size: x-small;
vertical-align: top; width: 33%;
color: #FFF; background-color: #666;
}
td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
td.author-text { font-size: x-small; }
/* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
a.info {
/* This is the key. */
position: relative;
z-index: 24;
text-decoration: none;
}
a.info:hover {
z-index: 25;
color: #FFF; background-color: #900;
}
a.info span { display: none; }
a.info:hover span.info {
/* The span will display just on :hover state. */
display: block;
position: absolute;
font-size: smaller;
top: 2em; left: -5em; width: 15em;
padding: 2px; border: 1px solid #333;
color: #900; background-color: #EEE;
text-align: left;
}
a { font-weight: bold; }
a:link { color: #900; background-color: transparent; }
a:visited { color: #633; background-color: transparent; }
a:active { color: #633; background-color: transparent; }
p { margin-left: 2em; margin-right: 2em; }
p.copyright { font-size: x-small; }
p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }
ol.text { margin-left: 2em; margin-right: 2em; }
ul.text { margin-left: 2em; margin-right: 2em; }
li { margin-left: 3em; }
/* RFC-2629 <spanx>s and <artwork>s. */
em { font-style: italic; }
strong { font-weight: bold; }
dfn { font-weight: bold; font-style: normal; }
cite { font-weight: normal; font-style: normal; }
tt { color: #036; }
tt, pre, pre dfn, pre em, pre cite, pre span {
font-family: "Courier New", Courier, monospace; font-size: small;
}
pre {
text-align: left; padding: 4px;
color: #000; background-color: #CCC;
}
pre dfn { color: #900; }
pre em { color: #66F; background-color: #FFC; font-weight: normal; }
pre .key { color: #33C; font-weight: bold; }
pre .id { color: #900; }
pre .str { color: #000; background-color: #CFF; }
pre .val { color: #066; }
pre .rep { color: #909; }
pre .oth { color: #000; background-color: #FCF; }
pre .err { background-color: #FCC; }
/* RFC-2629 <texttable>s. */
table.all, table.full, table.headers, table.none {
font-size: small; text-align: center; border-width: 2px;
vertical-align: top; border-collapse: collapse;
}
table.all, table.full { border-style: solid; border-color: black; }
table.headers, table.none { border-style: none; }
th {
font-weight: bold; border-color: black;
border-width: 2px 2px 3px 2px;
}
table.all th, table.full th { border-style: solid; }
table.headers th { border-style: none none solid none; }
table.none th { border-style: none; }
table.all td {
border-style: solid; border-color: #333;
border-width: 1px 2px;
}
table.full td, table.headers td, table.none td { border-style: none; }
hr { height: 1px; }
hr.insert {
width: 80%; border-style: none; border-width: 0;
color: #CCC; background-color: #CCC;
}
--></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 00<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>
Envelope Structures<br />
<a href="#anchor3">3.</a>
Creating Signature<br />
<a href="#anchor4">4.</a>
Serialization<br />
<a href="#anchor5">4.1.</a>
JSON Serialization<br />
<a href="#anchor6">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="#anchor9">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.
Envelope Structures</h3>
<p>JSON Simple Sign Envelope is a JSON object that contains three toplevel parameters, "type", "sig_params", and "payload". All of them are REQUIRED.
</p>
<p>Each parameters are JSON object in turn as described below.
</p>
<p></p>
<ul class="text">
<li>type - The String "http://jsonenc.info/jss/"
</li>
<li>payload - An envelop that holds the original JSON object to be signed.
</li>
<li>sig_params - An array that has JSON objects with "alorithm", "thumbprint", "certs_uri", "key_id" as its elements.
</li>
</ul><p>Followings are the parameters inside "sig_params".
</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 - REQUIRED for "HMAC-SHA256". A string that act as a key hint for HMAC-SHA256 signatures.
</li>
</ul>
<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>{
"type": "http://jsonenc.info/jss/",
"sig_params": [
{
"key_id": "example.com",
"algorithm": "HMAC-SHA256"
}
],
"payload": {
"oauth_token": "asdfjklsdfjwoIjfk",
"not_after": 12345678,
"user_id": 1223,
"profile_id": 1223
}
}
</pre></div>
<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>{
"type": "http://jsonenc.info/jss/",
"sig_params": [
{
"certs_uri": "https://example.com/mycerts.pem"
},
{
"algorithm": "RSA-SHA1",
"certs_uri": "https://example.org/mycerts.pem"
}
] ,
"payload": {
"audience": "https://example-client.com/redirect_uri",
"oauth_token": "asdfjklsdfjwoIjfk",
"not_after": 12345678,
"user_id": "1223",
"profile_id": "1223"
}
}
</pre></div>
<p>
</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.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 envelope to obtain the "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="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.4"></a><h3>4.
Serialization</h3>
<p>This specification defines two types of serialization
</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.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 - http://openid.net/specs/ab/1.0#signed_format
</li>
<li>sigs - the wrapper element that holds "certs_uri" and "signature"
</li>
<li>signature - the "signature string"
</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>
</ul>
<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>{
"type": "http://openid.net/specs/ab/1.0#signed_format",
"data_type": "application/json",
"data": "eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsIjAiOiJwYXlsb2FkIn0",
"sigs": [
{
"signature": "vlXgu64BQGFSQrY0ZcJBZASMvYvTHu9GQ0YM9rjPSso",
"certs_uri": "https://example.com/mycerts.pem"
},
{
"signature": "cfXgu64BQGFSQrY0ZcJBZASMvYvTHu9GQ0YM9rjPSso",
"certs_uri": "https://example.org/mycerts.pem"
}
]
}
</pre></div>
<p>
</p>
<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.2"></a><h3>4.2.
Web Token Serialization</h3>
<p>Web Token Serialization is done by concatenating the "signature string" and the "ascii armoured payload" with a period "."(ASCII 0x2E). Note that in Web Token Serialization, only a single signature is supported.
</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>vlXgu64BQGFSQrY0ZcJBZASMvYvTHu9GQ0YM9rjPSso
.
eyJhbGdvcml0aG0iOiJITUFDLVNIQTI1NiIsIjAiOiJwYXlsb2FkIn0
</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 5 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 signature and the 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", 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), Ryo Ito (Yahoo! Japan), 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="anchor9"></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>