attachment
<div dir="ltr"><div><div><div><div>Hi Smith,<br><br></div>And this is the brand new update to US NIST FIPS 180-4 that defines<br></div>*all* of the NIST hash algorithms (SHA1, SHA2, and SHA3):<br><br><a href="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf">http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf</a><br><br></div>Cheers,<br></div>- Ira<br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter 579 Park Place Saline, MI 48176 734-944-0094<br>Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div>
<br><div class="gmail_quote">On Fri, Oct 9, 2015 at 11:31 AM, Ira McDonald <span dir="ltr"><<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div>Hi,<br><br></div>The latest update from US NIST on crypto algorithm transitions is SP800-131a <br>Revision 1 (now in review) which, in section 9, contains an exhaustive list of the <br>specific tags that NIST uses for all hash algorithms, including SHA3 modes.<br></div></div><br>Appendix A: Mitigating Risk When Using Algorithms and Keys for Legacy-Use<br></div>is worth citing (and reading).<br><br><a href="http://csrc.nist.gov/publications/drafts/800-131A/sp800-131a_r1_draft.pdf" target="_blank">http://csrc.nist.gov/publications/drafts/800-131A/sp800-131a_r1_draft.pdf</a><br><div>"Transitions: Recommendation for Transitioning the Use of Cryptographic <br>Algorithms and Key Lengths"<br><br></div><div>Cheers,<br></div><div>- Ira<br><br></div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr">Ira McDonald (Musician / Software Architect)<br>Co-Chair - TCG Trusted Mobility Solutions WG<br>Chair - Linux Foundation Open Printing WG<br>Secretary - IEEE-ISTO Printer Working Group<br>Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br>IETF Designated Expert - IPP & Printer MIB<br>Blue Roof Music / High North Inc<br><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank">http://sites.google.com/site/blueroofmusic</a><br><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank">http://sites.google.com/site/highnorthinc</a><br>mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>Winter 579 Park Place Saline, MI 48176 <a href="tel:734-944-0094" value="+17349440094" target="_blank">734-944-0094</a><br>Summer PO Box 221 Grand Marais, MI 49839 <a href="tel:906-494-2434" value="+19064942434" target="_blank">906-494-2434</a><br><br><div style="display:inline"></div><div style="display:inline"></div><div style="display:inline"></div><div></div><div></div><div></div><div></div></div></div></div>
<br><div class="gmail_quote"><div><div class="h5">On Fri, Oct 9, 2015 at 9:30 AM, Michael Sweet <span dir="ltr"><<a href="mailto:msweet@apple.com" target="_blank">msweet@apple.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div style="word-wrap:break-word">Smith,<div><br><div><span><blockquote type="cite"><div>On Oct 6, 2015, at 5:16 PM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com" target="_blank">smith.kennedy@hp.com</a>> wrote:</div><br><div><div style="word-wrap:break-word">Hi there,<div><br></div><div>A couple of questions about the changes we agreed that I should make to the "job-password-repertoire" whitepaper:</div><div><br></div><div>1. There was this discussion of what to do about managing the set of possible values the device supports, vs. what the printer is configured to use:</div><div><br></div><div><div><ul><li>Q: Do we need multiple values?</li><ul><li>Original purpose was to tell client the 1 password format that is acceptable for job-password values</li><li>Important to convey capabilities (only have a numeric keypad)</li><li>Impossible to validate values when job-password is encrypted</li><li>A: Want a separate job-password-repertoire-configured Printer attribute that specifies the repertoire to use at the client end, job-password-repertoire-supported Printer attributes lists all of the (currently) available repertoire (for use by admin to configure the -configured value)</li></ul></ul><div><br></div></div><div>My worry about this is that this seems to break the "xxx" / "xxx-default" / "xxx-supported" design pattern that has been used thus far, because with this what would have been "xxx-supported" is now called "xxx-configured", and then the "xxx-supported" becomes an attribute that is considered by a tool engaging with the Printer via, for instance, a System Control Service.</div></div></div></div></blockquote><div><br></div></span>Not exactly. The consensus from the concall was to define two attributes:</div><div><br></div><div> job-password-repertoire-configured (type2 keyword | name(MAX))</div><div><br></div><div> The configured password repertoire that a client uses to limit and validate</div><div> the values entered into the print UI.</div><div><br></div><div> job-password-repertoire-supported (1setOf (type2 keyword | name(MAX)))</div><div><br></div><div> The list of printer-supported repertoire that can be configured by the</div><div> administrator in the job-password-repertoire-configured attribute.</div><div><br></div><div>This is consistent with how we handle printer settings for other things like natural language support - see the generated-natural-language-supported and natural-language-configured attributes from RFC 2911.</div><div><br></div><div>For printer/service settings (that are not part of the job ticket), the xxx-supported attribute lists the supported values while the xxx-configured attribute specifies the configured value.</div><div><br></div><div>For job tickets/settings we use xxx-default attributes to fill in values for missing Job Template xxx attributes.</div><div><br></div><div><span><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div>2. The Section 5.1 recommendation that we use the IANA registry for "Hash Function Textual Names" seems woefully out-of-date (last updated in August of 2006!):</div><div><br></div><div><a href="https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml" target="_blank">https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml</a></div><div><br></div><div>I think it is pretty clear how the new values will be encoded, but wanted to point this out and see if there were any follow-up recommendations. There seem to be a bunch of RFCs that didn't register new strings with IANA...</div></div></div></div></blockquote><div><br></div></span>I don't think a SHA-3 RFC has come through yet, and sometimes registrations do get missed during document review. Anyways, I'll be posting the registration template for the SHA-3 hashes to the IPP list today, which will take care of our needs...</div><div><span><br><blockquote type="cite"><div><div style="word-wrap:break-word"><div><div>3. Referencing NIST specs for deprecation recommendations - if someone can provide me with links to NIST deprecation recommendations, and to the SHA-2 specifications, I would appreciate it. I seem to be having issues finding anything but the SHA-3 specs (already referenced).</div></div></div></div></blockquote><div><br></div></span>Ira?</div><span><div><br></div><div>
<div><span style="font-family:'Andale Mono'">_________________________________________________________</span><br style="font-family:'Andale Mono'"><span style="font-family:'Andale Mono'">Michael Sweet, Senior Printing System Engineer, PWG Chair</span></div>
</div>
<br></span></div></div><br></div></div><span class="">_______________________________________________<br>
ipp mailing list<br>
<a href="mailto:ipp@pwg.org" target="_blank">ipp@pwg.org</a><br>
<a href="https://www.pwg.org/mailman/listinfo/ipp" rel="noreferrer" target="_blank">https://www.pwg.org/mailman/listinfo/ipp</a><br>
<br></span></blockquote></div><br></div>
</blockquote></div><br></div>