A secure user

[Michael Sweet]

Jim Hranicky wrote:
> [ crud, messed up the last message ]
> 
>>> But the addition of the cert parameter will require an addition to
>>> the HTTP API in the client library so that http_setup_ssl() will
>>> use it when negotiating the secure link.  *Or* you can duplicate
>>> all of the SSL code in the IPP backend... ;)
>> Ah, I see. Ok, let me ponder a bit.
> 
> One way to do it from the backend would be to parse the DEVICE_URI
> environment variable -- it's available to the call to http_setup_ssl()
> from the backend, but I don't know if that's the best way in general
> if you want to add generic cert support.

No, looking for the environment variable in http_setup_ssl() would
be a definite hack.  That's a quick way you could add it for your
own use, but ultimately we'll want to define a more general-purpose
API.

> Other than that, I think the options would be
> 
>     - add parameters to http_setup_ssl()
>     - grap it from a global variable
>     - grab the uri from the http_t parameter
> 
> Is the uri already passed in via the http_t struct?

No, the URI is only used for an actual operation.

.....

As for how I would design it, I'd be looking at adding a
certificate file/store for the IPP backend that provides the system
(and possibly user) certificates, e.g.:

     "ipp.certs":

     * ... PEM-encoded certificate data for system ...
     mike ... PEM-encoded certificate data for "mike" ...
     jim ... PEM-encoded certificate data for "jim" ...

Then the backend can read this file and use the best match that
is found.

Finally, add a httpSetClientCertificate(http_t *http, const char *pem)
function which saves the PEM-encoded certificate for the given
connection in the http_t structure, and then use it from
http_setup_ssl().

Longer term we'll want to make this more general-purpose (i.e. an
authenticated request with a client certificate will automatically
append that user's certificate to the ipp.certs file) and have the
cupsd program and CUPS API support using certificates for
authentication.

Um, how about a quick ASCII diagram:

     CUPS client   -------->    CUPS server  ------>    IPP Backend
        ^                            ^                      ^
        |                            |                      |
        |                            v                      |
     ~/.cups/identity.pub          ipp.certs --------------/
     ~/.ssh/identify.pub

The CUPS client sets up a SSL/TLS session with the CUPS server and
passes the user's certificate to the server as authentication.  The
first time the server gets a certificate for a user, it challenges
the user to authenticate and then stores the authenticated certificate
in the ipp.certs file.  Otherwise, providing the certificate and
matching username is sufficient to authenticate with the server from
that point on.  Both user and server certificates will be supported
(the HTTP authentication challenge would only happen for unregistered
user certificates...)

The IPP backend gets the username for the print job and looks for
a corresponding certificate.  If not found, it looks for the system
certificate (probably a copy of the ServerCertificate) and uses it
when encrypting the connection to the remote server.

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products           mike at easysw dot com
Internet Printing and Document Software          http://www.easysw.com