Policy-Discussion

["Sam Johnston" <samj AT samj.net>]

Does anyone have any problems with the following two statements:

1. All certificate information is verified by the issuer
   Typically this will be CAcert but it allows us to 'fix' the OAP by issuing certificates on behalf of verified organisations who agree to comply to our prevailing policies.
   
2. Verification must occur on or before issuance and may recur at any time during the validity period
   This allows for things that are pre-verified such as historical assurances and addition of domains and emails as well as for automated recurrent checks like DNS, HTTP, etc. and finally long running, periodically verified certificates should revocation ever be 'good enough'.
   

I've tried to be as concise as possible while finding something that will keep everyone happy (including the status quo).

Sam

On Thu, Oct 16, 2008 at 9:47 AM, Sam Johnston <samj AT samj.net> wrote:

Ok so we have consensus that only verified information goes into certificates (verified automatically or verified via assurance). That's good. It's clear and easily understood.

I liked where we were going with the automated verification stuff... in that we MUST verify at issuance and MAY verify at any time during the validity period. Maurice wanted us to apply this to humans too but they are far less tolerant than computers who don't mind being asked the same question over and over again. Philipp's proposal addresses this but throws the baby out with the bathwater on the grounds that revocation is broken so there's no point doing follow up checks. I think we should keep the door open with something like the MUST and MAY wording above - at least then we can add it later without having to rewrite this policy.

Putting the Org Assurance Officer hat on for a second, we've just blown the program out of the water. That's OK because it was broken, but we don't want to bite the early adopters too hard. Emails are always verified so they can be included and org info is verified too so it can go in, but to get names in their certs they will need to use the standard assurance program for now (eg org admins or other assurers verify IDs and apply 50 points). The reality is that organisations need to be able to put names in certs en masse, and there isn't really any decent options short of running your own CA and paying 6 figures for a CA cert. Again I think we should leave the door open with something like the 'verified by issuer' wording previously discussed.

Sam

On Thu, Oct 16, 2008 at 5:56 AM, Lambert Hofstra <lamberthofstra AT gmail.com> wrote:

--------------------------------------------------
From: "Philipp Dunkel" <p.dunkel AT cacert.org>
Sent: Wednesday, October 15, 2008 5:09 PM
To: "Policy-Discussion" <cacert-policy AT lists.cacert.org>
Subject: Re: [CAcert-Policy] CPS bugs. Vote please. Colosing date of votes21
October 12pm UTC

> Ok,
> Let's just take it one step at a time. Point one is that only verified
> information goes into certificates. That means that any information in
> a certificate has either been verified by assurance or verified via
> automatic evaluation.
> On that we seem to have a consensus. I counted ayes from Teus on this
> point as it is essentially the first part of his proposal. My own as
> this was my proposal. From Sam as in this mail. And from Ian via
> direct conversation. I also counted 1 neither nor from Maurice. I have
> counted no Nays so far. So I would say that there is a rough consensus
> on that only verified information goes into certs.

I vote yes

>
> That leaves open the question of of when and how we check info. I am
> eagerly awaiting feedback from everyone on that part of the proposal.
> At sam's statement of reserving the right to check at other times as
> well. We reserve the right to change policy at any time. So we also
> reserve the right to alter our policy to check more frequently. This
> is really about us making a statement of what our minimum standards
> are and what claims we make for or certificates. So I see no policy or
> application thereof as eternally fixed ever. After all we are writing
> a CPS and not the 10 commandments ;)
>

In my opinion it would be OK if we state that information has been checked
(=verified or assured) before issuing : I would vote yes on that.
(IMHO we can check more often, but no need since we only state we check at
date/time of issuance: if something changes and one of the member finds out
she/he can file a dispute and the cert could be revoked)

> Eagerly awaiting your feedback,
> Philipp
>
> ---
> Philipp Dunkel
> Tel: +43-720-407204
> Fax: +43-1-3060903-9
> ---
> Your reality and mine may not entirely coincide. Therefore you may not
> rely on this message meaning what you believe it means.
> ---
>

Lambert

> On Oct 15, 2008, at 15:54, samj AT samj.net wrote:
>
>> 100% agreed. Nice point re: revocation, so let's stop talking about
>> interfering with our users every 5 minutes.
>>
>> I would just add 'CAcert reserves the right to re-verify at any time'
>> so as to leave the door open for repetitive DNS checks et al.
>>
>> Sam on iPhone
>>
>> On 10/15/08, Philipp Dunkel <p.dunkel AT cacert.org> wrote:
>>> Hi,
>>> I have to agree with Sam here.
>>> However I want to suggest an alternative that might be a good
>>> compromise:
>>>
>>> 1. All information that goes into a Cert has to be verified.
>>>  that means either assured or verified via automatic means.
>>> 2. The verification takes place at the time of certificate issuance
>>> only, but at every issuance.
>>> 3. We state in the CPS that the information was verified at time of
>>> issue only and that no later checking need have taken place.
>>>
>>> This is a very clear policy of what happens and is easy to understand
>>> and defend.
>>> The following info is assured Individual-CN, O, OU, L
>>> Verified by automatic means are domains and email addresses. Email
>>> via
>>> reply within 24h.
>>> Domains via Whois or DNS token or alternatively via HTTP file place
>>> in
>>> the root or robots.txt
>>> In any case the verification is done every time a certificate is
>>> requested and at that time only.
>>>
>>> As Ian is so fond of saying anything is fine as long as we clearly
>>> state it. Because this is so simple and can be clearly states I think
>>> this may be the route to go. In addition to being easy, it has one
>>> more clear benefit. CRLs are currently often ignored or badly
>>> handled.
>>> That means that revocation is really broken in x509. If we state that
>>> we only check information claim its validity for the time of issue
>>> revocation becomes optional.
>>> Although this opens the doors to such things as buying a domain, then
>>> getting certs and selling the domain the next day, I truely think
>>> this
>>> is acceptable. CAcert is not able to be everything to everyone. At
>>> least this way we clearly state what we are not: a fascist
>>> organisation that keeps permanent tabs on everyone it ever came in
>>> contact with.
>>>
>>> Regards, Philipp
>>>
>>> ---
>>> Philipp Dunkel
>>> Tel: +43-720-407204
>>> Fax: +43-1-3060903-9
>>> ---
>>> Your reality and mine may not entirely coincide. Therefore you may
>>> not
>>> rely on this message meaning what you believe it means.
>>> ---
>>>
>>> On Oct 15, 2008, at 9:17, samj AT samj.net wrote:
>>>
>>>> Sounds [over]complicated:
>>>>
>>>> The 'verified by issuer' wording at least allows us to fix OA given
>>>> all the options currently break it, and appears to have consensus
>>>> already.
>>>>
>>>> 'Verified' is the appropriate term-no need to confuse by inventing a
>>>> new one. It could even replace 'Assured' which has 'insurance'
>>>> connotations.
>>>>
>>>> Automated verification is either good enough or it's not. Variable
>>>> durations are complexity which is the enemy of security.
>>>>
>>>> Where there is an automated option there is no need to slip in
>>>> manual
>>>> 'back doors'.
>>>>
>>>> Sam on iPhone
>>>>
>>>>
>>>>
>>>>
>>>> On 10/15/08, Teus Hagen <teus AT theunis.org> wrote:
>>>>> The CAcert blog: http://blog.cacert.org/2008/09/328.html gives an
>>>>> overview of the issues with the current work-in progress CPS found
>>>>> here: http://svn.cacert.org/CAcert/policy.htm .
>>>>>
>>>>> This Policy email list has an extensive amount of feedback, new
>>>>> issues, opinions, thoughts on these two topics.  On some of these
>>>>> debates, the details go deep, and some times too deep.
>>>>>
>>>>> The following will not be a 100% solution, and I do not believe
>>>>> that
>>>>> we can create a 100% solution, a compromise will be necessary. If
>>>>> needed a "dispute" can be filed:-(
>>>>> *
>>>>> Executive summary* of this proposal to solve the two remaining
>>>>> issues for
>>>>> CPS:
>>>>> The only information that appears in the issued CAcert certificate
>>>>> is:
>>>>>
>>>>>  * Assured information, as per Assurance Programme
>>>>>  * Evaluated information, as per CAcert Certificate Policy
>>>>> Statement
>>>>> (CPS)
>>>>>  * Technical details, as per CPS
>>>>>     + CAcert (e.g., serial number and sig)
>>>>>     + user (public key and hash)
>>>>>
>>>>> That is, either there are no "discretionary fields" like the
>>>>> current
>>>>> CN thing, or, there *are* discretionary fields, in which case
>>>>> CAcert
>>>>> needs some form of policy for these.
>>>>>
>>>>> *You are invited to Aye or Naye this proposal from the executive
>>>>> summary.
>>>>> If you want more discrimination in your vote please vote Aye or
>>>>> Naye
>>>>> per issue as stated below:*
>>>>>
>>>>>
>>>>> For the CPS there are two issues to be resolved:
>>>>>
>>>>> *1. Information such as Names* in the individual and organisation
>>>>> certificates.  This type of information is currently /assured/ via
>>>>> CAcert (Organisation) Assurers.  Let's call that *Assured
>>>>> Information*.
>>>>>
>>>>> Can we accept that only this Assured Information will appear in the
>>>>> individual and organisation certificate information fields, e.g.,:
>>>>>
>>>>> CN (common name),
>>>>> O (organisation name),
>>>>> OU (organisation unit name),
>>>>> L (location)
>>>>>
>>>>> (If a Member has more than one assured name he/she/it can select
>>>>> one
>>>>> from the (assured) list.)
>>>>> Conclusion: Assured Information will appear in the information
>>>>> fields of the
>>>>> issued certificate.
>>>>>
>>>>> *2. Some technical information* that appears (email address(es),
>>>>> domain
>>>>> name(s))
>>>>> is not assured but only /evaluated or verified/.  Let's call that
>>>>> *Evaluated Information*.
>>>>>
>>>>> Arguments on the policy list were raised to check the Evaluated
>>>>> Information periodically and/or minimally when the certificate
>>>>> is renewed.
>>>>> The quality of the evaluation tools differ.
>>>>>
>>>>> The conclusion is that the following measures are needed: we should
>>>>> have an ordered list of the tools of evaluation, put a weight on
>>>>> each tool, for each of email address and domain name.
>>>>>
>>>>> Tools suggested are (ordered list):
>>>>>
>>>>> Domain Name(s):
>>>>>  D1. DNS - add a cookie in the dns records.
>>>>>      -> 2 year (OR 1 yr+ 3 mnths for each D1-4)
>>>>>  D2. WHOIS - add a cookie in the registry records.
>>>>>      -> 2 year (OR 1 yr+ 3 mnths for each D1-4)
>>>>>  D3. HTTP - add a header, or HTML snippet or file.
>>>>>      -> 2 year (OR 1 yr+ 3 mnths for each D1-4)
>>>>>  D4. Statement of ownership/control of at least two Assurers.
>>>>>      -> 2 year (OR 1 yr+ 3 mnths for each D1-4)
>>>>>  D5. WHOIS info corresponds with assured information
>>>>>      -> 1 year
>>>>>  D6. RESPONSE within 24 hours to one
>>>>>     of the predefined list of email addresses
>>>>>     in that Domain Name.
>>>>>      -> 1 year
>>>>>  D7. Statement of the (assured) owner.???
>>>>>      -> 1 month
>>>>> Max expiration time: 2 year.
>>>>>
>>>>> Email Address(es):
>>>>>  E1. RESPONSE within 24 hours
>>>>>      -> 2 years
>>>>> Max expiration time: 2 years.
>>>>>
>>>>> Idea on weight: the expiration date of the certificate is dependent
>>>>> on quality of the tool used?
>>>>> The scheme provides some automatic push on getting high assurance
>>>>> for the
>>>>> Member and higher evaluation for the certificate.
>>>>>
>>>>> The expiration date value with the tool used will be defined as
>>>>> operational issue (so is not in the CPS policy):
>>>>>
>>>>> Evaluated Information (Email Address / Domain Name) will be
>>>>> rechecked
>>>>> whenever CAcert decides to do so, as an operational decision, and
>>>>> at
>>>>> the minimum with every renewal of the certificate.
>>>>> Failure of an evaluation check will initiate a dispute on
>>>>> the Domain Name and/or Email Address.
>>>>>
>>>>> Disputes can be filed with the CAcert Arbitrator when information
>>>>> (evaluated or assured) is found to be incorrect by any CAcert
>>>>> Member.
>>>>>
>>>>> ------------------------------------------
>>>>>
>>>>> _______________________________________________
>>>>> Have you passed the Assurer Challenge yet?
>>>>> http://wiki.cacert.org/wiki/AssurerChallenge
>>>>>
>>>>> CAcert-Policy mailing list
>>>>> CAcert-Policy AT lists.cacert.org
>>>>> https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy
>>>>>
>>>> _______________________________________________
>>>> Have you passed the Assurer Challenge yet?
>>>> http://wiki.cacert.org/wiki/AssurerChallenge
>>>>
>>>> CAcert-Policy mailing list
>>>> CAcert-Policy AT lists.cacert.org
>>>> https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy
>>> _______________________________________________
>>> Have you passed the Assurer Challenge yet?
>>> http://wiki.cacert.org/wiki/AssurerChallenge
>>>
>>> CAcert-Policy mailing list
>>> CAcert-Policy AT lists.cacert.org
>>> https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy
>>>
>> _______________________________________________
>> Have you passed the Assurer Challenge yet?
>> http://wiki.cacert.org/wiki/AssurerChallenge
>>
>> CAcert-Policy mailing list
>> CAcert-Policy AT lists.cacert.org
>> https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy
>
> _______________________________________________
> Have you passed the Assurer Challenge yet?
> http://wiki.cacert.org/wiki/AssurerChallenge
>
> CAcert-Policy mailing list
> CAcert-Policy AT lists.cacert.org
> https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy

_______________________________________________
Have you passed the Assurer Challenge yet?
http://wiki.cacert.org/wiki/AssurerChallenge

CAcert-Policy mailing list
CAcert-Policy AT lists.cacert.org
https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy