Re: self-signed

On 4/13/11 10:16 PM, peter williams wrote:
> A self-signed cert is not a cert. Therefore using one is not a cert-using
> system. We are just borrowing the format, formally.
> Certs are defined as things issued by third parties, intermediating two
> others who have mutual suspicion of each other (but not the TTP). The TTP is
> supposed to have high assurance, and have procedural controls do ensure it
> doesn't do what both VeriSign and Comodo did (enable false issuing acts) for
> important endpoints.
> In windows, one sets the validation mode in the kernels binding for the
> https endpoint. If I set certvalidation=none, its up to my code to choose
> whether or not to process extensions, or be conforming or not to the
> mandatory criticality setting.  I don't. I have a specific rationale:-

We do the same thing conceptually when configuring Virtuoso for WebID 
use re. IdP role.

This dimension is important re. IdP admin.


> As henry says, correctly, neither TLS server endpoint handling client certs
> nor webid validating process need to validate the signature on the
> self-signed cert. The extension values are essentially meaningless, as they
> have no integrity (as they are untested for being signed, in any case).
> It took A LOT OF EFFORT to ensure commodity system behave this way. If you
> want to step up.. to use higher assurances based on the control systems, you
> can of course. But by default, its laissez-faire - with no controls. Yes,
> this means by default, a lot of crap gets deployed. But, it's an investment
> in learning -  so millions of folks become crypto-capable (not just a few
> specialists in national security agencies).
> Apache needs to follow windows. And stop insisting on v3 enforcement by
> default (for webid purposes).
> -----Original Message-----
> From: []
> On Behalf Of Nathan
> Sent: Wednesday, April 13, 2011 4:45 PM
> To: Joe Presbrey
> Cc: Henry Story; WebID XG; Joerg Anders
> Subject: Re: self-signed
> 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.
> ]]
> 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.
> Either way, I believe this is a gotcha worth noting, perhaps even as a
> "Note:" in the WebID spec.
> 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:
>>              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<>
> wrote:
>>>         X509v3 extensions:
>>>             Netscape Cert Type: critical
>>>                 SSL Client, S/MIME, Object Signing
>>>             X509v3 Subject Alternative Name: critical
>>>       , URI:
>>>             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



Kingsley Idehen	
President&  CEO
OpenLink Software
Twitter/ kidehen

Received on Thursday, 14 April 2011 11:46:49 UTC