[foaf-protocols] FOAF+SSL and root certificates

Peter Williams home_pw at msn.com
Mon Feb 15 02:31:40 CET 2010


If u have power over mind and matter, pursuade them to design cert  
selectors that cue off the cert policy extension (either its Id, or  
metadata from it's url ref).

It's going to be hard though. The big vendors are all invested (on  
behslf of defense contracts) in websso card selectors ( vs ssl cert  
selectors ). Card selectors use policy extensively - vs uding names  
and ssl hello based negot
iation - when automatically choosing signing credentials.


On Feb 14, 2010, at 3:45 PM, Bruno Harbulot <Bruno.Harbulot at manchester.ac.uk 
 > wrote:

>
>
> On 14/02/2010 23:18, Story Henry wrote:
>>
>> On 14 Feb 2010, at 21:37, Bruno Harbulot wrote:
>>
>>>
>>> Defining a pseudo CA-certificate with CN=FOAF+SSL (for example)  
>>> would just allow those resources that don't use a CA to ask for a  
>>> FOAF+SSL certificate (rather than just any certificate), provided  
>>> we all agree on which DN to use.
>>> If this is what we end up doing (this seems sensible), I would  
>>> recommend that all parties emitting FOAF+SSL certificates put a  
>>> sufficiently random serial number in their certificates (e.g.  
>>> based on a UUID), to avoid conflicts for applications that keep  
>>> track of certificates based on their serial numbers.
>>
>> In http://tools.ietf.org/html/rfc4346#section-7.4.4
>>
>> it says:
>>
>>     ClientCertificateType values are divided into three groups:
>>
>>       1. Values from 0 (zero) through 63 decimal (0x3F) inclusive are
>>          reserved for IETF Standards Track protocols.
>>
>>       2. Values from 64 decimal (0x40) through 223 decimal (0xDF)
>>          inclusive are reserved for assignment for non-Standards  
>> Track
>>          methods.
>>
>>       3. Values from 224 decimal (0xE0) through 255 decimal (0xFF)
>>          inclusive are reserved for private use.
>>
>>
>> Perhaps we could use one of these numbers, instead? That seems like  
>> it would be more appropriate.
>
>
> No, this is not that kind of type at all. See the beginning of that  
> section:
>>      enum {
>>          rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
>>       rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6),
>>       fortezza_dms_RESERVED(20),
>>          (255)
>>      } ClientCertificateType;
>
> So far, we've been using RSA keys (and thus rsa_sign). I suppose we
> could use dss_sign at some point.
> These types imply a further CertificateVerify TLS message later on in
> the handshake, which is rather fundamental for what we are doing  
> (since
> that's what effectively proves that the client does indeed have the
> private key for the certificate its sending).
>
> Let's not dig into ClientCertificateType. The certificates we're using
> already fit into existing categories and this has nothing to do with
> verifying how the certificate is to be trusted (signing key-usage flag
> excepted perhaps, but we'd have this to true if present anyway).
> Introducing a new type here would not just be redundant, but also
> require modifications in a number of TLS libraries.
>
>
> Best wishes,
>
> Bruno.
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols
>


More information about the foaf-protocols mailing list