Please Note that this is now a year or two out of date... However it could be reviewed and made up to date, if someone wishes. The current information can be found at Policy.

Contents

CAcert policy issues
Current Issues and Topics
Resolved Issues
1. Assurance Policy

CAcert policy issues

This is an overview of the issues raised, discussions, decisions on sematics from the CAcert-policy email list (@lists.cacert.org).

By definition this overview will not be complete, nor be correct. It is meant as an overview to enable new members to take part of the discussions. to avoid reinventions of the wheel or deja vu from other participants.

Those issues which went into policies (wip/draft) or other documents are not mentioned here.

Current Issues and Topics

forms: CAP & COAP

Inclusion of CCA mark into the CAP form (Jan 2008).
General Organisation COAP form, one page, with easy to complete fields (pdf,OOo) (Mar 2008)

Organisation Assurance (OA) sub-policy definitions

Sub-policy definition accepted for: Germany, Holland, Austria, Australia, Ireland.Organisation Assurance sub-policy proposals for:

France (Guillaume/Sam) Awaiting proposal.
USA (Greg, Fred, Rayj, gla, Ljauron) Definition group established. Awaiting proposal.
Norway (Dag) Is awaiting a second Aye from a person familiar with Norwegian situation.
England (Cornall) Based on Ireland proposal.
Pakistan (Sawant) Awaiting sub-policy proposal.
Swiss requested, awaiting sub-policy proposal.
Sub-Policy template for all EU countries: first proposals defined via template based on Holland. For EU see comments in the document source text. The renewed sub-policy needs to be accepted and will void the current proposal.
Issues:
- need to list (and define) types of organisations, or just accepted all that are officialy registered?
- European Registrar (EBR) accepts that
- Domain name check in sub policy or in main OA policy?
- Need to define register number eg 12 digits or just register number (EU may have different number schemes per organisation type as well per registrar.
- May 2008:Discriminate on registered or not?: should CAcert allow organisations who are not registered with trade registrar? Argumented is organisations who are owned solely by an individual (usually not registrated) should have a certificate on the name of the owner as they are identical (Phil, Teus).
- May 2008 issue raised aboutbusiness names(UK Business Name Act of 1985): DBA which can be every name which appears eg on letter headings, bank account name, business license (Kyle). OAP 5.d allows DBA (alternative names) as long as they can be proven, eg registration as DBA, trademark, etc. Conclusion: unregistered DBA is not accepted. Basic question is: how to file in court? (Ian).
- May 2008: proposal not to definetrade office registration number format, and definedomain name requirements(how to check it) and checking in the OA main policy.

Assurance

Start by reviewing the Assurance Policy (POLICY).

Assurance Statement

Big issue is to work out what the Assurance system and CAcert's processes over all are for.

Is it for exporting Identity Documents to the Internet (in form of certs)? No, because otherwise we would have to incorporate all details and exact details, including which sort of document, as a minimum.
Establishing the right to use a Name? Not really, because there is no one unified world-wide infrastructure that does this: As governments issue documents that conflict in names, they cannot be considered to be authorities on the name, although they may be on the person (passport) or capability (D/L). Birth certificates are a better authority on names, but not on the person...
Helping the members to use certificates? Yes. For what it's worth.
Helping the members to secure themselves? Yes. Ditto.
Establishing some claims in certificates that can be relied upon? Yes, because reliance is the conventional sense of certs. However, there is no ready experience in reliance on certs. So to some extent as long as we can establish a chain of reliance for any claim, that is workable.
Establishing a claim of Name in certificates? Yes, as long as the chain of reliance can be established. Optional otherwise?

Depending on which is chosen, there are different edge effects. For example, the logic on exporting the documents indicates that we have to choose how we put any reliance on these documents.

Big practical issue is that the Assurance Policy (POLICY) defines a Statement of Assurance which is relied upon by the CPS in the Relying Party Statement. This Statement includes sufficient of the classical claims (Name) and the needs of CAcert to establish a chain of reliance (membership) that it covers both approaches.

What is the purpose of Assurance?
- what is the purpose of the Check on Identity? Answer: customary. Align it to the needs of the other policies and R/L/O; and incorporate both in the Statement.
- What does 'assurance' mean beyond getting certain (unspecified?) details 'assured'? Answer: Assurance means meeting the Statement.
- Most of 'the statement' is true for unassured members. Yes, for most Members, the Statement will always be true; rather, our task is to measure the confidence we have in the Statement, and that is the job of Assurance Points.

Semantics of Zero Points (Individual Assurances)

Zero Assurance points; Febr 2008 (Philipp, Ian, Jens, Bernhard) 50 points is name on certificate, 100 points is code signing and Assurance prospect (pass also Challenge).

What is the Semantics of zero points in an assurance? (Febr 2008). Issues:

zero points: Assurance completed but no positive info ID quality; Assurer is unfamiliar with ID shown.
- this is the only point that was made. Hence it survives the consensus test. Every other point made was on a different question to the actual one.
- Conclusion: Resolved, with zero points meaning Assurance was ok, but Assurer has no confidence in result, for example because documents are meaningless to Assurer.

All these points were on different questions, or did not hit the mark.

is there a middle road? ID shown looks perfect less as max points?
>= 200 point status had administrative problems which forces 0 or less points. what does this mean?
there are conflicting issues:
- ID's (is this for 100% certainty?) and
- Assurer confidence, training, experienceand
- familiarity with ID shown.
less than max points can be issued:
- allow other assurers to gain experience points by experienced Assurer and
- 1 ID is less as 2 ID's.
- get experience and have an experienced Assurer also to look at it (increase strength of the Web of Trust)
assurance points should be a natural number

Ref: Assurance Points Assurance points policy; (Subject: zero points means what?); May 2008 (Philipp, Sam, Fred, (Ian, Bernhard))

Assurance Point System (Individual Assurances)

Point system is too complex (Febr 2008)
- ref: pgpinconsistent Assurance point system inconsistent with PGP/GPG; Jan 2008 (Jan, Teus, Jens, Ian, Guillaume)
Separate the assurance points from points issued for experience;
- Conclusion: agreed to separate Assurance Points from Experience Points.
- (opinions) 50 or 100 assurance points includes assured minimal 2 times (Assurance Policy)
- Points Transfer: need to change points to be transferred (experience points plus assurance points).
Suggested changes to point system (some consensus for a change):
- Expiration time certificate (opinion):
  - 50 points one year
  - 100 points two years
TTP assured individuals have too many points (150) and no experience.
- TTP points must change.
- 50 or 100 max points maximal (opinions)
- TTP and/or Super Assurer drop completely (opinion).
(quite some opinions) Assurance could be binary
- give max points or none
- variable ass. point system was historical failure.
- Certificate is binary so Assurance is binary, because Assurer gives certificate???
given assurance points depends on, see also some documents Assurance Handbook and ID checking and points proposal:
- 1 or more ID's
- expiration date ok for CAcert not for eg travel?
- picture is close enough?
- confidentiality and trust at assurance
- familiarisation with shown ID
- force to allow more experienced assurer to have also a look at ID 's
- allow other assurers to gain experience on assurer events
- increase quality and strength of Web of Trust
- motivate new comers to come in WoT (no sudden-death syndrome).
- possibility: collect points via many assurances (risk: detection of fraud)
An idea: 1. collect basic info, 2. at home verify, 3. match with mutual assurance, 4. binary decision 5. systems automatically assigns points. Opinion: too complex, over done system.
Meaning of points: 100 assurance points is very well in WoT and some experience with what assurance is about (eg 10 experience points), 50 point level community decides enough in WoT for carrying name on certificate. Above 100 points is experience points.
Abandon 100 assurance restriction?
Assurer handbook gives possibilities and do what on: uncertainty ID, total uncertainty ID, believe ID but not complete evidence, suspect an error).
Ian: have a look at Assurance Policy WiP policy proposal! Much reasoning is provided there!
what is binary? :
- certificate
- assurance
- trust
- points
- the end result (certificate, assurer, community membership, certificate attributes (code signing))
Unclear request for vote, proposal: for binary assurance: 3 Ayes, more votes? (end of (25) May 2008?) (no real votes but expressed: 3 Nayes)
Assurance Challenge is omitted in discussion. Bernhard: no complains seen about challenge.
(opinion) Too many rules already, need to be consistent first, before leave this historical decision about variable points.

Some (unresolved) issues still (Ian):

binary is assured or not. So no need for assurance points?
trust is tricky word: trust points collected is different from Assurer trust
big change, be careful. It is already hard to do small changes.
security is about risk, not about certainty
important for CAcert: how good are eg the passports (license to travel), driver license (license to drive) for CA(cert).
- the problem is that these documents are designed for one purpose but used for another
- e.g., an expired passport is a fine identity document, but maybe a poor travel document. As CAcert does not do "travel", absolute expiry is not an issue, but general age may be.
What is the full points statement?
- Answer: full confidence; defer details to Handbook.

maximum of assurance points one can get

issues:
- should there be a max? if so:
- max of 50 assurance points
- max of 35 assurance points
- implicit from the tables in the sub-policies?
several types of obtaining assurance points:
- individual assurace by CAcert Assurer (table says max 35 assurance points per full name)
- Remote Assurance via Trusted Third Party as defined in RA sub-policy
  - 50 assurance points but need at least to TTP's?
  - 35 assurance points for one TTP
  - require two TTP's within a certain period or no requirement
  - CAcert Asuurer deserts: allow an arrangement (complicated) as eg individual gets Assurer status (and passed Challenge) but need experience points within a certain period and obtain more assurance points in that time frame (inbreed).

multiple names (Individual Assurances)

accepted to have more official names on account, already decided by policy group
each name needs to be assured.
- working number is 50 points on each name before it can be used in certificate.
requires quite some implementation effort (so on hold)
many detailed issues relate:
- transliterations in a name:
  - Are transliterations (ö -> oe, é -> e) accepted?
  - Implementation: Use a Table?
- some cultures have less strict matching, some require more strict matching.
- some cultures allow titles to be added, some countries require titles to be added.
- May "middle names" be omitted?
- May names be abbreviated?
- How to handle names in other alphabets?
How closely do the name(s) in a CAcert account have to match names on ID docs?
- This relates to the Assurance Statement above. What is Assurance for?
- This will tell us how to match the names.
One approach based on current practice has been done in PolicyDrafts/PolicyOnNames,
there is the common opinion, that the name(s) has/have to be exactly as in the ID docs.
Conclusions about the name debate (Philipp Diunkel June 2008):
there is no automated way to account all possible variations in names on a clear and evaluated way
there is a wish to have alternate names in certificates (added value for CAcert certificates)
assurances should restrict to actual official name(s) (CAcert account name(s) )and BoD
a table for allowed transliterations should be possible and accepted for the CAcert account name
propose to accept SubjAltName for freely chosen and not verified by CAcert.

Provide evidence of Assurer status and/or mutual assurances (Individual Assurances)

Discussion about proof that one is an assurer and force mutual assurance (Ian, Bernhard, Sam, Teus, Philipp's, Fred ).

provide evidence of Assurer status:
- consensus: not a real proof, but show one is listed, identify oneself and provide contact info, and one is recommanded to use mutual assurance
mutual assurance:
- $/!\$ (formally named as reciprocal assurance) some thing on this line yes (consensus). Iis is recommanded (WoT quality improvement):
  - ```
  That Assurance be a mutual / reciprocal process,
      allowing the two members to assure each other,
      even if one of the members is not an Assurer.
```
- (opinion) mutual assurance should not be forced as there are practical/reality, privacy and legal issues when one is forcing this.
- (idea): allow the procedure to complete in different stages using "cookies" (no folluw up in the discussion).
- mutual assurance trains new Assurer prospects, increases WoT

General Comments on Assurance

PGP CAcert signature expires after year, CAcert certificate one year or two year.
- expire certificate after one year unless user has more experience with the certificate;
- PGP/GPG CAcert signature should expire consistent with certificate expiration date (consensus);
Assurers need more regulation (loose experience, loose information): re-challenge?
Assurer gets information about Assuree before Assurer completes on-line assurance
- potential issue for rogue Assurers in the future
- should provide some evidence/proof that Assurer is an Assurer
- identity theft is big issue, albeit external and therefore complicated
An idea: provide Assuree with Assurer certificate and use web interface
current system has history, do not change things that easy
important points:
- protect users from illegitimate/rogue Assurers
- restrict flow of info for privacy reasons
- close critical/privacy flaw by email name/dob mapping "service"
- provide simplified process for power Assurers (simplified business cards)
- introduce new users to assurance process as early as possible (e.g. training)
- point system should be simple, clear and transparent.
idea: mutual assurance (Assuree also assures Assurer).
Is the WoT (c.f. OpenPGP) point system (c.f. Thawte) an appropriate trust metric?
- Appropriate for what?
- one view: The Assurance system is appropriate for CAcert because (a) it feeds into the CCA and Arbitration, and (b) it provides a reliable name for those certs that need it. [iang]
- more nuanced view: All statements are easy to tear down, because there are no absolutes in this area. So we need a three legged stool: a statement that suits reliance, a way of measuring confidence in that reliance, and a multiple-person approach to address occasional or gross errors.
is it one identity document or two?
- Answer: defer the details to the Handbook.

Trusted Third Party (Individual) Assurance

TTP documents:

Discusions/issues:

(Jan 2008) Instructions for TTP are too weak, too many questions. Wiki is inconsistent on # ID's.
Conclusion: 2 ID's, copies sent to CAcert with TTP signature + completed TTP forms, 2 X TTP.
(Jan 2008; Jens, Teus, Brian, Philipp, Robert, Ian, Guillaume, Jeremy, Bernhard): Can military 1st Sgt be TTP? Discussion "who is allowed as TTP?" Phone check of TTP cannot be done by CAcert. Consensus: allow current definitions: notary, lawyer, bank manager,... Proposal: TTP is defined as official (registered/practiced) identity validation instance.
(Feb 2008) Limit amount of points with TTP eg to 100 (each TTP 50) Consensus: TTP should not give Assurer power eg without Assurer Challenge. Opinions: TTP assured individual should become active as Assurer and help.
(opinion): TTP is now used to fill gaps for assurances in CAcert desert land (not directly becoming assurer).

(March 2008) Proposals to change TTP procedures: One ID per TTP, no need to sent copy of ID to CAcert, max 50 points per TTP, points can be variable to decision of CAcert TTP manager. Proposal for new TTP policy (Teus, Ian, Sam) coming to Remote Assurance Policy WiP definition. Issues: * TTP is not automated work, so attach fees and/or donations to CAcert (April 2008)

different points for different quality of TTP?
150 points is too high (consensus)
Assurance Policy suggests a limit of 50 points on any assurance process (see Assurance Policy).
should TTP be 35 points, the same as any other assurer?
unclear why a TTP is considered more authoritive than our own most experienced and trained Assurers.
no copy of ID to be archived with CAcert (maybe on doubt one can request)
notion of TTP officer (local/national TTP knowledge) to survey local TTP's.
TTP needs very clear guidence: Trusted/Remote Assurance Programme (TAP/RAP)
CCA needs attention
TTP should not break WoT

$/!\$ Concluding (end of March 2008) into the draft TTP (Sam) Remote Assurance Policy proposal (few comments: Sam, Ian, Teus, Philipp, Robert). Needs more comments and review before one can call for vote.

opinion: max 35 points per TTP. And no requirement for at least two TTP's check within a limited period of time.
no need to get individuals directly on 100 assurance points for Assurers via the TTP.

Other Assurance Issues

Mass assurances like big events: quality issue. Collect too many: it does not costs anything applications.
Code Signing policy:
- drop copy of ID requirement.
- suggestion for code signer agreement/statements (Febr 2008)
Date of Birth privacy policy:
- no drop of DoB from archive (Mar 2008)
- issues on European privacy directive and local directives.
- CAcert archive resides in Europe jurisdiction.
- suggestion to allow user to decide on archiving DoB
- DoB can have nice features/add ons in the future.

Assurance email / domain checks

ref: Email and domain check policy, Dec 2007 (Ian, Teus, Jens): ref: Jan 2008: primary email address should not be checked by Assurer.March 2008 (Sam, Ian, Greg, Russ, Bernhard)

regular check of primary email address
- eg with renewal of cert?
- regular email pings?
- human checks (Assurance process) ?
Required by:
- CCA says maintain email address in good working order
- needed for arbitration
- needed to advise of major changes to agreement (e.g., CCA should be mailed to all).
- DRC (CA Requirements Certificate):
  - if control email address/domain name is lost: revoke certificate (via arbitration)
  - this one also applies to every email address / domain where a certificate is issued
Suggestions for frequent check email/domain name:
- time-based: periods of say 6 months?
- event-based: account creation, addition of domains, certificate renewal (>6 months),
- In short: "Any user action on email addresses (addition, setting of default, certificate issuance) should be securely verified, except deletions." This has consensus.
- Suggested: Assurer should have email exchange before assurance and on failure lower assurance points.
  - This has some mass event issue.
  - (influences Assurer Handbook, CATS and Point system).
  - Can complicate the Point system. how?
  - strengthens the Assurer statement on assurance.
  - No consensus.
  - With improved verification (crypto cookie) not needed?
Ideas:
- stronger check such as evaluation email eg via sending URL with crypto cookie, which forces user authentication even if session already exists (Sam).
- display last date checked,
- add verify button;
send email to CAcert user when someone used Assure someone web interface and checks email address.
- Ask DoB as well as check.

Conclusion: Consensus on this issue was not reached. As it remains a critical part of the Assurance Statement, it is left in the policy as an optional part.

Miscellaneous

time stamping service

Time Stamping service:

stopped due to security problems (Jan 2008)

cert signatures

system date is easy to set back.
What does a signature date say if that date was before the revocation date?
revocation is done in CAcert time.
are signatures revoked? Or just certificates?
- simply stating "it is" or "it isn't" will not work for digital signing
- signatures are soft metric by definition. The court says if it is good.
- known hard problem
- most of the industry has not understood the issue
CPS says digital signing is not to be relied upon, in general.
- a signing protocol is required for any reliance to be placed on signatures.

Input of more people would be greatly appreciated!

more identity evidence needed?

Philipp Dunkel raised: more evidence needed as just one (or two is not more) ID?
if photo is too old do not assure
need more evidence reflected in point system, but it should be auditable
see also [http://wiki.cacert.org/wiki/PolicyDrafts/IdChecking ID check proposal]
make sure as Assurer you only check ID's where you are familiar with: it is up to the Assurer
assurance is not a binary thing: Assurer confidence in the shown ID is not binary.
assurance points per assurance and # assurances is the measure: once reached 50 it is binary.
example of Australian ID cards, which uses a identity qualification point system.
this topic is discussed more often and does not come to a good solution.
Current policy is: the combination of assurance points per assurance and the amount of assurances with different Assurance if the factor to check an identity name with an individual (Date of birth).

Resolved Issues

These items have been debated and consensus reached (or not) on the Policy group. Kept for the record only.

Assurance Policy

DoB
- This question relates to American-style Identity Theft
- Discussion on dropping the DoB failed to find consensus on Policy.
- Board voted to accept DoB, being aware of the liabilities. m20080430.1
Is the CAP/TTP form still necessary in a connected world with digital signature laws?
- Short answer: yes.
- Longer answer: The paper form creates the foundation to permit certificates to operate with a link that backs into old world legal framework. That is, the digital is built on the paper, which makes it strong. Otherwise, what is the digital built on? [iang]
Should we split out experience points from the Assurance Points?
- Yes, consensus achieved on policy group.
Assurer to provide evidence that he is an Assurer to a member / assuree before conducting an Assurance on her.
- See 'Mutual Assurance.'
- Yes, consensus achieved on policy group.
no form of Assurance process gives more than 50 points
- Yes, consensus achieved on policy group through no controversy.
full name string
- goal of assurance of names is to be comparable at least in strength with "western" governments-issued general purpose identity documents.
- each name of the Member as written on an ID document.
- If a name is not contained in an document it is not assured.
- Certian parts in the full name do not have to be fully included in the Assured name. Eg middle names, initials, titles, etc. (details in Handbook).
- transliterations are allowed (see Handbook).
- on Common Name in certificate:
  - assured names must be exactly used in certificates.
  - or: variations are accepted in forming the certificate CN. Eg middle names, initials, titles, etc. (details in Handbook) (this one is the preference).

CategoryPolicy

Brain/PoliciesAndSignificantTechnicalStandards/PolicyDiscussionsOverview (last edited 2014-05-31 23:04:30 by BenediktHeintel)