[IPP] Document Encryption design notions - some initial thoughts

[Ira McDonald]

Hi,

I agree with Mike.  Certainly operation attributes are the right place to
pass signatures, credentials, and other security ticket-like info in IPP.

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 Sat, Feb 28, 2015 at 12:57 PM, Michael Sweet <msweet at apple.com> wrote:

> FWIW, I don't think putting the actual security information in
> document-format-details is the right approach.  *If* the document format
> was a wrapper containing the document data and security info, then
> document-format and document-format-details could be used to identify the
> wrapper used.  But I don't think we want to stuff a signature or public key
> in there.
>
> (Consider how we have handled the destination-accesses and document-access
> attributes - they are operation attributes with explicit security
> requirements that are not "public" Document Description attributes...)
>
>
> > On Feb 8, 2015, at 10:40 AM, Ira McDonald <blueroofmusic at gmail.com>
> wrote:
> >
> > Hi Smith,
> >
> > Extending "document-format-details" is the preferable approach.  Note
> that
> > the JDF to PJT mapping spec has a considerable amount of detail already
> > mapped to this single IPP collection attribute.  More could be mapped in
> > future versions of JDF and PJT/Semantic Model.
> >
> > If you use an exotic MIME type, it will simply be ignored by most MIME
> parsers
> > (and may be "squashed" in transit).  I don't think generic MIME
> libraries are a
> > good place to depend on for your desired functionality.
> >
> > 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 Sun, Feb 8, 2015 at 8:16 AM, Kennedy, Smith (Wireless Architect) <
> smith.kennedy at hp.com> wrote:
> > Greetings,
> >
> > After the F2F meetings on Wednesday in El Segundo, I chatted with Joe
> Murdock for a few minutes about the overlap between this and what the IDS
> WG has been up to.  At the moment, for some reason my instinct is to try to
> identify an appropriate MIME Media Type, if one exists, that has a header
> that encapsulates information on the format and any metadata, as well as
> the encrypted payload (if the payload is present).  A document format that
> encapsulates all this information would allow the encrypted document to
> more easily traverse complex print system topologies that may contain
> mixtures of IPP and non-IPP transports, without requiring transcoding of
> the metadata at each hop.
> >
> > However, IF it is decided that that is an inappropriate direction in
> which to proceed, I was looking in JPS1 (5100.7) and found the
> “document-format-details” attribute, which is a collection of various
> things including attributes to describe a digital signature.  If we were to
> pursue describing this information via IPP attributes, extending this
> attribute’s “members” might be the right place to capture such information.
> >
> > Please share your thoughts!
> >
> > Cheers,
> > Smith
> >
> > /**
> >     Smith Kennedy
> >     Hewlett-Packard Co.
> > */
> >
> >
> > _______________________________________________
> > ipp mailing list
> > ipp at pwg.org
> > https://www.pwg.org/mailman/listinfo/ipp
> >
> >
> > _______________________________________________
> > ipp mailing list
> > ipp at pwg.org
> > https://www.pwg.org/mailman/listinfo/ipp
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.pwg.org/pipermail/ipp/attachments/20150228/6bdbbc55/attachment.html>