Re: certificate-authorities in CertificateRequest

Hi Henry

the first point to note is that signing CA public keys by the WebID root
CA is not signifying any trust in the CA per se. It is merely signalling
that this is the public key of this CA. Right? And because the root CA
has already done this for you, then we can be sure it is correct, or 
else the root CA is a fraudster. But given that the root CAs' certs are 
already built into our browsers by MS, Apple, Mozilla et al then they 
have already done the validation for you. Right?

The second point to note is that it is not the root CAs' keys which the
WebID CA is signing, but rather the subordinate CAs of these CAs. This
is because signature chain verification may not wont work if it comes
across a self signed root CA key which is not the WebID CA (the root of
trust). So by signing the keys of subordinate CAs of the root CAs built
into browsers, we create an alternative path to the trusted root CA. Of 
course this makes the work load even greater than you imagined, since 
each root CA may have 3 or 4 subordinate CAs. But your proposal below 
will probably handle this.

More comments below

On 12/10/2012 11:26, Henry Story wrote:
>
> On 12 Oct 2012, at 11:27, David Chadwick <d.w.chadwick@kent.ac.uk>
> wrote:
>
>> Hi Henry
>>
>> the problem is a large one that, from a quick scan of the web,
>> seems to effect more TLS users than just WebID. Essentially it is a
>> scalability problem, since the current way of filtering, using the
>> DNs of trusted CAs, is not scalable. Another mechanism is needed.
>> But this will be very time consuming since it will require the IETF
>> to standardise a new extension e.g. based on the "type" of CA.
>>
>> Your proposed solution of "standardising" a CA DN to be used in the
>> TLS negotiation is an appropriate one, given the current
>> limitations of the filtering mechanism. But doesn't this mean that
>> every WedID self signed client cert will need to have an issuer
>> field containing this standard DN rather than the DN of the user?
>
> It, or I suppose one of the signers in the chain, right?
>
>>
>> Or if the client cert is signed/issued by a real CA, then the root
>> CA of this chain will need to say that its issuer is this standard
>> DN rather than the current root? Which on the face of it might seem
>> to rule out the use of commercial CAs.
>>
>> Perhaps a solution to the latter problem, is that you/W3C/WebID
>> issue a single self signed root CA with the standard DN, and then
>> issue a set of subordinate CA certs that say the issuer is the
>> standard DN, and the subjects are the subordinate CAs of the
>> existing commercial root CAs. ie. you create a new hierarchy with a
>> WebID CA (with the standard DN) being the root CA of all existing
>> commercial CAs (or at least the ones that WebID users use).
>
> This is close to the lines along which we were thinking. But with a
> twist...
>
> The problem with the way you put it, is that the W3C would have to
> become a Certifier for all Root CAs,

no, not Root CAs but their immediate subordinates

  and of every group that wanted
> to become a client certificate provider. This would cause a
> bottleneck,

Its not a big task. One signature per CA. You only need to sign the 
public keys once, and make your certs have many years validity time to 
coincide with the validity time of the cert of the key you are signing.


  as the W3C would have to have someone do some type of
> verification procedure that people could take seriously.

Totally unnecessary for reasons given above.

  Unless of
> course we made the private key available for the CN=WebID,O=W3C so
> that everybody could then go sign their own keys. I imagine that just
> the thought of this is sending goosebumps across the whole body of
> any security specialist. :-)

Actually it sounds like a really cool idea, because the certificate 
signing is not providing any trust in the CA (other than mathematical 
trust that it is the right key pair). The trust of WebID comes from the 
associated web pages pointed to by the SAN extensions.


>
> But my feeling is that there is something to this. What is publishing
> the private key of a certificate other than essentially claiming it
> has no importance at all? So why even bother with the certificate:

Because you will probably need it for TLS cert chain validation. Also 
publishing something that is signed (the self signed cert of the WebID 
root CA say) gives the mathematical proof that the public key is the 
correct one associated with the private one.


> all we need is the name.
>
> As I understand, CA certificate verification procedure goes like
> this: A verifier receives a to-be-verified certificate chain. It
> starts with the leaf one, and walks up the signature chain until it
> finds a certificate signed by a CA it trusts. It verifies the
> signature and returns the answer of that verification. It need not go
> any further up the chain, since anything further up the chain is
> already verified.

As I understand it, the verification process goes down the chain from 
the trusted root (trust anchor in PKIX terms) since this is a public key 
you know is OK. You then check the certificate issued by this root, 
which gives you the public key of the subordinate CA. You do this 
recursively until you have validated the certificate of the end user.

>
> So here is the solution for any chain that wishes to signal its WebID
> compliance:
>
> make the root of your chain specify that it was signed by
> CN=WebID,O=W3C

and have a certificate in which the public key of this CA is held. This 
then gives the verification code the public key it needs to start the 
chain verification process.

>
> With this we should have the following scenarios: a- Usual CA
> verification procedures will iterate through the chain and either +
> find a CA they have in their TrustStore and so stop with a success or
> failure + or reach the root certificate signed by CN=WebID,O=W3C and
> fail because they won't have that in their trust store

sorry you lost me in this bit. What is being verified? A client webID 
certificate?

  b- WebID
> verification does not walk the certificate chain so it has no
> problems there (If WebID wanted to also get CA verification as a
> bonus, it would be in the situation (a) above )
>

No it doesnt. But the application code first needs to get the 
client/user cert in order to start the verification process. And it uses 
TLS for this. So I thought we were talking about TLS verification so 
that a user (client) could choose a cert that was issued by the WebID CA 
either directly or indirectly, so that the TLS code in the server could 
validate the client cert when it arrives at the server end and tell the 
application code that the client has been authenticated and here is the 
good and valid cert. The application can then start the WebID trust 
verification (since all we have up to this point is mathematical 
verification).

>
> So having written this out, I think I have convinced myself that this
> is a good idea now.  If that is correct, what should the DN be? It
> should be short.

It does not really matter what it is, as long as it is globally unique. 
So you should register a DNS name for it, say webid.w3c.org. Then you 
could have CN=webid.w3c.org (and optionally o=w3c)

  Could it just be CN=WebID ? If we want to add an
> organisation should it be W3C? (I was thinking GOD, would be a good
> one too, because essentially it is the CA of all self signed
> entities.

I like that idea :-)

  But W3C is pretty close to GOD I hear ;-)

But not that one :-)

David
>


>
>
>> Its simply a type of cross certification. I dont know how browsers
>> will work if they find a CA has two issuers. In theory it should
>> make no difference because cross certification is a standardised
>> procedure. Tree walking down from the new WebID trusted root should
>> work just the same as now (although tree walking up from a leaf may
>> cause problems when a fork is reached.) The only way will be to
>> "suck it and see"
>>
>> regards
>>
>> David
>>
>>
>> On 12/10/2012 09:15, Henry Story wrote:
>>> I have re-opened ISSUE-62 on certificate-authorities list [1]
>>>
>>> Currently the  WebID spec
>>>
>>> http://webid.info/spec/#requesting-the-client-certificate
>>>
>>> suggests that the server requests the null
>>> certificate-authorities list. This means that the end-user is
>>> asked to select all certificates available in his browser. As it
>>> happens at present for most users there will be none chosen,
>>> since most users don't have any, or very few as the author of the
>>> Android API argues in the message in bug report 38393 below.
>>>
>>> But things could change and users could end up having more than
>>> 1, and in Europe certificates are more widely spread. If they
>>> have more than 1 certificates it would be very helpful if a
>>> server could request certificates that were WebID enabled, so
>>> that the user did not mistakenly send a traditional certificate
>>> that the WebID enabled server could do nothing about.
>>>
>>> I think this was an issue Ben Laurie meant to bring up recently
>>> when he discussed the number of certificates we have to choose.
>>>
>>> So the only technical solution available to us at this time, is
>>> the certificate_authorities selector in a request, and to have
>>> this set to some DN that signals a WebID enabled certificate.
>>>
>>> Would this work? What could we have this DN be?
>>>
>>> CN=WebID,O=W3C
>>>
>>> perhaps? Are there tricks one could use so that even actual CAs
>>> could add that DN to their chain?
>>>
>>> I am asking for technical answers here please, not for rants
>>> about how TLS's failings. If this can get to work and be
>>> reasonably popular, it will be incentive for future versions of
>>> TLS or future protocols to improve this part of the protocol.
>>>
>>>
>>> On 12 Oct 2012, at 09:19, Anders Rundgren
>>> <anders.rundgren@telia.com> wrote:
>>>
>>>> Google's take on certificate selection:
>>>>
>>>> http://code.google.com/p/android/issues/detail?id=38393
>>>>
>>>> "I designed the API with the intent that filtering could be
>>>> added later if necessary, but I've never been convinced that
>>>> users really are going to have large numbers of keys. What I
>>>> said about issuer filtering really is true. It almost always is
>>>> configured wrong if at all. If you can motivate a use case, I'm
>>>> all ears"
>>>>
>>>> -- Anders
>>>
>>> Social Web Architect http://bblfish.net/
>>>
>
> Social Web Architect http://bblfish.net/
>

Received on Friday, 12 October 2012 17:22:58 UTC