Policy-Discussion

[Benedikt Heintel <benedikt AT cacert.org>]

Hi Ian, hi List,

this is what I think about priority: everything to its time. And now
it's time to answer this mail (almost 6 days later)..

Am 17.02.2013 14:01, schrieb Ian G:
> Hi Benedikt,
> 
> On 17/02/13 01:45 AM, Benedikt Heintel wrote:
> 
> 
> These other issues below -- please treat my response as bar talk over
> beers as we're not actually evaluating the documents concerned right
> now.  I find the comments interesting, tho.
> 
>> and should be made ISO
>> 27001 conform. It's on my task list but not on priority 1.
> 
> Hmmm.... what does ISO 27001 conformance mean and why would it be good
> for CAcert?
> 

That's an important question and when I was thinking about the SP, it
reminded me of the importance of Security in a CA. As written by Peter
in his 2nd analogy email, CAcert isn't a public CA yet, but it is public
enough to have stakeholders with high expectations towards the system
operations and trust of the CA.

ISO 27001 introduces the Information Security Management System (ISMS).
A system used to plan, execute, and control security (physical and data)
over an association's assets. You cannot deny that this is what we also
need to do an do everyday. Why not getting compliant to an international
norm?

To sum up the pros. Compliance to ISO 27001 goes hand in hand with our
information security goals, adds additional trust in our policies and
processes, and helps us to pass the audit since all audit rules are
somehow to a big part related to information security.

>> One Policy I like to add is CP / CPS. It is not totally compliant to RFC
>> 3647.
> 
> Same question as above.  Although the CPS was modelled after RFC 3647,
> it was never expected to be exactly the same.  IMHO nor is that useful: 
> "This document presents a framework to assist the writers of [CPS,
> etc]..."  We were assisted :) so are we not conformant with the
> intention of the document?
> 

You are right (what else, if you cite the RFC), that this document is
only a framework and could be modified to our own needs. However, the
RFC also says, that all chapters of the framework should stay and be
only marked as not stipulated:

   It is recommended that each and every component and subcomponent be
   included in a CP or CPS, even if there is "no stipulation"; [c.f. 4]

Second, the RFC divides CPS from CP, by describing the difference as follow:

   [T]he purpose of the CP is to establish what participants must do.
   A CPS, by contrast, states how a CA and other participants in a
   given domain implement procedures and controls to meet the
   requirements stated in the CP. [...]

   An additional difference between a CP and CPS relates the scope of
   coverage of the two kinds of documents.  Since a CP is a statement of
   requirements, it best serves as the vehicle for communicating minimum
   operating guidelines that must be met by interoperating PKIs. [...]
   By contrast, a CPS applies only to a single CA or single
   organization and is not generally a vehicle to facilitate
   interoperation. [c.f. 3.5]

CAcert does not has a dedicated CP, only a CPS, thus both are requested
by the RFC.

>> The RFC states one policy or at least one practice statement per
>> (sub-)CA. As I figured out, CAcert has 4 CAs: Test (no security),
> 
> I would agree that Test is a different CA.  Whether it needs a separate
> CPS, I don't know - why is that?  Or to put it on point, perhaps the CPS
> for the Test CA should be "this CPS imposes no restrictions." ?
> 
> 

On Test (what Uli explained to us are different CAs), we are clear, we
would not need a CPS at all.

>> Anonymous (low security), Named and Organisation (medium security).
> 
> Why are these different CAs?
> 

No, these are no different CAs (one CP), but the Anonymous Sub-CA does
not request for an RA process, since the name of the certificate holder
is not included in the certificate (two different CPS).

An (not that good) example of why to use different CPS can be found in
Chapter 3.5 of the RFC.

>> Not really covered is the security need for code signing. However,
> 
> 
> Say more? on code-signing, there is some older discussion here:
> 
> http://wiki.cacert.org/PolicyDrafts/CodesigningAssurancePolicy
> 
> practice is here I think:
> http://wiki.cacert.org/CodesigningCert
> SM here:
> http://wiki.cacert.org/SecurityManual 8.2.2/2 admin role to set
> code-signing flag.
> 
> 

Code signing is somewhat critical. If you allow someone to sign code,
you give someone the power to do malicious things with software. To
reach this ability - and CAcert understood this already - you need to
invest something.

What are the special security needs? The certificate may only include
one flag "code signing" and may be signed by a Sub-CA that could be
revoked if malicious action are taken on one or multiple code signing
certificates or the Sub-CA itself. This would be an own CPS.

Btw. the Code Singing Policy should be buried in the current state. This
will do only harm, alone the purpose (pass the audit) makes the policy
senseless in my mind.

>> CAcert is not capable to issue high security certificates at the moment.
>> This is also on my task list, after SP is done.
> 
> Define "high security" ?
> 

Certificates with high security needs are certificates for the so called
"qualified digital signature" [§17 SigG Germany] or "secure digital
signature" [§2 SigG Austria]. Certificates with lower needs are
"advanced digital signatures" and "simple digital signatures".

> 
> Certainly, some close attention to the CPS would be welcome.  Since it
> went to DRAFT, it has languished a bit.  It would be nice to improve it
> and/or move it to POLICY.  However I don't see it as the highest
> priority, nor the easiest task :)
> 

Right, I even see quite a lot of work. Maybe we should withdraw the
current version and issue a new one under a new OID.

> iang

Benedikt

-- 
Benedikt Heintel - 
benedikt AT cacert.org
CAcert Assurer for People & Organizations

CAcert.org - Secure Together
http://www.cacert.org

Attachment: smime.p7s
Description: S/MIME Kryptografische Unterschrift