Policy-Discussion

[Daniel Black <daniel AT cacert.org>]

On Monday 22 March 2010 09:35:52 Ian G wrote:
> On 21/03/2010 02:16, Daniel Black wrote:
> 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.

worth checking but I think someone confirmed it worked GR/cacert-support. 
needs more checking though/
> 
> (TLS can't handle SHA2, but that is a different issue.)
is it important for this discussion on roots?

> 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.

ok

> 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????

no question marks! be assertive!

> > 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.

ok - looks like an easy one to write in to the CPS.

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

it keeps some people happy.
> 
> 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.

where do we stand with adding it later post audit? I guessing an audit update 
would need to be done to cover it.
> 
> Again, it's not exactly needed, but it might make things easier.

I'm all for 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?

yes.

> > 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?)

yes.

These was my reading of the RFC and 

https://wiki.mozilla.org/CA:Problematic_Practices#OCSP_Responses_signed_by_a_certificate_under_a_different_root

tell me if i'm wrong.

> 
> > 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.

ok as long as its recorded.

-- 
Daniel Black
CAcert

Attachment: smime.p7s
Description: S/MIME cryptographic signature