[foaf-protocols] FOAF+SSL and root certificates

[Bruno Harbulot]

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.