Re: Proposal: DN="CN=WebID,O=∅" was: certificate-authorities in CertificateRequest

On 10/21/12 6:49 PM, Henry Story wrote:
> On 21 Oct 2012, at 18:42, Kingsley Idehen<kidehen@openlinksw.com>  wrote:
>
>> >On 10/21/12 2:46 AM, Henry Story wrote:
>>> >>I think I forgot to explain what the point of this proposal was:
>>> >>
>>> >>   A server needs to have a way to help pre-select the certificates a client
>>> >>can choose from, so that the user does not select by mistake a certificate
>>> >>that the server does not know how to verify.
>> >
>> >Yes, but that's an artificial condition that arises from existing PKI implementation.
> This is part of the TLS standard. We are just trying to espouse the standard even
> more closely to our advantage.
>
> Servers can still continue to ask for the null certificate chain, as most of our WebID servers do now. But if we do this correctly, then we can build an even better user experience. I'll try to show this in an example server soon, which should make the point clear.
>
>> >What about working around this broken pattern such that its easier for folks to update their local trust anchors re. local trust chains?  What's wrong with a CA's WebID in the IAN of a cert. such that it provides a path for de-referencing a public key or entire CA cert for local trust chain update?
> Nothing. But that does not deal with the certificate filtering problem we are trying to
> deal with here. You had a long debate with Ben Laurie on another thread on this issue. By implementing this, we can make that debate go away, and also gain some new allies.
>
>> >
>> >It isn't beneficial to assume users are incapable of getting over the scaring mongering inherent in current PKI implementations.
>> >
>>> >>  TLS has a very minimal system
>>> >>to do this based on DNs. We would like to add the ability to do this for
>>> >>WebID certificates: i.e. specify at the protocol layer that a server accepts
>>> >>a WebID cert.
>> >
>> >I think this is an optional heuristic. I don't share the perception of certificate selection being problematic to end-users. We all have more than one collection of cards in our wallets (circa. 2012), thus making a selection isn't unusual behavior in scenarios where proof of identity is requested etc..
> The point is just to allow the server to specify which types of certificates it knows how
> to deal with ahead of time, so that the user does not send a certificate to the server that
> the server does not know how to process. This is a User Intereaction issue most of all,
> and one that Ban Laurie and others have brought to the attention to the group. We can
> fix this quite easily by following the convention I propose in this thread.
>
> An example in use will certainly help make this clear.
>

Okay, let's work through an example. I'll have this implemented in a 
loosely coupled manner, as per usual :-)


-- 

Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen