RE: self-signed

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:-

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: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
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: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
> 
>

Received on Thursday, 14 April 2011 02:17:08 UTC