<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>The proposed SignatureHmacWithSha256 spec (below) repeats the details of the HMAC algorithm from RFC 2104. But should the details be removed and just refer to RFC 2104? Arguments for keeping the details are that it provides details for the discussion of
creating the KeyDIgest and also because some applications don't have HMAC in their crypto library and need to implement it directly. An argument against keeping the details is that the info is in RFC 2104 so an application writer can read the RFC if needed,
and that we don't repeat the details of other algorithms like SHA-256.</div>
<div><br>
</div>
<div>Any opinions on removing the algorithm details?</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div><br>
</div>
<div>- Jeff T</div>
<div>
<div class="document">
<div class="documentwrapper">
<div class="bodywrapper">
<div class="body">
<div class="section" id="signature">
<div class="section" id="keylocator">
<div class="section" id="signaturehmacwithsha256">
<h3>SignatureHmacWithSha256<a class="headerlink" href="cid:6B94E289-C6DC-4002-9EF9-948D08AD1503" title="Permalink to this headline" type="text/html"></a></h3>
<p><tt class="docutils literal">SignatureHmacWithSha256</tt> defines a hash-based message authentication code that is calculated over the
<a class="reference internal" href="cid:AC18F89D-17C3-42FC-9E01-3D98C498CF70" type="text/html">
</a><em>Name</em>, <a class="reference internal" href="cid:FAADCD52-F5F2-4B4F-8F23-8572A094F60B" type="text/html">
</a><em>MetaInfo</em>, <a class="reference internal" href="cid:63CEF72F-159E-490F-ACCD-10B291183891" type="text/html">
</a><em>Content</em>, and <a class="reference internal" href="cid:4BC39041-4470-4AAE-A916-93EFAFB2F6C0" type="text/html">
</a><em>SignatureInfo</em> TLVs, using SHA256 as the hashing function. The signature algorithm is defined in
<a class="reference external" href="http://tools.ietf.org/html/rfc2104#section-2">
Section 2 in RFC 2104</a>.</p>
<div class="highlight-python">
<div class="highlight">
<pre>SignatureInfo ::= SIGNATURE-INFO-TYPE TLV-LENGTH
SIGNATURE-TYPE-TYPE TLV-LENGTH(=1) 4
KeyLocator
SignatureValue ::= SIGNATURE-VALUE-TYPE TLV-LENGTH(=32)
BYTE++(=SHA256({KeyValue XOR opad, SHA256({KeyValue XOR ipad, Name, MetaInfo, Content, SignatureInfo})}))
</pre>
</div>
</div>
<p>where</p>
<div class="highlight-python">
<div class="highlight">
<pre>opad = 0x5c5c5c...5c5c5c (repeated 64 times)
ipad = 0x363636...363636 (repeated 64 times)
</pre>
</div>
</div>
<p><tt class="docutils literal">Key</tt> is a shared key known to the sender and receiver of the signed packet.
<tt class="docutils literal">KeyValue</tt> is derived from a shared <tt class="docutils literal">
Key</tt> as follows. If the byte length of <tt class="docutils literal">Key</tt> is less than the SHA256 block length (64 bytes) then append zeros to the end of the
<tt class="docutils literal">Key</tt> to create the 64-byte <tt class="docutils literal">
KeyValue</tt>. If the byte length of <tt class="docutils literal">Key</tt> is greater than 64 bytes then hash it with SHA256 to produce a 32-byte value then append 32 zeros to the end to create the 64-byte
<tt class="docutils literal">KeyValue</tt>. (The HMAC functions in most cryptographic libraries are supplied the
<tt class="docutils literal">Key</tt> and will internally derive the <tt class="docutils literal">
KeyValue</tt> in this way.)</p>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last"><tt class="docutils literal">Key</tt> is not included in the signature. It is the application’s responsibility to ensure that the receiver already knows the shared
<tt class="docutils literal">Key</tt>. It can be identified using a <tt class="docutils literal">
KeyDigest</tt> as the <a class="reference internal" href="cid:91E28A76-B2E3-4C4A-A5C6-B21BBE7AF358" type="text/html">
</a><em>KeyLocator</em> block in the <a class="reference internal" href="cid:D9F93FE6-7AA5-4798-94A4-F9C08EEEF53D" type="text/html">
</a><em>SignatureInfo</em> block of <tt class="docutils literal">SignatureHmacWithSha256</tt> as follows. If the byte length of
<tt class="docutils literal">Key</tt> is less than or equal to the SHA256 block length (64 bytes) then the
<tt class="docutils literal">KeyDigest</tt> is SHA256(<tt class="docutils literal">Key</tt>). But if the byte length of
<tt class="docutils literal">Key</tt> is greater than 64 bytes, the <tt class="docutils literal">
KeyValue</tt> is already SHA256(<tt class="docutils literal">Key</tt>) with zeros appended, so in this case
<tt class="docutils literal">KeyDigest</tt> is SHA256(SHA256(<tt class="docutils literal">Key</tt>)).</p>
</div>
<div class="admonition note">
<p class="first admonition-title">Note</p>
<p class="last">As stated in in <a class="reference external" href="http://tools.ietf.org/html/rfc2104#section-3">
Section 3 of RFC 2104</a> , keys shorter than the SHA256 output byte length (32 bytes) are strongly discouraged.</p>
</div>
<p>Provided that the signature verifies, this type of signature ensures provenance that the Data packet was signed by one of the parties which holds the shared
<tt class="docutils literal">Key</tt>. The key is identified using a <tt class="docutils literal">
KeyDigest</tt> as described above. It is the application’s responsibility to establish the identities of the parties who hold the shared
<tt class="docutils literal">Key</tt>.</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</span>
</body>
</html>