Policy-Discussion

[Ian G <iang AT cacert.org>]

On 21/03/2010 02:16, Daniel Black wrote:
> Ok looking closer at these it seems the decisions that need to be made are:
>
> Content:
>
> http://wiki.cacert.org/Roots/Contents
> http://wiki.cacert.org/Roots/ContentsDiscussion
>
> 1. Root PK type - SHA1  or SHA2
> SHA2 is supported in Windows XP SP3
> May not be supported in all appliances so would be prudent to stay with SHA1


that's client side ... what about server side?  Last I heard, Apache 
HTTPD could not handle SHA2 in certs.  I could be wrong, worth checking.

(TLS can't handle SHA2, but that is a different issue.)

The problem is different for the Root as for the Subroots.  The Root is 
listed for 30 years or so.  Subroots are listed for only 10 years?

SHA1 is likely to hit "MD5 paranoia" within around 3-5 years.  So 
getting the *root* out with SHA2 would be very good, because the 
paranoid don't understand the root equation, they just think everything 
with a bad brand is poisoned.

We could probably survive the paranoia with the subroots by re-issuing. 
 But, if we can issue the root with SHA2, we can also issue the 
subroots ... but also bear in mind, SHA3 is probably coming anyway.

Well, it's a mess.  For now, concentrate on whether we can issue a root 
with SHA2????

The Root is the only thing that goes to (Mozilla's) root list.  Not the 
subroots.


> 2. Root and Subroot OU  value (see discussion page)
>
> Structure:
>
> https://wiki.cacert.org/Roots/Structure
>
> 3. Contents page suggests an Assurer SubRoot. Is this really needed?


This was suggested for several reasons.

1.  AP says that member can know that Assurer is Assurer.  An email with 
Assurer-subroot signature could do that.

2.  There is a social need to reward the Assurers for their efforts.

3.  Assurers can make statements that are reliable, in the sense of 
CARS.  It would be useful to put those statements out with an Assurer 
subroot.

It's not needed, but there again, no subroot is "needed".

While on the topic, there is also a suggested Org subroot.  The reasons 
for this include:

a.  many outside (e.g., mozo, DRC) have suggested discomfort with either 
individual or org assurance as done by CAcert.  They want one not the 
other.  So one way to give them this is to separate by subroots.

b.  Organisation assurance as it is now cannot pass audit, IMHO.

Again, it's not exactly needed, but it might make things easier.

> Rest seems pretty right. I've added the OCSP Cert off the root for clarity.
> This would need to sign revocation requests on clients querying sub roots
> (http://tools.ietf.org/html/rfc2560#4.2.2.2 ;).

You mean here that the OCSP certificate for subroot revocation is signed 
by the root?

> To run separate signing and OCSP services we need to issue OCSP certificates
> off the subroots as well.

(and, OCSP certificate for EE certs is signed by subroots?)

> The general on separate subroots for different policies is still consistent
> with http://www.mozilla.org/projects/security/certs/policy/ #13.

OK, note organisation assurance is a separate (sub)policy.  Over on some 
group (cacert-devel ?) there is a debate as to whether orgs can delegate 
key creation to employees, which is an important policy decision that 
needs to be recorded in some fashion.

> Scripts:



out of scope for moment....

iang

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature