attachment.htm
Hi Nancy,<br><br>The MFD does NOT have access to the current Health Assessment<br>for the upstream enterprise server - if that server has been attacked<br>and had its antivirus compromised, then it behooves the MFD NOT<br>
to trust the firmware blindly - the essence of security is "trust nobody<br>more than you have to" - desktops (and now mobile devices) need<br>antivirus because sometimes the INFRASTRUCTURE systems get<br>corrupted too.<br>
<br>That was my point. <br><br>If an MFD doesn't have sufficient free-standing self-defense, then<br>sooner or later that MFD will be quarantined during Network<br>Endpoint Attachment and Health Assessment by a site policy that<br>
doesn't accept the premise that "security is out-of-scope".<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 4:31 PM, <span dir="ltr"><<a href="mailto:nchen@okidata.com">nchen@okidata.com</a>></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">I hope the enterprise server itself
already has antivirus software that can detect the corruption before MFD
retrieve the file. Otherwise, the antivirus does not work well on the enterprise
server. If that's the case, what's the use to install antivirus software
on MFD then?</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 <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>></b>
</font>
</div><p><font size="1" face="sans-serif">05/14/2009 04:09 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 <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>></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>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's no help.<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 3:00 PM, <<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>>
wrote:<br>
</tt></font>
<br><font size="2"><tt>><br>
> Hi Ira,<br>
><br>
> Yes, trusted path, with encryption and signature whenever necessary.
In<br>
> your case, you need to check the signature before executing.<br>
><br>
> -Nancy<br>
><br>
><br>
><br>
> *Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>>*<br>
><br>
> 05/14/2009 02:55 PM<br>
> To<br>
> <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>> cc<br>
> <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a> Subject<br>
> Re: Resource Service updates for Security<br>
><br>
><br>
><br>
><br>
> Hi Nancy,<br>
><br>
> 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>
><br>
> 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>
><br>
> Those are real threats.<br>
><br>
> Cheers,<br>
> - Ira<br>
><br>
> 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:<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>
> On Thu, May 14, 2009 at 2:42 PM, <<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>> wrote:<br>
><br>
> ><br>
> > Hi Ira,<br>
> ><br>
> > P2600 covers the security threats that you mentioned here.<br>
> ><br>
> > In short, firmware update must be through trusted path.<br>
> ><br>
> > User's document if needed (depending on site security requirement),
must<br>
> be<br>
> > protected from disclosure and/or alteration.<br>
> ><br>
> > There are many techniques to protect document disclosure and
alteration.<br>
> We<br>
> > think the best techniques to prevent from disclosure is by encryption,
to<br>
> > detect alteration is by signing digital signature.<br>
> ><br>
> > Many MFPs today do not have these security in place, but they
will<br>
> > eventually when they comply to the security standard.<br>
> ><br>
> > -Nancy<br>
> ><br>
> ><br>
> ><br>
> > *Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>>*<br>
> ><br>
> > 05/14/2009 01:56 PM<br>
> > To<br>
> > <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>>
cc<br>
> > <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a> Subject<br>
> > Re: Resource Service updates for Security<br>
> ><br>
> ><br>
> ><br>
> ><br>
> > Hi Nancy,<br>
> ><br>
> > OK - I'm fascinated.<br>
> ><br>
> > What conceivable system security could replace the<br>
> > need for onboard antivirus software?<br>
> ><br>
> > Especially given that many MFDs now update firmware<br>
> > via a "special" Print Job - and do NOT have digitally<br>
> > signed firmware packages with an unbroken, network-<br>
> > accessible chain of authority to a major public Certificate<br>
> > Authority.<br>
> ><br>
> > Certainly scripts and macros invoked in ordinary<br>
> > Print Jobs are very easily corrupted - users create<br>
> > them, so they aren't digitally signed - verification of<br>
> > source does NOT remove the need for verification<br>
> > that the source system was not in fact corrupted.<br>
> ><br>
> > Cheers,<br>
> > - Ira<br>
> ><br>
> > 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:<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>
> > On Thu, May 14, 2009 at 10:54 AM, <<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>> wrote:<br>
> ><br>
> > ><br>
> > > Hi Ira,<br>
> > ><br>
> > > I haven't seen any security certification requirement that
requires<br>
> > onboard<br>
> > > antivirus on MFP yet. Not sure what's the basis of
your prediction.<br>
> > > Antivirus software vendors of course will try to push their
products on<br>
> > any<br>
> > > platform. If you have not implemented MFP security standard,
properly<br>
> > > configure the system to secure it, antivirus might be a
good idea to<br>
> > have.<br>
> > > But once you have proper security instrumented, antivirus
is not that<br>
> > > critical. It's nice to have of course.<br>
> > ><br>
> > > -Nancy<br>
> > ><br>
> > ><br>
> > ><br>
> > > *Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>>*<br>
> > ><br>
> > > 05/13/2009 06:20 PM<br>
> > > To<br>
> > > <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>>
cc<br>
> > > <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a> Subject<br>
> > > Re: Resource Service updates for Security<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > Hi Nancy,<br>
> > ><br>
> > > Several vendors currently offer MFDs that incorporate virus<br>
> > > scanning of all files and executable modules and that CAN<br>
> > > integrate into enterprise antivirus update schemes.<br>
> > ><br>
> > > Anyway, it was only an EXAMPLE (not a requirement) - though<br>
> > > I think you will find that network endpoint attachment protocols<br>
> > > and architectures are ALL going to require that you certify<br>
> > > that you have healthy onboard antivirus on your MFD in the<br>
> > > very near future.<br>
> > ><br>
> > > MFDs running Linux or other general-purpose operating systems<br>
> > > are just too dangerous anymore without antivirus (or firewalls).<br>
> > ><br>
> > > Cheers,<br>
> > > - Ira<br>
> > ><br>
> > > 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:<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>
> > > On Wed, May 13, 2009 at 5:49 PM, <<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>>
wrote:<br>
> > ><br>
> > > ><br>
> > > > Hi Ira,<br>
> > > ><br>
> > > > I agree that<br>
> > > ><br>
> > > > "The threat is EXECUTING those Resources on an
Imaging<br>
> > > > System (the one hosting the Resource Service or ANY
other<br>
> > > > Imaging System) or even a desktop client system."<br>
> > > ><br>
> > > > and<br>
> > > ><br>
> > > > "The Resource Service spec should NOT say anything,<br>
> > > > anywhere about internal versus external storage and<br>
> > > > should NEVER reference a Resource Repository."<br>
> > > ><br>
> > > > But I don't think "virus scan" is practical
for an Imaging System<br>
> like<br>
> > an<br>
> > > > MFD or HCD to verify whether the stored or retrieved
Executable<br>
> > Resources<br>
> > > is<br>
> > > > safe to execute. There are many other techniques to
verify the<br>
> > integrity<br>
> > > of<br>
> > > > these type of resources that are more practical for
an MFD or HCD.<br>
> > > ><br>
> > > > Did I misunderstand something?<br>
> > > ><br>
> > > > -Nancy<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > *Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>>*<br>
> > > ><br>
> > > > 05/13/2009 05:01 PM<br>
> > > > To<br>
> > > > <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>, Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>><br>
> > > > cc<br>
> > > > <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a> Subject<br>
> > > > Re: Resource Service updates for Security<br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > > > Hi Nancy,<br>
> > > ><br>
> > > > Internal or external storage of the Resouces has NOTHING
to<br>
> > > > do with the security threat in 11.4 below.<br>
> > > ><br>
> > > > The threat is EXECUTING those Resources on an Imaging<br>
> > > > System (the one hosting the Resource Service or ANY
other<br>
> > > > Imaging System) or even a desktop client system.<br>
> > > ><br>
> > > > The Resource Service spec should NOT say anything,<br>
> > > > anywhere about internal versus external storage and<br>
> > > > should NEVER reference a Resource Repository.<br>
> > > ><br>
> > > > Every reference in 11.1 through 11.3 to Resource<br>
> > > > Repository should be deleted. Users do NOT know<br>
> > > > where a Resource Service stores things - if a vendor<br>
> > > > does such an extension, then that vendor has broken<br>
> > > > good security practice in their system design and<br>
> > > > will justifiably fail independent security audits.<br>
> > > ><br>
> > > > The Resource Service is completely responsible *on
its<br>
> > > > own* for every Resource that it stores (anywhere) or
allows<br>
> > > > an authenticated user to retrieve (from the Resource<br>
> > > > Service, that is).<br>
> > > ><br>
> > > > Any network system that hosts a Resource Service<br>
> > > > is, by definition, an Imaging System - it may not be<br>
> > > > dedicated (single-purpose), but it's still an Imaging<br>
> > > > System.<br>
> > > ><br>
> > > > Another way of putting it is that "Imaging System"<br>
> > > > is NOT simply a synonym for "Multifunction Device"<br>
> > > > - it's a wider definition that includes Spoolers and<br>
> > > > network server-hosted Imaging Services.<br>
> > > ><br>
> > > > Cheers,<br>
> > > > - Ira<br>
> > > ><br>
> > > > 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:<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>
> > > > On Wed, May 13, 2009 at 12:16 PM, <<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>>
wrote:<br>
> > > ><br>
> > > > ><br>
> > > > > Hi Ira,<br>
> > > > ><br>
> > > > > Thanks for the text for the Security Consideration.<br>
> > > > ><br>
> > > > > Here are something I need to clarify, and some
comments.<br>
> > > > ><br>
> > > > > 11.4 - Security Threats from Executable
Resources<br>
> > > > ><br>
> > > > > It's not clear to me whether the security problem
described here is<br>
> > for<br>
> > > -<br>
> > > > > 1) storing Executable Resources at an external
storage location<br>
> that<br>
> > > > > involves an external system for storing the resource,
and the<br>
> > Resource<br>
> > > > > Service is hosted by an Imaging System. Or,<br>
> > > > > 2) storing Executable Resources internally within
the Imaging<br>
> System<br>
> > > that<br>
> > > > > hosts the Resource Service.<br>
> > > > ><br>
> > > > > In both cases the security threat is to the Imaging
System.<br>
> > > > ><br>
> > > > > If it's case 1) - I agree that the external system
"SHOULD verify<br>
> the<br>
> > > > > safety of such resources (e.g., by virus scanning)".
But we agreed<br>
> in<br>
> > > > last<br>
> > > > > face-to-face meeting that it's out of scope of
Resource Service to<br>
> > > > consider<br>
> > > > > anything related to the external storage system.
What Resource<br>
> > Service<br>
> > > > > should consider is the restriction of the storage
and retrieval<br>
> > > > operations<br>
> > > > > on such resources to authorized users. How the
external storage<br>
> > system<br>
> > > > > should protect the stored executable resources
is out of scope.<br>
> > > Although<br>
> > > > I<br>
> > > > > prefer to recommend some security objectives to
be considered by<br>
> the<br>
> > > > > external storage system.<br>
> > > > ><br>
> > > > > If it's case 2) - I don't think we should give
"virus scanning" as<br>
> an<br>
> > > > > example to an Imaging System to protect the stored
Executable<br>
> > > Resources.<br>
> > > > > Virus scanning or intrusion detection techniques
are common in PCs,<br>
> > but<br>
> > > > > rarely existent in Imaging Systems. It's simply
not that practical<br>
> > for<br>
> > > an<br>
> > > > > Imaging System to have such software implemented
which involves<br>
> > > constant<br>
> > > > > maintenance of upto-date virus signatures by external
systems. At<br>
> the<br>
> > > > > abstract level, we can provide some good security
objectives to<br>
> > > consider<br>
> > > > for<br>
> > > > > the Imaging System, such as protection of confidentiality
and<br>
> > integrity<br>
> > > > of<br>
> > > > > the resources and their related metadata. Like
case 1), the storage<br>
> > and<br>
> > > > > retrieval of operations on such resources must
to restricted to<br>
> > > > authorized<br>
> > > > > users.<br>
> > > > ><br>
> > > > > A Resource Service could be hosted by a computer
remote to the<br>
> > Imaging<br>
> > > > > System that is under security consideration. We
should consider<br>
> this<br>
> > > case<br>
> > > > > too.<br>
> > > > ><br>
> > > > > 11.5 - Security Threats from Static Resources<br>
> > > > ><br>
> > > > > Static resources that have associated Intellectual
Property rights<br>
> or<br>
> > > > > license rights that involves metadata such as
DateTimeOfExpiration<br>
> > > which<br>
> > > > > should also be protected for alteration. Therefore,
not only<br>
> storage<br>
> > or<br>
> > > > > retrieval operations on Resources must be restricted,
other<br>
> > operations<br>
> > > on<br>
> > > > > resource metadata must be restricted too.<br>
> > > > ><br>
> > > > > Aslo the security problem you described here is
for storing Static<br>
> > > > > Resources internally in an Imaging System that
hosts the Resource<br>
> > > > Service.<br>
> > > > > We should also consider the case when the Resource
Service could be<br>
> > > > hosted<br>
> > > > > by a computer remote to the Imaging System.<br>
> > > > ><br>
> > > > > Thanks,<br>
> > > > > -Nancy<br>
> > > > ><br>
> > > > ><br>
> > > ><br>
> > ><br>
> ><br>
> -----------------------------------------------------------------------------<br>
> > > > > Principal Engineer<br>
> > > > > Solutions and Technology<br>
> > > > > Oki Data<br>
> > > > > 2000 Bishops Gate Blvd.<br>
> > > > > Mt. Laurel, NJ 08054<br>
> > > > > Phone: (856) 222-7006<br>
> > > > > Email: <a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a><br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > *Ira McDonald <<a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>>*<br>
> > > > ><br>
> > > > > 05/12/2009 03:15 PM<br>
> > > > > To<br>
> > > > > <a href="mailto:mfd@pwg.org" target="_blank">mfd@pwg.org</a>, NancyChen <<a href="mailto:nchen@okidata.com" target="_blank">nchen@okidata.com</a>>,
Ira McDonald <<br>
> > > > > <a href="mailto:blueroofmusic@gmail.com" target="_blank">blueroofmusic@gmail.com</a>> cc<br>
> > > > > Subject<br>
> > > > > Resource Service updates for Security<br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > ><br>
> > > > > Hi Nancy,
Tuesday (12 May<br>
> > > 2009)<br>
> > > > ><br>
> > > > > Per my action from the Resource Service review
during the April PWG<br>
> > > > > meeting, below is some text for the Security Considerations
section<br>
> > of<br>
> > > > > the Resource Service.<br>
> > > > ><br>
> > > > > 11.4 Security Threats from Executable Resources<br>
> > > > ><br>
> > > > > Resources with a ResourceCategory of 'Executable'
MUST be handled<br>
> > with<br>
> > > > > special care by implementations of the Resource
Service. Such<br>
> > > resources<br>
> > > > > can pose serious threats to the integrity of the
Imaging System<br>
> that<br>
> > > > > hosts the Resource Service. In particular,
such Resources can be<br>
> > used<br>
> > > > > to introduce Trojan Horses to the Imaging System.
If an<br>
> > implementation<br>
> > > > > of the Resource Service supports Executable resources,
then that<br>
> > > > > implementation MUST restrict the storage of such
resources (e.g.,<br>
> to<br>
> > > > > authorized administrators and manufacturers) and
SHOULD verify the<br>
> > > > > safety of such resources (e.g., by virus scanning).<br>
> > > > ><br>
> > > > > 11.5 Security Threats from Static Resources<br>
> > > > ><br>
> > > > > Resources with ResourceCategory of 'Static' SHOULD
be treated with<br>
> > > > > special care by implementations of the Resource
Service. Fonts<br>
> that<br>
> > > > > have associated Intellectual Property rights (e.g.,
as part of<br>
> their<br>
> > > > > network licenses) can pose serious threats to
the availability of<br>
> the<br>
> > > > > Imaging System that hosts the Resource Service
- security audits<br>
> can<br>
> > > > > result in the shutdown or physical removal of
the Imaging System.<br>
> If</tt></font>
<br><font size="2"><tt>> > > an</tt></font>
<br><font size="2"><tt>> > > > > implementation of the Resource
Service supports Static resources<br>
> that<br>
> > > > > have associated Intellectual Property rights,
then that<br>
> > implementation<br>
> > > > > SHOULD restrict the storage of such resources
(e.g., to authorized<br>
> > > > > administrators and manufacturers) and SHOULD restrict
the retrieval<br>
> > of<br>
> > > > > such resources (e.g., to a configured group of
authorized users).<br>
> > > > ><br>
> > > > > Comments?<br>
> > > > ><br>
> > > > > Cheers,<br>
> > > > > - Ira<br>
> > > > ><br>
> > > > > 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:<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>
> > > > ><br>
> > > ><br>
> > > ><br>
> > > ><br>
> > ><br>
> > ><br>
> > ><br>
> ><br>
> ><br>
> ><br>
><br>
><br>
></tt></font>
<br>
<br>
<br></div></div></blockquote></div><br>