[IPP] Minutes posted for today's IPP WG meeting

[IPP] Minutes posted for today's IPP WG meeting

Ira McDonald blueroofmusic at gmail.com
Fri Oct 9 15:31:28 UTC 2015


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/3d374189/attachment.html>


More information about the ipp mailing list