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.
Smith
> On 2015-10-09, at 9:42 AM, Ira McDonald <blueroofmusic at gmail.com> wrote:
>> Hi Smith,
>> And this is the brand new update to US NIST FIPS 180-4 that defines
> *all* of the NIST hash algorithms (SHA1, SHA2, and SHA3):
>>http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>
>> Cheers,
> - Ira
>>> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
>http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
>http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>
> Winter 579 Park Place Saline, MI 48176 734-944-0094
> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434
>>> On Fri, Oct 9, 2015 at 11:31 AM, Ira McDonald <blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>> wrote:
> Hi,
>> The latest update from US NIST on crypto algorithm transitions is SP800-131a
> Revision 1 (now in review) which, in section 9, contains an exhaustive list of the
> specific tags that NIST uses for all hash algorithms, including SHA3 modes.
>> Appendix A: Mitigating Risk When Using Algorithms and Keys for Legacy-Use
> is worth citing (and reading).
>>http://csrc.nist.gov/publications/drafts/800-131A/sp800-131a_r1_draft.pdf <http://csrc.nist.gov/publications/drafts/800-131A/sp800-131a_r1_draft.pdf>
> "Transitions: Recommendation for Transitioning the Use of Cryptographic
> Algorithms and Key Lengths"
>> Cheers,
> - Ira
>>> Ira McDonald (Musician / Software Architect)
> Co-Chair - TCG Trusted Mobility Solutions WG
> Chair - Linux Foundation Open Printing WG
> Secretary - IEEE-ISTO Printer Working Group
> Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG
> IETF Designated Expert - IPP & Printer MIB
> Blue Roof Music / High North Inc
>http://sites.google.com/site/blueroofmusic <http://sites.google.com/site/blueroofmusic>
>http://sites.google.com/site/highnorthinc <http://sites.google.com/site/highnorthinc>
> mailto: blueroofmusic at gmail.com <mailto:blueroofmusic at gmail.com>
> Winter 579 Park Place Saline, MI 48176 734-944-0094 <tel:734-944-0094>
> Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 <tel:906-494-2434>
>>> On Fri, Oct 9, 2015 at 9:30 AM, Michael Sweet <msweet at apple.com <mailto:msweet at apple.com>> wrote:
> Smith,
>>> On Oct 6, 2015, at 5:16 PM, Kennedy, Smith (Wireless Architect) <smith.kennedy at hp.com <mailto:smith.kennedy at hp.com>> wrote:
>>>> Hi there,
>>>> A couple of questions about the changes we agreed that I should make to the "job-password-repertoire" whitepaper:
>>>> 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:
>>>> Q: Do we need multiple values?
>> Original purpose was to tell client the 1 password format that is acceptable for job-password values
>> Important to convey capabilities (only have a numeric keypad)
>> Impossible to validate values when job-password is encrypted
>> 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)
>>>> 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.
>> Not exactly. The consensus from the concall was to define two attributes:
>> job-password-repertoire-configured (type2 keyword | name(MAX))
>> The configured password repertoire that a client uses to limit and validate
> the values entered into the print UI.
>> job-password-repertoire-supported (1setOf (type2 keyword | name(MAX)))
>> The list of printer-supported repertoire that can be configured by the
> administrator in the job-password-repertoire-configured attribute.
>> 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.
>> 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.
>> For job tickets/settings we use xxx-default attributes to fill in values for missing Job Template xxx attributes.
>>> 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!):
>>>>https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml <https://www.iana.org/assignments/hash-function-text-names/hash-function-text-names.xml>
>>>> 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...
>> 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...
>>> 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).
>> Ira?
>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>> _______________________________________________
> ipp mailing list
>ipp at pwg.org <mailto:ipp at pwg.org>
>https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20151012/d1ffec7b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4956 bytes
Desc: not available
URL: <http://www.pwg.org/pipermail/ipp/attachments/20151012/d1ffec7b/attachment.p7s>