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

Gregory Alan Bolcer greg at bolcer.org
Mon Oct 15 20:41:42 PDT 2012


When any currently implemented browser has multiple certificates for the 
same domain, it picks the first one regardless of the date.  If the date 
is expired, then it throws and error.  The correct behavior should be to 
ignore ones with expired dates and pick the one in the store that has 
the longest valid date.

There is no wrong use for PKI.  It's just a tool.  I'm using it in a far 
more useful way than it was intended--the mark of any good tool. In 
fact, there are tremendous business benefits for doing it my way for 
certain applications.

Wildcarded certificates don't work as I don't want to open up the whole 
domain.  I want the certificate to be tied to a certain n-tuple of 
access credentials and resource paths but not others.

No browser currently implemented will go out and grab a new certificate 
while in the middle of responding to an SSL negotiation.   You are 
talking about ahead of time installation of certificates, I'm not.

Greg

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