Very good points. TLS means the system must have a reasonable
notion of network time. And TLS is certainly a must-have for firmware
or most other Resource-related operations.
I'd be happy to get some input on the Security Considerations section
about the importance of meaningful network time (e.g., for both session
restart and certificate validation/revocation).
I was feeling very queasy about downgrading required attributes from
IPP Everywhere, which ought to be our "floor" for printers with System
Service. Shouldn't we require IPP Everywhere in System Service?
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
mailto: blueroofmusic at gmail.com
Jan-April: 579 Park Place Saline, MI 48176 734-944-0094
May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434
On Sun, Oct 2, 2016 at 1:09 PM, Michael Sweet <msweet at apple.com> wrote:
>> > On Oct 2, 2016, at 11:41 AM, Ira McDonald <blueroofmusic at gmail.com>
> > Hi,
> > The System Service requirement for a running tick counter and
> > for an actual RTC w/ meaningful time would prevent the use of any
> > Resource operations by some printers.
>> How exactly?
>> TLS basically requires the date and time to be set to generate an X.509
> certificate or do validation of certificates in things like firmware
> updates and applications.
>> > Also, the firmware update
> > and graceful restart abilities, which move away from traditional
> > vendor- and model-specific approaches and improve Managed
> > Print Service compatibility.
> > Questions:
> > (1) Should we reduce the various "date-time-at-xxx" attributes to
> > RECOMMENDED?
> > -- Comment - they are REQUIRED in IPP Everywhere
>> Given that we require TLS, we are requiring a real-time clock of some sort
> and thus we should make these REQUIRED (better for accounting).
>> > (2) Should we allow the various "time-at-xxx" attributes to be
> > trivial implementations (i.e., without meaningful tick counter)?
> > -- Comment - they are REQUIRED in RFC2911/RFC2911bis,
> > with some ambiguity about implementation
>> These should follow the same rules as for Jobs - copy the
> printer-up-time/system-up-time value while running, report 0 if the time is
> before the service started.
>> > Note that I've personally been a proponent of required RTC
> > with meaningful date/time for years, so I'm conflicted about
> > bringing this subject up.
>> I think that ship sailed as soon as we required TLS. And for resource
> validation we need a date and time as well.
>> I think the only ambiguity is "how does the date and time get set", which
> should be talked about in security considerations since the wrong date/time
> can have consequences. (thus the work in the IETF for a secure version of
> > WDYT?
> > 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> > Jan-April: 579 Park Place Saline, MI 48176 734-944-0094
> > May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434
> > _______________________________________________
> > ipp mailing list
> > ipp at pwg.org> > https://www.pwg.org/mailman/listinfo/ipp>> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer
>>-------------- next part --------------
An HTML attachment was scrubbed...