Re: self-signed

On 14 Apr 2011, at 01:44, nathan wrote:

> For any wondering, the specifications are quite strong on this:
> 
> [[
> A certificate-using system MUST reject the certificate if it encounters a critical extension it does not recognize or a critical extension that contains information that it cannot process. A non-critical extension MAY be ignored if it is not recognized, but MUST be processed if it is recognized.
> ]]

What this is saying is somewhat more complex I guess, that just quoting the above would lead one to think, because one has to read it in context of the way it was meant to be deployed. If by a Certificate Using system they mean system that relies for its trust on statements made by a CA then they are correct. If there is an extension in the certificate marked critical that you don't understand, then you must reject any idea that you understand what the certificate says. So of course you must reject the certificate and should not build a trust relation based on that.

What we are doing is 

1. discovering from TLS handshake crypto primitives that that agent on the end of the connection knows the private key of the public key that happens to be published in the cert (could be in DNS too in future versions of TLS)
2. Some CA dude, not sure we even know that person, says that this guy's name is https://name.example/#me - ok let's check

We need not rely on anything the CA says to come to the conclusion that the WebID is correct. (If we do want to then we'd better understand all the critical extensions.)

> 
> So either clerezza is very clever and can process all the extensions you marked as critical, or contains a bug in that it doesn't process them all and instead ignores that MUST from the specification.

So clerezza is very clever :-) It does not rely on anything the CA says and so does not need to process any of the critical extensions.

> 
> Either way, I believe this is a gotcha worth noting, perhaps even as a "Note:" in the WebID spec.

yes, for sure. 

What we also need to note is that default Apache configs may not be as clever as Clerezza, so for those we should help people make correct CA certs that will pass these types of 'meaningless' rules. 
(These thing can last a long time btw: in the UK it's a national habit to take long ago abandoned protocols and turn them into a national heritage this way. People continue to make the gestures just for the old folks sake and to keep memory alive.)

> 
> Best,
> 
> Nathan
> 
> Joe Presbrey wrote:
>> Hans X509 extensions should not be marked critical (should be marked
>> 'not critical'). See my extensions listing below for the distinction:
>>        X509v3 extensions:
>>            X509v3 Subject Alternative Name:
>>                URI:http://presbrey.mit.edu/foaf#presbrey
>>            X509v3 Subject Key Identifier:
>>                CD:16:4C:A8:DC:78:5C:45:33:1B:7C:71:46:0F:70:FF:0D:1E:FE:D5
>>            X509v3 Basic Constraints:
>>                CA:FALSE
>> On Wed, Apr 13, 2011 at 5:47 PM, Henry Story <henry.story@bblfish.net> wrote:
>>>       X509v3 extensions:
>>>           Netscape Cert Type: critical
>>>               SSL Client, S/MIME, Object Signing
>>>           X509v3 Subject Alternative Name: critical
>>>               email:ba.obma@vodafone.de, URI:http://foaf.me/Hans#me
>>>           X509v3 Subject Key Identifier: critical
>>>               58:92:81:B9:80:08:6F:6F:C9:65:D7:2E:70:D5:D8:D8:DC:28:3F:47
>>>           X509v3 Extended Key Usage: critical
>>>               TLS Web Client Authentication, Code Signing, E-mail Protection
>>>           X509v3 Key Usage: critical
>>>               Digital Signature, Key Encipherment, Data Encipherment, Key Agreement
>>>           X509v3 Basic Constraints: critical
>>>               CA:FALSE
> 

Social Web Architect
http://bblfish.net/

Received on Thursday, 14 April 2011 06:12:29 UTC