[FoRK] DNT: another example of "you can't make this shit up"

Stephen Williams sdw at lig.net
Mon Oct 15 20:15:40 PDT 2012


You're using it wrong.  PKI certificates are supposed to be like 
driver's licenses, birth certificates, etc. and change about as often.  
You only need one (or one per persona), more or less, and the rest of 
your identity is anchored from that.  If you want strong security, you 
need a PKI smart card or equivalent, protected by PIN, proofed at a 
known location by a well-trained officer by presenting sufficient proof 
of identity, with good surveillance.  You don't want to have to do that 
very often.

There should be only identity, expiration, and approval for an authority 
in a certificate.  There should never be application-specific 
authorization or anything ephemeral in the certificate.  That's what 
signed data is for, signed either by the user, a digital notary, or an 
authority or any combination of those.

You can have a certificate for a domain or subdomain, or a wildcarded 
domain.  Or an email address.
There shouldn't be multiple certificates with the same identity.

Browsers do check expiration date in at least some cases because I've 
seen the error messages.  If they don't check in all cases, it is an 
error.  They should also check for revoked certificates, via OCSP 
ideally, but that hasn't been widely used.  However, it does seem to be 
widely supported:
http://en.wikipedia.org/wiki/Online_Certificate_Status_Protocol
> Browser support
> Internet Explorer starting with version 7 on Windows Vista (not XP) 
> supports OCSP checking[1]
> All versions of Mozilla Firefox support OCSP checking. Firefox 3 
> enables OCSP checking by default.[2]
> Safari on Mac OS X supports OCSP checking. It is enabled by default as 
> of Mac OS X 10.7 (Lion). Prior to that, it has to be manually 
> activated in Keychain preferences.[3]
> Versions of Opera from 8.0[4][5] to the current version support OCSP 
> checking.
> Google Chrome supports OCSP checking.[3]

In what way does PKI need to be dynamic?

Browsers accept new certificates all the time when they talk SSL/TLS to 
a new server.
You mean accepting a new client certificate?  As in provisioning a new 
identity for the user of the browser?  Most browsers can accept new 
identities fairly easily, even new CA identities which should not be 
easy to add.

Dynamic and micro-access should use signed authorizations, similar to 
Kerberos and just like BrowserID / Persona.

On 10/15/12 11:02 AM, Gregory Alan Bolcer wrote:
>
>
> On 10/15/2012 10:43 AM, Stephen Williams wrote:
>>
>> What doesn't work correctly with client-side certificates?
>
> 1) They are domain specific and not path certificate based on content 
> inside them
>
> 2) Browsers pick the first certificate in their store that matches the 
> domain, though there could be infinite paths, thus infinite 
> certificates with the same domain inside the store
>
> 3) Browsers, even if it has the right domain, doesn't check the 
> timeout date
>
> 4) PKI is not dynamic
>
> 5) Browsers don't and can't dynamically incorporate a new certificate 
> while in the middle of an SSL negotiation process
>
> So, it doesn't work for dynamic nor micro-access.
>
> Greg
>
>> I've used both soft and hard certificates with browsers, SSH, etc. Other
>> than the proprietary driver fiasco for hard certificate access, it
>> works.  Except for the problems with PKI itself.
>>
>>>
>>> Gawd, that would be really cool.
>>>
>>> Greg
>>>
>>> On 10/15/2012 10:25 AM, Damien Morton wrote:
>>>> On Thu, Oct 11, 2012 at 5:41 PM, Stephen D. Williams <sdw at lig.net>
>>>> wrote:
>>>>
>>>>>
>>>>> We need something like cookies, at least some of the time.
>>>>
>>>>
>>>> Oh yeah - when do "we" need cookies?
>>>>
>>>> What does a user do with a cookie? Nothing, they don't even see them.
>>>>
>>>> If you have a way of presenting something like a BrowserID - a crypto
>>>> mashup of username/password/domain - any state can be stored 
>>>> server-side
>>
>> sdw

sdw



More information about the FoRK mailing list