Skip to Content.
Sympa Menu

cacert-policy - SGC key usages

Subject: Policy-Discussion

List archive

SGC key usages


Chronological Thread 
  • From: peter williams <home_pw AT msn.com>
  • To: <cacert-policy AT lists.cacert.org>
  • Subject: SGC key usages
  • Date: Sat, 9 Oct 2010 19:45:17 -0700


Nothing to do with the topic, but the EE signing/clientauth cert in the mail
Im responding to (see RFC822 headers) has SGC oids in the key usages (see
http://support.microsoft.com/kb/290388)

What do these mean and what do they do, in this context?

They used to induce an SSL client to invoke a special double handshake in
SSL (when presented by a server) - which invoked certain special security
semantics for session creation and resumption (that were exploited to
auto-enforce some legacy US export controls).


-----Original Message-----
From: 
ulrich AT cacert.org
 
[mailto:ulrich AT cacert.org]
 
Sent: Saturday, October 09, 2010 7:09 PM
To: 
cacert-policy AT lists.cacert.org
Subject: AW: AW: CCA 3.4 in the green? -> CCA-Rollout

Hi,

>> keep topic 3.4 intact
>> remove comment in green ;)

>> so here we are on track to remove the green part ;)

> What I'm more pointing out is that CAcert has moved a long way since
> those times, and modern agreement techniques also have improved.  We
> should be capable of avoiding a mailout every time a minor thing
changes.

hmm ... I expect a change of CCA not every month ...
once a year or two ... ?!?


> When that sentence was written, we had no effective internal (community)

> governance control.  So the mail-out requirement was a protection
> against changes against our interests;  it assumed a closed, secretive
> board that had control of all decisions including policy.  Which, in a
> nutshell, was the 2006 problem.

the members notification on contract changes is an essential part
in every business ... so CCA changes are for CAcert ....
if its by mailout, or by notification on service usage
(eg. issue certs) doesn't care ....


> Now we're in 2010.  Now we have a very strong governance in this group,
> as one of the things was that 2007 board passed all control to policy
> group with PoP.  We can rely on the policy group to look after our
> community agreement.  Also, the software is ready to be unleashed and we

> can put the ability for change notification in there (if you're using
> the certs, you'll find out when you re-issue!).

> And this is a change that arguably *should be done before the 1st
> mailout* ;-)

so a CCA revision handling should be integrated here ...
Agreed on Rev 2007 ... Agreed on Rev 2010
If a new revision comes in effect, each member has to agree
again ...

suggestion for practicle deployment (not to be written into CCA)
This can be a 2 step process ...
As I understand, revision changes needs a fixed date new revision
comes to effect ... a day in the future ...
so a 2 months phase is to reset the old revision level so members
have to agree on the new revision for 1 month by system services
usage and a 2nd phase with mailout for members who didn't agreed
onto the new revision yet ...


> iang

regards, uli   ;-)




Archive powered by MHonArc 2.6.16.

Top of Page