attachment
<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">OK, that's good - I already had that listed in the references list and my read of it was that it included them all, so I'm glad you confirmed this. T'm trying to finish off an update to the "job-password-repertoire" whitepaper today.<div class=""><br class=""><div class="">
Smith<br class=""><br class=""><br class="">
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">On 2015-10-09, at 9:42 AM, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" class="">blueroofmusic@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class="">Hi Smith,<br class=""><br class=""></div>And this is the brand new update to US NIST FIPS 180-4 that defines<br class=""></div>*all* of the NIST hash algorithms (SHA1, SHA2, and SHA3):<br class=""><br class=""><a href="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf" class="">http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf</a><br class=""><br class=""></div>Cheers,<br class=""></div>- Ira<br class=""><br class=""></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class="gmail_signature"><div dir="ltr" class="">Ira McDonald (Musician / Software Architect)<br class="">Co-Chair - TCG Trusted Mobility Solutions WG<br class="">Chair - Linux Foundation Open Printing WG<br class="">Secretary - IEEE-ISTO Printer Working Group<br class="">Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br class="">IETF Designated Expert - IPP & Printer MIB<br class="">Blue Roof Music / High North Inc<br class=""><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank" class="">http://sites.google.com/site/blueroofmusic</a><br class=""><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank" class="">http://sites.google.com/site/highnorthinc</a><br class="">mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank" class="">blueroofmusic@gmail.com</a><br class="">Winter 579 Park Place Saline, MI 48176 734-944-0094<br class="">Summer PO Box 221 Grand Marais, MI 49839 906-494-2434<br class=""><br class=""><div style="display:inline" class=""></div><div style="display:inline" class=""></div><div style="display:inline" class=""></div><div class=""></div><div class=""></div><div class=""></div><div class=""></div></div></div></div>
<br class=""><div class="gmail_quote">On Fri, Oct 9, 2015 at 11:31 AM, Ira McDonald <span dir="ltr" class=""><<a href="mailto:blueroofmusic@gmail.com" target="_blank" class="">blueroofmusic@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class=""><div class=""><div class=""><div class=""><div class="">Hi,<br class=""><br class=""></div>The latest update from US NIST on crypto algorithm transitions is SP800-131a <br class="">Revision 1 (now in review) which, in section 9, contains an exhaustive list of the <br class="">specific tags that NIST uses for all hash algorithms, including SHA3 modes.<br class=""></div></div><br class="">Appendix A: Mitigating Risk When Using Algorithms and Keys for Legacy-Use<br class=""></div>is worth citing (and reading).<br class=""><br class=""><a href="http://csrc.nist.gov/publications/drafts/800-131A/sp800-131a_r1_draft.pdf" target="_blank" class="">http://csrc.nist.gov/publications/drafts/800-131A/sp800-131a_r1_draft.pdf</a><br class=""><div class="">"Transitions: Recommendation for Transitioning the Use of Cryptographic <br class="">Algorithms and Key Lengths"<br class=""><br class=""></div><div class="">Cheers,<br class=""></div><div class="">- Ira<br class=""><br class=""></div></div><div class="gmail_extra"><br clear="all" class=""><div class=""><div class=""><div dir="ltr" class="">Ira McDonald (Musician / Software Architect)<br class="">Co-Chair - TCG Trusted Mobility Solutions WG<br class="">Chair - Linux Foundation Open Printing WG<br class="">Secretary - IEEE-ISTO Printer Working Group<br class="">Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG<br class="">IETF Designated Expert - IPP & Printer MIB<br class="">Blue Roof Music / High North Inc<br class=""><a style="color:rgb(51,51,255)" href="http://sites.google.com/site/blueroofmusic" target="_blank" class="">http://sites.google.com/site/blueroofmusic</a><br class=""><a style="color:rgb(102,0,204)" href="http://sites.google.com/site/highnorthinc" target="_blank" class="">http://sites.google.com/site/highnorthinc</a><br class="">mailto: <a href="mailto:blueroofmusic@gmail.com" target="_blank" class="">blueroofmusic@gmail.com</a><br class="">Winter 579 Park Place Saline, MI 48176 <a href="tel:734-944-0094" value="+17349440094" target="_blank" class="">734-944-0094</a><br class="">Summer PO Box 221 Grand Marais, MI 49839 <a href="tel:906-494-2434" value="+19064942434" target="_blank" class="">906-494-2434</a><br class=""><br class=""><div style="display:inline" class=""></div><div style="display:inline" class=""></div><div style="display:inline" class=""></div><div class=""></div><div class=""></div><div class=""></div><div class=""></div></div></div></div>
<br class=""><div class="gmail_quote"><div class=""><div class="h5">On Fri, Oct 9, 2015 at 9:30 AM, Michael Sweet <span dir="ltr" class=""><<a href="mailto:msweet@apple.com" target="_blank" class="">msweet@apple.com</a>></span> wrote:<br class=""></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><div class="h5"><div style="word-wrap:break-word" class="">Smith,<div class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Oct 6, 2015, at 5:16 PM, Kennedy, Smith (Wireless Architect) <<a href="mailto:smith.kennedy@hp.com" target="_blank" class="">smith.kennedy@hp.com</a>> wrote:</div><br class=""><div class=""><div style="word-wrap:break-word" class="">Hi there,<div class=""><br class=""></div><div class="">A couple of questions about the changes we agreed that I should make to the "job-password-repertoire" whitepaper:</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class=""><div class=""><ul class=""><li class="">Q: Do we need multiple values?</li><ul class=""><li class="">Original purpose was to tell client the 1 password format that is acceptable for job-password values</li><li class="">Important to convey capabilities (only have a numeric keypad)</li><li class="">Impossible to validate values when job-password is encrypted</li><li class="">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 class=""><br class=""></div></div><div class="">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 class=""><br class=""></div></span>Not exactly. The consensus from the concall was to define two attributes:</div><div class=""><br class=""></div><div class=""> job-password-repertoire-configured (type2 keyword | name(MAX))</div><div class=""><br class=""></div><div class=""> The configured password repertoire that a client uses to limit and validate</div><div class=""> the values entered into the print UI.</div><div class=""><br class=""></div><div class=""> job-password-repertoire-supported (1setOf (type2 keyword | name(MAX)))</div><div class=""><br class=""></div><div class=""> The list of printer-supported repertoire that can be configured by the</div><div class=""> administrator in the job-password-repertoire-configured attribute.</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">For job tickets/settings we use xxx-default attributes to fill in values for missing Job Template xxx attributes.</div><div class=""><br class=""></div><div class=""><span class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><div class="">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 class=""><br class=""></div><div class=""><a href="https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml" target="_blank" class="">https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml</a></div><div class=""><br class=""></div><div class="">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 class=""><br class=""></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 class=""><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><div class="">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 class=""><br class=""></div></span>Ira?</div><span class=""><div class=""><br class=""></div><div class="">
<div class=""><span style="font-family:'Andale Mono'" class="">_________________________________________________________</span><br style="font-family:'Andale Mono'" class=""><span style="font-family:'Andale Mono'" class="">Michael Sweet, Senior Printing System Engineer, PWG Chair</span></div>
</div>
<br class=""></span></div></div><br class=""></div></div><span class="">_______________________________________________<br class="">
ipp mailing list<br class="">
<a href="mailto:ipp@pwg.org" target="_blank" class="">ipp@pwg.org</a><br class="">
<a href="https://www.pwg.org/mailman/listinfo/ipp" rel="noreferrer" target="_blank" class="">https://www.pwg.org/mailman/listinfo/ipp</a><br class="">
<br class=""></span></blockquote></div><br class=""></div>
</blockquote></div><br class=""></div>
</div></blockquote></div><br class=""></div></body></html>