Skip to Content.
Sympa Menu

cacert-policy - Re: proposal to stop issuing class3 certificates

Subject: Policy-Discussion

List archive

Re: proposal to stop issuing class3 certificates


Chronological Thread 
  • From: Philipp Guehring <philipp AT cacert.org>
  • To: cacert-policy AT lists.cacert.org
  • Subject: Re: proposal to stop issuing class3 certificates
  • Date: Wed, 13 Jan 2010 18:14:56 +0100
  • Authentication-results: lists.cacert.org; dkim=pass (1024-bit key) header.i= AT cacert.org; dkim-asp=none

Hi,

> Just for my understanding, I know we cannot change this right now, and
> we did not have class-3 when CAcert started)
> Would it be correct to state that when the class-3 root was a separate,
> self-signed root, it would not be a problem?
> Also, wouldn't it be more correct (greenfield?) to have the class-3 root
> as highest root, and have the class-1 root signed by the class-3 root?
> So that you can choose:
>  - rely only on class-1 ==> load the class-1 root as CA
>  - rely on class-3 (better verified certs) ==> load the class-3 root,
> and get class-1 (lower reliance) as bonus
> Or would it be better to create a separate class-1 root and class-3 root?
>   

From my point of view, it turned out that it's the wrong idea to use
intermediate certificates for different reliance levels, since most
software (Browsers, ...) do not support that concept.
From a technological point of view, the correct way would be to add an
extension field to the certificate that states whether the certificate
is an assured one, or not.
Using completely different root certificates would be an alternative
solution, but this would make it more complex for users to install
several certificates instead of just one.
As far as I have seen, only a very small part of the users actually have
a need for differentiating unassured from assured certificates, and
invested work to do it.
So the easier option I think would be to encode it in the end-user
certificates, whether the certificate is an assured one, or not.
The other advantage we have with the encoding in the end-user
certificates is that we could even encode more details into it, like
putting the actual amount of assurance points in it.

Best regards,
Philipp Gühring



Archive powered by MHonArc 2.6.16.

Top of Page