Hi, Max -
> Couple of things to note:
> 1. What is the 'killer app' for secure connection? I know Frank and
> Mark had talked in the past about the need to "authenticate"
> clients to be able to provide finer granied access control.
> If this is the real driver behind this work then I think some sort
> of strawman to how how it can work end-to-end, i.e. how can pmcd
> verify that it knows the client would go a very long way in proving
> that the abstraction actually makes sense. [...]
You're right, the main motivation is the future access control work,
where clients would authenticate with pmcd using userids/passwords or
perhaps ssl certificates, a process which naturally has to be
A secondary motivation is simple opportunistic encryption, which aims
only to preserve privacy from snoopers on a network. This is
important at some sites.
A tertiary motivation is ipv6 support that NSPR helps with for pcpd
comms, even without SSL/TLS.
> 2. In PCP world pmcd can send unsolicited PDU to the client. This kind
> of communication does not map well on STARTTLS-like paradigm unless
> you're planing to delay STARTTLS phase until after connection
> handshake is done.
> 3. Who's going to decide what it's time to 'starttls'? Usually it's
> the 'client' decision but client needs to know that server is
> capable of this. How is it going to be communicated to the client?
We're not sure yet. From my cursory reading of the code, offering
STARTTLS capability early via one of those early unsolicited PDUs
could do the trick. The server would advertise its capability with
one packet; older clients would ignore it, newer clients reply "yes
please", then they switch over. If a scheme such as this were not
possible, we'd be stuck with having a separate SSL port#, which
we'd like to avoid.