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
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/blueroofmusichttp://sites.google.com/site/highnorthinc
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>
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> "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/highnorthinc> 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 9:30 AM, Michael Sweet <msweet at apple.com> wrote:
>>> Smith,
>>>> On Oct 6, 2015, at 5:16 PM, Kennedy, Smith (Wireless Architect) <
>>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>>>> 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>>https://www.pwg.org/mailman/listinfo/ipp>>>>>-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20151009/e067e853/attachment.html>