Policy-Discussion

[Philipp Gühring <pg AT futureware.at>]

Hi,

> Section 1.3 - Why are two sentences required? Isn't the first sentence
> a subset of the second?

It looks ok for me, to differentiate between assured and unassured users 
there.

> section 1.3.3 - Did you mean "Personal CA"?

I don´t know, I removed it.

> section 1.5.4 - "evidence to to so" Do we need to specify what
> constitutes "evidence"?

I changed it to "unless there is a reason to do so."

> section 3.1.5 - Do we (need or do) check the uniqueness of names of
> user? 

I think we are currently checking for the uniqueness of the email address.
Could someone verify in the sourcecode, what we are checking exactly?

> Why is this needed? If there are two people by the same name, 
> what prevents them from using their name? I guess this clause becomes
> inportant in the context of certificates for Organisations and
> Institutions. But then as long as the institution produces documentary
> prrof that they are wjo they they say they are, it means that the
> govermnent body incharge of the registering the insitution was ok with
> the name - so should we bother?

Well, the topic is that the CA should/must not issue the same certificate to 
two different parties, who have the same name, so that they are 
differentiable at least with the certificates.
(Different serial numbers of the certificates)

> section 3.2.5 - Do we support ping to email address in the whois
> database? 

Yes.

> As far as I know, we do not. Even if we plan to support that 
> feature, we still neeed to decide which email address to honor.

Just try it out, login -> Domains -> Add Domain -> yourdomain.com
Then you will see the email addresses you can choose from.

> Billing as well as technical address may not be the actual owner of a
> domain. 

Well, everyone who is in the whois database, is somehow administratively 
responsible for the domain.

> Shouldnt we restrict it to the admin part of whois?  

That´s technically impossible to extract the admin part of the whois record.

> This is 
> what is stated in section 4.2.1 incidentally.

Yes, there it is also stated. "to one of the administrative email addresses 
for the domain in question"

> section 3.3 - what is "re-key requests"?

If you re-issue the same certificate with a different key, just to update the 
key. That´s necessary for commercial CA´s, where the people pay per 
certificate, and therefore needed a way to update the key without billing 
again.
http://certificate.nikhef.nl/medium/policy/cps-medium-2.2/cps-medium/node71.html

> section 4.2.3 - "less than a minute" - are we providing any kind of
> guarantee for the 1 minute? Will we get into any trouble with a hard
> number like that?

Currently we are "less than a second", and browser timeouts are "less than 30 
seconds", so I think that shouldn´t give any troubles.

> sections 4.7.x and 4.8.x - Dont we need to add atleast an "N.A." as an
> answer to these subsections?

Hmmm. I wanted to keep it shorter, but I changed it now.

> section 4.9.3 - How is a fraud report handled? What constitutes a
> fraud? How does on verify it?

Someone who notices will contact CAcert about the fraud (through the normal 
contact procedures). CAcert will have to try to verify the claim then, and 
act accordingly.

Since we had no such cases yet (as far as I know), we can´t make the policy 
more detailled here. As soon as we have handled several such cases, we might 
be able to improve the policy on it then.

> section 5.2 - Even though the "identity Verification Form" has the
> space to specify two photoID, there is *nothing* in the form that
> specifies that two IDs are a requirement for verification. I
> personally know of several people who have verified people based on
> single ID!

You need minimum 1 Photo ID, but you can also use several IDs. Since paper is 
a limited ressource, the author decided to put only two fields on it.
The Assurer has to decide himself, whether he trusts the person, or he wants 
more than the minimum evidence, and how many points he will give for it.

> section 5.2.3 "additional Assurer Test" - what is that? Any publicly
> available info on this?

No, we are still in a very early phase of that.
Some parts might be taken from the CAcert Security Handbook, some parts might 
be taken from the Security-Personnel checks, and some parts might be taken 
from the HowTos and the Wiki on the Website.

> section 6.1.5 - what about the specs of the CA's root cert? Shouldn't
> this be mentioned?

Could you send me the details?

> section 6.2 - Shouldn't we copy the details of root key protection
> procedure rather than just link?

The link is already down. I´ll try to get a copy of the text, and try to 
integrate it.

> I will go through the WebTrust policy next and see what I can contribute.

Ok, yes. Please do that! 

> Thanks for the patient hearing.

Thank you very much for your help!

Regards,
Philipp Gühring

Attachment: pgpREskDwvTRH.pgp
Description: PGP signature