To Brain CAcert Inc. - CAcert.org Members Association - To Brain CAcert Inc. Committee Meeting Agendas & Minutes - last meeting - next meeting

Committee Meeting 2010-03-21 21:00

The meeting will take place at 21:00 UTC in the IRC channel #board-meeting on the CAcert IRC network.

Feel free to add a business within the acceptance period or your question to the board below.

Agenda

Preliminaries

Chair opens the Committee Meeting
1. Apologies: Iang may not have net, so may not be able to attend. Will know more by Thursday, if no contact seen, no net.
Who is making minutes?
Accept the Minutes of the last Committee Meeting
Progress on agreed ACTION items to be filled out before meeting
1. ACTION items
2. Outstanding From 2010-02-02

Action	Who	Progress
write up Oophanga letter response for President Lambert's signature	Mark	Completed and sent
contribute to discussion on Board/Community goals on board email list	ALL	Ian Daniel Not complete - reiterated in 20100221 meeting
Get automatic sending bit on the key persons list that I said I'd do ages ago.	Dan	waiting on Nick to deliver list
Pay Ian (old audit debt related) and Oophanga	Mark	Paid - received(?) - Oophaga received first payment
Westpac to change to a single signatory to sign payments in accordance with AGM rule change.	Mark	on hold, practically status quo tho
revisit more signatories once current mess is sorted out	Mark	on hold
lodge finance papers with Office of Fair Trading	Mark	sent
deliver firmly worded letter to former public officer	Mark	sent
Write up AGM minutes	Ian
AGM rule changes to Office of Fair Trading	Mark	sent
Association rules on svn and wiki	Unallocated	svn done(daniel) wiki is still do be done

Outstanding From 2010-02-21

Action	Who	Progress
Provide progress on financial lodgement and other post AGM Public Officer duties	Mark
news on payments, payment facilities, signatories, bank statements	Mark	N/A?
write up heading of board-private-list from last meeting 20100221 to the prior one	Mario	done
Find out from US bankers whats required to open an account	Nick
Prepare summary of payment options / investigation for association	Lambert
Propose Walter (??) as Events Officer as out of band motion	Ian
Triage personnel not covered by ABC - revisit on policy list	Ian
Keypersons list, finish the excel spreadsheet and emailing it out	Nick
letter to Oophanga to include access team transfer	Mark	draft by Dan
discuss team leadership with access team	Ian
Contribute towards root escrow / recover discussion	ALL	Done(Daniel)
Comment and report on the key escrow proposals by a week after Daniel writes them up	ALL	Done(Daniel)
Comment and discuss COI procedures	ALL	Ian

Outstanding From 2010-03-06

Action	Who	Progress
Ask Mark about his outstanding items	Daniel	phoned - left message - Oophaga letter came out
Board/Community Goals - get an overview	unallocated
Board/Community Goals - come up with one or two items to look at and then to decide a priority and a timeline	ALL
Board/Community Goals - 6-12 month position statement	ALL
Status report of current projects	Ernie/community	OverviewProjectsBoard
Status report of current officers	Ernie
OTRS updated	Support TL
Root Escrow/Recover - ask questions needed to evaluate methods	ALL
Install Meetbot for next IRC meeting	Nick
Email list (members) about US banking options	Nick

Businesses Important Note: Acceptance of Businesses 48 Hours before beginning of Committee Meeting latest!
1. Determine Root escrow and recovery mechanism - added by Daniel Black
  - Criteria
  - Proposals
  - Archives/Discussion
  - Outcome is to decide a mechanism. Previous meeting action items required a review of proposals.
2. Question Time Important Note: Questions from CAcert.org Community Members can be added until beginning of Committee Meeting! As well questions can be asked at "Question Time", without added Question here
Closing
1. Confirm the next committee meeting: 2010-04-03 22:00 UTC.
2. Chair closes the committee meeting

Minutes

Preliminaries
1. Chair opens the Committee Meeting
  1. Present: Lambert, Daniel, Mark, Ernie, Mario
  2. Apologies: Iang was not able to attend
  3. Absent: Nick
2. Daniel taking minutes
3. Accept the Minutes of the last Committee Meeting - done
4. Progress on agreed ACTION items to be filled out before meeting
  1. ACTION items
  2. Comment that action items be separated from agenda. - Agreed
  3. Oophaga payment received by them. Second payment sent EUR1626.61/AUD2303.27 (dueing meeting)
Businesses
1. Determine Root escrow and recovery mechanism - added by Daniel Black
  - Criteria
  - Proposals
  - Archives/Discussion
  - Who has read proposals?
    - Ernie admits to reading proposals.
    - Mark - I only glossed over them
    - Lambert - I might have missed some
  - General comment - has thought been given to how good an idea it is to store the escrowed roots in NL, as opposed to somewhere where the legal entity has easier legal control, like AU? (mark)
  - "is the solution secure enough?", the second is "what will we do if "secure enough" turns out to be "not secure enough" (mark)
  - Lack of development of most proposals meant only Multi-member escrow was discussed
    - Dan explains multi member escrow for those that didn't read it. Approximately 10 key holders and 50 key guardians is suggested.
    - Mark:
      - great plan from a novel high security escrow
      - brilliant from protection against compromise
        contradictions:
        implied legal enforcement of banks/solicitors/attorneys is better 21:31:46
        strong dual encryption - isn't strong enough 21:37:50
      - too high a risk of failure in terms of recovery in a timely manner - low ability to recover parts in timely manner
        if you reduce the 50+ holders, you start to seriously impact on recover-ability in an emergency, because getting three random people to come to the party quickly will be difficult (and we need quickly, because we potentially need to sign revokations)
        correction recover is 1 of 10 key holders and then one of a different 50 key guardians (or 2 in dual encryption variant (dan)
        dan explained there are no parts - only keyholder and coordinator need to be collocated
        have no effective recourse against those people to compel quick action
      - Community control may not meet audit requirement C.3.d
        Needs to be association member control (Mario)
        Need a new association of keyholders/guardians (Mark)
        Why not use attorneys, banks, solicitors ? (isn't this simpler)
        against audit criteria C.3.d - cacert control (dan)
        cost (dan and lambert)
        Why use attorneys, banks, solicitors?
        legally enforceable and protected place to store our key
        disclosed it improperly, they have insurance that could be sued against to recover costs (ernie has never heard of a successful claim)
        lot to loose (his job, his reputation, claims, also from others)
        higher claims can be made against the compared to our assurers (1000 EUO)
        increase member liability? (dan) - no (lambert)
    - Lambert:
      - no way to even discover a compromise
      - Having 10 holders and 50 guardians simply seem too much on availability, but not enough on confidentiality
      - what I've seen so far was a split of the root/master key over at least three people, where no-one had the complete key and that was just for master keys of a HSM. I assume the root key of a CA is better protected
        HSM not suitable for long term storage (Ernie)
        This isn't a proposal - you've had a month to write one (Dan)
        Dual control or three control is achieved using encryption
        I don't necessary agree on the encryption offering full protection (Lambert)
        Encryption of pgp and x509 have provided confidentially encryption reliability for the last 10+ years. there have been implementation flaws. the offline status protects the keys from attack (except from the keyholder). they dual encryption option would be very hard to have a compromise due to two flaws acting in just the right way (Dan).
        I think the board needs to be in control of the root key and password - community control in this may fail criteria around board control
        it might even be better not to have the board involved, since it seems to change every year
    - Alternative: second copy of the root key on a second backup signing (alternate option to be competed this week by Mark)
      - z.4 The Board must be able to recover the root independently of the critical team (fails?)
      - Discussion as to what is "offline"
2. Question Time Important Note: Questions from CAcert.org Community Members can be added until beginning of Committee Meeting! As well questions can be asked at "Question Time", without added Question here
3. What are we doing with the second Oophaga letter added by Daniel
  - Current intent is to use original draft and Wytze reworded paragraph
  - Mario to raise content informally
  - Lambert to review draft by Tuesday
  - Ernie accepts draft so far.
  - Tell Oophaga about OverviewProjectsBoard page - goal search for volunteers
  - Need to contact Oophaga more regularly
4. What about this post? added by Ulrich
  - No conclusion reached, deferred.
Closing
1. next committee meeting: 2010-04-03 22:00 UTC.
2. Chair closes the committee meeting at 2255

Action Items

Action	Who	time reference
Create dual signing server escrow method	Mark	this week
Create motion for deciding on a escrow method	Daniel	This week
Review escrow methods and decide	ALL	Within Week
Review second Oophaga letter	Lambert and Nick	Tuesday
Informal contact via email with Oophaga	Mario
Informal talks with Oophaga	Lambert

Synopsis

Move Action Items out of agenda due to confusion
Inquisition of Multi Member escrow proposal
- Mark - second backup signing alternative?
- Mario - DR not good enough
- Lambert - double encryption not good enough
- 10 key holder 50 guardian split too high
- deferred to mail list
Oophanga - Mario to contact informally, continue with formal letter soon
Policy Officer - not decided - few informal thought described

Motions

m20100403.#: Motions from the meeting

Meeting Transcript

(log in GMT+11)
[07:59:56] <Q> Ok, 21.00 UTC, The meeting is opened, wlcome everyone
[08:00:19] Nik_mobil [Nik_mobil@dslb-084-062-252-232.pools.arcor-ip.net] has joined #board-meeting
[08:00:49] <Q> So far I have Dan, Ernie, Mario, Mark, Nick (I guess :-), and myself
[08:00:59] <Q> Seems Ian has no connectivity
[08:01:26] <Q> I'd like a volunteer for the minutes, please?
[08:02:46] <Q> Ernie, can I ask you to do minutes?
[08:03:07] <ernie> not this time, we have two events next time, and still have to work on prject-list
[08:03:15] <Q> Mark?
[08:03:27] <markl> I would volunteer, but I am not in a position to do it in a timely fashion at the moment.
[08:03:53] <dan> i'll actually probably have time this week - don't mind too much
[08:04:06] <Q> Ok, many thanks
[08:04:17] Nik_mobil [Nik_mobil@dslb-084-062-252-232.pools.arcor-ip.net] has quit IRC: 
[08:04:41] <Q> Ok, first, accept minutes of last meeting
[08:05:09] <Q> Any comments on the minutes?
[08:05:38] <dan> nope
[08:05:43] <Q> I move we accept the minutes
[08:05:51] <dan> to comments - i do accept previous minute s- aye
[08:05:58] <ernie> for me ok
[08:06:04] <markl> I'll second, and abstain, being that I wasn't there
[08:06:11] <Q> aye
[08:06:14] <ernie> aye
[08:06:26] <Q> law?
[08:07:47] <Q> Hmm, no response, but since he made them I assume he either votes aye or abstain. So I declare it carried
[08:08:22] dan notes this could be created as a motion before the meeting too
[08:08:31] <Q> Question to the group: last time we went through all the actions, and that took a lot of time
[08:08:53] <Q> We were all asked to add notes before hand.
[08:09:08] <Q> So we can also go through them asking if there is anything to add
[08:09:21] <Q> Suggestions?
[08:09:26] <markl> These are like a poor man's agenda items.. I think that anything that needs to be addressed by the meeting should generally be an agenda item?
[08:09:41] <dan> agree
[08:09:59] <markl> With perhaps the exception that if someone has an action item they would like to bring up, they can do so, but we shouldn't need to approach each one individually otherwise.
[08:09:59] <Q> so your suggestion is...
[08:10:02] <ernie> for me too
[08:10:16] <Q> ok, I like that approach
[08:11:14] <markl> I think they should be on a separate page, or at least separated from the agenda, because these are decided matters, they're just the action for them.
[08:11:19] <Q> Let's each mention if they have something to add
[08:11:34] <markl> Something's not done, or not to your liking, or not quick enough, then add that fact as an agenda item.
[08:11:34] <Q> Dan, you have anything on the actions?
[08:12:24] <dan> i don't care how they are stored
[08:12:42] <dan> can do a separate page if listing them here is confusing
[08:13:06] <Q> dan: any action that you want to comment on? Otherwise I'll go to the next person
[08:13:21] <dan> no comments
[08:13:27] <dan> thanks mark for the updates :-)
[08:13:29] <Q> Ernie, you have comments?
[08:13:59] <ernie> only question regarding payments, both invoices to oophaga paid, because robert confirmed payment for one
[08:14:12] <markl> no, only one.. until robert confirmed it was received
[08:14:18] <markl> I will send the other one today if he has confirmed
[08:14:31] <Q> Yes, was confirmed
[08:14:45] <ernie> yes one he confirmed
[08:14:48] <Q> Ok, Law?
[08:15:08] <Q> (was not here)
[08:15:09] <Q> Mark?
[08:16:02] <markl> not me
[08:16:13] <Q> Ok, then I guess myself.
[08:16:50] <Q> Have looked into the payment overview, sent you an update, might get more info next week. Once we have a clear overview I'll add it to the agenda
[08:16:55] <Q> Nothing else
[08:17:15] <markl> second oophaga payment is now sent too
[08:17:25] <markl> for EUR1626.61/AUD2303.27
[08:17:39] <Q> Since Nick is not yet here I would like to continue with point 2.1
[08:17:45] <Q> Dan, you have the floor
[08:18:00] <dan> have people read the proposals?
[08:18:18] <ernie> yes I read
[08:18:29] <Q> I've been trying to catch up, but have been really busy, so I might have missed some
[08:18:47] <dan> is there enough info to decide?
[08:20:05] <dan> i'm happy with my multimember escrow as probably infered and I don't think any others have the level of detail required
[08:20:06] <markl> I only glossed over them, but I had a question.. has thought been given to how good an idea it is to store the escrowed roots in NL, as opposed to somewhere where the legal entity has easier legal control, like AU?
[08:21:11] <dan> the level of control always conflicts with the availablity
[08:21:13] <markl> How does the multi-member escrow deliver us emergency access in the event of a complete failure?
[08:21:46] <dan> the root key is stored with a number of keyholder around the world.
[08:22:22] <dan> though agreement we nominate a coordinatore in the vicinity to the keyholder to organise an escrow 
[08:23:01] <dan> i'm relying on the trust of keyholder and coordinators to do the right thing when the time comes
[08:23:45] <markl> I think it's a great plan from a novel high security escrow point of view, but I think it has too high a risk of failure if we ever needed to call upon it.  I think it fails from a disaster recovery point of view.
[08:24:18] <dan> failure meaning compromise? what would be the likelist senario here?
[08:24:30] <markl> no, I think that from that point of view it's brilliant
[08:24:43] <markl> failure meaning our ability to recover the root in a timely manner in the event of a disaster
[08:25:13] <dan> what do you see as the likely failure?
[08:25:33] <markl> the ability to collect the parts back in a timely fashion
[08:26:07] <dan> its not split - each key holder has a complete key encrypted separately multiple times
[08:26:41] <dan> the number of key guardians is fairly unlimited and they don't need to be colocated
[08:27:02] <markl> but doesn't that just make it a different "part"?
[08:27:23] <Q> Dan, do you have an overview of these proposals, what they're good at, where the might fail
[08:27:30] <Q> to compare them
[08:27:44] <Q> and see if all elements have been taken into account in the comparison
[08:27:52] <dan> most are miising sufficent detail to assess properly
[08:27:58] <Q> for instance the issue Mark brings up: recovery
[08:28:12] <Q> Yes, I noticed they miss detail
[08:29:45] <dan> markl: i'm envisaging ~10 key holders and 50+ key guardians. for a recover we just need one of each. I expect that every year we can just do a quick check to make sure media is safe and uncorrupted and the key guardians still have their keys in working order
[08:30:30] <markl> so, it takes the coordinator, one each of the key holder and the key guardian acting in unison (or having their keys disclosed) to recover the root, right?
[08:30:40] <dan> key holder as ernie suggested is probably good in organisatinally assured places
[08:30:57] <dan> right
[08:31:16] <markl> how does that improve upon the much simpler situation of using notaries?
[08:31:25] <markl> or attorneys
[08:31:46] <markl> where both have the distinct advantage of having easily enforceable legal obligations to us
[08:32:09] <dan> the audit criteria round possession being with cacert personell
[08:32:35] <Q> dan, just trying to understand: does this mean each key holder has a complete root key, and all he needs is to influence a guardian to get to our Root key?
[08:32:49] <ernie> and there are organizations existing, the have safe or other secure spare
[08:33:08] <ernie> because they are already storing "sensible" datas
[08:33:27] <dan> Q: yes - but we don't need to tell them who eachother is :-) carefull selection of keyholders is required
[08:33:50] <markl> C.3.d
[08:33:50] <markl>  is the criteria, right?
[08:34:08] <dan> as ernie said we can make sure the keyholder have a strong interest in protection as well
[08:34:31] <dan> markl: right
[08:34:53] <Q> dan: I'm not sure, doesn't seem right to me
[08:35:25] <markl> Hmm, I suspect there's some wiggle room in there, as to what constitutes an outside party.  Is an attorney who is acting as our agent an "outside party"
[08:35:32] <Q> especially since we would have many holders and guardians, we would have no way to even discover a compromise
[08:35:46] <dan> i don't see what atorney's gain us
[08:36:12] <markl> dan: a legally enforceable and protected place to store our key?
[08:36:13] <dan> Q: there's another page on discovering compromise
[08:36:28] <markl> if an attorney disclosed it improperly, they have insurance that could be sued against to recover costs
[08:36:56] <Q> Well, an attorny has a lot to loose (his job, his reputation, claims, also from others) where we can only sue for up to 1000 euro if we use our own members
[08:37:19] <ernie> I think, keyholders should not be involved in our ongoing work
[08:37:20] <markl> the other, much simpler option which would address the DRC at least is to simply have a second copy of the root key on a second backup signing server
[08:37:25] <dan> the strong dual encryption means that a loss isn't that much in terms of confidentaility. the multi members means that there is redundancy
[08:37:50] <markl> it's not strong though, it's three members who we limit to EUR1000 damages
[08:38:14] <dan> there is no damage in a loss- financial or otherwise
[08:38:14] <markl> that's not sufficient stick to stop someone doing something with a root that may one day be "worth" several hundred multiples of that damages cap
[08:38:28] <markl> loss is not just "oops, lost it", it's disclosure too
[08:38:47] <markl> but there is cost in "oops, lost it", too, because new roots would need to be issued
[08:39:04] <ernie> markl, regarding assurance from attornies - till now I have never seen, that the insurance have paid after a failure (indescrition)
[08:39:25] <law> Hi. I am here now but do not have a backlog - something weird happend to my IRC.
[08:39:51] <markl> ernie: you're in the wrong country :)
[08:40:06] <markl> I need to step away for about 5 minutes.
[08:40:11] <Q> there is always a trade-off between availability/redundancy and confidentiality. Having 10 holders and 50 guardians simply seem too much on availability, but not enough on confidentiality
[08:40:13] <ernie> markl, mhh, have seen in three countries, one time in the anglo-room
[08:40:24] <dan> Q: so make it lessw
[08:40:36] <dan> what do you see as viable?
[08:40:50] <markl> why not just store the key on two separate signing servers, and not escrow it?
[08:40:59] <markl> it would satisfy all of the criteria
[08:41:09] <Q> Well, that's the problem, the other proposals are not good enough either
[08:41:27] <ernie> markl, and where is the second one placed?
[08:41:31] <dan> ian put in z4
[08:41:47] <markl> next to the first one would still satisfy the criteria
[08:42:24] <Q> all: I see an issue here, this is a crucial decision, we only have part of the board present, and we don't all seem to agree
[08:42:39] <Q> on the other hand we need to make a decision, cannot drag this on
[08:42:45] <Q> for ever
[08:43:23] <markl> brb
[08:43:56] <Q> I'm sorry I appearantly have not spent enough time on this, but so far I'm not yet happy with the current proposal
[08:43:56] <dan> markl: i understatn you have some concerns - i'm happy to address these. want to phone/email these later
[08:44:03] <law> can anyone read me?
[08:44:05] <dan> you too Q
[08:44:09] <Q> hi Law
[08:44:10] <Q> yes
[08:44:25] <Q> can send you the log in an email?
[08:45:08] <Q> sent
[08:45:09] <law> I will see if it is on my server, but had nothing in here from today... really weird
[08:45:12] <law> thx
[08:45:17] <dan> Q: is you're main concent that the people we entrust to the storage are going to do bad things?
[08:45:24] <Q> yes
[08:45:47] <dan> law:  do you have any thoughts objectsion on http://wiki.cacert.org/Roots/EscrowAndRecovery/MultiMemberEscrow
[08:46:42] <dan> Q: is entrusting them to the right people going to help? is keeping the indenties of the keyholder/key guardians secret from each other going to help?
[08:47:05] <law> hmm... the proposal does look not very reliable regarding DR
[08:47:06] dirk_g1 [dirk_g1@89.244.110.142] has quit IRC: Remote host closed the connection
[08:47:15] <dan> details please!
[08:47:30] <Q> dan: what I've seen so far was a split of the root/master key over at least three people, where no-one had the complete key
[08:48:09] <Q> dan: and that was just for master keys of a HSM. I assume the root key of a PKI is better protected
[08:48:22] <Q> PKI=CA
[08:48:23] <dan> Q: in the variants there is a dual encryption proposal that effectively places three person control - is this varient acceptable
[08:49:33] <dan> noone does have complete control in this off the key in even the basic proposal
[08:49:43] <dan> (in terms of confidentiality)
[08:49:45] <ernie> if we are speaking for longterm storage, I'm not sure it will really work 
[08:50:32] <ernie> if you need three people to bring together
[08:50:43] <Q> dan: what's "normal" is splitting a key in three or more components, so that you *must* have acceess to all components in order to recover. With the key available under encryption (albeit encrypted twice or more) one would need only one encrypted root, and break the encryption
[08:51:03] <dan> you've had a month to write a propsal like that
[08:51:26] <Q> dan: yes, I know
[08:51:42] <dan> i don't care whats normal or not - I only care of the effectiveness of meeting the criteria
[08:52:16] <law> I think the board needs to be in control of the root key and password. So in this proposal, the board is dependent on community members. Depending on the auditor this might by a fail criteria.
[08:52:34] <dan> in the dual encrytion variant you need the keyholders' key and two key guardians to gain control
[08:52:53] <Q> dan: I'm not saying normal is better, but in this case normal means has been tested and in use
[08:53:07] <Q> dan: yes, unless one can break the encryption
[08:53:19] <dan> as far as testing i think we should test it withing the first year
[08:53:51] <dan> law: if you have objections raise them
[08:54:37] <ernie> I think the board is responsible to find a secure way, but it must not have the controll (means people from the baord)
[08:54:43] <dan> law: the auditor could fail any proposal for  any reason. getting them reviewed and tested is as good as we can do
[08:55:22] <dan> my aversion to speciing the board is it changes too often and the movement creates availability risks
[08:55:22] magu_on_tour [magu@g230250018.adsl.alicedsl.de] has quit IRC: Ping timeout: 180 seconds
[08:55:43] <Q> ernie: I agree, it might even be better not to have the board involved, since it seems to change every year
[08:55:47] magu_ [mgummi@g230250018.adsl.alicedsl.de] has quit IRC: Ping timeout: 180 seconds
[08:55:52] <dan> i'm thinking organisationally assured places are a good long term storage
[08:56:31] <dan> i don't see the justification for lawers, notaries or the costs of bank vaults to be justified for an encrypted, maybe double encrypted key
[08:57:08] <Q> (board involvement meaning board having access to)
[08:57:31] <Q> dan, agree
[08:57:45] <ernie> dan, is my opinion too
[08:57:58] <Q> dan, I mean, I agree regarding changing boards
[08:58:00] <ernie> we are not speaking from 1-3 years
[08:58:16] <markl> sorry, back
[08:58:30] <dan> i'm sorry i'm back too
[08:58:34] <Q> dan: don't necessary agree on the encryption offering full protection
[08:58:46] <dan> what protection doesn't it provide
[08:59:19] <markl> I think we're likely to fail the very criteria we're seeking to address... an auditor might determine that C.3.d is not met by storing it with community members
[08:59:19] <dan> and there is no full protection - there's only security tradeoffs
[08:59:49] <markl> assurers are RAs in our setup, not the CA, correct?
[09:00:08] <law> community members are not a very good idea I think - they would at least have to be association member I think
[09:00:19] <dan> markl: yes 
[09:00:27] <dan> law WHY!
[09:00:28] <markl> on the assumption that assurers are RAs, they would not meet the criteria of being "stored by the CA"
[09:00:29] <dan> >?
[09:00:45] <markl> RA != CA
[09:00:47] <ernie> law, we are speaking from "organizations/associations"
[09:00:50] <Q> dan: agree, there is no full protection, but we also do not have data on what level of protection such encryption can bring. 
[09:01:12] <ernie> law, how I understand it :-)
[09:01:13] <dan> markl: community members are probably more classed as the orgnaisation 
[09:01:48] <law> CAcert Inc. is audited. Giving the root keys to community members somehow is outsourcing, so this will mean, the root keys leave the control of CAcert Inc.
[09:01:55] <markl> dan: on what basis? (just asking the same question an auditor is likely to ask in the future)
[09:02:27] <Q> law: no, not as long as these are protected in such a way that a community member cannot access the key
[09:02:28] <ernie> law, comunity is part of Inc - community is not a seperate entity
[09:02:32] <dan> there was also an arguement that the certification is run by the community on teh root/structure/conent pages
[09:02:42] <dan> not sure i fully buy it either
[09:02:57] <markl> I can see a way to do it, by creating an agency between the members who hold the keys and CAcert, Inc, making them "part of" the CA
[09:03:27] <Q> markl: well, that way we can at least find out who the holgers and guardians are ;-)
[09:03:33] <dan> markl: we could make sure the keyholders and guardinans are cacert inc members 
[09:03:52] <ernie> markl, creating an agency? could you explain this 
[09:04:49] <Q> dan: question, have you had any feedback from nick or Ian on this?
[09:04:56] <markl> ernie: the legal concept of agency
[09:05:16] <ernie> markl, and who are the agency (which kind of people) ?
[09:05:38] <Q> markl: that would mean costs (to start the agency), money that could also be spend on a bank vault?
[09:05:38] <markl> anyone.. I'm just saying that I can see a possible framework to make it meet the criteria in DRC
[09:05:59] <law> I agree that the community is part of the whole. But when it comes to legal relationships I am not sure this will stand.
[09:06:00] <Q> sorry, not trying to upset you :-)
[09:06:02] <markl> I still disagree it's the best solution, just thinking aloud at how it might work
[09:06:03] <dan> Q: the encryption of pgp and x509 have provided confedentialy encryption reliability for the last 10+ years.  there have been imlementation flaws. the offline status protects the keys from attack (except from the keyholder). they dual encryption option would be very hard to have a compromise due to two flaws acting in jsut the write way.
[09:07:17] <dan> markl: if we need an agency how about we just extend our membership status to those protecting the key in some way
[09:07:23] <markl> the problems I see with this proposal are that it takes three people from a potential pool of 50+ to recover the root, which is, in my mind, too many "sets" of people who may act in concert to disclose the root
[09:07:52] <dan> markl: Q said the same before. happy to make this smaller
[09:07:59] <Q> markl: yes, the trade-off between confidentiality and availability
[09:08:01] <markl> and if you reduce the 50+, you start to seriously impact on recoverability in an emergency, because getting three random people to come to the party quickly will be difficult (and we need quickly, because we potentially need to sign revokations)
[09:08:05] <law> Aye to the minutes (as I wrote them)
[09:08:14] <dan> and its more 1 of 10 and then one of a differenet 50 (or 2 in dual encryption varian)
[09:08:49] <dan> if lower number are desired what do you see as workable?
[09:08:58] <markl> every person you add to the requirements to recover doubles the risk of non-recovery
[09:09:26] <dan> regardless of who they are how they are releated where they are located?
[09:09:35] <markl> and we have no effective recourse against those people to compell quick action
[09:09:52] <markl> yes, because if one of those people from any given set is missing, that set is useless
[09:10:16] <dan> redundancy is the recorse for quick action - and understandin gof obligation
[09:10:25] <markl> so, pick three people from three countries... you now have about 60 days of the year in which any one of them might be observing a national holiday, on summer vacation, etc
[09:10:43] <markl> right, but an understanding of obligation may not pass muster
[09:10:57] <markl> we have an obligation to be able to quickly sign revokations.. lets take the situation of the theft of our signing server
[09:11:04] <dan> why do you assume the people we entrust are going to maliciouly do something bad? whoever we entrust can do something bad.
[09:11:40] <markl> dan: I'm not?
[09:12:00] <markl> but to ignore it as a possibility would be crazy
[09:12:20] <Q> dan: we have a limited number of active members.
[09:12:22] <law> I also do not like the idea of any person holding the whole root key. I somehow like the idea of SSSS - maybe this could be combined.
[09:12:24] <dan> right - i'm seeing the possibilty fairly equally likely whoever we do.
[09:12:31] <markl> especially when we'd be capped at recovering 1000EUR
[09:12:56] <dan> cost recovery or the threat of it doesn't gain us anything. 
[09:12:56] <Q> dan: and we entrust them, but always keep in mind that they might make a mistake
[09:12:56] <markl> dan: well, that's not entirely true... lawyers, notaries, banks, etc all have more compelling, more costly than EUR1000 reasons to keep our trust
[09:13:18] <Q> dan: I disagree
[09:13:32] <Q> dan: if we loose our root cert, we are gone!
[09:13:42] <dan> law: SSSS would be good it it had fully defined procedures around it.
[09:14:34] <dan> can we contract the holders for more liability ?
[09:14:40] <Q> Can you ensure that no one of the entrusted group will take a 10000 offer to provide info, when they know all it would cost them is 10%?
[09:15:00] <markl> the whole commercial world works on cost/benefit... a bank takes our storage with them seriously, because failing to do so would jeopardise their customers' trust, a lawyer doesn't want to screw us because he could face disciplinary action, etc etc.. and each of these entities carries professional indemnity insurance, and are capable of being sued if they mess it up
[09:15:17] <dan> the cost for lawyers, bank, notaries etc isn't much since they are insured
[09:15:57] <markl> dan: not exactly true, because they have to pay their insurance premium next year, but even still, it gives us an effective avenue to recover the large costs of a mistake
[09:16:09] <dan> banks have breaches all the time and manage them quitely as a good cheap business practice
[09:16:14] <Q> Dan: I don't think we would find many vvolunteers if their liability goes up. That's the wrong approach, we need something that's inherently safe, so we don't need a higher liability
[09:17:00] <markl> there are two sides to any discussion of this type... first is "is the solution secure enough?", the second is "what will we do if "secure enough" turns out to be "not secure enough"
[09:17:16] <Q> all: looking at the discussion, I have the feeling that although we're only discussing one proposal, the one that's seen as the best so far, it's not yet good enough
[09:17:22] <markl> even assuming entirely good motives of everyone, everywhere, we still must consider the second part
[09:17:51] <markl> Q: I think we might be on to a more philosophical discussion now, about who to trust and why...
[09:17:55] magu [mgummi@f054012060.adsl.alicedsl.de] has joined #board-meeting
[09:18:02] <Q> I also miss the input of two board members
[09:18:24] <dan> Q: like you they have had a month to comment
[09:19:03] <dan> markl: yes you're right - it is a very value based decision as to who to trust an why
[09:19:05] <Q> dan: I agree, but it also does not seem correct to vote
[09:19:28] <Q> dan: even though we all should have had enough time to respond
[09:19:45] <Q> dan: because this is vital for CAcert
[09:19:50] <dan> markl: they same procedures can use two "trusted" parties however define if required
[09:20:02] <markl> Q: they have the opportunity to vote on anything we vote on here for three days, too
[09:20:14] <dan> s/define/defined/
[09:20:15] <Q> markl: that's true
[09:20:21] <markl> why can we not just store the root on a separate secured system under cacert's control?
[09:20:43] <markl> I presume this is how larger CAs do it?
[09:20:43] <dan> i'd be happy to give them a week or two by putting a vote up
[09:21:16] <dan> markl: because it fails z.4 which ian pu tup
[09:21:30] <markl> we have an existing agreed upon access control policy for systems
[09:21:34] <markl> what is z.4?
[09:21:46] <dan> z.4 The Board must be able to recover the root independently of the critical team.
[09:21:56] <markl> it can
[09:22:02] <markl> it can override the critical team
[09:22:03] <Q> not really
[09:22:20] <Q> who of us would be able to access the secured system?
[09:22:42] <markl> legally capable of access is not the same as physically capable of accessing
[09:22:57] <markl> being legally capable of access means the ability to *force* the phyiscal ability to access
[09:23:03] <Q> ok, so what is needed: logical ot physical?
[09:23:32] <markl> legal access, surely.. because we wouldn't have physical access under most of these proposals
[09:24:27] <markl> we have legal control over the physical access... ergo we have indirect physical access
[09:24:28] <dan> how are we going to resolve this month old question?
[09:24:50] <Q> dan: that's my problem right now.
[09:25:02] <Q> Don't want to extend the discussion with another month
[09:25:26] <Q> But I also see too much discussion at this point to continue
[09:25:26] <markl> having a second signing server would address all the DRC, and all the z.X criteria
[09:26:10] <ernie> markl, and how often you will test / change system ... a system will not work for ever
[09:26:14] <dan> markl: want a week to write up that propsal with costings and procedures?
[09:26:14] <markl> we also have to address what it means to us to have an "offline" root
[09:26:34] <markl> ernie: same method we must use to the test the primary offline root
[09:27:11] <ernie> markl, and did you think one system id enough?
[09:27:15] <markl> dan: sure, I'll take a stab at that, but we need to consider a threshold question too... that of the offline root
[09:27:17] <dan> "offline" is whatever we choose it to be.  we'll just be assessed on it. various degrees of offline will be assessed differnetly depending on what an auditor decides
[09:27:57] <dan> as long as we don't need to generate crls for subroots there is no need to have any operational status for the root
[09:28:29] <markl> right, so in theory, we should not need to use the root other than in the manual process of issuing new subroots
[09:28:34] <ernie> dan, good idea - one week, but once we must find a solution
[09:29:07] <dan> markl:  and a OCSP cert but yes - right.
[09:29:28] magu_on_tour [magu@f054012060.adsl.alicedsl.de] has joined #board-meeting
[09:29:42] <markl> so, to have "offline root machine #1" and "offline root machine #2" in physically separate locations (physically separate could mean different room at the same facility, or even different rack), would seem to satisify all of the criteria
[09:30:06] <dan> i'm happy to accept that as offline
[09:30:31] <Q> I move we pospone the decision until the next board meeting, to enable everyone to review the current proposals and/or come up with a new one
[09:30:44] <markl> Q: works for me
[09:31:04] <dan> also as an action item I propose that any problems with the multi member escrow be raised with what you perceive as potential solutions
[09:31:31] <markl> I think I raised all my concerns in the minutes
[09:31:33] <Q> dan: that was implied by *review* :-)
[09:31:46] <dan> markl: yes but no solutions
[09:31:47] <Q> Not just delay
[09:32:03] <markl> yes, my solution is an alternate proposal :)
[09:32:05] <dan> or not full soltions anywya
[09:32:37] <markl> I think the multi member escrow is fundamentally flawed, and is likely to cause us audit headaches
[09:32:58] <markl> but I like it as an idea, but I just don't think it'll work for the root
[09:33:21] <ernie> and it should be great, if people have enough time to think about new proposals (if there are made some)
[09:33:47] <Q> So, do we all agree we'll do (a lot of) homework and be ready next meeting?
[09:33:48] <Q> (I'm sure dan has spent a lot of time on this, so it needs our attention)
[09:34:09] <markl> yes, it definitely needs our attention
[09:34:15] <dan> ok -i'll look at your issues raised and see what solutions i can come up with. if i understand correctly you favour banks/notaries/laywers and they could be a holder of some sort
[09:34:35] <markl> dan: no, I actually favour backing it up on a second signing server, and not involving anyone else
[09:34:56] <dan> ok moving on?
[09:35:09] <ernie> next meeting a decision sounds good
[09:35:26] <dan> anyone want to address a second oophaga letter?
[09:35:28] <Q> Good
[09:35:47] <Q> That would bring us to 2.2, questions 
[09:35:56] <dan> can that be my question?
[09:36:07] <Q> Go ahead
[09:36:39] <dan> is the second letter that i drafted with the nicer more accurate wording from wytze acceptable? if not why not?
[09:37:05] <ernie> in my opinion it is acceptable
[09:37:19] <Q> Here I have to apologize again, I promised to resp[ond
[09:37:34] <Q> seemed acceptable, was thinking about wording
[09:37:34] <markl> I don't have a problem with it, but I think Mario made a good point, that we should try to start more informally
[09:38:14] <ernie> to send by email is for me ok 
[09:38:33] <dan> i'm ok with that - mario want to send something informally and cc us?
[09:39:27] <ernie> I think it must come from all, and not from a single person - think lambert will be here the better way
[09:39:35] <ernie> since he will live in the same country
[09:39:47] <dan> and after lambers comments I'll  redraft something formally
[09:40:12] <dan> lambert's* -sorry slack figers
[09:40:14] <ernie> and lambert could also once maybe get in touch more informally with them
[09:40:39] <law> I am fine with the points addressed but not like the wording - at least as it seems to me. I can draw up a more informal version if it is what we agree on and send it to the private list.
[09:40:50] <Q> I will send my feedback asap, however, that could be Tuesday
[09:40:58] <markl> I think we need to consider ways to better involve Oophaga on a more regular basis, to "connect" them more to us as a community
[09:41:26] <markl> because they've kind of taken on the role of simple "supplier of services", rather than what I understand the original intent was, to be more of a partner
[09:41:29] <Q> (I was happy with the proposal for the second letter though!)
[09:41:37] <dan> law: i'm happy for you just to send it - cover the general principles roughtly and not in depth and i'm happy
[09:42:12] <ernie> the second version was for me ok
[09:42:16] <dan> (ref informal email)
[09:42:31] <Q> I intend to contact them as well more informally: talked to one of the Oophaga people (on a totally unrelated issue) and got some informal feedback
[09:42:37] <dan> ernie: ok i'll try to keep it as close as possible - depends what Q says thoguh
[09:42:51] <ernie> :-)
[09:42:59] <Q> dan: don't expect big changes
[09:43:10] <dan> good :-)
[09:43:13] <u60> about informal infos to oophaga ... we have the board projects (started by ernie) and we have the community updates ... probably should be sent also to oophaga ?!? as informal updates ?
[09:43:17] <law> OK. I will read over it once again on comment more on the points.
[09:43:40] <ernie> u60, my list is not finished 
[09:43:46] <Q> I think a call or meeting would be good
[09:44:12] <Q> seems Ian's call was also appeciated, just let them know we exist and remember them :-)
[09:44:14] <dan> ernie: so whats the plan for the project list after its done?
[09:44:14] <u60> ernie: yup ..  but its WIP ... so updating is a good option for openess
[09:44:28] <dan> i hope people have seen it - it looks good
[09:44:51] <ernie> dan, to be able to search better for volunteers 
[09:45:09] <u60> its the all groups workpace ... and interface between groups and board
[09:45:27] <ernie> dan, that not everybody means, he is only welcome for big task, we have a lot of other not tech-related tasks
[09:45:30] <u60> and also the overview for i.e. oophaga to see move on
[09:46:20] <ernie> dan, and to have somehow a overview what is going on - with the links to project-sites
[09:46:48] <dan> ok -just checking - going really well btw - i'm liking it a lot
[09:47:10] <u60> ok, question time continued ?  I have one ;)
[09:47:25] <Q> Uk Uli, go!
[09:47:37] <Q> (UK=Ok)
[09:47:44] <dan> if you noted them before the meeting we'd think about it better though
[09:47:51] <u60> about PO i've sent a mail in board-mailing list, but didn't read a reply yet
[09:48:18] <u60> what do you think about my proposal ?
[09:48:25] <dan> i didn't respond because ian can make his own nomination if he wants to
[09:48:50] <u60> Ian is more offline than online currently ....
[09:49:08] <u60> so my question goes to you: the board
[09:49:09] <dan> its not like the position is going to disappear
[09:49:11] <markl> yeah, any further discussion would be contingent on Ian being willing to accept :)
[09:49:12] <ernie> and what I see here, we also try to find more people there - it takes a lot of time to do all - and one person will not have nomally
[09:49:13] <Q> does it have to be decided now?
[09:49:36] <ernie> Q, what?
[09:50:01] <ernie> Q, if you mean PO, I think not
[09:50:09] <u60> I think, it doesn't have to decided now, but a PoV will be great ;)
[09:50:25] <dan> no -  it doesn't need to be decided now. I'm not keen on deciding now.
[09:50:28] <Q> U60: I agree that Ian has been very valuable in "managing" the policies, but he needs to nominate himself and accept
[09:50:37] <Q> ernie: yes
[09:50:40] <ernie> we need more volunteers for policy and documents review ( there are a lot of outdated ones)
[09:50:41] <law> If Ian has the time to do it, I think he should get the job.
[09:50:51] <dan> my PoV is the same as ernie -there's lots to be done and I don't think putting one person in the position is enough
[09:51:01] <law> But I would also welcome someone who is not that deeply involved for now.
[09:51:01] <markl> my personal PoV is that anyone who has the requisite skills for policy officer steps up and puts their name forward, I would look very favourably on
[09:51:12] <Q> markl: agree
[09:51:39] <u60> there are other candidates avail ?
[09:51:42] <ernie> markl, agree - nobody will be keep away do to something in the polcy group
[09:51:42] <markl> but no one has, so far...
[09:52:16] <dan> i did get one email late last night - i'll forward it to the board
[09:52:18] <ernie> maybe we never communicated 
[09:52:42] <ernie> that we are searching for volunteers in this part
[09:52:43] <Q> U60: it seems the board is willing to accept anyone who has the required skills and time. We know Ian has the skills.
[09:52:51] <markl> and if you feel more than one person would be suitable, put forward that as a proposal, a policy officer group or something.. being it's such a crucial task, I would personally favourably consider a proposal like that too
[09:53:00] <Q> Any other questions?
[09:53:15] <dan> markl: time for email catch up - i did :-)
[09:53:18] <ernie> Q, but what I will see for longtermn, it is better to have a team there not only one
[09:53:31] <u60> one info: software assessment moves forward
[09:53:40] <markl> dan: put it on an agenda then so we can discuss it! :)
[09:53:52] <dan> k i will
[09:53:55] <u60> see wiki:Software/Assessment  page and Board group overview :=
[09:53:57] <u60> ;)
[09:54:06] <Q> ok, any other question?
[09:54:21] <u60> not from my side
[09:54:31] <dan> none here
[09:54:46] <Q> Ok, meeting closed
[09:54:53] <Q> Thanks everybody
[09:55:02] <markl> thanks all
[09:55:20] <Q> btw. Next meeting 2010-04-03 22.00 UTC

Original meeting transcript in SVN

Categories:

CategoryBoardMinutes

Brain/CAcertInc/Committee/MeetingAgendasAndMinutes/20100321 (last edited 2010-07-20 06:55:31 by SunTzuMelange)