Policy-Discussion

[maurice Kellenaers <maurice AT gkbikes.com>]

Sam Johnston 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.
I agree to leave the door open. If we use the must and may, we can look 
at it at a later point without rewriting.
> 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 <mailto:lamberthofstra AT gmail.com>> wrote:
>
>
>
>     --------------------------------------------------
>     From: "Philipp Dunkel" 
> <p.dunkel AT cacert.org
>     
> <mailto:p.dunkel AT cacert.org>>
>     Sent: Wednesday, October 15, 2008 5:09 PM
>     To: "Policy-Discussion" 
> <cacert-policy AT lists.cacert.org
>     
> <mailto: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
>  
> <mailto: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
>     
> <mailto: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
>  
> <mailto: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
>     
> <mailto: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
>     
> <mailto: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
>     
> <mailto: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
>     
> <mailto: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
>     
> <mailto: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
>     
> <mailto: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
>  
> <mailto: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
>

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