You could easily set up some access control policies based on certificates.
For example:
- Only accept jobs from clients having a certificate containing OU=PSD,
O=IBM (OU is organizational unit, O is organization)
- Only accept jobs from clients having a certificate issued and signed by
my private certificate authority (CA)
- Only accept admin requests from clients having a certificate issued and
signed by my private CA, containing O=PSD, OU=Admins
Or, you could create a directory or database mapping subject unique
identifiers to specific capabilities.
-Carl
pmoore at peerless.com@pwg.org on 08/21/2000 03:23:43 PM
Sent by: owner-ifx at pwg.org
To: Carl Kugler/Boulder/IBM at IBMUS
cc: ifx at pwg.org
Subject: Re: IFX> draft-moore-qualdocs-protocol-00.txt
You are quite correct - and I certainly believe we should explore
certificate
based authentication.
Access control is more of a challenge - as far as I am aware (but I am
probably
wrong) there is no widely accepted mechanism for certificate based access
control.
"Carl Kugler/Boulder/IBM" <kugler at us.ibm.com> on 08/21/2000 02:09:47 PM
To: ifx at pwg.org
cc: (bcc: Paul Moore/AUCO/US)
Subject: IFX> draft-moore-qualdocs-protocol-00.txt
<!--StartFragment-->7 Security considerations
QD presents an interesting challenge of balancing security and
openness. Many of the envisaged uses of QD require confidentiality of
the data . at the same time the receiver typically has no prior
knowledge of the sender or the sending user. This last point will
normally rule out all user-based authentication and access control.
<!--EndFragment-->
Comment: I don't think the receiver's lack of knowledge of the sender
necessarily rules out all user-based authentication. Authentication is
"the act of verifying the claimed identity of an individual,
station or originator".
Client-side certificates could be used for this. I think it's useful,
because it would allow one to set up a Printer that is publicly, but not
anonymously, accessible.
-Carl