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

Gregory Alan Bolcer greg at bolcer.org
Mon Oct 15 20:43:54 PDT 2012

Also, we can agree that a user identity, aka Stephen Williams is not the 
same as persistence of identity, aka the person who used his stored 
karma/goodwill/ad$/whatever to access X is the same person who is coming 
back to access Y on the same or crypto-family-related server within the 
time period/expiry date of his access.


On 10/15/2012 8:15 PM, Stephen Williams wrote:
> 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
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork

greg at bolcer.org, http://bolcer.org, c: +1.714.928.5476

More information about the FoRK mailing list