attachment-0001

Hi Nancy,<br><br>Right - my point is, after you verify the digital signature,<br>prudent security implementation is to SCAN the firmware<br>before making it your next boot image - what if the correct<br>digital signature comes from an enterprise server that has<br>
ITSELF become corrupted?  Digital signature&#39;s no help.<br><br>Cheers,<br>- Ira<br><br clear="all">Ira McDonald (Musician / Software Architect)<br>Chair - Linux Foundation Open Printing WG<br>Blue Roof Music/High North Inc<br>
email: <a href="mailto:blueroofmusic@gmail.com">blueroofmusic@gmail.com</a><br>winter:<br>  579 Park Place  Saline, MI  48176<br>  734-944-0094<br>summer:<br>  PO Box 221  Grand Marais, MI 49839<br>  906-494-2434<br>
<br><br><div class="gmail_quote">On Thu, May 14, 2009 at 3:00 PM,  <span dir="ltr">&lt;<a href="mailto:nchen@okidata.com">nchen@okidata.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">

<br><font size="2" face="sans-serif">Hi Ira,</font>
<br>
<br><font size="2" face="sans-serif">Yes, trusted path, with encryption and
signature whenever necessary. In your case, you need to check the signature
before executing.</font>
<br>
<br><font size="2" face="sans-serif">-Nancy</font>
<br>
<br>
<br>
<br>
<table width="100%">
<tbody><tr valign="top">
<td width="40%"><div class="im"><font size="1" face="sans-serif"><b>Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;</b>
</font>
</div><p><font size="1" face="sans-serif">05/14/2009 02:55 PM</font></p><div><div></div><div class="h5">
</div></div></td><td width="59%">
<table width="100%">
<tbody><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">To</font></div>
</td><td><font size="1" face="sans-serif"><a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;</font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">cc</font></div>
</td><td><font size="1" face="sans-serif"><a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a></font>
</td></tr><tr valign="top">
<td>
<div align="right"><font size="1" face="sans-serif">Subject</font></div>
</td><td><font size="1" face="sans-serif">Re: Resource Service updates for Security</font></td></tr></tbody></table>
<br>
<table>
<tbody><tr valign="top">
<td>
</td><td></td></tr></tbody></table>
<br></td></tr></tbody></table><div><div></div><div class="h5">
<br>
<br>
<br><font size="2"><tt>Hi Nancy,<br>
</tt></font>
<br><font size="2"><tt>Trusted path for firmware merely means you know which<br>
upstream server was corrupted - at least, if you CHECK<br>
the content of the firmware before blindly executing it.<br>
</tt></font>
<br><font size="2"><tt>And user scripts (and PostScript-like PDL jobs) can
be<br>
highly effective Denial-of-Service attacks (by crashing the<br>
entire MFD or just the Print Service) unless scanned by<br>
antivirus/antimalware tools.<br>
</tt></font>
<br><font size="2"><tt>Those are real threats.<br>
</tt></font>
<br><font size="2"><tt>Cheers,<br>
- Ira<br>
</tt></font>
<br><font size="2"><tt>Ira McDonald (Musician / Software Architect)<br>
Chair - Linux Foundation Open Printing WG<br>
Blue Roof Music/High North Inc<br>
email: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
winter:</tt></font>
<br><font size="2"><tt>579 Park Place  Saline, MI  48176<br>
734-944-0094</tt></font>
<br><font size="2"><tt>summer:<br>
PO Box 221  Grand Marais, MI 49839<br>
906-494-2434</tt></font>
<br>
<br>
<br><font size="2"><tt>On Thu, May 14, 2009 at 2:42 PM, &lt;<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>&gt;
wrote:<br>
</tt></font>
<br><font size="2"><tt>&gt;<br>
&gt; Hi Ira,<br>
&gt;<br>
&gt; P2600 covers the security threats that you mentioned here.<br>
&gt;<br>
&gt; In short, firmware update must be through trusted path.<br>
&gt;<br>
&gt; User&#39;s document if needed (depending on site security requirement),
must be<br>
&gt; protected from disclosure and/or alteration.<br>
&gt;<br>
&gt; There are many techniques to protect document disclosure and alteration.
We<br>
&gt; think the best techniques to prevent from disclosure is by encryption,
to<br>
&gt; detect alteration is by signing digital signature.<br>
&gt;<br>
&gt; Many MFPs today do not have these security in place, but they will<br>
&gt; eventually when they comply to the security standard.<br>
&gt;<br>
&gt; -Nancy<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;  *Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;*<br>
&gt;<br>
&gt; 05/14/2009 01:56 PM<br>
&gt;   To<br>
&gt; <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;  cc<br>
&gt; <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>  Subject<br>
&gt; Re: Resource Service updates for Security<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; Hi Nancy,<br>
&gt;<br>
&gt; OK - I&#39;m fascinated.<br>
&gt;<br>
&gt; What conceivable system security could replace the<br>
&gt; need for onboard antivirus software?<br>
&gt;<br>
&gt; Especially given that many MFDs now update firmware<br>
&gt; via a &quot;special&quot; Print Job - and do NOT have digitally<br>
&gt; signed firmware packages with an unbroken, network-<br>
&gt; accessible chain of authority to a major public Certificate<br>
&gt; Authority.<br>
&gt;<br>
&gt; Certainly scripts and macros invoked in ordinary<br>
&gt; Print Jobs are very easily corrupted - users create<br>
&gt; them, so they aren&#39;t digitally signed - verification of<br>
&gt; source does NOT remove the need for verification<br>
&gt; that the source system was not in fact corrupted.<br>
&gt;<br>
&gt; Cheers,<br>
&gt; - Ira<br>
&gt;<br>
&gt; Ira McDonald (Musician / Software Architect)<br>
&gt; Chair - Linux Foundation Open Printing WG<br>
&gt; Blue Roof Music/High North Inc<br>
&gt; email: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
&gt; winter:<br>
&gt; 579 Park Place  Saline, MI  48176<br>
&gt; 734-944-0094<br>
&gt; summer:<br>
&gt; PO Box 221  Grand Marais, MI 49839<br>
&gt; 906-494-2434<br>
&gt;<br>
&gt;<br>
&gt; On Thu, May 14, 2009 at 10:54 AM, &lt;<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>&gt; wrote:<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; Hi Ira,<br>
&gt; &gt;<br>
&gt; &gt; I haven&#39;t seen any security certification requirement that requires<br>
&gt; onboard<br>
&gt; &gt; antivirus on MFP yet.  Not sure what&#39;s the basis of your
prediction.<br>
&gt; &gt; Antivirus software vendors of course will try to push their products
on<br>
&gt; any<br>
&gt; &gt; platform. If you have not implemented MFP security standard,
properly<br>
&gt; &gt; configure the system to secure it, antivirus might be a good
idea to<br>
&gt; have.<br>
&gt; &gt; But once you have proper security instrumented, antivirus is
not that<br>
&gt; &gt; critical. It&#39;s nice to have of course.<br>
&gt; &gt;<br>
&gt; &gt; -Nancy<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;  *Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;*<br>
&gt; &gt;<br>
&gt; &gt; 05/13/2009 06:20 PM<br>
&gt; &gt;   To<br>
&gt; &gt; <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;
 cc<br>
&gt; &gt; <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>  Subject<br>
&gt; &gt; Re: Resource Service updates for Security<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; Hi Nancy,<br>
&gt; &gt;<br>
&gt; &gt; Several vendors currently offer MFDs that incorporate virus<br>
&gt; &gt; scanning of all files and executable modules and that CAN<br>
&gt; &gt; integrate into enterprise antivirus update schemes.<br>
&gt; &gt;<br>
&gt; &gt; Anyway, it was only an EXAMPLE (not a requirement) - though<br>
&gt; &gt; I think you will find that network endpoint attachment protocols<br>
&gt; &gt; and architectures are ALL going to require that you certify<br>
&gt; &gt; that you have healthy onboard antivirus on your MFD in the<br>
&gt; &gt; very near future.<br>
&gt; &gt;<br>
&gt; &gt; MFDs running Linux or other general-purpose operating systems<br>
&gt; &gt; are just too dangerous anymore without antivirus (or firewalls).<br>
&gt; &gt;<br>
&gt; &gt; Cheers,<br>
&gt; &gt; - Ira<br>
&gt; &gt;<br>
&gt; &gt; Ira McDonald (Musician / Software Architect)<br>
&gt; &gt; Chair - Linux Foundation Open Printing WG<br>
&gt; &gt; Blue Roof Music/High North Inc<br>
&gt; &gt; email: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
&gt; &gt; winter:<br>
&gt; &gt; 579 Park Place  Saline, MI  48176<br>
&gt; &gt; 734-944-0094<br>
&gt; &gt; summer:<br>
&gt; &gt; PO Box 221  Grand Marais, MI 49839<br>
&gt; &gt; 906-494-2434<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; On Wed, May 13, 2009 at 5:49 PM, &lt;<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>&gt; wrote:<br>
&gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Hi Ira,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; I agree that<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &quot;The threat is EXECUTING those Resources on an Imaging<br>
&gt; &gt; &gt; System (the one hosting the Resource Service or ANY other<br>
&gt; &gt; &gt; Imaging System) or even a desktop client system.&quot;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; and<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &quot;The Resource Service spec should NOT say anything,<br>
&gt; &gt; &gt; anywhere about internal versus external storage and<br>
&gt; &gt; &gt; should NEVER reference a Resource Repository.&quot;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; But I don&#39;t think &quot;virus scan&quot; is practical for
an Imaging System like<br>
&gt; an<br>
&gt; &gt; &gt; MFD or HCD to verify whether the stored or retrieved Executable<br>
&gt; Resources<br>
&gt; &gt; is<br>
&gt; &gt; &gt; safe to execute. There are many other techniques to verify
the<br>
&gt; integrity<br>
&gt; &gt; of<br>
&gt; &gt; &gt; these type of resources that are more practical for an MFD
or HCD.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Did I misunderstand something?<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -Nancy<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;  *Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;*<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; 05/13/2009 05:01 PM<br>
&gt; &gt; &gt;   To<br>
&gt; &gt; &gt; <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>, Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;<br>
&gt; &gt; &gt;  cc<br>
&gt; &gt; &gt; <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>  Subject<br>
&gt; &gt; &gt; Re: Resource Service updates for Security<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Hi Nancy,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Internal or external storage of the Resouces has NOTHING
to<br>
&gt; &gt; &gt; do with the security threat in 11.4 below.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The threat is EXECUTING those Resources on an Imaging<br>
&gt; &gt; &gt; System (the one hosting the Resource Service or ANY other<br>
&gt; &gt; &gt; Imaging System) or even a desktop client system.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The Resource Service spec should NOT say anything,<br>
&gt; &gt; &gt; anywhere about internal versus external storage and<br>
&gt; &gt; &gt; should NEVER reference a Resource Repository.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Every reference in 11.1 through 11.3 to Resource<br>
&gt; &gt; &gt; Repository should be deleted.  Users do NOT know<br>
&gt; &gt; &gt; where a Resource Service stores things - if a vendor<br>
&gt; &gt; &gt; does such an extension, then that vendor has broken<br>
&gt; &gt; &gt; good security practice in their system design and<br>
&gt; &gt; &gt; will justifiably fail independent security audits.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; The Resource Service is completely responsible *on its<br>
&gt; &gt; &gt; own* for every Resource that it stores (anywhere) or allows<br>
&gt; &gt; &gt; an authenticated user to retrieve (from the Resource<br>
&gt; &gt; &gt; Service, that is).<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Any network system that hosts a Resource Service<br>
&gt; &gt; &gt; is, by definition, an Imaging System - it may not be<br>
&gt; &gt; &gt; dedicated (single-purpose), but it&#39;s still an Imaging<br>
&gt; &gt; &gt; System.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Another way of putting it is that &quot;Imaging System&quot;<br>
&gt; &gt; &gt; is NOT simply a synonym for &quot;Multifunction Device&quot;<br>
&gt; &gt; &gt; - it&#39;s a wider definition that includes Spoolers and<br>
&gt; &gt; &gt; network server-hosted Imaging Services.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Cheers,<br>
&gt; &gt; &gt; - Ira<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Ira McDonald (Musician / Software Architect)<br>
&gt; &gt; &gt; Chair - Linux Foundation Open Printing WG<br>
&gt; &gt; &gt; Blue Roof Music/High North Inc<br>
&gt; &gt; &gt; email: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
&gt; &gt; &gt; winter:<br>
&gt; &gt; &gt; 579 Park Place  Saline, MI  48176<br>
&gt; &gt; &gt; 734-944-0094<br>
&gt; &gt; &gt; summer:<br>
&gt; &gt; &gt; PO Box 221  Grand Marais, MI 49839<br>
&gt; &gt; &gt; 906-494-2434<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; On Wed, May 13, 2009 at 12:16 PM, &lt;<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>&gt;
wrote:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Hi Ira,<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Thanks for the text for the Security Consideration.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Here are something I need to clarify, and some comments.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; 11.4  - Security Threats from Executable Resources<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; It&#39;s not clear to me whether the security problem described
here is<br>
&gt; for<br>
&gt; &gt; -<br>
&gt; &gt; &gt; &gt; 1) storing Executable Resources at an external storage
location that<br>
&gt; &gt; &gt; &gt; involves an external system for storing the resource,
and the<br>
&gt; Resource<br>
&gt; &gt; &gt; &gt; Service is hosted by an Imaging System. Or,<br>
&gt; &gt; &gt; &gt; 2) storing Executable Resources internally within the
Imaging System<br>
&gt; &gt; that<br>
&gt; &gt; &gt; &gt; hosts the Resource Service.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; In both cases the security threat is to the Imaging
System.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; If it&#39;s case 1) - I agree that the external system
&quot;SHOULD verify the<br>
&gt; &gt; &gt; &gt; safety of such resources (e.g., by virus scanning)&quot;.
But we agreed in<br>
&gt; &gt; &gt; last<br>
&gt; &gt; &gt; &gt; face-to-face meeting that it&#39;s out of scope of Resource
Service to<br>
&gt; &gt; &gt; consider<br>
&gt; &gt; &gt; &gt; anything related to the external storage system. What
Resource<br>
&gt; Service<br>
&gt; &gt; &gt; &gt; should consider is the restriction of the storage and
retrieval<br>
&gt; &gt; &gt; operations<br>
&gt; &gt; &gt; &gt; on such resources to authorized users. How the external
storage<br>
&gt; system<br>
&gt; &gt; &gt; &gt; should protect the stored executable resources is out
of scope.<br>
&gt; &gt; Although<br>
&gt; &gt; &gt; I<br>
&gt; &gt; &gt; &gt; prefer to recommend some security objectives to be
considered by the<br>
&gt; &gt; &gt; &gt; external storage system.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; If it&#39;s case 2) - I don&#39;t think we should give &quot;virus
scanning&quot; as an<br>
&gt; &gt; &gt; &gt; example to an Imaging System to protect the stored
Executable<br>
&gt; &gt; Resources.<br>
&gt; &gt; &gt; &gt; Virus scanning or intrusion detection techniques are
common in PCs,<br>
&gt; but<br>
&gt; &gt; &gt; &gt; rarely existent in Imaging Systems. It&#39;s simply not
that practical<br>
&gt; for<br>
&gt; &gt; an<br>
&gt; &gt; &gt; &gt; Imaging System to have such software implemented which
involves<br>
&gt; &gt; constant<br>
&gt; &gt; &gt; &gt; maintenance of upto-date virus signatures by external
systems. At the<br>
&gt; &gt; &gt; &gt; abstract level, we can provide some good security objectives
to<br>
&gt; &gt; consider<br>
&gt; &gt; &gt; for<br>
&gt; &gt; &gt; &gt; the Imaging System, such as protection of confidentiality
and<br>
&gt; integrity<br>
&gt; &gt; &gt; of<br>
&gt; &gt; &gt; &gt; the resources and their related metadata. Like case
1), the storage<br>
&gt; and<br>
&gt; &gt; &gt; &gt; retrieval of operations on such resources must to restricted
to<br>
&gt; &gt; &gt; authorized<br>
&gt; &gt; &gt; &gt; users.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; A Resource Service could be hosted by a computer remote
to the<br>
&gt; Imaging<br>
&gt; &gt; &gt; &gt; System that is under security consideration. We should
consider this<br>
&gt; &gt; case<br>
&gt; &gt; &gt; &gt; too.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; 11.5 - Security Threats from Static Resources<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Static resources that have associated Intellectual
Property rights or<br>
&gt; &gt; &gt; &gt; license rights that involves metadata such as DateTimeOfExpiration<br>
&gt; &gt; which<br>
&gt; &gt; &gt; &gt; should also be protected for alteration. Therefore,
not only storage<br>
&gt; or<br>
&gt; &gt; &gt; &gt; retrieval operations on Resources must be restricted,
other<br>
&gt; operations<br>
&gt; &gt; on<br>
&gt; &gt; &gt; &gt; resource metadata must be restricted too.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Aslo the security problem you described here is for
storing Static<br>
&gt; &gt; &gt; &gt; Resources internally in an Imaging System that hosts
the Resource<br>
&gt; &gt; &gt; Service.<br>
&gt; &gt; &gt; &gt; We should also consider the case when the Resource
Service could be<br>
&gt; &gt; &gt; hosted<br>
&gt; &gt; &gt; &gt; by a computer remote to the Imaging System.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Thanks,<br>
&gt; &gt; &gt; &gt; -Nancy<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; -----------------------------------------------------------------------------<br>
&gt; &gt; &gt; &gt; Principal Engineer<br>
&gt; &gt; &gt; &gt; Solutions and Technology<br>
&gt; &gt; &gt; &gt; Oki Data<br>
&gt; &gt; &gt; &gt; 2000 Bishops Gate Blvd.<br>
&gt; &gt; &gt; &gt; Mt. Laurel, NJ 08054<br>
&gt; &gt; &gt; &gt; Phone: (856) 222-7006<br>
&gt; &gt; &gt; &gt; Email: <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a><br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;  *Ira McDonald &lt;<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;*<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; 05/12/2009 03:15 PM<br>
&gt; &gt; &gt; &gt;   To<br>
&gt; &gt; &gt; &gt; <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>, NancyChen &lt;<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>&gt;, Ira
McDonald &lt;<br>
&gt; &gt; &gt; &gt; <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>&gt;  cc<br>
&gt; &gt; &gt; &gt;   Subject<br>
&gt; &gt; &gt; &gt; Resource Service updates for Security<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Hi Nancy,            
                     
       Tuesday (12 May<br>
&gt; &gt; 2009)<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Per my action from the Resource Service review during
the April PWG<br>
&gt; &gt; &gt; &gt; meeting, below is some text for the Security Considerations
section<br>
&gt; of<br>
&gt; &gt; &gt; &gt; the Resource Service.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; 11.4 Security Threats from Executable Resources<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Resources with a ResourceCategory of &#39;Executable&#39; MUST
be handled<br>
&gt; with<br>
&gt; &gt; &gt; &gt; special care by implementations of the Resource Service.
 Such<br>
&gt; &gt; resources<br>
&gt; &gt; &gt; &gt; can pose serious threats to the integrity of the Imaging
System that<br>
&gt; &gt; &gt; &gt; hosts the Resource Service.  In particular, such
Resources can be<br>
&gt; used<br>
&gt; &gt; &gt; &gt; to introduce Trojan Horses to the Imaging System.  If
an<br>
&gt; implementation<br>
&gt; &gt; &gt; &gt; of the Resource Service supports Executable resources,
then that<br>
&gt; &gt; &gt; &gt; implementation MUST restrict the storage of such resources
(e.g., to<br>
&gt; &gt; &gt; &gt; authorized administrators and manufacturers) and SHOULD
verify the<br>
&gt; &gt; &gt; &gt; safety of such resources (e.g., by virus scanning).<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; 11.5 Security Threats from Static Resources<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Resources with ResourceCategory of &#39;Static&#39; SHOULD
be treated with<br>
&gt; &gt; &gt; &gt; special care by implementations of the Resource Service.
 Fonts that<br>
&gt; &gt; &gt; &gt; have associated Intellectual Property rights (e.g.,
as part of their<br>
&gt; &gt; &gt; &gt; network licenses) can pose serious threats to the availability
of the<br>
&gt; &gt; &gt; &gt; Imaging System that hosts the Resource Service - security
audits can<br>
&gt; &gt; &gt; &gt; result in the shutdown or physical removal of the Imaging
System.  If<br>
&gt; &gt; an<br>
&gt; &gt; &gt; &gt; implementation of the Resource Service supports Static
resources that<br>
&gt; &gt; &gt; &gt; have associated Intellectual Property rights, then
that<br>
&gt; implementation<br>
&gt; &gt; &gt; &gt; SHOULD restrict the storage of such resources (e.g.,
to authorized<br>
&gt; &gt; &gt; &gt; administrators and manufacturers) and SHOULD restrict
the retrieval<br>
&gt; of<br>
&gt; &gt; &gt; &gt; such resources (e.g., to a configured group of authorized
users).<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Comments?<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Cheers,<br>
&gt; &gt; &gt; &gt; - Ira<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Ira McDonald (Musician / Software Architect)<br>
&gt; &gt; &gt; &gt; Chair - Linux Foundation Open Printing WG<br>
&gt; &gt; &gt; &gt; Blue Roof Music/High North Inc<br>
&gt; &gt; &gt; &gt; email: <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a><br>
&gt; &gt; &gt; &gt; winter:<br>
&gt; &gt; &gt; &gt; 579 Park Place  Saline, MI  48176<br>
&gt; &gt; &gt; &gt; 734-944-0094<br>
&gt; &gt; &gt; &gt; summer:<br>
&gt; &gt; &gt; &gt; PO Box 221  Grand Marais, MI 49839<br>
&gt; &gt; &gt; &gt; 906-494-2434<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt;<br>
&gt;<br>
&gt;</tt></font>
<br>
<br>
<br></div></div></blockquote></div><br>
<br />-- 
<br />This message has been scanned for viruses and
<br />dangerous content by
<a href="http://www.mailscanner.info/"><b>MailScanner</b></a>, and is
<br />believed to be clean.