W3C home > Mailing lists > Public > public-xg-webid@w3.org > April 2011

Re: self-signed

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 14 Apr 2011 07:46:21 -0400
Message-ID: <4DA6DE8D.9030808@openlinksw.com>
To: peter williams <home_pw@msn.com>
CC: nathan@webr3.org, 'Joe Presbrey' <presbrey@gmail.com>, 'Henry Story' <henry.story@bblfish.net>, 'WebID XG' <public-xg-webid@w3.org>, 'Joerg Anders' <jan@informatik.tu-chemnitz.de>
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.

Kingsley

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


-- 

Regards,

Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Thursday, 14 April 2011 11:46:49 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:24 UTC