Subject: Re: [IPP] Minutes posted for today's IPP WG meeting

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Tue, 6 Oct 2015 21:16:13 +0000

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.

I have to assume this circumstance, where one attribute lists the range of values that could be enabled by the admin for use by end users, vs. the range of values that are available to end users, will come up in other cases?  If so, should we rather define what that new suffix is and align to that?  What does the SM or System Control Service have to say about this, if anything?

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...

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).

Smith

/**
    Smith Kennedy
    Wireless Architect - Client Software - IPG-PPS
    Standards - PWG / Bluetooth SIG / Wi-Fi Alliance / NFC Forum
    HP Inc.
*/

> On 2015-09-21, at 2:59 PM, Michael Sweet <[email-masked]> wrote:
> 
> All,
> 
> I have posted the minutes from today's IPP WG meeting to:
> 
> 	http://ftp.pwg.org/pub/pwg/ipp/minutes/ippv2-concall-minutes-20150921.pdf
> 
> Our next conference call will be on October 5, 2015 at 3pm ET.
> 
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
> 
> _______________________________________________
> ipp mailing list
> [email-masked]
> https://www.pwg.org/mailman/listinfo/ipp

_______________________________________________
ipp mailing list
[email-masked]
https://www.pwg.org/mailman/listinfo/ipp

---

From: Michael Sweet <[email-masked]>
Date: Fri, 09 Oct 2015 09:30:52 -0400

Smith,

> On Oct 6, 2015, at 5:16 PM, Kennedy, Smith (Wireless Architect) <[email-masked]> wrote:
> 
> Hi there,
> 

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.

> 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 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…

Ira?

---

From: Ira McDonald <[email-masked]>
Date: Fri, 9 Oct 2015 11:31:28 -0400

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: [email-masked]
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 <[email-masked]> wrote:

> 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.
>
>
> 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.
>
> 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!):
>
>
> 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?
>

---

From: Ira McDonald <[email-masked]>
Date: Fri, 9 Oct 2015 11:42:22 -0400

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

On Fri, Oct 9, 2015 at 11:31 AM, Ira McDonald <[email-masked]>
wrote:

> Revision 1 (now in review) which, in section 9, contains an exhaustive
> list of the
>>       - Original purpose was to tell client the 1 password format
>>       that is acceptable for job-password values
>> 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?
>>

---

From: "Kennedy, Smith (Wireless Architect)" <[email-masked]>
Date: Mon, 12 Oct 2015 22:39:54 +0000

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 <[email-masked]> wrote:
> 
> Hi Smith,
> 
> http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf <http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>
> 
> Cheers,
> - Ira
> 
> 
> 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: [email-masked] <mailto:[email-masked]>
> On Fri, Oct 9, 2015 at 11:31 AM, Ira McDonald <[email-masked] <mailto:[email-masked]>> 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 
> 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>
> 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: [email-masked] <mailto:[email-masked]>
> 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 <[email-masked] <mailto:[email-masked]>> wrote:
> Smith,
> 
>> On Oct 6, 2015, at 5:16 PM, Kennedy, Smith (Wireless Architect) <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Hi there,
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.pwg.org/mailman/listinfo/ipp <https://www.pwg.org/mailman/listinfo/ipp>
> 
> 
>